[Coco] Learning CPU Architecture and Digital Design

[John Kent]

Mark,

When you say it messes up the graphics, is it the actual graphic drawing 
routines or does it more relate to the timing.
i.e. is it synchronized to some timing standard ?
I have tested the instructions against a real chip although I haven't 
used a full compliment of data.
i.e. I have tested pretty well all combinations of instruction with 
addressing modes but I haven't tested all instructions with all possible 
combinations of data, as the possible combinations blow out exponentially.

If the graphics is some how dependent on the timing, then yes there may 
be problems.
I could make it cycle accurate, but verifying it would need a logic 
analyzer that I could compare the outputs with and something like chip 
scope to measure the internal signals in the FPGA. The data would have 
to be in some form that you could compare.  It all takes time and money 
which I don't have. If someone paid me a lot of money to do it, I might 
consider it but I have more important things competing for my time. You 
get what you pay for and in the case of the 6809 core you get a lot more.

The core is open source, so anyone can modify it if they want to. 
Someone has converted the design to SystemC. I've wanted to make it go 
faster by implementing it in an FPGA. I suspect I would have to change 
the design to make it perfectly cycle accurate. It may not be a simple 
case of inserting idle bus states. The other thing is that I really 
don't want to make it slower. the real appeal is having something that 
works much faster than the original chip, using modern technology. If I 
made it cycle accurate, I couldn't just conditional out the code to make 
it more efficient. I'd have to degrade the whole design.

If you upgraded it to the 6309, that's not cycle compatible with the 
6809 as I understand it any way.. From what I've seen of the data for 
the 6309 it too is faster cycle for cycle. There is an emulation mode 
for the 6809, but I don't know if that changes the instruction timing as 
well. If memebers of the list have substituted the 6809E for a 6309E in 
there CoCos, can they run all the games, and the ones that are dependent 
on software timing loops ?


John.

On 20/02/2013 3:12 PM, Mark McDougall wrote:
> On 20/02/2013 11:34 AM, jdaggett at gate.net wrote:
>
>> I made my judgement based solely on the source code. John makes
>> comments in certain areas where the CPU09 does things in one or two
>> cycles faster than the 6809. So I do know that it was not 100% cycle
>> accurate.
> I'm not really sure how many instructions are 'off', just going on
> empirical evidence from my Vectrex and the fact that things like
> SockMaster's Bouncing Ball demo need to be 'fixed' on Coco3FPGA. Taking
> nothing away from John's effort of course!
>
> On the Vectrex implementation there were other factors at stake, such as
> the delays and decays of the X/Y integrators, however I did attempt to
> 'calibrate' and compensate for those in my code. However it was clear that
> there were other significant timing inaccuracies (CPU) involved. It's
> unfortunate that the Vectrex is particularly sensitive to these; far more
> so than raster-based systems like the Coco.
>
>> I have yet to actually use it in a real application.
> I've given it a good work out in the Williams games, plus Tutankham, Juno
> First and Coco 1/2. And of course there's System09 running FLEX and
> Coco3FPGA. I've also heard it's used in some Williams pinball circuit
> emulation. So it's definitely a core that's holding up well!
>
>> Congradulations on the new child. Get sleep when you can.
> Thanks! Coming up to 10 months now and we can almost claim our nights back! :O
>
> Regards,
>

-- 
http://www.johnkent.com.au
http://members.optusnet.com.au/jekent