Minerva4Q68 v1.70 released

[janbredenbeek]

Hi Derek,

I am not totally against the inclusion of Language files in SMSQ/E or Minerva, but if the desired language is not included, then another foreign language would have to be used. I prefer the Minerva method of load language and keyboard tables on boot up. Where new specific language files can be generated as required.

In the original Minerva everything had to fit into 48K, which is why foreign language support has to be loaded externally.
The Q68 version requires an external keyboard driver and has twice as much ROM memory available, so inclusion of foreign keyboard tables is not a big issue (it only costs a few hundred bytes extra).

But it's not much work to implement a KBD_TABLE command in the Q68 keyboard driver (including support for loadable keyboard tables). It will probably take more time to test it than to actually write it.

(I just realised that the list of extra keywords in Minerva4Q68 has now grown to the point that it needs a separate chapter in the documentation...)

[Peter]

Hello Jan,

So please upgrade now to v1.71 and Minerva 1.98j2. And for the users with German keyboards, there is now Minerva 1G98j2 available!

Thanks for adding the German version. I did burn a 1G98j2 ROM with QL-SD 1.10. The results:

Expanded QL: Boots and basically works. QL-SD shows "card detected" but can not actually access the card. I previously used QL-SD 1.07, so I'm not 100% sure it has to do with the SD driver version as well.

Gold Card: Hangs at the F1/F2/F3/F4 screen during the first (of the dual) boot phases.

Super Gold Card: Draws the Minerva boot screen, but wihout any text. Blinking cursor appears in the inner box. I'm going to send you a video of that by messenger.

I wonder if you or someone else tested 1.98j2 or 1G98j2 on a real QL at all.

My reports have to be taken with caution, because the many card and ROM changes start making my QL a little unreliable. Reverting back to the original 1G98a1 ROM worked well though.

Since I also need my QL for the QL60, I'd be glad if further Minerva versions could receive initial testing by someone else, who is better equipped with QLs than me.

All the best, Peter

[janbredenbeek]

Hi Peter,

Hello Jan,
I wonder if you or someone else tested 1.98j2 or 1G98j2 on a real QL at all.

I've now tested on a QL with GC, using my custom boot utility.

With QIMSI plugged in, it crashes on all 1.98 versions (including those from Marcel), even when I load from floppy.
When I remove QIMSI and boot from floppy, all 1.98 versions appear to work.

I'm not sure what causes this, maybe it's the QL itself that has issues. I'll test again with another QL asap.

To be continued...

[Peter]

I've now tested on a QL with GC, using my custom boot utility.

I don't know about that utility and what magic it does with the GC, but it sounds like a piece of software that does not change the QL-side ROM.
Therefore you will still run on an original Minerva ROM at first! This can not reproduce the crash during the first boot stage that I see here.

[janbredenbeek]

I've now tested on a QL with GC, using my custom boot utility.

I don't know about that utility and what magic it does with the GC, but it sounds like a piece of software that does not change the QL-side ROM.
Therefore you will still run on an original Minerva ROM at first! This can not reproduce the crash during the first boot stage that I see here.

It copies the new image to the ROM area, which is in fact RAM with a (S)GC, and then boots the new ROM.
A point of conflict might be the (S)GC ROM which needs to be paged in at $C000, which apparently conflicts with QIMSI.

So far, the only bug I have found it that it tries to boot from WIN1 rather than MDV1, which confuses some drivers that try to imitate MDV at startup (so I have to DIR mdv1_ the first time rather than DIR flp1_).

More elaborate testing would involve burning an EPROM, which I'm not sure would succeed on my aging home-built eprom burner...

[Peter]

So far, the only bug I have found it that it tries to boot from WIN1 rather than MDV1, which confuses some drivers that try to imitate MDV at startup (so I have to DIR mdv1_ the first time rather than DIR flp1_).

Indeed a DIR mdv1_ before DIR win1_ makes the expanded QL work well with both QIMSI and QL-SD.

Could the (S)GC problems be related to their patching algorithms not "liking" your new binary?

[janbredenbeek]

So far, the only bug I have found it that it tries to boot from WIN1 rather than MDV1, which confuses some drivers that try to imitate MDV at startup (so I have to DIR mdv1_ the first time rather than DIR flp1_).

Indeed a DIR mdv1_ before DIR win1_ makes the expanded QL work well with both QIMSI and QL-SD.

Yes, obviously this was changed for the Q68, but not put in GENIF/ENDGEN clauses for assembling different versions. I could change this back to MDV for the standalone version which makes booting from flp and QIMSI work again. I know sQLux and maybe Qemulator patch this back to WIN1.

Could the (S)GC problems be related to their patching algorithms not "liking" your new binary?

If that was the case, it would more likely display a message like 'unsupported ROM, contact Miracle Systems'. AFAIK, it doesn't expect Minerva code to be patched at fixed locations, given the various Minerva versions that have been around.

Would it be possible to reprogram QIMSI Gold to allow the QL_ROM.SYS to take over the whole 64K ROM area? Of course this would also involve removal of the QL ROMs, but it would be a great tool to test Minerva without having to burn EPROMs.

[XorA]

For sQLux I manually search the patch address for every release. And what you patch it too is configurable.