Genesis Address Bus and Max RAM

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Fri Nov 30, 2007 12:50 am

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.

tomaitheous
Very interested
Posts: 256
Joined: Tue Sep 11, 2007 9:10 pm

Post by tomaitheous » Sat Dec 01, 2007 9:21 pm

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.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sat Dec 01, 2007 11:06 pm

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.

HardWareMan
Very interested
Posts: 745
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Sat Dec 15, 2007 8:03 am

In the experiments, we get this memory map. Names for signals got from known pictures (Mega01.gif and Mega01.gif).
Image
Last edited by HardWareMan on Mon Jan 07, 2008 7:03 am, edited 1 time in total.

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Sat Dec 15, 2007 6:55 pm

Great info !!! I think I find this useful for some hardware stuff I may make.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Sat Dec 15, 2007 7:57 pm

HardWareMan wrote:In the experiments, we get this memory map. Names for signals got from known pictures (Mega01.gif and Mega01.gif).
Image
Hey excellent work, any chance of probing DTACK activation and number of clk cycles after AS? (speed check)


:wink:

HardWareMan
Very interested
Posts: 745
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Sun Dec 16, 2007 4:58 am

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).
Image
Hey excellent work, any chance of probing DTACK activation and number of clk cycles after AS? (speed check)
:wink:
!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).

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Sun Dec 16, 2007 10:43 am

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

HardWareMan
Very interested
Posts: 745
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Sun Dec 16, 2007 1:41 pm

Jorge Nuno wrote:WOW!! Only the # cycles elapsed between AS and DTACK remaining :D
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.

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Sun Dec 16, 2007 4:53 pm

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).
Image
Hey excellent work, any chance of probing DTACK activation and number of clk cycles after AS? (speed check)
:wink:
!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
:wink:

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 ?

HardWareMan
Very interested
Posts: 745
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Sun Dec 16, 2007 5:33 pm

Eke wrote:This is quite interesting, especially for emulation accuracy
:wink:
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.

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Sun Dec 16, 2007 5:51 pm

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...

8bitwizard
Very interested
Posts: 159
Joined: Sat Feb 24, 2007 11:35 pm
Location: San Antonio, TX

Post by 8bitwizard » Sun Dec 16, 2007 8:39 pm

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.

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Sun Dec 16, 2007 8:55 pm

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?

LocalH
Very interested
Posts: 152
Joined: Tue Dec 19, 2006 5:04 pm

Post by LocalH » Mon Dec 17, 2007 12:12 am

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.

Post Reply