[Coco] Coco Digest, Vol 53, Issue 4

[Ty S]

> > If this unit is given a small amount of memory and a uC, it could keep> > track of the contents of the 6809's registers by decoding & processing> > the instructions in the same way as the 6809 (as they relate to changing> > the values in the registers). AFAIK, this would be the most transparent> > way to "peek" at the registers without interrupting the execution cycle.> > I'll put it on the proposed feature list for now, but I don't want to> > make any promises. My time is limited at the moment.> > How do you plan on mirroring the interrupt behaviour? You have no way of > knowing exactly *when* an interrupt is latched by the 6809, and you could > lose all synchronisation between the emulation and the processor...> 
Since this was just an idea on the table, I never considered the possibility of handling interrupts, but I like where this is going.  Since the 6809's BA and BS pins are cut, as you mentioned, I would have no idea of knowing when an interrupt is being serviced.
 
However, if this unit does get a uC to implement the more advanced features, I don't see why we can't toss a few more into the mix:
 
- HALT the CPU at startup so the unit is able to read and store FFF0-FFFF (the interrupt vector table).
- Disable HALT so the processor can fetch the reset vector and begin.
- Monitor the address bus for accesses to FFF0-FFFF; if the bus is in 'write' mode, update the internal table to the values that are being written.  If data is being read from the interrupt vector table, assume that we are servicing an interrupt if the address read from the vector table is the next address on the bus.
- The value of the address bus (when the uC has determined that 6809 code is being executed) would need to be stored for at least one cycle, e.g.:
 
* last_add = current_add;
* current_add = getAddressBus();
 
If the unit determines it is servicing an interrupt, it can also determine when the interrupt service has completed by using last_add as a reference point for the values on the address bus.
 
Of course, this is just me thinking out loud ... I'm sure there's quite a few scenarios where the unit could be fooled into thinking it is servicing an interrupt by this logic.  But still, there's the appeal of seeing an LED light with an "SWI1" label under it.
 
 
> Why not replace the 6809 in the coco with an FPGA running a modified soft > core that had debugging capability built-in... of course there's the voltage > level issues, and it wouldn't be cheap...> > Regards,> > -- > | Mark McDougall | "Electrical Engineers do it> | <http://members.iinet.net.au/~msmcdoug> | with less resistance!"
 
I'm not entirely sure where you're going with this one -- as I envision it, my unit serves as a pass-through to the cartridge port so you can debug hardware.  I imagine it would be quite helpful to have access to the values in the 6809's registers while debugging hardware, which is why this came about in the first place.
 
Anyway, these are just ideas on the table... I'd like the unit to require a stock CoCo if at all possible.  (The 6809's BS, BA, and TSC would be exceptionally helpful though!)  If the FPGA CoCo3 project ends up with a 'standard' CoCo3 expansion port, this unit would work wonderfully with it.
 
Keep the ideas coming!  :)
 
Ty
 
_________________________________________________________________
Put your friends on the big screen with Windows Vista® + Windows Live™.
http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_102007