[Coco] Writing a CPU simulator for the 6809

[Ciaran Anscomb]

Tony Cappellini wrote:
> 2. Because I have a reasonably good understanding of how to emulate a CPU
> having looked at the source code for the Apple 2 simulator. Executing the
> CPU instruction set in software makes sense to me. What I haven't figured
> out how to do is to mimic the instruction cycles, so that my software
> version appears to run at the same speed as a real 6809.

You don't keep time across individual instructions, you count up the
amount of time that *should* have elapsed, then periodically perform
an action that introduces an appropriate delay.  Generally one of three
approaches:

1. Periodically check the system clock, see the difference between
   time that should have elapsed and time that has elapsed and sleep
   the difference.

2. Know (or set) the host's video refresh rate, run until the emulated
   time == one frame of video, then wait for vsync.

3. Know the audio sample rate and synchronise to that in a similar
   fashion.  With a blocking audio API, this is really easy: set a low
   buffer size and keep writing audio at the appropriate rate; the OS
   will delay emulation for you in probably the lowest-latency fashion
   you're likely to get.  The threaded callback based APIs everyone
   seems to like for some reason are a little trickier.

If video & audio are synchronous on your platform, 2 & 3 are effectively
identical, which would be nice, but very rare on modern systems.

You might end up doing 2 & 3 at the same time anyway - OpenGL buffer
swaps might well wait for vsync.  The slight delay in getting data to
the audio API is probably made up for by the audio buffer size though.

XRoar picks option 3 at the moment, mostly because it's unlikely you'll
be able to set the host video timings to *exactly* match the non-standard
output of a Dragon/CoCo.

> 3. I never really understood the details of the VDG and never really needed
> to understand what it does, back when I actually had a color computer. I
> think it is solely responsible for generating the correct timing of the video
> signal so that the user can see the coco displayed on a monitor.

That's all the VDG itself does, though some of those timings feed back
to the user in the form of interrupts coincident (ish) with horizonal &
vertical sync pulses.

> I really would like to see the sources for VCC.

I don't believe VCC's are open, but XRoar's sources are freely
available...  I make no guarantees about their quality though!

..ciaran