Hello & help needed with QL networking and TK2

Helpful tips and guides, also new users can ask for help here.
jll745562
ROM Dongle
Posts: 15
Joined: Wed Apr 10, 2019 2:15 pm
Location: Ynys Mon

Re: Hello & help needed with QL networking and TK2

Post by jll745562 »

Martyn,

I'm using the Minerva 1.98 ROM that was provided by Tetroid's ROM switcher - I'm assuming it must be the unpatched version. I'll just have to stick with the JS ROM at the moment.
Unfortunately, I can't burn a newer version of Minerva as my (home made) EEPROM programmer can't handle the 512Kx8 ic that the ROM switcher uses.

Nevertheless, I can still have a go at the FSERVE protocol - I start looking into that maybe next week.


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: Hello & help needed with QL networking and TK2

Post by martyn_hill »

jll745562 wrote:I'm using the Minerva 1.98 ROM that was provided by Tetroid's ROM switcher - I'm assuming it must be the unpatched version.
That's likely - I don't believe the I/O Fix version of 1.98 was available when Tetroid was building his multi-ROM (I have one of those too - very handy device.)
jll745562 wrote:Nevertheless, I can still have a go at the FSERVE protocol - I start looking into that maybe next week.
Without wishing to put you off in any way - the FSERVE code is quite a step-change in terms of complexity - one of the reasons why I designed the QLUB adapter only to implement the wire-level protocol and leave everything else to QDOS & TK2...


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: Hello & help needed with QL networking and TK2

Post by martyn_hill »

Hi Norm!
NormanDunbar wrote:Lots of good stuff here Gents, anyone fancy writing something for the Wiki? (https://qlwiki.qlforum.co.uk)
It's always been on my to-do list - once I've completed the QLUB adapter project that embodies much of what I've learnt on the topic over the past few years...


jll745562
ROM Dongle
Posts: 15
Joined: Wed Apr 10, 2019 2:15 pm
Location: Ynys Mon

Re: Hello & help needed with QL networking and TK2

Post by jll745562 »

Hi Martyn,
martyn_hill wrote: - the FSERVE code is quite a step-change in terms of complexity -
Yes, I suspect that I won't be able to make any great inroads into how that protocol works. Only having one QL makes 'snooping' the network traffic a somewhat one-sided affair!, plus my knowledge of 68000 assembly is rudimentary at best.

If you don't mind, I do have another question about the network protocol regarding the scout period:
- I've noticed that the scout appears to have some data encoded into it (some variation of the NET ID?), even though it appears to be completely ignored, however can this data be used to reliably differentiate between the standard protocol and TK2 protocol?

Jason


jll745562
ROM Dongle
Posts: 15
Joined: Wed Apr 10, 2019 2:15 pm
Location: Ynys Mon

Re: Hello & help needed with QL networking and TK2

Post by jll745562 »

Hi Norm,

If I ever discover any info about the QL beyond what is already published, I will definitely pass that knowledge back to the community!


Jason


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Hello & help needed with QL networking and TK2

Post by tofro »

jll745562 wrote:Hi Martyn,

- I've noticed that the scout appears to have some data encoded into it (some variation of the NET ID?), even though it appears to be completely ignored, however can this data be used to reliably differentiate between the standard protocol and TK2 protocol?

Jason
Jason,

what's in the scout is not very relevant for any receiving station, but rather for the sending one. Scout contents are only used to detect collisions - The sending station tries whether it can read back the scout contents it has just put on the network unmodified. If the scout comes back modified, that must be a collision. That value obviously must be unique, and if I remember right, this was the bit-reverse of the sending station's station number.

Tobias
Last edited by tofro on Thu May 02, 2019 10:50 am, edited 1 time in total.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Hello & help needed with QL networking and TK2

Post by mk79 »

martyn_hill wrote:
jll745562 wrote: It does seem odd that TK2 SAVEs BASIC files (over the network) without the header, but expects a header on LOAD.
I agree - arguably a design-bug in TK2.
No, there is no need to explicitly write a header because a default header (or rather directory entry, except MDV I don't think any device driver really uses headers) will be created that is perfectly fine
As LOAD should not require a header (and doesn't in QDOS), my view is that the error in design is there, rather than with the header-less SAVE.
And as far as I can see it doesn't demand a header on LOAD, or where have you seen that?

Marcel


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: Hello & help needed with QL networking and TK2

Post by martyn_hill »

Hi Marcel!
mk79 wrote:And as far as I can see it doesn't demand a header on LOAD, or where have you seen that?Marcel
We have seen it empirically when running (some versions of) TK2 - see below.

My quick review of the latest TK2 source (from SMSQ v3.34) was sloppy - I realise now that only if the requested file-type (passed in d7) is non-zero will the file-header then be read, thus (in src/sbsext/ut/opdefx_asm):

Code: Select all

uod_chk
	btst	#uod..typ0,d7		 ; type zero files only?
	beq.s	uod_rts 		 ; ... no, OK

	jsr	ut_fhead		 ; read file header
....
However, testing again, I found the following:
  • TK2 v2.32 (from yourself Marcel) does NOT exhibit the problem of expecting a file-header on LOAD. I have this version of TK2 loaded on all my QLs.
    TK2 from the SGC (SGC v2.49) in Tetroid's SGC clone running with (Minerva - not SMSQE) DOES exhibit this expectation. I can't find an easy way to check the version of TK2 in the SGC.
    TK2 on the QXL running SMSQE v3.32 does NOT exhibit this issue.
    Earlier TK2 versions DO exhibit the issue - but can't recall how far back as I have updated all my QLs/TK2 to 2.32 since.
    Jason's experience running with the TK2 version pre-loaded on Tetroid's Multi-EPROM also exhibits the issue on LOAD.
So it appears to have been addressed in later versions of TK2!

Jason - when you get the chance, just update to TK v2.32 and, better still, Minerva with at least the I/O Fix. Using the EPROM programming adapter from Tetroid will allow you to use an modern EPROM programmer to burn the Flash on this device.


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Hello & help needed with QL networking and TK2

Post by mk79 »

martyn_hill wrote:I realise now that only if the requested file-type (passed in d7) is non-zero will the file-header then be read, thus (in src/sbsext/ut/opdefx_asm):

Code: Select all

uod_chk
	btst	#uod..typ0,d7		 ; type zero files only?
	beq.s	uod_rts 		 ; ... no, OK

	jsr	ut_fhead		 ; read file header
....
Actually you left out the most crucial (next) line ;)

Code: Select all

        jsr     ut_fhead		 ; read file header
        bne.s   uod_ok                   ; OK!!
...
uod_ok
        moveq   #0,d0
        rts
So in case of an error the test is accepted as OK. This is the difference to earlier TK2 as supplied by the SGC, which reacts to the error by closing the channel.
So it appears to have been addressed in later versions of TK2!
It's likely that this was changed for SMSQ/E and that only my TK2 versions contain the fix as this was derived from the SMSQ/E source code.

Cheers, Marcel


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: Hello & help needed with QL networking and TK2

Post by martyn_hill »

Thanks for confirming, Marcel!

Jason, coming back to your enquiry over the SCOUT:

[quote jll74556]I've noticed that the scout appears to have some data encoded into it (some variation of the NET ID?), even though it appears to be completely ignored, however can this data be used to reliably differentiate between the standard protocol and TK2 protocol?[/quote]

This discussion really now belongs in the HW or SW section of the forum, but I'll leave it to you to continue the thread elsewhere hereafter, if you wish...

As mentioned below, the SCOUT serves two purposes - one to allow any receiving stations to detect the start of a new packet and synchronise reception with the sender and secondly for the sender to detect any collisions/contention (or a 'bad-line.')

In practice, due to the PNP arrangement in the NET hardware - either sourcing current in to the network, or switched off - only when you attempt to 'send' a low/zero (switched-off) can you detect whether someone else is concurrently also sending a high/one level (sourcing current). Thus the SCOUT is arranged to include a (arguably) unique selection of ones/zeros. The ones allow the SCOUT to be detected by the listener, the zeros to allow the sender to detect collision with a concurrent sender.

Across the various implemenations of the QL NET - and even the ZX Net as per the Spectrum + Interface-1 - various permutations of SCOUT can be seen, mostly based on the SRC station address (0-64) - either inverted or actual. In some cases, a mix of the SRC and DST station numbers is used - again, inverted or actual. The SCOUT typically starts with a minimum length of high/one level bits to ensure it can be reliably 'caught' by any listeners.

Under TK2, the SCOUT is also extended (remaining high) by a whopping 5ms for any Broadcast sends, knowing that any receivers currently expecting a Broadcast are also sampling the Keyboard between attempts to detect the SCOUT, which might take a couple of ms each round.

In practice, the SCOUT is an 8 or 15/16 bit value (depending upon OS platform), transmitted at a lower bit-rate to the real data which will follow (30 or 60 us per bit vs. 11.2 us for actual data.)

However, the only critical aspect of the SCOUT is that it must have no further high-to-low transitions after around 525 ms following the very start of the SCOUT going high. The next high-to-low transition is then taken by any receiver to be the beginning of the START bit of the very first byte of the 8-byte Packet Header.

With some care and a fast enough receiver, you could make a reasonably educated guess as to the OS platform of the sender by sampling the SCOUT. In fact, with a bit of ingenuity, you could safely use the SCOUT period to encode a few bits of more useful data (8-10) that tell any suitably programmed receiver more about yourself or your 'capabilities' in a way that is entirely transparent/invisible to existing NET devices - an idea that I've been toying with :-)

Once you fire-up a new thread, I'll provide a more direct answer to your question as to how to differentiate a TK2 sender from a vanilla QDOS (or ZX Spectrum!)

M.
Last edited by martyn_hill on Thu May 02, 2019 9:30 pm, edited 1 time in total.


Post Reply