QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Nagging hardware related question? Post here!
User avatar
QLvsJAGUAR
Gold Card
Posts: 455
Joined: Tue Feb 15, 2011 8:42 am
Location: Lucerne, Switzerland
Contact:

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by QLvsJAGUAR »

BTW: THE DISTRIBUTION holds the following Minerva binaries:
THE_DISTRIBUTION\emu\ROMs\JSL161.ROM 49'152 18.07.2001 22:04
THE_DISTRIBUTION\emu\ROMs\JSL163.ROM 49'152 18.07.2001 22:04
THE_DISTRIBUTION\emu\ROMs\JSL164.ROM 49'152 18.07.2001 22:04
THE_DISTRIBUTION\emu\ROMs\JSL166.ROM 49'152 18.07.2001 22:04
THE_DISTRIBUTION\emu\ROMs\JSL189.ROM 49'152 24.05.1997 00:03
THE_DISTRIBUTION\emu\ROMs\JSL197.ROM 49'152 10.12.1995 21:27
THE_DISTRIBUTION\emu\ROMs\JSL198.ROM 49'152 30.08.2013 10:20
THE_DISTRIBUTION\qos\ROMs\JSL189.ROM 49'152 24.05.1997 00:03
THE_DISTRIBUTION\qos\ROMs\JSL197.ROM 49'152 10.12.1995 21:27
THE_DISTRIBUTION\qos\ROMs\JSL198.ROM 49'152 30.08.2013 10:20


QL forever!
https://www.sinclairql.net/ - Go and get THE DISTRIBUTION & QL/E!
https://www.youtube.com/QLvsJAGUAR/community - Blog
https://www.youtube.com/QLvsJAGUAR - Dedicated QL videos
Sinclair, QL, ATARI, JAGUAR, NUON, APPLE, NeXT, MiST & much more...
Videos, pictures & information
User avatar
QLvsJAGUAR
Gold Card
Posts: 455
Joined: Tue Feb 15, 2011 8:42 am
Location: Lucerne, Switzerland
Contact:

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by QLvsJAGUAR »

And... I have a 1.92 somewhere.


QL forever!
https://www.sinclairql.net/ - Go and get THE DISTRIBUTION & QL/E!
https://www.youtube.com/QLvsJAGUAR/community - Blog
https://www.youtube.com/QLvsJAGUAR - Dedicated QL videos
Sinclair, QL, ATARI, JAGUAR, NUON, APPLE, NeXT, MiST & much more...
Videos, pictures & information
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by martyn_hill »

Thanks guys.

Jan - I'll try burning Min 1.97 + Tk2 and see how that fares.

Out of interest, which version of Tk2 are you using and did LBYTES specifically work for you?

Interesting to read Lau's memoirs !

Does anyone happen to have v1.89 (or perhaps v1.97) source for Minerva?

M.


User avatar
janbredenbeek
Super Gold Card
Posts: 629
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by janbredenbeek »

martyn_hill wrote:Thanks guys.

Jan - I'll try burning Min 1.97 + Tk2 and see how that fares.

Out of interest, which version of Tk2 are you using and did LBYTES specifically work for you?

Interesting to read Lau's memoirs !
I just did SBYTES on the Minerva QL without any extension to a JM with GC to save the Minerva image - you can't do this with the GC plugged in as it patches the ROM. I will have to do some more tests to check LBYTES.
The byte at 661 reads 32 but this ROM has never given any problems for many years. I bought my copy in October 1991 from Tony at an Eindhoven meeting, but I'm not sure if this was already at 1.97 back then - it might have been updated later.

Jan.


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

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by martyn_hill »

Hi Jan

