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

Nagging hardware related question? Post here!
martyn_hill
Gold Card
Posts: 390
Joined: Sat Oct 25, 2014 9:53 am

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

Postby martyn_hill » Sat Oct 15, 2016 12:18 pm

Hi!

That trimming capacitor on the Iss5 is actually to trim the 8302's 'real-time' clock :-)

I do think that timing tolerances between Minerva and Tk2 could well be a significant factor, but again - this wouldn't in itself explain why different types of high-level device access (OPEN, LOAD vs. LBYTES) show different behaviour - the very same _physical_ code is used in each case.

Assuming my hardware isn't flaky, a more likely explanation could be that, as Tk2 was written before Minerva and would have been designed against original QDOS 'conventions'; Tk2 would be assuming register usage and other environmental factors that are no longer the same under Minerva. I've seen several examples of older toolkits behaving differently under QDOS vs Minerva, as Minerva tries to follow the official documentation, which QDOS often didn't!

But Derek's observation would seem to indicate that Minerva + Tk2 networking worked OK...

I should point out that I've made some significant hardware mods to both Issue boards and, on the Iss5 in particular, I have extended the memory by also shadowing the internal QL DRAM: writes go to both DRAM and fast SRAM in the lower 64kB - necessarily contended and which includes the video RAM range, whereas all reads come from the fast SRAM across the entire RAM memory map - or as much as I've filled with the 512k SRAm IC - and is uncontended (zero-ws). Everything else seems to work nicely and some simple tests show a significant 'speed' increase, though not the full 2x, as any real-world test will write as well as read from the lower memory (only reads are faster in that lower 64kB).

Another reason I don't think the different hardware/Issue boards are the root-cause is that the behaviour is symmetric between them - whichever has Tk2 running will fail to respond to the scout/header when LBYTES is used.

In my earlier testing, I also tried a few different 8302 and 8301 IC combinations as well - didn't seem to show any difference in behaviour.

Its a bit of a distraction from my USB-QNet project, but I will continue to try to code-in the Minerva physical routines in to the Tk2 networking code.


Derek_Stewart
QL Wafer Drive
Posts: 1039
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

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

Postby Derek_Stewart » Sun Oct 16, 2016 8:26 am

Hi Martyn,

From the excellent explanation by Tobias, it would seem reasonable that your hardware mod of shadowing the QL Ram would allow QLNET connections with a software based Toolkit 2.

The explanation from the Minerva team was that Minerva fixed a lot of bugs in the JS Rom issue of the QL and made networking actually work reliably. Whether that is correct I can not say, but since the Minerva source was released under GPL, the changes maybe documented in the source comments.

I was looking to to design a Shadow Ram board for the QL so that SMSQE GOld could be loaded in the BBQL with ram expansion, the other idea was t alter SMSQE Gold to run on a standard QL. Both are challenging.


Regards,

Derek
martyn_hill
Gold Card
Posts: 390
Joined: Sat Oct 25, 2014 9:53 am

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

Postby martyn_hill » Sat May 06, 2017 12:07 am

OK, so as a temporary distraction from finishing my QNet-USB adapter (coming along nicely...), I found myself trying once again to uncover the cause of the apparent incompatibility between Minerva and Tk2 networking...

Ultimately, I intend to run latest Minerva + Tk2 on my QLs and getting a reliable network is part of the fun...

Just to recap, with Minerva 1.98 and pretty much any version of Tk2 loaded, receiving packets using LBYTES from the network fails and hangs the QL. Simple OPEN/INPUT/INKEY$ works as expected.

Minerva without Tk2 also works as expected.

Both JS and MG with Tk2 also works as expected.

From sampling the wire, it was clear that the Minerva v1.98 +Tk2 combination would fail to ACK the header - and only a reset would release the listening QL.

