[Coco] Checking/Testing a 68B09P

[jdaggett at gate.net]

On 2 Jul 2007 at 14:52, Mike Pepe wrote:

> jdaggett at gate.net wrote:
> > On 2 Jul 2007 at 11:06, Frank Pittel wrote:
> > 
> >> Other then doing it because you can. Is there a reason why a person
> >> would want to build an interface to allow the use of a MC68B09 in a
> >> Coco? The cost of building such an interface must certainly exceed
> >> the cost of an "off the shelf" chip that could be used without any
> >> modification.
> >>
> >> This is a serious question.
> >>
> >> Frank
> > ****************
> > 
> > Only serious reason that I would consider it is to take advantage of
> > the MC68B09 DMA function. Outside that there is no other reason than
> > one could do it.
> > 
> > james 
> > 
> 
> Hey James,
> 
> Yeah, although the DMA function would be hard to implement as well.
> Far easier in the CoCo to just TSC/HALT the thing and hijack the bus
> for DMA.
> 
************

For starts the MC6809 has built in limited DMA capabilities that allows the MPU 
to be put in standby  mode for up to 32 machine cycles. Far easier to use than the 
HALT/TSC combo. The TSC and LIC lines of the MC6809E improves the usage 
of the MPU in dual processor systems with an external arbitrator circuit. 


> I'm not sure what you're pondering to make sure the internal E and Q
> clocks are in sync with the E/Q generated by the SAM (or GIME).
> Generating or hijacking a 4x clock signal to be fed into the extal pin
> is relatively simple. However guaranteeing that the phase relationship
> between the internally generated E/Q and what the SAM is feeding as
> E/Q is extremely critical. My guess would be that you can gate the 4x
> clock input to the CPU until the phase relationship on E and Q match
> and then let it loose.
> 
**************

I am not tr ying to accomplish anything. My comments were to the effect that a 
MC6809 cou ld be used in a Coco, with modifications to test the part out 
functionally. The MC6809 generates the E and Q signals internally. The 
MC6809E does not. 

> Agreed with Frank though, there's really no practical reason to do
> something like this, but it's interesting to speculate if and how it
> could be done!
> 
*****************

Actually I could see only one reason and that would be to use the limited DMA 
capabilities of the MC6809(non E version) part. MC6809E has advantages for 
usage with dual processor setups. 

james