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.