SpritesMind.Net

I'll try to dig up those docs and scan them. They were really useful at the time when I got them (sent in a request for info and samples on company stationary). There was one REALLY odd processor they had in particular - it was two 65C02's in a single package. Quite a bit of the timing was the same, but the microcoding did make some off a little, and a few off a lot.

There are a number of 16bit coding formats for different RISC chips to make them more attractive for embedded devices. You mentioned the ARM Thumb - there's also the MIPS16, and the SH2 family. Even then, the instructions are just a single 16 bit word, while the 68K uses variable numbers of 16 bit words. I can see how that would throw you off if you hadn't looked at it in a while. I just so familiar with it because I did so much assembly programming on the 68K, having also done a 68K emulation on the PC.

Chilly Willy wrote:I'll try to dig up those docs and scan them. They were really useful at the time when I got them (sent in a request for info and samples on company stationary). There was one REALLY odd processor they had in particular - it was two 65C02's in a single package. Quite a bit of the timing was the same, but the microcoding did make some off a little, and a few off a lot.

There are a number of 16bit coding formats for different RISC chips to make them more attractive for embedded devices. You mentioned the ARM Thumb - there's also the MIPS16, and the SH2 family. Even then, the instructions are just a single 16 bit word, while the 68K uses variable numbers of 16 bit words. I can see how that would throw you off if you hadn't looked at it in a while. I just so familiar with it because I did so much assembly programming on the 68K, having also done a 68K emulation on the PC.

If you could scan them, that'd be great. 6502.org might be interested in them too.

Well, I can't find the info saying the 65C02 was microcoded... so I'll withdraw that statement until such time as I can find it again. The info I HAVE found says the first microcoded CPU used by home computers was the 68000. Maybe I was confusing the two in my head... it's been 25 years and I did a LOT of 68000 programming, so I could see myself confusing the two over that detail. Sorry if I confused anyone.

Anywho, the 68000 was released in 1979, so microcoding in common CPUs has been around a LONG time.

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.