ZXLINK driver for PC
ZXNet echo conference «code.zx»
From Kirill Frolov → To All 30 July 2000
Press RESET immediately, Aleksandr!
30 Jul 00 09:36, Kirill Frolov wrote to Aleksandr Majorov:
More than one Spectrumist has already connected his Spectrum with wires to the PC,
but the connection diagrams are often different and you have to write and use them yourself
various communication programs. I propose to develop one for everyone
subject,
which will allow the use of the same communication programs and increase
their quality.
Do you really need a ms-dos driver, and not just some dll? I don’t
I'm sure
Most likely you still need a dll. Simply, with any access to parallel
port from one VM it is blocked for all other programs (blue
death window with the question "allow access?"). This is true in WIN'98. I'm not sure that
this can be overcome with the ms-dos driver from config.sys, but there are no other options at all
I see, but I wish they could
run 2 programs from 2 VMs in parallel through different channels. When I
prescribed
your fossil in config.sys it was available to everyone, but the blue screen of death still
appeared :-( That is, the fossil code was executed in the context of the task that called it,
and I need the driver code to run in the context of the kernel. I hope I understand
expressed himself.
I hope it’s clear why it’s MS-DOS driver and not VXD - MS-DOS
emulated
In other OSes and the ms-dos driver it is much easier to do. I just created the VXD structure
notI present. Among Spectrumists there are many OS/2 and Linux users,
this is
Another plus in the direction of the ms-dos driver, and not windows.
I have already indicated the necessary driver functions in the previous letter, but
I repeat, this is:
1. Opening the device.
2. Closing.
3. Transferring data to the port.
4. Receiving data from the port.
5. Collecting statistics and obtaining information, versions.
I propose to organize the logical structure of the transmission channel in the form 256
ports available for reading and writing on both sides (ZX and PC) and independent
among themselves. This is necessary for the simultaneous operation of several
independent
programs: for example MMD, modem emulator simultaneously and support for virtual
TRD drives at the same time. Each port must provide reliable delivery
data to the other side of the channel or report an error. Data structures
I propose to organize those transmitted through the port as a list of blocks of information
(length, data), during transmission, block boundaries and lengths must
be preserved
This is necessary primarily for the correct functioning of the MMD. However, in
some
In some cases a byte stream type channel may be required and so I suggest
128 ports for transmitting information in blocks and 128 ports for transmitting bytes
flow. I am not yet considering the implementation of the program interface on the Spectrum.If you don’t see any shortcomings in the above model, then I’ll try
quickly start working with the technical implementation of the driver. I'm planning for now
use
The ms-dos method of calling the driver and passing parameters. It's unclear
only
how to transmit information about the number of the currently used port. If you do
in a non-standard way, then the possibility of standard ways of working will be lost
with driver from dos. But this is probably the only way... I’m still thinking
convey
the number of the port used in 'element number' (byte +1 in the request header).
Presumably used driver functions:
00h -- initialization.
06h -- status (ready).
07h -- clearing of the reception queue.
0bh -- clearing the transmission queue.
04h - reception.
05h -- non-destructive reading from the receiver buffer.
08h, 09h -- transfer.
0dh -- open.\n
0eh -- close./ use is not specified yet.
driver device attribute: 1010100000000000 (character, non-ibm,
open/close).
It’s not entirely clear what to do if there is a read request to the driver
the number of characters is greater than is in the buffer - in this case I suggest
return error 01h and indicate the real number of characters in the counter
read from the buffer. This is for ports working with a byte stream.For ports working with a list of blocks, I suggest not setting the error,
but read the first block in the queue from the buffer and return its length in the counter
requested bytes. Function 05h for 'block' ports returns the first one in
block list Open and Close are just stubs for now.
More precise technical details will only be determined after
I'll start writing a 'skeleton' of such a driver that can easily be remade
for any method of connecting the ZX to a PC to obtain a full driver.