New Documentation: M68000 microcode-level bus access timing

[Nemesis]

Well I plan to actually add in accurate DTACK emulation, which could impact speed because it requires interaction from the Bus Arbiter/VDP, but I won't know the performance impact for sure until I implement it. I will be keeping the existing core around though, yes.

[PiCiJi]

I mean, what will be the perfect 68k emulator?

I would say something like this: http://visual6502.org/

At the beginning of the third clock cycle, the state of DTACK is latched is latched. If DTACK hasn't been asserted, this clock cycle repeats until DTACK is asserted. This will loop infinitely if DTACK is never asserted.

in case of amiga the bus wait cycle count is always divisible by two, because there is no 68k operation which is not divisible by two.
Disregarded that the speed of real systems differs among each other in comparison to emulation. So it could be possible that the bus wait time is not divisible by two in a real system. But such like behavior can not be repeated. It differs always. Emulating such randomness is tricky. I think it's better to let emulation run in a perfect world.

[Mask of Destiny]

in case of amiga the bus wait cycle count is always divisible by two, because there is no 68k operation which is not divisible by two.

It's not the 68K that's causing the delay to be a multiple of 2 cycles in the Amiga. At least not directly anyway. The Amiga has a somewhat unusual memory bus arrangement that takes advantage of the fact that it takes the 68000 4 cycles to complete a memory operation. 4 cycles is a relatively long time at 7-8MHz so it's not hard to find memory that could complete 2 operations in that time and that's what the Amiga does. One memory operation feeds the 68000 and the other is used to feed other hardware so that most of the time the 68000 is not slowed down. Some hardware competes with the 68000 though and some instructions have a duration that's not a multiple of 4 so it can get temporarily desynced with its slot. However, since all the bus operations take 2 cycles, the delay will always be a multiple of 2 cycles. (At least that's my understanding of the setup in the Amiga. I admittedly haven't looked into it in great detail).

On a system like the Megadrive/Genesis though, things are different. The VDP doesn't run at a clean multiple of the 68K clock so if the VDP holds up the 68K because the FIFO is full it's not necessarily going to delay it by a multiple of 2 68K clocks.

[PiCiJi]

It's not the 68K that's causing the delay to be a multiple of 2 cycles in the Amiga.

Yes I wasn't clear enough. It's because an amiga bus operation takes always 2 cpu cycles for each subsystem and each 68k operation is always divisible by two.

Some hardware competes with the 68000 though and some instructions have a duration that's not a multiple of 4 so it can get temporarily desynced with its slot.

Basicly the amiga 68k can use each free bus slot (even or odd). But the chance is a lot higher that an odd bus slot is occupied by dma.

But I am not so sure if the wait time is in all cases a multiple of two for "real system". The cpu is running concurrently besides other bus participants and each part of hardware differs a little bit from default speed.

[Mask of Destiny]

Thanks for the clarifications.

But I am not so sure if the wait time is in all cases a multiple of two for "real system". The cpu is running concurrently besides other bus participants. Each cpu differs a little bit from default speed.

I would think that in a stock 500/1000/2000 that it's always a multiple of two since the CPU is running off the same base clock as everything else. Obviously things get messy when you have a CPU upgrade installed though.

[Nemesis]

I've changed my plans for the new M68000 core in Exodus. I was planning to simply add proper timing for external bus operations, and not do a full-blown microcode level emulation of the M68000, but after looking more closely at all the issues, in particular inconsistencies with what data is pushed to the stack in the event of an address or bus error, it seems the only way to get full accuracy for all these cases is to do a full microcode level emulation of the core. That's now my focus. I'm currently analysing the patent information and I'm going to attempt to emulate the M68000 at a full microcode level. If anyone has any other documentation, or even transcriptions of the patent information, I'd be very interested to see it.

[Shadow]

it seems the only way to get full accuracy for all these cases is to do a full microcode level emulation of the core. That's now my focus. I'm currently analysing the patent information and I'm going to attempt to emulate the M68000 at a full microcode level.

I glad to hear it. ^_^

[r57shell]

I'm currently analysing the patent information and I'm going to attempt to emulate the M68000 at a full microcode level.

Man, you mad, definitely. It's too bad.
Please, don't leave us.

[Shadow]

Man, you mad, definitely. It's too bad.
Please, don't leave us.

Let him do it.

No matter, how many CPU power will use, it will be first extreme accurate Mega Drive emulator.