SpritesMind.Net

Lately i was playing with z80 and i done some 68k ram access test. it works perfectly on emulator but my attempts failed on real hardware. At least the z80 isn't able to modify the 68k ram. I've rarely saw any games doing that (except '777 casino' but with inexpected result, i guess devers did something wrong here).
Does someone know if that's really possible ? i would love it is :-/ maybe it requires some obscure usage to get it to work... Thanks by advance for any help here =)

Hi,

Steve Snake said(its also written in Charles MacDonalds's docs) that it was indeed possible on very early models. These were used for developing games. Later models would either lock-up or as in my case return 0xFF. I think only some models allowed it.

stay safe,

AamirM

AamirM wrote:Hi,

Steve Snake said(its also written in Charles MacDonalds's docs) that it was indeed possible on very early models. These were used for developing games. Later models would either lock-up or as in my case return 0xFF. I think only some models allowed it.

stay safe,

AamirM

Yeah i remember that talk. Anyway i woul like to be certain about this point :p
In my case writing to the 68000 ram from z80 doesn't seem to do anythink (tested on a pal genesis model 1)... afaik i don't know if it's the read or the write which doesn't work. I'll do more tests. I need to know what work or not, no i need to get that to work, hardware compliant or not X'D
thanks for your reply

Well, there IS a bug in the real hardware associated with the Z80 accessing the 68000 bus: if the 68000 ever accesses $A100xx (the pads) without first requesting the Z80 bus, the Z80 will no longer be able to read/write the 68000 bus correctly. Apparently, the hardware cuts the Z80 cycles to the 68000 bus short after that. So anytime you read/write $A100xx, you are supposed to request the Z80 bus, THEN read/write $A100xx, then release the Z80 bus.

Chilly Willy wrote:Well, there IS a bug in the real hardware associated with the Z80 accessing the 68000 bus: if the 68000 ever accesses $A100xx (the pads) without first requesting the Z80 bus, the Z80 will no longer be able to read/write the 68000 bus correctly. Apparently, the hardware cuts the Z80 cycles to the 68000 bus short after that. So anytime you read/write $A100xx, you are supposed to request the Z80 bus, THEN read/write $A100xx, then release the Z80 bus.

Yep, that's mentionned in the manual but afaik that's not always true.
I did some demos of WAV playback, the demo wasn't requesting the Z80 bus on pad access and Z80 was still able to correctly fetch data from the 68000 bus (in rom exactly). It worked nicely on real hardware as on emulator of course. I think the behavior occurs only in some situations but not always.

Well, the addendum makes it sound like it's always, but it probably varies according to the exact revision of the chips used. It's possible it's even fixed on certain models.

There's also that issue on bus requesting the Z80 during an interrupt. That combined with the $A100xx issue is something to keep in mind or some folks will have trouble.

Chilly Willy wrote:Well, the addendum makes it sound like it's always, but it probably varies according to the exact revision of the chips used. It's possible it's even fixed on certain models.

There's also that issue on bus requesting the Z80 during an interrupt. That combined with the $A100xx issue is something to keep in mind or some folks will have trouble.

Ok, it's something important to know anyway, because we can search for hour and finally discover it was just a typo which that point.
Anyway i investigated a bit more and it appears that we can't do even 68000 ram read from the Z80 as Charles Mc Donald was refering in his document. I'll do all possible tests on my 2 megadrive (too bad my japan model 1 is broken, maybe it was more friendly for that type of manipulation).

Ok, i done all possible tests and i can confirm it is *not* possible to access 68k RAM from Z80. Any read from the Z80 return $FF and write doesn't work, they are simply ignored...
I tested on each possible areas ($E00000 to $FF0000) and it gave always the same result. I tested on a PAL model 1 and a PAL model 2, same result. Charles Mc Donald infos were totally right
I'm a bit dissapointed, i want to have 68000 <--> Z80 communication without interrupt Z80. I guess i'll have to investigate the VDP solution, a lot less pratical :-/

Yes, pity that the Z80 can't do simple access to M68K RAM. I think this is all becouse they were to want to use DRAM (all the necessary signals and mode chipset is also available), and DRAM is difficult to synchronize with M68K, let alone for independ Z80. But with the ROM all simple - it always gives the data when it's activated.

Chilly Willy wrote:Well, there IS a bug in the real hardware associated with the Z80 accessing the 68000 bus: if the 68000 ever accesses $A100xx (the pads) without first requesting the Z80 bus, the Z80 will no longer be able to read/write the 68000 bus correctly. Apparently, the hardware cuts the Z80 cycles to the 68000 bus short after that. So anytime you read/write $A100xx, you are supposed to request the Z80 bus, THEN read/write $A100xx, then release the Z80 bus.

HOHOOOO... I never halt Z80 when reading control pads, and my sound engine doesn't go crazy then... I must be lucky or something. It works on my MD2 and on my MD1s without TMSS.

TmEE co.(TM) wrote:

Chilly Willy wrote:Well, there IS a bug in the real hardware associated with the Z80 accessing the 68000 bus: if the 68000 ever accesses $A100xx (the pads) without first requesting the Z80 bus, the Z80 will no longer be able to read/write the 68000 bus correctly. Apparently, the hardware cuts the Z80 cycles to the 68000 bus short after that. So anytime you read/write $A100xx, you are supposed to request the Z80 bus, THEN read/write $A100xx, then release the Z80 bus.

HOHOOOO... I never halt Z80 when reading control pads, and my sound engine doesn't go crazy then... I must be lucky or something. It works on my MD2 and on my MD1s without TMSS.

Same here and honestly i'm happy we don't need that !

Stef wrote:

TmEE co.(TM) wrote:

Chilly Willy wrote:Well, there IS a bug in the real hardware associated with the Z80 accessing the 68000 bus: if the 68000 ever accesses $A100xx (the pads) without first requesting the Z80 bus, the Z80 will no longer be able to read/write the 68000 bus correctly. Apparently, the hardware cuts the Z80 cycles to the 68000 bus short after that. So anytime you read/write $A100xx, you are supposed to request the Z80 bus, THEN read/write $A100xx, then release the Z80 bus.

HOHOOOO... I never halt Z80 when reading control pads, and my sound engine doesn't go crazy then... I must be lucky or something. It works on my MD2 and on my MD1s without TMSS.

Same here and honestly i'm happy we don't need that !

If you only run the Z80 on it's own memory and use the 68000 to transfer all data to the Z80 memory, then you'll never see the problem. The problem is with the Z80 accessing the 68000 bus - accessing the ROM I would guess is the main example. Also as I mentioned, it's probably fixed for new Gennys (and certainly isn't an issue for emus), but you should still do it for folks with old Gennys.

My sound engine moves about 50KB of data per second to YM2612 form ROM area...

Chilly Willy wrote:

Stef wrote:

TmEE co.(TM) wrote: HOHOOOO... I never halt Z80 when reading control pads, and my sound engine doesn't go crazy then... I must be lucky or something. It works on my MD2 and on my MD1s without TMSS.

Same here and honestly i'm happy we don't need that !

If you only run the Z80 on it's own memory and use the 68000 to transfer all data to the Z80 memory, then you'll never see the problem. The problem is with the Z80 accessing the 68000 bus - accessing the ROM I would guess is the main example. Also as I mentioned, it's probably fixed for new Gennys (and certainly isn't an issue for emus), but you should still do it for folks with old Gennys.

Of course i was speaking of example where we use the 68000 BUS from Z80, but i assure you i never met any problems. I think it can happen but rarely in fact.

Stef wrote: Of course i was speaking of example where we use the 68000 BUS from Z80, but i assure you i never met any problems. I think it can happen but rarely in fact.

Yes, but SEGA says it will give SOME people a problem SOMETIMES. If your stuff is aimed at a small group, you can probably ignore a lot of these things (especially if it's just for yourself). However, if what you are doing is aimed at the general public, you SHOULD do these things, even if you never see a problem yourself. SEGA doesn't make these things up out of thin air - they're actual issues they've gotten complaints about from users or developers.

For example, you can poll some SEGA controllers more often than 60 times a second, but some controllers WILL fail to return valid data if you do. If you are doing something for yourself and you've verified all your controllers work faster than 60 Hz, no problem. If it's for the general public, you shouldn't poll the controller more than 60 times a second or those people with the problem controllers won't be able to use your game. That's why SEGA told developers to not poll the controllers any faster than that. They suggest you do it during the vertical blank, and not any more often than the vertical blank, for just that reason.