68000 ram access from z80 ?

[TmEE co.(TM)]

well, when someone spots some issues in some of my demo, I'll "fix" it. My controllers don't like to be polled more than once a frame at all !!!

[Stef]

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.

Yeah yeah i know that. I know SEGA didn't said that just for fun
But that problem is really annoying, i mean the sound quality of sample playback becomes really bad when you interrupt the Z80, so, if we can avoid it, it's imo a good thing. If i meet some problems then i'll do as SEGA recommended but for now it works perfectly without it so...

Edit: About the controllers pooling stuff, i already observed it and anyway you need a "quiet period" that for the 6 buttons controllers.

[Chilly Willy]

I can see what you mean. Especially if you have the Z80 doing PCM audio. That would cause a slight stutter.

I actually found out about the "polling too fast" issue on the Amiga. You can make SEGA controllers work with the Amiga with just a single resistor, so I was able to convert some nice 6-button controllers to use on my A1200 and A4000, and work support into Doom.

[TmEE co.(TM)]

I don't really have any issues with my sound engine, as halts needed to be done are very very short... long DMAs have negative effect though, you get some nasty stops in sound when you DMA some 128x128 pic to VRAM for example.

[Chilly Willy]

I take it the DMA has priority to the 68000 bus over the Z80. You could try splitting the DMA into smaller pieces to give the Z80 a better chance at bus cycles. You want larger DMAs to minimize the overhead of setting up the DMAs, but too big and they hold everything off too much. You could experiment with different sizes to see the affect it has on speed and Z80 sound quality.

[TmEE co.(TM)]

Doing more intensive VDP access will cause Z80 to "slowdown" when it accesses ROM too.

[Chilly Willy]

Which is probably why newer Genesis games use the 68000 for audio instead of the Z80.

[TmEE co.(TM)]

I can't afford to use 68K for sound in my game if there's something that's pretty much dedicated for it... and Z80 will only do samples in 68K+Z80 engines and samples are the things that get negative effects, so its better to have Z80 only engine, you have more power for game code.

[Stef]

Doing more intensive VDP access will cause Z80 to "slowdown" when it accesses ROM too.

I guess this is when you fill the VDP FIFO, the next write to the VDP port will lock the 68000 (and then the bus) until it free a FIFO emplacement. On real hardware you can avoid that by testing the "FIFO full" flag in status register. It doesn't make your VDP transfert faster but that helps the Z80 to get the bus

[Mask of Destiny]

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.

I seem to remember Steve Snake mentioning that he was able to convince Sega to let him read the pads without halting the Z80 so that it wouldn't interfere with sample playback in NBA Jam. I believe he said the only problem it would cause is occasional, barely noticeable artifacting on screen. Or something like that. I'd have to go dig up the message on the old segadev yahoo group to be sure.

Which is probably why newer Genesis games use the 68000 for audio instead of the Z80.

I don't know about Genesis games in general, but it is definately not the case with the Sonic games. Only Sonic 1 uses the 68000 for sample playback. All of the later Sonic games use a pure Z80 based sound solution.

[TascoDLX]

I seem to remember Steve Snake mentioning that he was able to convince Sega to let him read the pads without halting the Z80 so that it wouldn't interfere with sample playback in NBA Jam. I believe he said the only problem it would cause is occasional, barely noticeable artifacting on screen. Or something like that. I'd have to go dig up the message on the old segadev yahoo group to be sure.

From way back in December 2001, here you go:

I've also noticed some games take the Z80 bus when reading the
joysticks, I don't understand the purpose behind that. Just like with
DMA, it's not really necessary to disable the Z80, though as you said
most all games do it.

Well, I can tell you why that is:

It's a Sega requirement. They tell you you MUST do this.

You are 100% correct, of course - it works with or without taking the Z80 bus. However, there is a reason why they tell you to do this - it affects the timing of *something*. Quite what, I don't know. But, during development of NBA Jam TE 32X, I took the Z80 halt out of my joystick reader, because killing the Z80 every 60th of a second - even for a short time - was seriously affecting the quality of the YM2612 DAC. When I did this, however, every so often (very infrequently) one scanline of the display would be completely white. Which line was completely random, and seemed completely unrelated to anything else - but it didn't happen when I disabled the Z80 while reading the joysticks. Go figure. Despite this, Sega eventually agreed that I could leave it like that.

I've never seen this happen with the Genesis, then again timing is much more critical with a 32X attached. For example, if the PSG is playing a noise channel while the SH2s are reading ROM, it can cause the 68K to fetch invalid data. Weird....

[Eke]

I always thought it was because 68000 bank access by Z80 was done through the IO chip (the only chip which got access to both complete data buses)

it maybe affects the timing of banking access, bad data can be read if the read cycle is shortened

[Chilly Willy]

I always thought it was because 68000 bank access by Z80 was done through the IO chip (the only chip which got access to both complete data buses)

it maybe affects the timing of banking access, bad data can be read if the read cycle is shortened

And maybe it doesn't affect carts with faster roms. SEGA does say that the effect was to shorten the cycle the Z80 uses, but faster ROMs wouldn't be affected by a shorter cycle. Hence, new Genesis games using the new/faster roms never seemed to show the problem.

Makes sense to me.

[TmEE co.(TM)]

Does anyone know how fast were standard ROMs back then ?

[Jorge Nuno]

120/150 nanoseconds, maybe more...?