Are we sure MD Z80 can't write to M68K RAM? NCS does it...

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

andlabs
Very interested
Posts: 62
Joined: Sat Aug 08, 2009 4:44 pm

Are we sure MD Z80 can't write to M68K RAM? NCS does it...

Post by andlabs » Tue Oct 04, 2011 1:40 am

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.

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Re: Are we sure MD Z80 can't write to M68K RAM? NCS does it.

Post by Charles MacDonald » Tue Oct 04, 2011 5:13 am

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

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.

User avatar
Stef
Very interested
Posts: 2774
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Tue Oct 04, 2011 7:38 am

I remember that another game : 777 casino was doing that too but i think it was a mistake from developers.
As you said write to 68k RAM from Z80 doesn't work (unfortunately).
Reads doesn't work either by the way...
Are you sure you have to emulate that writes to make the game working ?

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

Post by Eke » Tue Oct 04, 2011 11:49 am

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) !
I remember that another game : 777 casino was doing that too but i think it was a mistake from developers.
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.

andlabs
Very interested
Posts: 62
Joined: Sat Aug 08, 2009 4:44 pm

Post by andlabs » Tue Oct 04, 2011 1:24 pm

Yes, 777 Casino will clobber 68000 RAM if the copy protection check fails.

I'll take a closer look at this game's driver codeflow later today. Thanks for the help so far!

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

Post by Eke » Tue Oct 04, 2011 3:41 pm

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.

User avatar
Nemesis
Very interested
Posts: 689
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Post by Nemesis » Thu Oct 06, 2011 11:14 pm

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?

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

Post by Eke » Fri Oct 07, 2011 9:08 am

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?
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: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 log all access to these odd registers and nothing came up for this sone, it is never written with anything.

andlabs
Very interested
Posts: 62
Joined: Sat Aug 08, 2009 4:44 pm

Post by andlabs » Fri Oct 07, 2011 3:25 pm

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

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Tue Oct 11, 2011 12:48 am

I'll test it on a few different Genesis systems (Gen1/2/3/MD1) this weekend unless somebody else is doing it -- otherwise I can save myself some trouble. :)

andlabs
Very interested
Posts: 62
Joined: Sat Aug 08, 2009 4:44 pm

Post by andlabs » Wed Oct 12, 2011 2:35 pm

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

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Sun Oct 16, 2011 8:32 pm

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.

User avatar
Stef
Very interested
Posts: 2774
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Mon Oct 17, 2011 8:18 am

Charles MacDonald wrote:So I can confirm the Z80 can write to 68K RAM just fine....
How you managed to get that working ???
I made many tests about it and i never worked :-(
I tried to make the Z80 increasing slowly a byte in 68k ram, and the 68k to read and display that number... without sucess.

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

Post by Eke » Mon Oct 17, 2011 10:05 am

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.
Great, thanks for confirming it.
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.
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 ?
The fact reading is not possible indicates that Z80 access to 68k bus is a little tricky.

User avatar
Stef
Very interested
Posts: 2774
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Mon Oct 17, 2011 4:00 pm

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 ?
Well, that would be pretty useless then as it would result in potential miss writes :-/

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests