[Coco] Learning CPU Architecture and Digital Design
Arthur Flexser
flexser at fiu.edu
Wed Feb 20 03:24:23 EST 2013
When I switched out my 6809 for a 6309, I found no software whose timing
was affected in any noticeable way. The only thing that worked
differently, under Disk Basic, was a couple of oddball pieces of software
that used illegal opcodes, which the 6309 vectored to the appropriate
uninitialized error address, generally causing a crash. ($3E causes a
reset on the 6809 but is considered illegal by the 6309, somewhat
unfortunately.)
Art
On Wed, Feb 20, 2013 at 2:26 AM, John Kent <jekent at optusnet.com.au> wrote:
>
> 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<http://members.optusnet.com.au/jekent>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/**mailman/listinfo/coco<http://five.pairlist.net/mailman/listinfo/coco>
>
More information about the Coco
mailing list