[Coco] values other than 0 or 1 for byte 14 of decb dir entry

[Robert Gault]

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
> ago.
> I'll be interested if you can refresh my memory about what that CoCo
> Max 3 compatibility line inserted into the boot program does.
>
> Art
>

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
  LDA #$3E
  STA $FFA3 controls $76000-$77FFF changed by POKE
  LDX #$C000
  LDY #$6000                       changed by POKE
A@ LDD ,Y++
  STD ,X++
  CMPX #$DD00
  BCS A@

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.