Are we sure MD Z80 can't write to M68K RAM? NCS does it...
Moderator: BigEvilCorporation
Are we sure MD Z80 can't write to M68K RAM? NCS does it...
I am helping GerbilSoft fix a bug I found in his semi-rewrite Gens/GS II: Mamono Hunter Youko halts during the level load. We looked a bit into it and determined that the Z80 sound driver appears to be writing to MC68000 RAM... but wasn't it determined that this wasn't allowed on all but the earliest Mega Drives? This game was released in March 1991.
Sound driver is full 8KB at ROM $1E000. There are two functions at Z80 $120 and $12D that switch the ROM bank to $FF0000 and $FF8000, respectively. After the former, $FF0800 and $FF00Cx are written to. After the latter, $FFEFF2 (and probably something else I don't know what) is written to.
Thanks.
Sound driver is full 8KB at ROM $1E000. There are two functions at Z80 $120 and $12D that switch the ROM bank to $FF0000 and $FF8000, respectively. After the former, $FF0800 and $FF00Cx are written to. After the latter, $FFEFF2 (and probably something else I don't know what) is written to.
Thanks.
-
- Very interested
- Posts: 292
- Joined: Sat Apr 21, 2007 1:14 am
Re: Are we sure MD Z80 can't write to M68K RAM? NCS does it.
Well I've tested this on a number of Genesis consoles and Z80 writes to 68K RAM never work in any situation I tried. I've also played that game you mentioned on these systems and it runs fine, sound and SFX too. But maybe there is a unique combination of events where these writes do work.andlabs wrote:I am helping GerbilSoft fix a bug I found in his semi-rewrite Gens/GS II: Mamono Hunter Youko halts during the level load. We looked a bit into it and determined that the Z80 sound driver appears to be writing to MC68000 RAM... but wasn't it determined that this wasn't allowed on all but the earliest Mega Drives? This game was released in March 1991.
Are the writes to RAM required for the game to run? Now and then you find games with debug code left in that write to ROM or do other things that don't affect the real machine, but would have had a purpose in the development hardware.
Is this the only game we know of that that writes to 68K RAM using the Z80? It would be interesting if only one game in the entire Genesis library does it.
See end of this thread:
viewtopic.php?t=347
I confirm that this game hangs during the intro if you don't emulate 68k RAM writes from Z80. I also confirm it works on my PAL Mega Drive so it's not something only working on old japanese models.
And it's 68k which is hanging, waiting for a specific value to be written in RAM, which it never does itself (apparently) !
viewtopic.php?t=347
I confirm that this game hangs during the intro if you don't emulate 68k RAM writes from Z80. I also confirm it works on my PAL Mega Drive so it's not something only working on old japanese models.
And it's 68k which is hanging, waiting for a specific value to be written in RAM, which it never does itself (apparently) !
This game has copy protection. I think I remember Z80 is reading from normally unused cartridge areas ($4xxxxx) and uses those values returned as an index for later ROM bank access. If the emulator returns $FF on illegal/unused access as many do, it could end up programming a 68k RAM banked access.I remember that another game : 777 casino was doing that too but i think it was a mistake from developers.
Apart from that, it would be interesting to figure how the banking mechanism actually works, and eventually why Z80 would be able to access anything the 68k can (except its own bus off course) through banking but not 68k RAM.
I used those schematics as reference:
http://emudocs.org/Genesis/mega1.png
http://emudocs.org/Genesis/mega2.png
As far as I can tell, banking is managed through the I/O chip and is triggered by the Bus Arbitrer which asserts ZTOV (or VTOZ ?) when ZA15 is set.
This probably makes the Bus Arbitrer drive VA23-VA15 (using bank register 9-bit value) and the I/O chip drives VA14-VA1 (using ZA14-ZA1). On read, this chip copies VD0-VD7 (if ZA0 is set) or VD8-VD15 (if ZA0 is cleared) to ZD0-ZD7 and most likely on writes, ZD0-ZD7 is copied to both VD0-VD7 and VD8-VD15.
I don't know about the other signals (/AS, /RW, /UDS and /LDS) normally used for address decoding but at least the first two are required if Z80 can read/write the VDP (which has been reported to be possible).
Lastly, the bus arbitrer needs to request the 68k bus, which is most likely done by using the 68k bus request mechanism. I have no idea how many cycles the bus is kept and no idea either about the timings of bus request.
So I see 2 possible causes:
1) missing signals: /UDS and /LDS are not asserted, which makes impossible to determine the selected RAM module. Those signals are used on writes by the VDP to assert /LWR or /UWR and on reads by the Bus Arbitrer to assert /EOE or /NOE.
2) incompatible timings: 68k bus access timing are incompatible with RAM timings.
Second hypothesis seems very unlikely since there is no problem with ROM. Still, correct timings would be interesting to know for accurate emulation of banked ROM access. The opposite (banked access to Z80 from 68k), which probably goes through the same mechanism (inverted), would be interesting to get as well.
I used those schematics as reference:
http://emudocs.org/Genesis/mega1.png
http://emudocs.org/Genesis/mega2.png
As far as I can tell, banking is managed through the I/O chip and is triggered by the Bus Arbitrer which asserts ZTOV (or VTOZ ?) when ZA15 is set.
This probably makes the Bus Arbitrer drive VA23-VA15 (using bank register 9-bit value) and the I/O chip drives VA14-VA1 (using ZA14-ZA1). On read, this chip copies VD0-VD7 (if ZA0 is set) or VD8-VD15 (if ZA0 is cleared) to ZD0-ZD7 and most likely on writes, ZD0-ZD7 is copied to both VD0-VD7 and VD8-VD15.
I don't know about the other signals (/AS, /RW, /UDS and /LDS) normally used for address decoding but at least the first two are required if Z80 can read/write the VDP (which has been reported to be possible).
Lastly, the bus arbitrer needs to request the 68k bus, which is most likely done by using the 68k bus request mechanism. I have no idea how many cycles the bus is kept and no idea either about the timings of bus request.
So I see 2 possible causes:
1) missing signals: /UDS and /LDS are not asserted, which makes impossible to determine the selected RAM module. Those signals are used on writes by the VDP to assert /LWR or /UWR and on reads by the Bus Arbitrer to assert /EOE or /NOE.
2) incompatible timings: 68k bus access timing are incompatible with RAM timings.
Second hypothesis seems very unlikely since there is no problem with ROM. Still, correct timings would be interesting to know for accurate emulation of banked ROM access. The opposite (banked access to Z80 from 68k), which probably goes through the same mechanism (inverted), would be interesting to get as well.
Yikes. This has been on my list to test for awhile, but based on all the tests performed by others, I was expecting to find it wasn't possible.
I have a logic analyzer, so I can hook up to the bus signals and get a definitive answer on what's actually going on here. I don't expect to do it for awhile though. I'm messing around with the LaserActive and the VDP right now.
I have one question though: The Z80 sound driver for this game, does it continuously write to M68K ram in a loop until it works, or does it perform the write once and only once? Maybe writes to M68K RAM from the Z80 usually fail, but they just keep on hammering away until it gets through?
If the write is performed once only, and yet the game consistently boots on later systems as well as early systems, maybe there's another factor here we haven't considered. Crazy idea: maybe another setting in the Bus Arbiter affects the success of this operation, eg, the "Memory Mode" setting at 0xA11000? Since setting this to DRAM is specifically intended for development cartridges, maybe it also releases some restrictions, eg, blocking access from the Z80 to M68K RAM, to aid in debugging? Does this game set this register to anything other than 0?
I have a logic analyzer, so I can hook up to the bus signals and get a definitive answer on what's actually going on here. I don't expect to do it for awhile though. I'm messing around with the LaserActive and the VDP right now.
I have one question though: The Z80 sound driver for this game, does it continuously write to M68K ram in a loop until it works, or does it perform the write once and only once? Maybe writes to M68K RAM from the Z80 usually fail, but they just keep on hammering away until it gets through?
If the write is performed once only, and yet the game consistently boots on later systems as well as early systems, maybe there's another factor here we haven't considered. Crazy idea: maybe another setting in the Bus Arbiter affects the success of this operation, eg, the "Memory Mode" setting at 0xA11000? Since setting this to DRAM is specifically intended for development cartridges, maybe it also releases some restrictions, eg, blocking access from the Z80 to M68K RAM, to aid in debugging? Does this game set this register to anything other than 0?
As far as I can tell, 68k RAM is written once per frame by Z80, various addresses being used. I'm still not sure those writes are done on purpose or simply a mistake in the code. It "seemed" to me that 68k was locked waiting for a value in RAM but I'm not that much certain anymore, maybe it's something else, related to missing interrupts for example ?Nemesis wrote: I have one question though: The Z80 sound driver for this game, does it continuously write to M68K ram in a loop until it works, or does it perform the write once and only once? Maybe writes to M68K RAM from the Z80 usually fail, but they just keep on hammering away until it gets through?
I log all access to these odd registers and nothing came up for this sone, it is never written with anything.Nemesis wrote:If the write is performed once only, and yet the game consistently boots on later systems as well as early systems, maybe there's another factor here we haven't considered. Crazy idea: maybe another setting in the Bus Arbiter affects the success of this operation, eg, the "Memory Mode" setting at 0xA11000? Since setting this to DRAM is specifically intended for development cartridges, maybe it also releases some restrictions, eg, blocking access from the Z80 to M68K RAM, to aid in debugging? Does this game set this register to anything other than 0?
I still need to look into it, however my guess is that the $FF0800 is a flag used to indicate music is ready to play or something, since it doesn't lock up until a level is loaded.
Apparently this game uses the NCS/Explode Star sound driver, which was only used in two other games: Trampoline Terror! (which is Explode Star, and which was released earlier) and Sorcerer's Kingdom (which was released later). Neither lock up this way...
Apparently this game uses the NCS/Explode Star sound driver, which was only used in two other games: Trampoline Terror! (which is Explode Star, and which was released earlier) and Sorcerer's Kingdom (which was released later). Neither lock up this way...
-
- Very interested
- Posts: 292
- Joined: Sat Apr 21, 2007 1:14 am
As far as I know it does not write $A11000. I'd have to look into how the A-line opcodes, which it seems to use for some VDP accesses, works.
The sound driver only writes values once before continuing.
The write to $FF0800 happens once a nonzero value is written to Z80 $1BFB. The only reference to that address I can see on the 68000 side is at ROM $4350, which comes after the 68000 sets $FF0800 to $FF itself, then does stuff with a jump table that overwrites bytes in the $FF06xx range. The Z80 sets it to 0 once all that and more is done. Data is copied to the Z80 immediately before ($200 bytes from $FF0400, which this routine, which starts at ROM $4298, also writes to, to Z80 $1C00), so this sounds like new data load+sync... In this particular block, the Z80 is locked by trap #0, which does nothing but bus request.
EDIT - Trampoline Terror! only banks to $8000, never to RAM...
The sound driver only writes values once before continuing.
The write to $FF0800 happens once a nonzero value is written to Z80 $1BFB. The only reference to that address I can see on the 68000 side is at ROM $4350, which comes after the 68000 sets $FF0800 to $FF itself, then does stuff with a jump table that overwrites bytes in the $FF06xx range. The Z80 sets it to 0 once all that and more is done. Data is copied to the Z80 immediately before ($200 bytes from $FF0400, which this routine, which starts at ROM $4298, also writes to, to Z80 $1C00), so this sounds like new data load+sync... In this particular block, the Z80 is locked by trap #0, which does nothing but bus request.
EDIT - Trampoline Terror! only banks to $8000, never to RAM...
-
- Very interested
- Posts: 292
- Joined: Sat Apr 21, 2007 1:14 am
Great, thanks for confirming it.So I can confirm the Z80 can write to 68K RAM just fine, but reads always return $FF for these systems:
Genesis 1 (No TMSS), Mega Drive 1 (TMSS), Genesis 2 (TMSS), Genesis 3 (TMSS)
$A11000 seems to have no effect.
Maybe it does not work if 68k is reading from its RAM at the same time, access might be locked when Z80 is taking the bus ?made many tests about it and i never worked Sad
I tried to make the Z80 increasing slowly a byte in 68k ram, and the 68k to read and display that number... without sucess.
The fact reading is not possible indicates that Z80 access to 68k bus is a little tricky.