QL Net server to back-up Spectrum files?

[martyn_hill]

Hi again Mike

OK, so I've reviewed the ROM image of TK2 v2.23 and have identified the relevant offsets for the three critical 'timing constants' that I have observed allow better (if not 100% perfect) comms between a BBQL (+TK2) and Int-1/Spectrum.

You can open your existing TK2 v2.23 ROM binary image file and edit it within any HEX editor of your choice and find the relevant timing constants using the table below (each one is a byte value) and manually patch the bytes with the recommended values (use OVERWRITE mode, and NOT INSERT mode!). Save those changes to a fresh 16KB image and burn to a spare 16KB EPROM (erasing first, if your EPROM has a UV window.)

All values are shown in HEX and the offsets listed are from the base of the 16KB ROM.

Bear in mind that this change can break comms between this QL and other QLs, etc, unless you make a corresponding change to those other network stations.

If it still doesn't allow comms between your US QL and Spectrum, there may be something else at play, but my own experience leads me to feel pretty hopeful

Code: Select all

TK2 v2.23 (ROM) - Adjustment to suit QL to ZX Net comms

TC name     Offset  Default For ZX  Comments
========    ======  ======= ======  ========
ndt_send    0x3596  EC      E0      Adds 0.53us to each Bit-cell during SEND, using the formula: E0 + (x * 2 * (x<>8)) for values of x: 1..8
ndt_rdly    0x35D5  0E      14      Adds 1.6us to the delay from detection of START-bit to reading Bit-0 during READ
ndt_rbit    0x35DD  08      0A      Adds 0.53us to each Bit-cell during READ

[martyn_hill]

Hi again Mike!

Just curious as to whether you were able to try thoseTK2 ROM mods and what the outcome was, if so?

[bwinkel67]

So I couldn't re-program my TK2 EPROM (it was the only spare I had)...wouldn't take for some reason. I ordered a bunch more from AliExpress, which will get here in July. I'll post as soon as I find out if it works. Thanks for all the help.

In the meantime, I've been keeping busy with this beast:

[tofro]

Oh, be careful: Those old boxes can be death traps.

[bwinkel67]

Oh, be careful: Those old boxes can be death traps.

I will avoid my tongue-test technique for checking live connections :-/

Right now I'm refurbishing the case...I got all that putty on the screen off. It slowly melts with water but is very sticky and gummy otherwise. It took a long time to remove it form the wooden case. Now I'm re-gluing parts of the case. Then on to check the tubes (one is missing), and finally replace all those capacitors. After all that, I will plug it in, step far away and turn it on...likely while outside.

[bwinkel67]

Hi again Mike!

Just curious as to whether you were able to try thoseTK2 ROM mods and what the outcome was, if so?

Hi Martyn,

The EPROMs finally arrived and I made the timing changes to TK2 v2.23 and got it to work both ways (sending and receiving). Pretty cool to see it copy a file from one machine to the other's screen.

I haven't explored it any further at this point, but that's the plan. Can you save a Spectrum file onto a QL microdrive and then load it bac? Can you do directory listings? I have a book and need to read up on it. Just wondering how integrated you can make the two machines.

Mike

[XorA]

Hi again Mike!

Just curious as to whether you were able to try thoseTK2 ROM mods and what the outcome was, if so?

Hi Martyn,

The EPROMs finally arrived and I made the timing changes to TK2 v2.23 and got it to work both ways (sending and receiving). Pretty cool to see it copy a file from one machine to the other's screen.

I haven't explored it any further at this point, but that's the plan. Can you save a Spectrum file onto a QL microdrive and then load it bac? Can you do directory listings? I have a book and need to read up on it. Just wondering how integrated you can make the two machines.

Mike

Should get those rom images on dilwyns site!

[martyn_hill]

Hi Mike!

The EPROMs finally arrived and I made the timing changes to TK2 v2.23 and got it to work both ways (sending and receiving).

Glad to hear that!

Pretty cool to see it copy a file from one machine to the other's screen.

Fun, isn't it!

Can you save a Spectrum file onto a QL microdrive and then load it bac? Can you do directory listings? I have a book and need to read up on it. Just wondering how integrated you can make the two machines.

