Genesis 68K bus timing

[ijor]

I have some questions about Genesis if you don't mind. Knowing the accuracy of the Exodus emulator, you might have the knowledge. I also might provide some answers myself (see below)

I specialize in the 68K CPU. I am collaborating with other people in improving a Genesis FPGA core. I'm afraid I'm not very familiar with the Genesis and I'm trying to find as much information as possible. I found a lot of programming information, but hardly anything at the hardware level.

I am searching hardware level information about the interface with the 68K. Do you know if anybody performed logic analyzer traces showing the timing of the clock and the bus control signals? Or traces when performing bus arbitration (DMA)? Do you know if VPA is used for interrupts only? For all interrupts?

And because the 68K is my own area of expertise, I am making some small contributions Better at the next message ...

Thanks.

[ijor]

Browsing your code I looked a bit at your 68K implementation. Here I am providing some answers to some of the comments at your code:

Note that hardware tests have shown that all registers are not initialized to 0 when the processor is first powered on. In fact, it would appear that most likely all that is initialized is what is initialized by a normal reset operation, namely, PC, SSP, and SR. We know that the data registers and address registers 0-6 are uninitialized

Only the SR is initialized at reset, nothing else. The PC and the SSP are initialized only indirectly, as a consequence of reading the vectors at the exception process.

We have reason to believe that this interrupt execution time is too long for user interrupts on the Mega Drive. Tests with horizontal interrupts on the last line of the display indicate that horizontal interrupts need to be taken more quickly by the M68000

The interrupt exception time at the Motorola manual is correct. But as noted on the manual, it assumes an interrupt ack cycle taking 4 cycles. However I understand that Genesis interupts are autovector. Autovector interrupts use VPA and not DTACK and the interrupt ack cycle becomes a 6800 peripheral bus cycle. Then the timing is variable depending on the internal state of the E counter. See appendix B at the Motorola user manual for details.

This is based on a best guess, that the M68000 probably drives the data lines low before starting the read, and considers the interrupt vector number to be uninitialized if the resulting vector number is 0.

There is no such a thing. There is no concept of unitialized interrupt at the CPU. This is just a Motorola convention, a recommendation to the interrupt controllers to use that vector if the interrupt is not initialized. If DTACK is asserted the CPU expects the data bus to be driven during the ack cycle. And if it is not, it will read bus capacitance, pullups or just plain random noise.

[Mask of Destiny]

I am searching hardware level information about the interface with the 68K. Do you know if anybody performed logic analyzer traces showing the timing of the clock and the bus control signals?

Yes. 68K clock is always the master clock/7 (unless you count the Teradrive which can also run the CPU at 10MHz). !DTACK is normally asserted in time for a zero-wait state read, but there are periodic delays to ROM and RAM reads due to refresh. There is some incomplete info about that in this thread. !DTACK is also used to add wait states for access to the Z80's memory space and for reads/writes to the VDP data port when the FIFO is full (for writes) or prefetch has not occurred yet (for reads).

Or traces when performing bus arbitration (DMA)?

Yes. BR is asserted immediately by the VDP after the write that triggers a 68K->VDP DMA and by immediately, I mean early enough that the second word of a longword write will be delayed until after the DMA is compelete if the first write is what triggered the DMA. The bus arbiter will also request the bus for Z80 accesses in the $7F00-$FFFF range of its address space.

Do you know if VPA is used for interrupts only? For all interrupts?

Yes to both.

EDIT: I can dig up the actual captures if they would be useful to you

[ijor]

EDIT: I can dig up the actual captures if they would be useful to you

Thanks a lot. Yes, I'd love to see the captures, if it is not too much trouble.

[Enforcer]

Me too, if it’s not to much trouble.

[Mask of Destiny]

Here's a small collection of captures of various types of bus interactions. They are in Open Logic Sniffer Project format. Explanations below:

direct_color_dma.olp - Capture of the start of 68K->VDP DMA from one of Chilly WIlly's Direct Color DMA samples (note that !CAS and !RAS here refer to VRAM !CAS and !RAS)
68k_interrupts_vdp_enable.olp - Capture of enabling an interrupt via VDP registers that is pending and already enabled at the 68K labeled
68k_refresh_delays.olp - Capture of a number of signals running a simple test ROM that is constantly on the bus and alternates between RAM and ROM. Sadly I did not capture the necessary signals to actually see refresh for the cart/expansion area so I can only see their impact via !DTACK. RAM refresh cycles are directly visible though.
z80_bus_arbiter.olp - Capture of Z80 access to the 68K's memory space via the bus arbiter
68k_to_z80_bus_arbitration.olp - Capture of 68K access to Z80 memory space via the bus arbiter

[ijor]

Here's a small collection of captures of various types of bus interactions. They are in Open Logic Sniffer Project format. Explanations below:

Thanks a lot!