[Coco] GIME Question

[jdaggett at gate.net]

On 10 Jun 2007 at 14:51, Darren A. wrote:

> The SAM in the CoCo 1/2 maps addresses $FFF0 - $FFFF (interrupt/reset
> vectors) to $BFF0 - $BFFF (End of Color Basic ROM). Does the GIME not
> mimic this behavior? On a CoCo 3, PEEKing at &HFFF0 returns a
> different value than a PEEK at &HBFF0.
> 
***************************
Darren

The Coco 3 is different. The normal vector addresses for the MPU contain entry 
points to a jump table that is stored at &HFEEE to &HFEFF and  not execution 
addresses.  I am not sure the vectors at &HBFF0 to &HBFFF are seen or used. 
While they are copied into RAM, I don't think that the code ever points to these 
vectors. Even with the MC3 bit in &HFF90 register is cleared, the jump table 
should be read from ROM and not from RAM. Not sure about that but from the 
code it seems likely. 

Also when looking into RAM, besure that you use the correct PEEK command. 
Using PEEK &HBFFF can yield a different value than LPEEK &HBFFF. LPEEK 
will look at the actual extended address by changing the DAT value in a MMU 
block and then restore it back. The PEEK command will use the existing MMU 
register value for the range in which the address is and it may not result in what 
you intended.  

> I wanted to burn an EPROM with a new address for the 6309 illegal
> instruction vector, but my initial tests under MESS didn't work when I
> only changed the address at $BFF0.
> 
> Does anyone know of a simpler way to change the COCO 3 ROM without
> having to completely desolder the original? I'm kind of afraid to
> undertake such a project. The CoCo 1's socketed boards are so much
> easier to tinker with.
> 
**************

I don't think so. You can write a program that will copy the contents of the ROM 
entirely and dump it to a disk file in binary form You can then import it to another 
computer and use a hex editor to alter the bits you need. Burn it into a EPROM. 
Another avenue is to get a disassembled form of the ROM and add your code 
and reassemble then burn it. There is about 1000 bytes in the Super Extended 
ROM area and that can hold an illegal opcode trap handler.

 

james 

james