Possible problem with cloned SGC and Minerva 1.98

Nagging hardware related question? Post here!
Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: Possible problem with cloned SGC and Minerva 1.98

Post by Martin_Head »

mk79 wrote:Hmm, looking over the list I suspect the scatter load of the MDV device driver is broken on later Minervas. Further experiments now show that it always crashes when you LBYTES a file that is exactly 4096 bytes or bigger. Too late to investigate further, but the bug will be in dd_msvsc_asm I guess. Still pretty amazing that this hasn't been reported before.
When I said I had a problem with the scatter load on a drive. It was my MDI driver, which is based on the Minerva code.

I cannot quite remember exactly what the fix was. But it was something to do with the driver i/o routine when the i/o routine decides it need to call the scatter load code.

I think the problem was with the call instruction. Something like it was a branch to a subroutine, instead of a branch always.

At the time I thought it was a typo on my part. But maybe , it wasn't.

You could try comparing the MDI sources http://www.dilwyn.me.uk/utils/MDIsources107.zip with the Minerva sources around that point.


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

Re: Possible problem with cloned SGC and Minerva 1.98

Post by mk79 »

Martin_Head wrote:I cannot quite remember exactly what the fix was. But it was something to do with the driver i/o routine when the i/o routine decides it need to call the scatter load code.

I think the problem was with the call instruction. Something like it was a branch to a subroutine, instead of a branch always.

At the time I thought it was a typo on my part. But maybe , it wasn't.
The scatter code works on a QL without (S)GC, so it is probably not broken per-se. That's why I think it might be related to the interrupt somehow.


Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: Possible problem with cloned SGC and Minerva 1.98

Post by Martin_Head »

I have been comparing my MDI driver and Minerva source codes. But I cannot see any difference where I thought the problem was.

So I had a search in the forum viewtopic.php?f=19&t=683&p=4979&hilit=minerva#p4979 from when I was hunting it.


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

Re: Possible problem with cloned SGC and Minerva 1.98

Post by martyn_hill »

Thanks Martin - it was good to re-read your older post and gives me some other ideas to consider.

Meanwhile, I've burnt a fresh EPROM with Min 1.98 + Marcel's IO fix, but with the enable/disable interrupt instruction-pair in the MDV Scatter routine effectively removed (actually, replaced with 4x NOPs).

There is a change in behaviour, though not especially useful, namely that the QL no longer crashes with that 2/3 blank display, but instead continues to spin the tape without any success at loading any of the image to screen.

Whilst you can't stop it with CTRL-Space, pulling the cartridge out generates the usual error (Bad or Changed medium) and control returns to SB.

Food for thought, at least.

EDIT: I took a cursory look at the binary image for Min 1.66 (which, as Marcel discovered, doesn't fail in the Scatter-load) and note that in a fairly close byte-offset to v1.98 has the very same pair of enable/disable interrupt instructions, further suggesting that the scatter-load itself is similar and potentially OK, but perhaps the interrupt handling in later Minervae is upset when run on the (S)GC.

I read in a couple of places in the Min 1.98 commentary references to the 68020 etc not handling the RTE 'correctly' and in one or two spots, instead an RTE is replaced with an explicit re-load to SR followed immediately by a standard RTS - functionally equivalent, bar the chance that an interrupt might get serviced between the SR reload and the RTS from the current interrupt handler... What I found curious was that there remain a number of other RTE's in the code that are not replaced in this fashion...


Nasta
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: Possible problem with cloned SGC and Minerva 1.98

Post by Nasta »

Just a thought - SGC uses a 68020 while GC uses a 68000, maybe it should be tested to see if there is a difference in behavior.
The 68020 has a third stack pointer for interrupts and other differences in stack frames so this may be the difference that breaks the code?


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

Re: Possible problem with cloned SGC and Minerva 1.98

Post by martyn_hill »

Now my head hurts!

Having read the 68k PRM manual again and, as you point out Nasta, the use of not just the two usual USP and SSP, but instead one USP as well as independent Interrupt and Master SPs (ISP/MSP).

It does seem possible that Minerva is only catering for a single (Supervisor) stack, whereas depending upon whether we're in an Interrupt routine or just in plain Supervisor mode, the SP (a7) could be pointing at two entirely different places!

This would certainly explain why we don't see the problem on a 68008.

As far as I can tell, the actual stacked frame - whilst there are more options available on the '020 - is likely to still be the 6 bytes of SR and PC.

Far to late at night for a mere mortal like me to make sense of this :-)


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

Re: Possible problem with cloned SGC and Minerva 1.98

Post by tofro »

The following is just a wild guess:

Apparently, the problem occurs with both the GC and the SGC (I hope this is verified?) - So I would assume it's not caused by the subtle differences in interrupt handling between the various 68k CPUs. Apparently, it is also not related to the patches done by GC and SGC ROMs.

What's left as root cause is then simply variations in timing:

When the Minerva code enables interrupts for that one instruction, could it be that in the 68008 case, the timing is such that an interrupt is always triggered in this short timing window, but in the case of the faster CPUs it's (sometimes) not? This could be resulting in code that assumes something is there, provided by the ISR, that in fact sometimes isn't. One could simply verify this by keeping the faster CPUs busy by a short delay loop in the code before rep_enab.

I was thinking about testing this, but couldn't find a working microdrive cartridge in my collection...

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: Possible problem with cloned SGC and Minerva 1.98

Post by Martin_Head »

A few odd thoughts.

I don't have the Minerva source code to hand. But I think that normal loading and scatter loading use the same routine to actually read the sectors off the cartridge, So it does not sound like a timing fault in reading the sectors.

I don't know if its anything to do with slave blocks, as the scatter load does not use them.

Does the same problem happen when trying to EXEC a program greater than 4K. As that should use the scatter load.

Does the same thing happen if you try to LBYTES outside of the first 64K of RAM. I'm thinking is the screen refresh getting in the way somewhere.

With to S/GC plugged in, disassemble the scatter load routine, and compare it with the Minerva sources to see if anything has changed.


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

Re: Possible problem with cloned SGC and Minerva 1.98

Post by martyn_hill »

Hi again Tobi and Martin

All good points.

Worth taking a step back for a moment.

The simple fact that no one seems to have reported such an issue running Minerva (after v1.66 at least) on SGC (and possibly GC - according to Marcel's earlier findings) could be that its not such a common setup and perhaps that most (S)GC owners:

a) are running old-school QDOS (JS/MG, or Minerva upto 1.66 etc) or
b) are immediately booting in to SMSQ/E from FLP to take full advantage of their shiny, fast QL and that the issue just isn't present in SMSQ (though the source for the MDV Scatter-load appears to be identical between both Min v1.98 and the equivalent SMSQ/E routines for (S)GC) or
c) just don't play with MDVs any longer - and who could blame them? (I still love the little beasts, but I'm weird...)

From my own perspective, its more 'because its there' that I'll continue to explore the issue - I've always been better at finding fault in other's work than actually developing something new myself :-)

I'll report back again in due course, in case anyone else cares enough to keep reading :-)


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

Re: Possible problem with cloned SGC and Minerva 1.98

Post by tofro »

Definitely (b) and (c) for me - I don't have any working cartridges anymore, and boot directly into SMSQ/E from QL-SD. The only time my SGC has seen itself running Minerva was until the SD card/floppy/QubIDE was set up the first time.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Post Reply