[Coco] Coco Digest, Vol 53, Issue 4
mark at cloud9tech.com
Thu Dec 6 14:16:15 EST 2007
The Pro-Tector+ knows what the bus is doing. So there is a way to get
to BA and BS.
Since I would expect this to be a hardware emulator, the answer is simple.
The hardware emulator would best be suited for hardware targeted
projects. Software can already be debugged in MESS as already note by
Quoting Ty S <ty140 at hotmail.com>:
>> > 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
> 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! :)
> Put your friends on the big screen with Windows Vista® + Windows Live™.
> Coco mailing list
> Coco at maltedmedia.com
More information about the Coco