Minerva Bug?

Anything QL Software or Programming Related.
Post Reply
User avatar
XorA
Site Admin
Posts: 1629
Joined: Thu Jun 02, 2011 11:31 am
Location: Shotts, North Lanarkshire, Scotland, UK

Minerva Bug?

Post by XorA »

Code: Select all

* The value in d1.l is used to decide what sort of restart is required:

*       bit(s)  value   meaning
*       0       0       do the full memory test
*               1       skip the memory test for a quick reset
*       1       0       scan rom slots
*               1       skip the rom slots, unexpand the m/c
*       2       0       normal establishment of memory size
*               1       take the upper memory limit below as gospel!
*       3       0       monitor mode
*               1       tv mode
*       4       0       wait for f1-f4 selection
*               1       skip the f1-f4 selection
*       5-6     0..3    extend supervisor stack by 0K, 8K, 16K or 24K
*       7       0       set single screen
*               1       set dual screens
*       8-13    0..63   extra blocks of 64k between last screen and system vars
*       14-31           upper limit on memory (0 = no limit)
* (Note that the top bits of d1 are unlikely to ever make sense as memory!)
Does not seem to agree with the code

Code: Select all

        btst    #2,d5           is this a forced limit?
        bne.s   res_a5          yes, go use it, whatever it is!
I think that should be a beq.s?


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

Re: Minerva Bug?

Post by mk79 »

No, why? Comment and code agree here.


User avatar
XorA
Site Admin
Posts: 1629
Joined: Thu Jun 02, 2011 11:31 am
Location: Shotts, North Lanarkshire, Scotland, UK

Re: Minerva Bug?

Post by XorA »

mk79 wrote:No, why? Comment and code agree here.
If I set bit 2 Minerva is ignoring the ram limit set, and going ahead and detecting ram. Which means its then putting ramtop the wrong side of the extended screen in uQlx/sQLux!

If I leave bit 2 clear it works as though RAM limit is used!


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

Re: Minerva Bug?

Post by mk79 »

XorA wrote:If I set bit 2 Minerva is ignoring the ram limit set, and going ahead and detecting ram. Which means its then putting ramtop the wrong side of the extended screen in uQlx/sQLux!
I haven't tried it, but from the code if you set bit 2 the jump to res_a5 will be taken an a5 used as limit (which is derived from d1). If bit 2 is clear it will start the RAM boundary scan.


User avatar
XorA
Site Admin
Posts: 1629
Joined: Thu Jun 02, 2011 11:31 am
Location: Shotts, North Lanarkshire, Scotland, UK

Re: Minerva Bug?

Post by XorA »

mk79 wrote:
XorA wrote:If I set bit 2 Minerva is ignoring the ram limit set, and going ahead and detecting ram. Which means its then putting ramtop the wrong side of the extended screen in uQlx/sQLux!
I haven't tried it, but from the code if you set bit 2 the jump to res_a5 will be taken an a5 used as limit (which is derived from d1). If bit 2 is clear it will start the RAM boundary scan.
Im going to have to kick the uQLx codebase a bit more and see if I can get it to give me reliable output of the opcodes it runs then!


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

Re: Minerva Bug?

Post by mk79 »

Just tried it on an SGC QL, "CALL 390,$00200004" works as expected, giving me 2MB.


User avatar
XorA
Site Admin
Posts: 1629
Joined: Thu Jun 02, 2011 11:31 am
Location: Shotts, North Lanarkshire, Scotland, UK

Re: Minerva Bug?

Post by XorA »

mk79 wrote:Just tried it on an SGC QL, "CALL 390,$00200004" works as expected, giving me 2MB.
Thanks, must be an unintended side effect somewhere in uQLx code (this has never worked in original code due to missing brackets)


User avatar
XorA
Site Admin
Posts: 1629
Joined: Thu Jun 02, 2011 11:31 am
Location: Shotts, North Lanarkshire, Scotland, UK

Re: Minerva Bug?

Post by XorA »

Code: Select all

go_key
        moveq   #io.fbyte,d0
        trap    #3
        addq.l  #-err.nc,d0     check if timed out
        beq.s   set_mde1        yes, just use what we started with
        addq.b  #8,d1           f5 key = $f8
        add.b   d1,d3           check if {ctrl+}{shift+}f1-f4 (d3.lsb = $10)
        bcc.s   read_key        not f1-f4, read again
        roxl.b  #5,d3           set quick reset bit and dual to extend
        ror.b   #3,d3           slide TV/128k/ROM/quick bits down
        roxr.b  #1,d3           slip in the dual bit
        moveq   #$40000>>16,d1  start getting 128k mask ready
        bset    d1,d3           flag byte now: dual/0/0/f1-f4/TV/128k/ROM/quick
        and.b   d3,d1           isolate 128k bit
        swap    d1              put it up in msw, now $40000 if 128k requested
        move.b  d3,d1           d1.l now ready for re-reset call
        move.l  (sp),d3         get top of stack
        move.l  d1,(sp)         replace top of stack
        eor.b   d1,d3           check which bits differ
        and.b   #%10000110,d3   do dualscreen, 128k and romscan bits agree?
set_mde1
        beq.s   set_mode        yes - we're happy to leave that as it is
        jmp     390             no - go to magic reset location with d1.l set
Ok, found out why I was seeing the wrong branch, I was only seeing the 2nd pass though, caused by hitting this condition above. Now just to work out why!


Post Reply