Ok, so that's where it gets a bit more involved. Towards the end of that article I mentioned before you'll find some clues, but to really facilitate the transparent use of the network between the two diverse platforms, you need a fair bit of 'glue'.

I have developed an FTP like client/server application that takes the core ideas presented in the ZX Microdrive & Interface 1 manual and builds on it.

Now you've got your machines talking to each other properly, I'll share the 'QServer' application (both QL and Speccy ends) once I've tidied it up a bit. Give me a couple of weeks...

M.

[bwinkel67]

The EPROMs finally arrived and I made the timing changes to TK2 v2.23 and got it to work both ways (sending and receiving). Pretty cool to see it copy a file from one machine to the other's screen.

Should get those rom images on dilwyns site!

I can do that. Should the version number be changed? Maybe v2.23t (t for timings)? Or v2.23b? Or incrment to v2.24?

Edit1: I see on Dilwyn's site that there is a newer version of TK2 that may already have improved timing in there (though I haven't tried it):

• tk232_net_rom.zip

So if the number doesn't need to change, here is a zipped version of v2.23 with the network parameter timings changed. I'm calling it tk223_zxnet_bin to clarify that the network timings are tweaked for the Spectrum network. The _bin vs _rom I didn't touch as the original TK v2.23 from Dilwyn's site used the _bin extension even though it is for burning a 16K EPROM (so it seems _bin/_rom are used interchangeably). This can obviously be renamed as best fits a common naming scheme.

Updated readme.txt and included clock.bin:

TK223-ZXNET-16K.zip

(14.28 KiB) Downloaded 152 times

Edit2: I think the reason I used v2.23 is because it clearly stated on Dilwyn's site that it could be burned to EPROM. It wasn't 100% clear to me weather any of the v2.32's could (the respr version could be loaded into memory, but I'm not experienced enough to understand if that then could also just be burned to an EPROM).

[martyn_hill]

Hi Mike!

Marcel created a couple of distinct v2.32 ROM image builds, with at least one including the NET driver 'physical' routines that need the zero wait state offered by running in ROM. The distinct builds offload a portion of TK2 to be loaded into RAM (some parts like 'ED', that aren't sensitive to timing) as v2.32 won't fit 16KB in it's entirety. Check out his blog for details.

For those lucky enough to host TK2 in non volatile RAM, it's a trivial procedure to switch between QL and ZX timing as needed.

For anyone interested in why the timing changes are needed, in fact both platforms run nominally at 11.2/11.4 microsecond bit-rate, which on paper should be within tolerance of one another.

However, due to ULA Contention on the Spectrum, every now and again, during the active part of the Speccy's video output, there are a small number of byte values that will get 'extended' when being sent from the Interface-1 - and this periodic extension of the byte frame can be misinterpreted by the receiving QL.

Even then, it depends on precisely when the QL driver 'detects' the falling edge of the START bit, and the combination of this margin/ambiguity (around 1-2 us), plus the occasional extension of the byte frame due to the Speccy's ULA Contention, it's enough to corrupt the received byte and cause the check summing to fail for that packet.

By extending slightly the timing constants at the QL end, we can find a happy medium that accepts both nominal and 'extended' byte frame timing sent by the Speccy.

It then begs the question, why Spectrum to Spectrum comms doesn't seem to be affected. To understand that, it helps to know that the Int-1 ULA includes START-bit detection in hardware (effectively adding wait-states to the Z80 OUT [EDIT] instruction), giving more precise/less ambiguous timing of the detection of the all-important falling edge of the START bit.

This also explains why the Q68 (with the ND-Q68 net driver), as well as faster QL processors such as in the GC/SGC and QXL seem to accommodate the Speccy's slightly wobbly timing without modification - the delay in detection of the START bit is much less than on a 7.5MHz QL...

There are other Net related bugs in the Spectrum Shadow ROM that can cause other problems, but that's on receiving. I've developed fixes for all these issues in the Shadow ROM, but it's such a chore to replace the ROM neatly inside the Int-1, that it proves much easier to get the majority of the benefit by fixing at the QL end...

Happy Networking!