Networking the QL and ZX Spectrum - updated guide (Part-1)

[Martin_Head]

Hi Martin!

To be honest, if the ULA access contention of your Iss5 turns-out to be the primary cause of the problem, I don't think tweaking the Timing Constants or the TK2 code itself will fully overcome the issue, though if anything would help it might be to very slightly reduce the timing-constant 'ndt_rdly'.

I assume no (super)Gold Card is fitted and that your TK2 is in ROM, in which case any changes to that timing-constant requires to patch (a single byte) and re-flash your EEPROM. And it may still not help a great deal.

To get my Iss5's NET working more consistently, I ended up hacking the board and adding a GAL to effectively bring the 8302 on to the CPU side of the bus, like it became in later issue boards. A nasty hack, but effective...

We could pick-up this thread via email, if you do want to pursue it.

M.

Hi Martyn,

Thanks for that. It's not a great problem, as I only get my actual QL's out if I need to do something special. At the moment the offending QL just has a post-it note stuck on it saying the network is iffy.

If this is a ZX8302 problem, it might be nice to know if it's a particular date coded chip so they can be identified.

I have a spare QL main board, and a re cased QL that has a faulty ZX8302, but I don't know off hand the issue numbers. So I might be able to swap out this particular main board for another.

[martyn_hill]

Hi Peter!

Before we put further thought into this: Wouldn't a third physical network layer in addition to Ethernet and QLNET fragment development and user base too much?

Possibly so - but I would fully support any out of the box thinking in regards to developing QL networking, especially if we could overcome the inherent speed limitations of the QLAN hardware design to a point where multi-node computing could evolve!

[martyn_hill]

Hi Martin!

If this is a ZX8302 problem, it might be nice to know if it's a particular date coded chip so they can be identified.

I haven't consciously noted any problems with specific builds/batches of the 8302 itself - the issue I have seen is due to the mobo itself and how the Iss5 places the ULA 'inside' the private data-bus of the main 8301 ULA alongside video RAM access and the access contention that results.

I have a spare QL main board, and a re cased QL that has a faulty ZX8302, but I don't know off hand the issue numbers. So I might be able to swap out this particular main board for another.

That might be your better route to eliminate the issue, assuming the spare mobo is an issue 6 or later, where the 8302 is finally placed directly on the CPU data-bus.

M.

[Peter]

Possibly so - but I would fully support any out of the box thinking in regards to developing QL networking, especially if we could overcome the inherent speed limitations of the QLAN hardware design to a point where multi-node computing could evolve!

I think something like 1 Mbit/s makes sense with the original QL while still allowing usage of cheap audio cables. The LVDS network could be implemented quite QL-style by using a stereo jack instead of mono. Stereo audio cables even seem easier to get these days. Termination by integrated switch as usual.

Unfortunately, it's now too late to nicely integrate in QIMSI. At design time, I was not sure whether digital video would work well enough to allow re-dedication of the VGA pins.

Sorry I forgot the data rate you had reliably achieved Q68-to-Q68 over the singlewire QLNET. What was it again?

[martyn_hill]

Hi Peter

Sorry I forgot the data rate you had reliably achieved Q68-to-Q68 over the singlewire QLNET. What was it again?

With the latest ND-Q68 driver (v1.18) I can reliably connect Q68's/QZero at 8x the nominal Sinclair bit-rate - c. 700 kbps. That's what I demonstrated at last summer's event in Dormagen...

I think there is still a bit more we could squeeze out of the driver, given some further refinements I made to the Spectrum Next/QL-Core driver (which I based squarely in the Q68 driver.) The Next doesn't hit the same rate as the Q68 for other reasons, but should manage about 4x the std bit-rate with a bit more coaxing...