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.

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 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?

- 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.

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?

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):

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.

[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.