[Coco] values other than 0 or 1 for byte 14 of decb dir entry
robert.gault at att.net
Mon Mar 26 16:14:18 EDT 2012
Arthur Flexser wrote:
> I seem to recall that the problem had to do with the weird way ROM
> segments move around in response to changing the MMU setting for them.
> Which I think was a topic of discussion on the list a couple of years
> I'll be interested if you can refresh my memory about what that CoCo
> Max 3 compatibility line inserted into the boot program does.
Right, the lines are
160 IFPEEK(&HFE80) THEN LOADM"FILE512" ELSE LOADM"FILE128"
165 IFPEEK(&HFE80) THEN POKE &H5DE9,&HA4:POKE&H5DA2,&H80
So logically the POKEs should change FILE### which I disassembled.
The effect of this line is to change some code that sets the MMU values and
copies the DOS to a new location.
STA $FFA6 controls $7C000-$7DFFF regA content not known
STA $FFA3 controls $76000-$77FFF changed by POKE
LDY #$6000 changed by POKE
A@ LDD ,Y++
The POKEs change this to STA $FFA4 and LDY #$8000.
Actually this does not make much sense. The code seems to read the DOS at
"$C000-$DD00" and copy it to the same location but in an unknown MMU block. The
change just moved the location used to access the DOS code.
The only point to this would be if the MMUs can't access the DOS (probably in
ROM mode) with $FFA3 but can with $FFA4.
I'll see if the MESS debugger can trap the value sent to $FFA6.
More information about the Coco