[Coco] CoCo 32k rom architecture

[Robert Gault]

Barry Nelson wrote:
> Ok, but…
>
> How does the rom map both before and after those bits are set? Does it start out with the top 16k half of the 32k rom mapped at $C000, or the lower half? After the bits are toggled, the rom maps to $8000-$FDFF, correct? At that point does the lower half of the rom map to $8000-$BFFF and the top half maps to $COOO-$FDFF? How does this all line up with the format of a .ccc file? Does the file have the lower address half first or does it start with the part of the rom that maps at $C000? Does the cartridge need any special wiring or special hardware?
>
>
>

Well, I ran a test with a real Coco3, MPI, and the Rad Warrior cart which is a 
32K unit. The same test does not work with MESS so emulators are up for grabs. 
The .ccc image of this pack does work with VCC 2.01 but VCC does not have a 
debugger.

The cart was in MPI slot2 and the MPI was set for empty slot4. The Coco3 started 
with Extended Basic.
I turned off the cart auto-start with
POKE&HFF23,&H34
accessed the cart with
POKE&HFFDE,0
POKE&HFF7F,&H11
and read the cart with
FOR I=0 TO 10: PRINT HEX$(PEEK(&HC000+I));:NEXT

The data printed was the same as the first ten bytes in the .ccc image of this 
game. That suggests that with 16k internal and 16k external, you read the first 
16k from the cart ROM at $C000 but after setting $FF90 for 32k external, then 
where is that code?
This does raise the following problem. The beginning code in the game was
  lda #$47
  sta $FF90
Now where then would the next opcode be read? RegPC is still at $C005 but the 
code there is junk in this context. That would seem to require that the first 
16k is still at $C000- while the second 16k is seen from $8000-. Frankly that 
make no sense at all.

What I would require to know exactly what happens, is a way to read memory on a 
Coco3 after setting $FF90 for 32k external ROM. Unfortunately you can't use 
Basic as it gets removed. You would need an ml program loaded into RAM below 
$8000 that sends data to the screen.
Guess I'll have to write a routine to solve this. :)

Robert