4

I'm currently learning C for my next emulation project, a cycle accurate 68000 core (my last project being a non-cycle accurate Sega Master System emulator written in Java which is now on its third release). My query regards cycle level accuracy as taking things to this level is a new thing for me.

To break things down to a granularity of 1 CPU cycle, presumably I need to know how long memory accesses take and so on, but my question is that for instructions that take multiple cycles in their memory fetch/write stages, what is the CPU doing each cycle - e.g. are x amount of bits copied per cycle.

With my SMS emulator I didn't have to worry too much about M1 stages etc, as it just used a cycle count for each instruction - in other words it is only accurate to an instruction level, not a cycle level. I'm not looking for architecture specific details, merely an idea of what sort of things I should look out for when going to this level of granularity.

68k details are welcome however. Basically I'm wondering what is supposed to happen if a video chip reads from an area of memory whilst a CPU is still writing the data to it mid way through that phase of an instruction, and other similar situations. I hope I've made it clear enough, thank you.

PhilPotter1987
  • 1,306
  • 2
  • 12
  • 20
  • 1
    I understand what you're trying to do, but I don't know what your actual question is. Making a truly cycle accurate simulator for any physical core is nearly impossible (there are just too many variables), so the real question is, what are your goals? How accurate do you want to be? If you're happy with 20%, then you can do that with a simple pipeline model and a simple memory model. – Nathan Binkert Jun 22 '12 at 18:15
  • I am thinking along the same kind of lines as BSNES accuracy as my 68k core will eventually go into a Megadrive/Genesis emulator. Basically, I'm wondering how to accurately model multi-cycle instructions at a per-cycle level - at the moment I just execute the whole instruction instantly in my Z80 core, then return the number of cycles it is supposed to take to a counter. There is no sense of 'what happens and when' within the instruction. – PhilPotter1987 Jun 23 '12 at 20:32

2 Answers2

1

My guess is that you don't have to get in to excruciating detail to get good enough results for the timing for this sort of thing. Which you can't do anyway f you don't want to get into the specifics of the architecture.

Your main question seemed to be "what is supposed to happen if a video chip reads from an area of memory whilst a CPU is still writing the data to it". Generally on these older chips, the bus protocols are pretty simple (they're not packetized) and there is usually a pin that indicates that the bus is busy. So if the CPU is writing to memory, the video chip will simply have to wait until the CPU is done. Because of these sorts of limitations, dual ported ram was popular for a while so that the frame buffer could be simultaneously written by the CPU and read by the RAMDAC.

Nathan Binkert
  • 8,744
  • 1
  • 29
  • 37
1

For a really cycle accurate emulation you have first to decide on a master clock you want to use as reference. That should be the fastest clock at which's granularity the software running can detect differences in order of occurance. This could by the CPU clock, but in most cases the bus cycle time decides at which granularity events can be discerned (and that is often only a fraction of the CPU clock).

Then you need to find out the precendence order the different devices (IC's) connected to that bus have (if there is more than one bus master). An example would be if (and how) video DMA can delay the CPU.

There exist generally no at the same time events. Either the CPU writes before the DMA reads, or the other way around (that is still true in case of dual ported devices, you just need to consider the device's inherent predence mechanism).

Once you have a solid understanding which clock is the effectively controlling the granularity of discernible events you can think about how to structure the emulator to reproduce that behaviour exactly.

This way you can create a 100% cycle exact emulation, given you have enough information about all the devices behavior.

Sorry I can't give you more detailed info, I know nothing about the specifics of the Sega's hardware.

Durandal
  • 19,919
  • 4
  • 36
  • 70