Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?
Moderator: BigEvilCorporation
-
- Very interested
- Posts: 616
- Joined: Thu Nov 30, 2006 6:30 am
Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?
I've expanded and cleaned up the test ROM I used to verify this behavior. All the tests now have a PASS/FAIL indication with the exception of the ones testing the delay between asserting !BUSREQ and when the request is acknowledged as the value varies between 1 and 0 on the hardware and I haven't had a chance to figure out how to synchronize things such that it's reliably one or the other. For tests that should result in an "open" bus value, I simply test that it's not the value that was written as this isn't really intended to be a test of how prefetch values get used for open bus reads. For the "unused bits" tests I check for non-zero as at least one buggy game depends on that behavior for the BUSREQ/BUSACK register.
Here's it is:
Assembled ROM
Source Code
Here's it is:
Assembled ROM
Source Code
-
- Interested
- Posts: 34
- Joined: Mon Oct 19, 2015 12:34 pm
Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?
Probably not useful info, but running your test in different emulators gives different results. Shocking, no?
-
- Very interested
- Posts: 616
- Joined: Thu Nov 30, 2006 6:30 am
Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?
Not a huge surprise (ok, not really a surprise at all since I ran it on a few emulators previously). I can confirm that Genesis Plus GX gives more or less perfect results including the exact "open bus" values I see on the hardware I have here. The only real difference is that on real hardware the busack delay is sometimes not zero (just hit start a few times), but it's always zero on Genesis Plus GX. The delay measurement has pretty poor granularity, it's basically how many move.b (aN), dN instructions get a value without the busack bit set appropriately. I didn't have a chance to test on Exodus to see how it fairs (most of my machines run Linux exclusively). BlastEm fails the unused reset bits test and currently makes no attempt at simulating actual open bus values. For others, it seems that the handling of word-wide accesses is the most commonly messed up.
Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?
I'm using this thread to ask a question about Reset et BusAck signals from the Z80.
While the Z80 is resetting (RESET Pin in low state) how is the BusAck Signal?
If the BusAck Signal is low that mean the 68k can read/write the Z80 bus (That what i understand from this post).
While the Z80 is resetting (RESET Pin in low state) how is the BusAck Signal?
If the BusAck Signal is low that mean the 68k can read/write the Z80 bus (That what i understand from this post).
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?
The 2 aren't connected but SEGA clearly indicate to always asserting BUSREQ during Z80 reset operation.
Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?
It's… messier than that:
https://plutiedev.com/using-the-z80#loading-z80
Or also from the Sega docs (though it's essentially describing the same thing):
https://plutiedev.com/using-the-z80#loading-z80
Or also from the Sega docs (though it's essentially describing the same thing):
The biggest gotchas are that:Z80 Start-Up
Z-80 Operation Sequence:
- BUS REQ ON
- BUS RESET OFF
- 68k copies program into Z-80 S-RAM
- BUS RESET ON
- BUS REQ OFF
- BUS RESET OFF
- You absolutely need to wait at least 192 68k cycles after you assert reset (note: waiting longer is OK). The YM2612 needs that to go to a stable state.
- You can't access Z80 RAM during Z80 reset, hence why you need to bus request then end reset (that gives you access to Z80 RAM, but the Z80 still won't run until bus request is also deasserted).
- The bus request signal will be invalid during reset, so do not wait for the Z80 to return the bus in this case.
Sik is pronounced as "seek", not as "sick".
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?
I haven't had any issues by doing a shorter than 192 cycle reset, but I always explicitly zero out all the YM registers and it seems internal state is also fine.
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?
I've had it break (inconsistently… it starts making weird noises) when doing less than 192 cycles, so yeah. To be fair it's possible that the actual amount needed is less, but doing more doesn't hurt. From what I recall, I got the 192 cycles amount by looking at docs.
Considering how some problems seem to show up only on specific consoles (or for extra pain, specific cartridges too), I'd say to play it safe.
Considering how some problems seem to show up only on specific consoles (or for extra pain, specific cartridges too), I'd say to play it safe.
Sik is pronounced as "seek", not as "sick".
Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?
Thanks Sik for your informations.Sik wrote: ↑Mon Nov 18, 2019 7:50 pmIt's… messier than that:
https://plutiedev.com/using-the-z80#loading-z80
Or also from the Sega docs (though it's essentially describing the same thing):The biggest gotchas are that:Z80 Start-Up
Z-80 Operation Sequence:
- BUS REQ ON
- BUS RESET OFF
- 68k copies program into Z-80 S-RAM
- BUS RESET ON
- BUS REQ OFF
- BUS RESET OFF
Considering how it works, you probably don't need to reset again after loading the Z80 program if the reset before had been long enough (and it probably was if you're coming from reset as you were likely spending time on other stuff), but it doesn't hurt either, hence why it's the recommended method.
- You absolutely need to wait at least 192 68k cycles after you assert reset (note: waiting longer is OK). The YM2612 needs that to go to a stable state.
- You can't access Z80 RAM during Z80 reset, hence why you need to bus request then end reset (that gives you access to Z80 RAM, but the Z80 still won't run until bus request is also deasserted).
- The bus request signal will be invalid during reset, so do not wait for the Z80 to return the bus in this case.
When you say :
=> The bus request is set by 68K, so why you say is invalid during Z80 reset? What consequences?The bus request signal will be invalid during reset
In my opinion the 68K does not read the bus through the Z80?so do not wait for the Z80 to return the bus in this case
The Z80 bus is connected to the 68K no? I dont understand why you said the Z80 return the bus.
Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?
When you assert bus request, what you're doing is asking the Z80 to let its bus alone — which may take a bit of time, since it needs to finish any ongoing access first. You're supposed to read back from $A11100 to know when the Z80 has done that. The problem is that while the Z80 is reset it will never tell you that it has given the bus (even though by definition it has done it already), so waiting for the Z80 to give you the bus while it's reset will result in a hang up (you waiting forever).
Sik is pronounced as "seek", not as "sick".
Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?
... and this reset can finish only when you will set the reset flag to 1, so you will wait foreverSik wrote: ↑Tue Nov 19, 2019 4:22 pmWhen you assert bus request, what you're doing is asking the Z80 to let its bus alone — which may take a bit of time, since it needs to finish any ongoing access first. You're supposed to read back from $A11100 to know when the Z80 has done that. The problem is that while the Z80 is reset it will never tell you that it has given the bus (even though by definition it has done it already), so waiting for the Z80 to give you the bus while it's reset will result in a hang up (you waiting forever).
All is clear