The Sinclair QL Forum

Hi,
I am reading this discussion with great interest, but I don't use mdv since age neither I have any working cartridge to test.
I installed QL-SD on my 2 working QL and mainly booting in SMSQ/E.

Fabrizio

martyn_hill wrote: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

I can provide a couple of good microdrive cartridges if people need them for testing. Would be nice to know if the same issues happen on the original Gold Card / Super Gold Card.

I have finished my reverse-engineering of the GC code and have typed up a short essay about the (S)GC boot process (including source code). Enjoy:
https://www.kilgus.net/2018/11/14/super ... -sequence/

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

In this case it's not functionally equivalent because the 68020 RTE instruction expects a different stack layout. Many of the SGC patches deal with this problem, RTE must only be used on traps/exceptions and nothing else.

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.

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

My GC crashed, too, so it's maybe more of a speed thing. It might be interesting to compare the Minerva 1.66 code to the current one, but it's possible that they are too much removed. The GoldCard patch code often lumps Minerva versions 1.67 and lower together with QDOS.

Another bit of a shot in the dark.

There has been mention of POKE!!53 to change interrupts in the IPC, Is this a Hermes thing? Are the three of you seeing this problem all using Hermes?

Also in my last post perhaps I should have said... Does the same thing happen if you try to LBYTES outside of the first 128K of RAM. I'm thinking is the screen refresh getting in the way somewhere.

Hi Martin

I actually tested with both the IPC Interrupt enabled (default) and disabled (with that POKE!!53,128) - same result.

Whilst I haven't yet tested other memory ranges for LBYTES, Marcel indicated that he had - again with the same result.

I'll verify that later today, just to be sure.

In any case, if the slower memory access of the first 32 or 64KB triggers the issue, it would still come down to the 'timing' - or more specifically, what interrupt handlers are invoked at the 'sensitive' point of the Scatter load, when we deliberately enable interrupts between two instructions to let other interrupt-driven housekeeping activities get a look in, whilst waiting for a new sector to pass the MDV head...

(In my recent testing, I disabled the enabling/disabling interrupts instruction pair within the Scatter-load routine and noted that the crash didn't occur - albeit, nor did the scatter-load compete either - as, I guess - it must rely on a new GAP being processed by the relevant interrupt handler in that short time window when interrupts are enabled.)

Another point that occurs to me regarding the 'timing' proposition - whilst the faster CPU of the (S)GC can obviously execute more instructions in a given time frame, there is no reason why more interrupts would actually be generated in any given time-window as this is determined by the same asynchronous events (e.g. GAPs passing the MDV head) that a slower machine would also meet.

Once interrupts are enabled, any pending interrupts would _all_ get serviced in between those two instructions in the Scatter-load (enable/disable interrupts). On an (S)GC, it would simply take less time to process all the pending interrupts before handing-back control to the Scatter-load routine. (There is an assumption in that last assertion that I am not 100% sure of.)

Still a mystery...

I did try LBYTES into a RESPRed area, but I didn‘t verify that the area is outside of SCR2 or that SCR2DIS was engaged, so that option is still on the table.

Hi again

When I test with LBYTEs in to a RESPR'd area, I get a crash but looking very different. The memory reserved was at 4064K, so well out of the contended DRAM range.

This test repeatedly results in a very colourful vertical strip-pattern making its way steadily _up_ the display area.

When I remove the cartridge, it keeps spinning for a few seconds, then the QL resets itself without further intervention.

Not sure what to make of the difference in behaviours - the only difference as far as the Scatter-load routine is concerned is the start address of the load (in a1.)

Still looking...

I decided to try to replicate your problem.

After a lot of trouble of trying to get a QL to work, and find a microdrive cartridge that still worked.

Power up, F1, LBYTES mdv2_filename,131072

And I do not see the problem, It works as expected.

This is the set up...

Issue 5 QL, with Minerva 1.97, An original Miracle Systems Gold card with ROM version 2.32

In case it matters, The IPC is a Philips MAB8049HP, and the ZX8301 is marked ZX8301.

I will try again with a Super Gold card (That QL was playing up).
I don't have any later Minerva/Gold card ROM's, so I may not be able to try the versions you are using.


EDIT...
Quick update... Same QL. Tried my SuperGold card. One of the Quanta build ones, with ROM 2.49

And it looks like I can see the problem. The bottom half of the screen blanks, The microdrive continues to run, and I loose control.

I can see a narrow band where the bottom of the screen blanks, of what looks like some of the screen I am trying to load. I am guessing it's read one sector before falling over.

Further testing may be a problem, as the Super Gold Card is as flaky as hell. Keeps throwing up RAM errors at power up, and crashing if you breathe on it. I suspect the RAM IC sockets, as I know there are problems with them.

Anyway it looks like something may have gone wrong between Gold card ROM versions 2.32 and 2.49.

Martin_Head wrote:Issue 5 QL, with Minerva 1.97, An original Miracle Systems Gold card with ROM version 2.32

Interesting. Do you have any means for reading out the complete 2.32 ROM? If not, can you SBYTES the area $1C200-$1FFFF after boot and send it to me?

Cheers, Marcel

mk79 wrote:

Martin_Head wrote:Issue 5 QL, with Minerva 1.97, An original Miracle Systems Gold card with ROM version 2.32

Interesting. Do you have any means for reading out the complete 2.32 ROM? If not, can you SBYTES the area $1C200-$1FFFF after boot and send it to me?

Cheers, Marcel

Here's an SBYTES, 15871 bytes, is that right?

At a pinch I could remove the ROM, and if my EPROM programmer still works, read the actual ROM.