SpritesMind.Net

In the experiments, we get this memory map. Names for signals got from known pictures (Mega01.gif and Mega01.gif).

Great info !!! I think I find this useful for some hardware stuff I may make.

HardWareMan wrote:In the experiments, we get this memory map. Names for signals got from known pictures (Mega01.gif and Mega01.gif).

Hey excellent work, any chance of probing DTACK activation and number of clk cycles after AS? (speed check)

Jorge Nuno wrote:

HardWareMan wrote:In the experiments, we get this memory map. Names for signals got from known pictures (Mega01.gif and Mega01.gif).

Hey excellent work, any chance of probing DTACK activation and number of clk cycles after AS? (speed check)

!DTACK not activates in white areas. Also, in "A" area, it's activates only at this addresses (at other not activates):
$A00000-$A0FFFF - Z80 Area;
$А10000-$А100FF - IO
$A11000-$A110FF - Z80 Bus Control
$A12000-$A120FF - !FDC
$A13000-$A130FF - !TIME
$A14000-$A140FF - TMSS (OS ROM)
$A14100 - Cartridge Control Register (bit 8 = 0: cartridge disabled, OS; ROM enabled bit 8 = 1: cartridge enabled, OS ROM disabled)
$A15000-$A150FF - SVP (I'm thinking, SVP activate DTACK itself. Cartrige connector got this signal.)
Don't sure for "C" area (VDP).

WOW!! Only the # cycles elapsed between AS and DTACK remaining

Jorge Nuno wrote:WOW!! Only the # cycles elapsed between AS and DTACK remaining

Hmm... Maybe I can do this. But it's take some time. Maybe much time. But it's for real and it will be in "VCLK" or "EDCLK" units.

HardWareMan wrote:

Jorge Nuno wrote:

HardWareMan wrote:In the experiments, we get this memory map. Names for signals got from known pictures (Mega01.gif and Mega01.gif).

Hey excellent work, any chance of probing DTACK activation and number of clk cycles after AS? (speed check)

!DTACK not activates in white areas. Also, in "A" area, it's activates only at this addresses (at other not activates):
$A00000-$A0FFFF - Z80 Area;
$А10000-$А100FF - IO
$A11000-$A110FF - Z80 Bus Control
$A12000-$A120FF - !FDC
$A13000-$A130FF - !TIME
$A14000-$A140FF - TMSS (OS ROM)
$A14100 - Cartridge Control Register (bit 8 = 0: cartridge disabled, OS; ROM enabled bit 8 = 1: cartridge enabled, OS ROM disabled)
$A15000-$A150FF - SVP (I'm thinking, SVP activate DTACK itself. Cartrige connector got this signal.)
Don't sure for "C" area (VDP).

This is quite interesting, especially for emulation accuracy


Does this mean that the Genesis locks when accessing area where /DTACK do not activates?

PS: as you seem to have dedicated hardware, I always been interested in the actual timings of /VSYNC and /HSYNC signals (period & length), in relation with EDCLK and VCLK cycles... have you already measured this ?

Eke wrote:This is quite interesting, especially for emulation accuracy

Emulating system hangs, when accessing to forbidden addresses? Useless. Important information is only # cycles between AS and DTACK. But it still unknown. Maybe I measure it in the future.

Eke wrote:Does this mean that the Genesis locks when accessing area where /DTACK do not activates?

Yes. M68K simple hangs, but Z80 still working. Z80 can hangs too, if try access to M68K resourses (M68K not completed own bus cycle, so bus is still busy).

Eke wrote:PS: as you seem to have dedicated hardware, I always been interested in the actual timings of /VSYNC and /HSYNC signals (period & length), in relation with EDCLK and VCLK cycles... have you already measured this ?

No. Why should I do that? It's simple separated TV sync signals.
PS I made a device, that generate DTACK, when it not activate in 8 VCLK cycles. You can see it here (add-on in center). One binary counter and simple logic IC.

What's the danger of forcing the DTACK signal low (active) when the megadrive drives it high?

A big counter is the best solution for Eke's request...

Jorge Nuno wrote:What's the danger of forcing the DTACK signal low (active) when the megadrive drives it high?

A big counter is the best solution for Eke's request...

As far as I know, DTACK should be connected from open-collector outputs and should never be "driven" high.

Basically, what is needed is a bus-error circuit. I think a simple one (I saw this in a textbook on the 68000) can be made with a counter that starts when AS goes low, and after a few dozen clock cycles it asserts BERR. But of course you could use DTACK instead to just ignore the error.

The "danger" would be making DTACK go low too soon, when something needs a few cycles of wait state to finish, and either reading bad data or data not being written. 31 or 63 cycles should be more than enough.

OK I see it now: basically it is either low or tri-stated, and there have to be a pull-up somewhere, right?...

Asserting BERR would trigger an interrupt, wouldn't it?

HardWareMan wrote:Emulating system hangs, when accessing to forbidden addresses? Useless.

Not useless. A truly accurate emulators behaves as close to real hardware in ALL situation. Look at the C64 - while emulators are extremely accurate, they're still not 100%, and those inaccuracies DO break demos. And as we Genesis coders bang more and more and more on the hardware, we WILL end up creating code that works on hardware and that breaks on emulation.

HardWareMan wrote:Emulating system hangs, when accessing to forbidden addresses? Useless.

That can be useful for developers who uses emulators to make fast tests of their code.

Emulating system hangs can be useful, as it will save me lot of trouble finding out why my code doesn't run (if I manage to do some illegal write)...

No. Why should I do that? It's simple separated TV sync signals.
PS I made a device, that generate DTACK, when it not activate in 8 VCLK cycles. You can see it here (add-on in center). One binary counter and simple logic IC.

To know the exact cycle count (exprimed in pixel and 68k clocks) for one scanline/one frame... but this is a little off-topic, you're right