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

[Charles MacDonald]

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.

Hmm, I did this:

I set the bank to $FF8000-$FFFFFF and had the Z80 copy the first four bytes of $8000-$8003 to its own RAM and then increment $8004 in a loop. The 68K RAM was filled with $DEADBEEF. In VBlank I printed a portion of Z80 and 68K RAM.

The Z80 RAM showed the four bytes copied were $FFFFFFFF instead of $DEADBEEF.

The 68K RAM had zero written at offset $FF8004, because the increment operation by the Z80 read $FF (instead of $DE), incremented it to $00, and wrote it back.

Maybe that's too simple of a test and I should try something more complex later this week, it was just the fastest thing to code in a few minutes.

For all I know it could be influenced by even/odd addresses or using the low or high 32K of 68K work RAM. If you have any ideas I will certainly try them. It would be good to develop a comprehensive test, then I could post the source+ROM here and others could try on their systems.

[Stef]

Thanks for explaining.
Well I did almost same tests except Z80 was writing first, then read by 68k, modified and finally read back by Z80...
One thing is that i was actually trying to write non null values and so i was expecting non null values read from 68k. Maybe that each write from Z80 to 68k ram end by 0x00 to be effectively written.
I need to test that.

[Chilly Willy]

Another thought is to try reading/writing while the 68000 is running from cart, and again while running from ram. Might make a difference in the timing. We know that VDP DMA ops require the last bus cycle to be a ram cycle for proper operation - it might be something similar.

[Nemesis]

As a note, reads from the M68K RAM through Z80 banked memory access probably fail because the bus arbiter fails to assert EOE and NOE while forwarding requests to the M68K bus from the Z80 bus. This could even be a logic error or oversight in the bus arbiter, since EOE and NOE use the input line state of UDS and LDS respectively, but when the bus arbiter is forwarding a request from the Z80 bus to the M68K bus, the bus arbiter itself is asserting the lines, not reading them as an input, so perhaps in this case, they both read as not asserted?

The EOE and NOE lines act as the OE line inputs to the RAM chips, so if they aren't asserted, the RAM chips won't respond to the read request. Writes on the other hand could work, since they only rely on the LWR and UWR lines as their WE line inputs, which are asserted by the VDP, not the bus arbiter. We know the R/W line is asserted correctly because writes to the VDP/PSG work, so the VDP should assert all its output lines exactly the same for banked memory access, meaning there should be no reason why writes from the Z80 to M68K RAM shouldn't work reliably, bizarre bus timing issues aside that is. I had assumed that the bus arbiter was actually specifically blocking Z80 banked memory access to M68K RAM.

As a note, since it appears we've found at least one set of output lines which aren't asserted correctly by the bus arbiter for Z80 banked memory access, we should check other lines output by the bus arbiter too, eg, are the TIME and FDC lines asserted for access within their address blocks from the Z80?

[Eke]

If you have any ideas I will certainly try them. It would be good to develop a comprehensive test, then I could post the source+ROM here and others could try on their systems.

I think the most logical test would be to fill 68k RAM with a pattern as you did, have Z80 write a fixed byte ($55) in the whole 64k range then finally have 68k read its own RAM again and displays it. It could indeed be that Z80 writes to 68k RAM always end up with $00 being written...

Reading the whole RAM from Z80 could be interesting as well, though I think it's rather safe to assume now that $FF (open bus ?) is read from any address in this range.

[Charles MacDonald]

Reading the whole RAM from Z80 could be interesting as well, though I think it's rather safe to assume now that $FF (open bus ?) is read from any address in this range.

I'm glad you mentioned that -- I'll throw on some pull-down resistors and see if the value changes (meaning the bus is tristated) , or if the bus is really being driven with $FF.

[Jorge Nuno]

Hum, Tiido said that one of the 68k RAMs is used in SMS mode. The one with the fantom address line: IA14. If this line is disconnected (to use the real VA14, SMS mode won't work anymore). So /NOE has to work somewhat for the z80. In MD mode, swapping IA14 for VA14 has no effect.

But hey, I can give a 315-5364 to anyone for decapping purposes :p


...And maybe a 315-6123 while we are at it (Gen3 chipset with VScroll bug fixed and different sync generation)

[Charles MacDonald]

An update, writing any value to the FF0000-FFFFF range works fine (tried 00-255).

I have the feeling writes will always work and maybe there was some initial confusion about reads not working instead -- I noticed my old Genesis docs have a note saying writes work but reads don't. So perhaps reads were always the problem, not writes?

Also I was able to use the Z80 to write to registers in the TIME area (tried $A130FB), so that much can be confirmed.

[Stef]

I really wonder why i was almost certain than writes weren't possible... Anyway, too bad that only write is possible, the contrary would have be a lot more interesting (68k sending command to Z80).
Maybe we can find some use of it of this capability anyway

[Charles MacDonald]

I really wonder why i was almost certain than writes weren't possible... Anyway, too bad that only write is possible, the contrary would have be a lot more interesting (68k sending command to Z80).
Maybe we can find some use of it of this capability anyway

At least now we know several games are writing to RAM and that doing so is completely valid.

I suppose it would be useful for the Z80 to set a flag or write a status byte telling the 68K it is done processing, instead of wasting time requesting the bus just to check a Z80 RAM location.