Thanks for clarifying. OK, so the specific issue I am seeing relates to receiving on Minerva 1.98 using LBYTES, but only when Tk2 is active on the receiving end (doesn't matter what the sender is running - always the same response at receiver).

I'll try v1.97 anyways, but otherwise will take v1.89 as the last version that worked _fully_ with Tk2 networking.

I'll post back again as I discover more.


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

Resolved: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by martyn_hill »

Hi everyone

In case you haven't been following the recent thread on the QL Users mail-list, the issue reported in this post has since been diagnosed and fixed.

Marcel Kilgus has posted on his blog how he tested and identified the very small fault in later versions of Minerva (after v1.92) that can cause a QL to hang when LBYTES is used to receive using the TK2 enhanced Network driver. You can read about it here as well as downloading a recompiled version of Minerva based on v1.98 known to work well with the TK2 NW:

https://www.kilgus.net/2018/02/27/debugging-minerva

If you're interested in a little more detail or if you suspect that your own lack of success using the QL Network might have something to do with the issue Marcel has now fixed, read on...

Ultimately, the root cause was not with the Minerva NET driver, nor the TK2 driver that replaces it (both of which are pretty marvelous bits of programming), but with a QDOS/Minerva routine called 'serio' that all simple, serial device drivers - like NET - call to route each of ten supported access-layer requests to one of three very simple core routines that the device driver provides - "test for pending input", "fetch a byte" and "send a byte".

One of the 10 serial device access-layer requests is "fs.headr" - used to read the (simple) 15x byte file-header that has been prepended to data sent via SBYTES and similar commands (SEXEC, etc) and used by the receiving command to determine the length of the data that follows and, if an executable file, the exec-flag and data-space requirements.

So, before LBYTES reads the data itself, it first attempts to read this simple file-header by calling the fs.headr routine via serio. In turn, fs.headr prepares to call the device driver's core 'test for pending input' or io_pend, effectively to read the first byte from the receiving channel. io_pend returns not just whether there is any data available yet, but also a copy of the next byte that would be retrieved upon the next 'fetch byte' call.

LBYTES et-al check this first byte to ensure it is FFh - which flags the start of simple file-header. This is why you get a 'bad parameter' error when you attempt to LBYTES a file over a serial channel (open to NET, SER or MEM devices etc...) that does not include a file-header - perhaps sent with plain 'COPY'. (Curiously, LOADing a S*Basic program on Minerva also complains if no file-header is detected, even though it shouldn't need one...)

In Minerva sometime after v1.92, but certainly by v1.97, the authors had chosen to tweak very slightly the serio code provided by the OS, based on an assumption that any valid call to io_pend would hold a particular value (0) in register d0. This is true when an access-layer call requests directly to 'test for pending input' (Trap #3, Key $00), but _not_ valid if fs.headr had been requested - effectively serio 'nests' the call to io_pend within the fs.headr routine, by which time the value of d0 is certainly not 0...

Marcel has now sorted that by reintroducing a single instruction (moveq #0,d0) back in to Minerva's serio routine - where, as it happens, it had previously been commented out :-)

One remaining question I had that the above does not directly answer is 'why did LBYTES work at all for Minerva without TK2 loaded, yet failed when it was loaded?'

The answer is that Minerva also introduced - and uses internally - a variant of serio, called 'relio'. relio is slightly more efficient and easier to arrange your access-layer calls around, but effectively runs through most of the serio code to meet the request. Minerva uses relio for NET (and IIRC all its simple device drivers) and it just so happens that relio does not rely on the value of register d0 as serio does when calling io_pend, so never hits the problem described above.

Introduce the TK2 Net driver to Minerva v1.97+ and you are back to using the standard serio call: invoke LBYTES and Bang!

If its not already apparent from the above, whilst this was uncovered whilst playing with the NET driver specifically, _any_ device driver that leverages 'serio' to wrap around its own access-layer routines is liable to hang the QL in a similar manner when a request is made to read the file-header, either indirectly via LBYTES/EXEC* or directly requesting fs.headr (Trap #3, Key $47). This would include the ubiquitous MEM device, for example...

Having now studied as a result of this long-standing issue both the Minerva and TK2 source code enough to make one's head spin, I am left ever more impressed by the brilliance of the original developers and also an ever-so-slightly smug feeling that I was right to be 'curious' about Minerva, Tk2 and LBYTES after-all!

You gotta love the QL...


User avatar
Pr0f
QL Wafer Drive
Posts: 1298
Joined: Thu Oct 12, 2017 9:54 am

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by Pr0f »

Good bit of detective work :-)


User avatar
Pr0f
QL Wafer Drive
Posts: 1298
Joined: Thu Oct 12, 2017 9:54 am

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by Pr0f »

Is there a definitive list of the fixes for Minerva ?


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

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by martyn_hill »

Hi PrOf
Pr0f wrote:Is there a definitive list of the fixes for Minerva ?
How do you mean? I do not believe that there is a list of known issues waiting to be addressed by some enthusiastic soul, although at least one suggestion was posted a while back to default the IPC Interrupt to disabled (which can be done with a simple POKE anyway.)

Were you offering to compile such a list ? :-)


User avatar
Pr0f
QL Wafer Drive
Posts: 1298
Joined: Thu Oct 12, 2017 9:54 am

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by Pr0f »

I don't mind compiling it, if people are willing to provide a list of the discovered issues, and the necessary patches :-)

In all seriousness, I still keep looking at the Minerva code and the techniques used in the programming in some wonderment. I found DTACK grounded a good source of tips for optimisation, but there's a nice flow to some of the Minerva code.


Post Reply