[Coco] Coco Digest, Vol 53, Issue 4

[Mark Marlette]

Ty,

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  
other post.

Mark

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  
>> 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
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>