QL net - is it worth redoing ?

[Nasta]

Ql net is extremely simple. On the QXL IIRC it was completely software based. Most of the needed circuitry fits a small CPLD.
It's just a shared line with pull-down. Oddly enough, a slightly more complex circuit with current drive like old style coax ethernet would have done a far better job.
Even so, it's UART based. AFAIk no hardware collision detection was implemented (although it would have been easy to do - the NET port simultaneously outputs and inputs data, comparing output to input under a proper protocol would have been enough to detect collision).
The main problem is no galvanic isolation. Which brings us to a different idea - using IR instead of wires. Not to difficult, I'm sure you can figure it out

[EtchedPixels]

Are the correct voltages and currents and hardware signals documented anywhere for this. I've found the documentation for the protocol at the higher level but nothing on the voltages and raw encoding/clocking.

It looks an ideal way to get stuff to and from a QL without doctoring the QL, or fitting a rare interface to an ever more unreliable bit of rotating rust. The performance requirements seem well in the grasp of a current $5 microcontroller and easily met by a cheap FPGA board. In fact I think my 128MHz Z80 FPGA box could probably bitbang it while doing SD card I/O 8)

Alan

[tofro]

There's not much to document - It's plain TTL, 0V/5V.
The bit rate is 87.5kbps, and it's not quite what a standard UART would expect or send (collision detection requires a bit of fiddling)

And yes, both the Spectrum and the QL (and the QXL) simply bit-bang the network. So anything >3.5MHz should be able to do it

I am currently working in this direction every now and then when I have a bit of free time.

Tobias

[EtchedPixels]

There's not much to document - It's plain TTL, 0V/5V.

That's promising, so old PC parallel port pin and a diode providing the PC end doesn't want to do any listening, or with an input pin to the same line if it does.

[tofro]

The problem is rather - You need to be able to send and receive on the same pin in order to enter the network - That's the tricky bit that's needed for colission detection. Also, I would rather not go for the parallel port - That's a dying breed....

Tobias

[EtchedPixels]

The problem is rather - You need to be able to send and receive on the same pin in order to enter the network - That's the tricky bit that's needed for colission detection. Also, I would rather not go for the parallel port - That's a dying breed....

Tobias

Parallel port is handy for hacking initially.

I'm not sure I follow "send and receive on the same pin". You sense the bus then if need be turn your signal two cpu instructions later. Wiring the bus to the parallel port input to sense and via a diode to a parallel port output to signal ought to work no ? Should be good enough for the basic PC-QL cable problem anyway.

For the simple case I'm not sure you even need a receive pin to download software to the QL. You know the exact sequence the QL will follow so providing you set the QL loading then hit "go" on the PC end all should be fine 8)

Alan

[tofro]

That would work.
Note you need to have a port that leaves the bus alone on "0" (i.e /not/ pulling low) for it to work.

Maybe the diode is not so a good idea - That's going to pull the whole bus down by 0.6V which might be disturbing other stations. For a 1:1 connection, it might work, however.

My approach uses a Cypress PSOC4 (ARM-based µC with USB that can be had for a few €) to connect to the network.

In case you want to dig deeper, the Spectrum Microdrive Book, the TK2 manual and Minerva sources can be used to re-engineer the protocol (Or you can ask me , although I have not verified everything so far)

Note the protocol is always 2-ways, i.e you really need to follow it properly, even if you are only transmitting to the QL.

Tobias