Page 1 of 1
Minerva Bug?
Posted: Thu Feb 03, 2022 3:42 pm
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?
Re: Minerva Bug?
Posted: Thu Feb 03, 2022 3:57 pm
by mk79
No, why? Comment and code agree here.
Re: Minerva Bug?
Posted: Thu Feb 03, 2022 4:01 pm
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!
Re: Minerva Bug?
Posted: Thu Feb 03, 2022 4:04 pm
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.
Re: Minerva Bug?
Posted: Thu Feb 03, 2022 4:06 pm
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!
Re: Minerva Bug?
Posted: Thu Feb 03, 2022 5:25 pm
by mk79
Just tried it on an SGC QL, "CALL 390,$00200004" works as expected, giving me 2MB.
Re: Minerva Bug?
Posted: Thu Feb 03, 2022 5:46 pm
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)
Re: Minerva Bug?
Posted: Thu Feb 03, 2022 10:07 pm
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!