After a few days diving ever deeper in to the Tk2 sources and comparing against Minerva and JS sources, building a 'debug' version of the Tk2 networking code and all sorts of fun besides, I finally decided to just try an older version of Minerva. I was prompted to try again after reading another poster's comments about a bug he found in Minerva 1.98 that wasn't in 1.89...

I can now confirm that Minerva 1.89 plus Tk2 v2.26 works as expected with LBYTES et-al (BTW the network code in Tk2 doesn't appear to have changed since forever.) Phew!

I'd still like to figure out where it broke and fix it - we have the source for Minerva 1.98 but not for 1.89 to compare against - anyone here have a copy of the 1.89 source?

Enough procrastination - back to coding the QNet physical driver on my Teensy (Ardiuno-like) micro-controller.


User avatar
Dave
SandySuperQDave
Posts: 1996
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

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

Postby Dave » Sat May 06, 2017 2:33 am

This sounds like an interesting project, so I have an impertinent question. What does QNet-USB do?

If you find the bug in 1.98, would you be willing to patch it to make 1.99?

Is there an official maintainer of Minerva currently?


martyn_hill
Gold Card
Posts: 390
Joined: Sat Oct 25, 2014 9:53 am

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

Postby martyn_hill » Sat May 06, 2017 8:28 am

Hi Dave

For sure, if I can track down the v1.89 Minerva source, I'd be happy to compare against v1.98 and try to identify what broke and fix it for an unofficial '1.99'!

The QNet-USB adapter is something I'm developing for PC based emulators to be able to speak QNet with real QLs. A different approach to what Martin Head has developed in IP-Net.

For me the fascination is with the native hardware... More to follow in a separate thread.

M.


User avatar
XorA
Gold Card
Posts: 490
Joined: Thu Jun 02, 2011 11:31 am
Location: Shotts, North Lanarkshire, Scotland, UK

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

Postby XorA » Sat May 06, 2017 8:59 am

I can now confirm that Minerva 1.89 plus Tk2 v2.26 works as expected with LBYTES et-al (BTW the network code in Tk2 doesn't appear to have changed since forever.) Phew!

I'd still like to figure out where it broke and fix it - we have the source for Minerva 1.98 but not for 1.89 to compare against - anyone here have a copy of the 1.89 source?


Without source I guess you could connect logic analyser and compare the two traces.

But this would explain why I have never ever got QL network running.


Martin_Head
Gold Card
Posts: 298
Joined: Tue Dec 17, 2013 1:17 pm

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

Postby Martin_Head » Sat May 06, 2017 10:04 am

Found this as a change in the Minerva versions doc

Version 1.96
e - Network driver verifies stop bits on incoming bytes


I don't know if that helps


martyn_hill
Gold Card
Posts: 390
Joined: Sat Oct 25, 2014 9:53 am

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

Postby martyn_hill » Sat May 06, 2017 12:28 pm

Hi Martin

Yeah, read that.

From all the research I've done to-date, it doesn't appear to be in the physical layer (phys_asm), but something to do with the base OS 'serio' vector code in Minerva which is quite different from plain QDOS.

The Minerva net drivers for example use Minerva's particular 'relio' vector and Minerva does some funky stuff to differentiate between traditional serio and relio calls - the return address is taken from the stack and for relio, the address is made odd temporarily, so as to make the right type of calls (pend, fetch & send) back in to the driver before restoring the return address. Fiddly and typically clever stuff from QView...

There is a comment in the Minerva version_doc about some changes to 'serio' to better support pure serial devices like MEM.

Anyways, if I can;t get my hands on the 1.89 source, I'll try disassembling and piecing together by hand.

Atleast we''ve got a version of Minerva that does work with Tk2 now - that's a start.

M.


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

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

Postby janbredenbeek » Sun May 07, 2017 4:16 pm

One of my QLs has Minerva 1.97 and I can confirm the networking in this version does work. I can supply the ROM image if you're interested.

Jan.


User avatar
QLvsJAGUAR
Gold Card
Posts: 264
Joined: Tue Feb 15, 2011 8:42 am
Location: Lucerne, Switzerland
Contact:

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

Postby QLvsJAGUAR » Sun May 07, 2017 7:10 pm

Please be aware that of v1.97 (and maybe v1.98) there were various binaries. I myself have two binaries with internal version 1.97 but one of those is in fact an early 1.98. Read this report from the author:

Von: "Lau"
An: <ql-users@quanta.org.uk>
Betreff: [ql-users] Minnie 1.98 - will the real one please stand up!
Datum: Mittwoch, 9. April 2003 21:30


I think I've finally worked out what has been going on.

Way back in those dim distant days when I was trying to sort out the
buglets of 1.97, I supplied Tony with what I thought might be 1.98. My
backup disks for that actually have two bugs. Firstly, I didn't remember
to change it from saying 1.97 to saying 1.98, and secondly, I'll say
later. What came off that set of backup disks labled 1.98 is what I have
up on the website at present (bar for the renaming of od_con_asm). It's
naff.

Tony thinks he may have sent out a small number of copies of that bugged
version to interested parties, and we think I may have told him over the
phone to patch byte 661 to read "8". Or maybe they went out still saying
they were 1.97. We're not sure. In any case, Tony no longer has an image
for 1.98, whatever it was.

The second bug in that copy is what was the killer. SDATE and ADATE
didn't work on (Super) Gold Card machines. We didn't find that out for
some time (there has always been a bit of argy-bargying between the Mk2
RTC and GC RTC, so somehow we missed it).

By the time we had found out about the bug, I was trying to get Tony to
test 1.99, a significant prune and bug fix. He tested it, found the same
bug, that version never went anywhere and I entered hibernation.

So... in effect, a sensible 1.98 has never really existed and 1.99 not
at all.

The upshot is that I'm now going to put what was going to be 1.99 onto
the website as 1.98 (is that all clear?).

My reason for doing this is that it leaves me the one final version
number, before we hit rock bottom (top?). Due to various bits of code
about the place (e.g. in (S)GC), I can't have a version above 1.99
(although I do have the idea of putting a zero-cost sub-version number
in location $D6).

The main reason for keeping that one version number in hand, so to
speak, is that 1.98 now has at least 128 bytes of ROM space free (plus
the 70-odd bytes of $FF down in low memory which I've never quite felt
the urge to use). So - any suggestions for an enhancement?

Don't suggest "colour drivers" or the like. As a hint of what the space
is worth, the BEEP command takes about 128 bytes and the PEEK/POKE set
takes more like 160 bytes.

PS.

The ADATE / SDATE bug is solved - and it's a bug in (S)GC. (I got going
on it the morning at 5.50am and woke Tony up at 8am with the news - he
wasn't as pleased as he might have been!)

Trap #1 calls are firmly defined as only requiring D0.B to be set. I've
certainly seen (inefficient) code in the past that used "MOVE.B #summat,D0".

In fact, all ROMs have always ignored all but the least significant
seven bits (the value is anded with 127 as soon as the trap gets going
and I beleive there was some intention to use bit 7 as a trap modifier
flag of some sort - an A6 relative flag or some such).

I had changed some code around SDATE / ADATE / DATE / DATE$ / DAY$ to
save space, and I happened to call the trap with D0.B bit 7 set, knowing
(sic) that that was perfectly valid. (S)GC actually uses "CMP.W" against
D0, and doesn't recognise either of my ADATE and SDATE calls.

I spent a lot of time today, being really irritated about having to
waste a whole word of my precious free space on pandering to (S)GC,
until I came up with a trick or three that meant I finished up saving
six bytes instead.

My, hasn't this been a long message!

--
Lau


http://www.sinclairql.net/ - Go and get THE DISTRIBUTION & QL/E!
http://www.youtube.com/QLvsJAGUAR
https://plus.google.com/+QLvsJAGUAR
Sinclair, QL, ATARI, JAGUAR, NUON, APPLE & more
Videos, pictures & information

Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 3 guests