[Coco] auto-starting game paks

[Mark McDougall]

Roger Taylor wrote:

> I've never known the CoCo to jump-by-hardware to $C000 if CART is active 
> the instant the CoCo comes on, so I had to ask.

Not sure if you quite understand this, so please forgive if I'm telling you 
how to suck eggs...

The hardware doesn't have any _direct_ control over the CPU flow of 
execution, in that it cannot directly affect the execution address. Each CPU 
will power-up (or exit reset) and fetch from a fixed location - some CPUs 
immediately begin executing code from a fixed location, others fetch a 
"reset vector" which determines the address from which it will start to 
execute code.

Once a CPU is running (and interrupts are enabled), external hardware may 
generate an interrupt on the CPUs interrupt line(s). Different CPUs behave 
differently, but in general an interrupt causes the CPU to complete the 
current instruction and then (like at power-on) either branch to a fixed 
address or fetch a vector from a fixed address before branching to that 
vector. And generally, an interrupt will also automatically internally 
disable same- and lower-priority interrupts.

In the case of auto-starting paks on the Coco, the CART# line is (generally) 
connected to the Q line. This is merely "convenient" as it provides an 
eternal falling-edge on the CART# line. As others have explained, in general 
once an auto-start pack has initialised, it won't re-enable the CART# 
interrupt otherwise a perpetual re-boot will occur, as you yourself have 
deduced.

> It's not that important, but I was trying to figure out a way to 
> auto-start a 6551-based cartridge that quickly after starting uses the 
> same CART signal for another purpose.  

As the Coco uses CART# to auto-start, and you want to re-use the signal as a 
peripheral interrupt, you need to - as you have also correctly deduced - add 
logic to your cart to disconnect the Q line after initialisation.

One problem is that your "hardware" needs to know _when_ to disconnect the Q 
line, as it will toggle many many times before the interrupt is finally 
serviced and vectored to auto-start the pak.

One option would be to have a software-accessible register (flip-flop/latch) 
that is used to gate the Q signal input to CART#. Your rom-pak 
initialisation routine would hit this register.

Another option is not to use Q at all, but some on-board method of 
oscillating CART# on start-up that is similarly software-controlled.

Hope this makes things a little clearer?

Regards,

-- 
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"