Genesis Address Bus and Max RAM
Moderator: BigEvilCorporation
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
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.
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.
-
- Very interested
- Posts: 256
- Joined: Tue Sep 11, 2007 9:10 pm
If you could scan them, that'd be great. 6502.org might be interested in them too.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.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 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.
Anywho, the 68000 was released in 1979, so microcoding in common CPUs has been around a LONG time.
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
In the experiments, we get this memory map. Names for signals got from known pictures (Mega01.gif and Mega01.gif).
Last edited by HardWareMan on Mon Jan 07, 2008 7:03 am, edited 1 time in total.
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
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
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
!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).
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
This is quite interesting, especially for emulation accuracyHardWareMan wrote:!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).
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 ?
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
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:This is quite interesting, especially for emulation accuracy
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:Does this mean that the Genesis locks when accessing area where /DTACK do not activates?
No. Why should I do that? It's simple separated TV sync signals.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 ?
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.
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
-
- Very interested
- Posts: 159
- Joined: Sat Feb 24, 2007 11:35 pm
- Location: San Antonio, TX
As far as I know, DTACK should be connected from open-collector outputs and should never be "driven" high.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...
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.
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
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.