Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

RetroGames
Interested
Posts: 34
Joined: Mon Oct 19, 2015 12:34 pm

Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?

Post by RetroGames » Mon Oct 26, 2015 4:57 pm

Hey folks, total noob here. I'm learning Genny programming with EASy68K and MAME debugger. (Unfortunately, I don't have access to a real Gen/MD at the moment.) I've been following along with the Big Evil Corp tutorials (really nice work on those, Matt!) and MarkeyJester's 68k tutorials (also really nice work, MarkeyJester!) I've also been regularly consulting the Genesis Technical Overview and the 68k Programmer's Reference Manual, and trying to search around Spritesmind for answers to some of my questions. I'm enjoying the process so far, trying to learn as much as I can on my own, but I've got myself all confused about how Z80 BUSREQ and RESET work, and I'm hoping you guys can set me straight.

These are the results of my testing in MAME debugger:

Code: Select all

EntryPoint:						   ; First thing that runs after powering on
 move.b ($00a11100),d5			 ; Get BUSREQ state
 andi.l #1,d5						 ; D5 = 1, MAME memory disassembly says Z80_HAS_BUS flag = 1 (true)
 move.b ($00a11200),d4			 ; Get RESET state, but this doesn't work, it always returns 0
; move.w ($00a11200),d4			; Same thing, it always returns 0
; move.l ($00a11200),d4			; Again, always 0
 andi.l #1,d4						 ; D4 = 0 no matter what, but memory disassembly says Z80_IS_RESET flag = 1 (true)

;-----This part doesn't work. No matter how long I wait, Bit #0 of BUSREQ never becomes 0, and Z80_HAS_BUS flag never becomes 0 (false)-----;
; move.w #$0100,($00a11100)	  ; Write 0100h to the BUSREQ port to REQUEST CONTROL of the Z80 bus
;.LocalLoop1:
; btst #0,($00a11100)			  ; Check Bit #0 of the byte at the BUSREQ port
; bne .LocalLoop1				   ; Loop until Bit #0 of the byte at BUSREQ = 0, then we control the bus

;----------This part works fine.-----------;
 move.w #$0100,($00a11200)		; Write 0100h to the RESET port to STOP HOLDING the Z80 in a reset state
 										 ; Memory disassembly now says Z80_IS_RESET flag = 0 (false)
 move.w #$0100,($00a11100)		; Write 0100h to the BUSREQ port to REQUEST CONTROL of the Z80 bus
										  ; Memory disassembly now says Z80_HAS_BUS flag = 0 (false)
.LocalLoop:
 btst #0,($00a11100)				; Check Bit #0 of the byte at the BUSREQ port
 bne .LocalLoop					  ; Loop until Bit #0 of the byte at BUSREQ = 0, then we control the bus
; Access Z80 memory here...
 move.w #0,($00a11100)			 ; Write 0000h to the BUSREQ port to RELEASE CONTROL of the Z80 bus
										  ; Memory disassembly says Z80_HAS_BUS flag = 1 (true)
Some questions:
  1. The Z80 manual says that the BUSREQ and RESET pins are both "active low." From what I've read, that seems to mean a low voltage signal (a "0" from a software standpoint) turns them ON, and a high signal (a "1" in software) turns them OFF. If that is correct, then it matches the way the RESET port works (0000h = RESET Z80 ON; 0100h = STOP RESETTING Z80), but it's the reverse of how the BUSREQ port works (0100h = REQUEST BUS; 0000h = LET GO OF BUS). Is the BUSREQ pin wired to the 68k backward or something?
  2. Do I need to check to make sure the Z80 regains control of the bus after I release control of it? If so, what should I do if the Z80 doesn't regain control? Write another release command to the port, or maybe reset the Z80?
  3. Is it necessary to write a word to these ports, or can I write bytes instead:

    Code: Select all

    move.b #1,($00a11100)		; Request bus
    move.b #0,($00a11200)		; Request reset
    
  4. The Z80 manual mentioned something about how lengthy DMA operations with BUSREQ active can prevent DRAM from being refreshed properly. Do I need to worry about that when using BUSREQ? (The Genesis Technical Overview mentions this DRAM refresh business, but it's talking about hardware dev kits or something like that.)
  5. Is there any reason besides accessing Z80 memory from the 68k that I would use BUSREQ?
  6. When/why would I need to reset the Z80 in the main body of my code? Every time the 68k writes to its memory?
  7. Can you read from the RESET port on real hardware? Or the BUSREQ port, for that matter (with a MOVE instruction, that is)?
TL;DR: How exactly do Z80 BUSREQ and Z80 RESET work, and when do I use them?

Also, if you'd like to make suggestions about different debugging or dev tools I should try out, go right ahead. I'm happy with the ones I'm using so far, but I like hearing different opinions.

Sik
Very interested
Posts: 934
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?

Post by Sik » Tue Oct 27, 2015 4:29 am

Quick since I have 6 minutes of battery but:

#2 no, it's pointless =P
#3 you can use bytes (the manual even says so)
#5 YM2612 is mapped in the Z80 area too
#6 normally just when you load the Z80 code and want the Z80 to start running it (i.e. initialization)
#7 you actually need to read the busreq port to ensure the Z80 has released the bus
Sik is pronounced as "seek", not as "sick".

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

Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?

Post by Eke » Tue Oct 27, 2015 8:09 am

1) Z80 /BUSREQ is not directly connected to 68k CPU, it is handled by a dedicated chip which handles most address decoding and will assert z80 /BUSREQ if access is done to proper 68k address range and proper 68k data line is asserted.

2) It always get the bus back, there is nothing you can do to force it. And since you don't need the z80 bus anymore, you don't care when exactly z80 is getting it back.

3) You can write bytes but make sure to access upper (i.e even) address. The chip asserting z80 /BUSREQ and /RESET lines only got D8 from 68k.

4) z80 is connected to static RAM, it is not refreshed

5) anything connected to z80 address and data buses requires you to request z80 bus first, that includes z80 ram and ym2612 sound chip. In tech bulletins, there is also a recommandation to request z80 bus before accessing i/o ports ($A100xx) but I think it's just to prevent some timing issues if this eventually happens while z80 is accessing 68k bus (bus interconnection is handled by the i/o chip).

6) when you want to reset z80 program obviously, generally needed after you loaded a new program from 68k but you could do it for many other reasons

7) i think ZRESET bit returns z80 /RESET signal status when read but I'm not 100% sure. Reading ZBUSREQ bit returns 1 if z80 bus can be accessed (z80 reset off and z80 busack on), 0 otherwise.

RetroGames
Interested
Posts: 34
Joined: Mon Oct 19, 2015 12:34 pm

Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?

Post by RetroGames » Fri Oct 30, 2015 1:31 pm

Eke wrote:1) Z80 /BUSREQ is not directly connected to 68k CPU, it is handled by a dedicated chip which handles most address decoding and will assert z80 /BUSREQ if access is done to proper 68k address range and proper 68k data line is asserted.
1. OK, that makes sense. I guess I'm just wondering why they decided to wire it so that /BUSREQ and /RESET are activated using different "commands" from the 68k [move.w #0,(Z80_RESET) = /RESET ON vs. move.w #$0100,(Z80_BUSREQ) = /BUSREQ ON]. But I guess it doesn't matter as long as the programmer knows how it works, eh?

Sik wrote:#2 no, it's pointless =P
Eke wrote:2) It always get the bus back, there is nothing you can do to force it. And since you don't need the z80 bus anymore, you don't care when exactly z80 is getting it back.
2. The reason I asked this was what I found in this thread:
Stef wrote:It should be :
request bus
wait bus taken

// do your stuff
// ..

start reset
release bus
wait bus released
end reset
And if you only want to reset Z80 for some reason :
start reset

if bus taken
{
release bus
wait bus released
}
else
{
waitSomeTime
}

end reset
Stef's instructions make it sound like I do need to care about when the Z80 regains the bus. Or am I misunderstanding this?

Sik wrote:#3 you can use bytes (the manual even says so)
Eke wrote:3) You can write bytes but make sure to access upper (i.e even) address. The chip asserting z80 /BUSREQ and /RESET lines only got D8 from 68k.
3. I saw that line in the manual, but I didn't know if I could trust it. :D For instance, I had no idea what "D8" was referring to, plus I thought I read somewhere that byte access wasn't possible, so I felt uneasy about accepting the rest of the info in that section. But between your comments and finding the Sega "Technical Bulletins", I get it now. :D

Eke wrote:4) z80 is connected to static RAM, it is not refreshed
4. Oh, OK. I got thrown off by the manual calling Z80 RAM "sound RAM" at some point, so I didn't make the connection that S-RAM = static RAM in this case. :D

Sik wrote:#5 YM2612 is mapped in the Z80 area too
Eke wrote:5) anything connected to z80 address and data buses requires you to request z80 bus first, that includes z80 ram and ym2612 sound chip. In tech bulletins, there is also a recommandation to request z80 bus before accessing i/o ports ($A100xx) but I think it's just to prevent some timing issues if this eventually happens while z80 is accessing 68k bus (bus interconnection is handled by the i/o chip).
5. Thanks for the tips!

Sik wrote:#6 normally just when you load the Z80 code and want the Z80 to start running it (i.e. initialization)
Eke wrote:6) when you want to reset z80 program obviously, generally needed after you loaded a new program from 68k but you could do it for many other reasons
6. OK. I think I understand this now, but just one more super noob question and I think I'll have it all figured out: Is it possible to directly access or control the Z80's registers from the 68k? (I'm guessing the answer is a huge "NO," but still I ask... ;))

Sik wrote:#7 you actually need to read the busreq port to ensure the Z80 has released the bus
Eke wrote:7) i think ZRESET bit returns z80 /RESET signal status when read but I'm not 100% sure. Reading ZBUSREQ bit returns 1 if z80 bus can be accessed (z80 reset off and z80 busack on), 0 otherwise.
7. Wait, are we talking about the same thing? MAME gave me the opposite result when reading from /BUSREQ (see my code above). As for reading from /RESET, if there's anyone who has tried to do that on real hardware, please let us know what results you got.

Thanks for the replies Sik and Eke! I appreciate the help!

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

Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?

Post by Eke » Fri Oct 30, 2015 4:48 pm

Stef's instructions make it sound like I do need to care about when the Z80 regains the bus. Or am I misunderstanding this?
I don't know, maybe it's because when you need to reset z80, /RESET must be asserted long enough while Z80 has control of the bus to be effective. I'm not sure if that's really needed though.

Is it possible to directly access or control the Z80's registers from the 68k? (I'm guessing the answer is a huge "NO," but still I ask... ;))
You can read them using Z80 instructions and storing the result in Z80 RAM for 68k to read it later but direct access from 68k to Z80 CPU internal state is physically impossible.

Wait, are we talking about the same thing? MAME gave me the opposite result when reading from /BUSREQ (see my code above).
My bad, it's indeed the opposite. 0 means the Z80 bus can be accessed (/BUSACK asserted and/ZRESET released).

Sik
Very interested
Posts: 934
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?

Post by Sik » Sat Oct 31, 2015 5:27 pm

RetroGames wrote:6. OK. I think I understand this now, but just one more super noob question and I think I'll have it all figured out: Is it possible to directly access or control the Z80's registers from the 68k? (I'm guessing the answer is a huge "NO," but still I ask... ;))
Yeah no way. You can manipulate the Z80 RAM while the Z80 is reset though, so any data that you want to pass before it starts can be just passed through RAM.

Unless you're using Regen. For some reason, it won't let the 68000 write to Z80 RAM while reset is asserted (this is why Echo releases reset and keeps the bus during initialization). On real hardware you can write to Z80 RAM regardless of the reset state, only thing that matters is bus request.
Sik is pronounced as "seek", not as "sick".

Mask of Destiny
Very interested
Posts: 594
Joined: Thu Nov 30, 2006 6:30 am

Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?

Post by Mask of Destiny » Sat Oct 31, 2015 8:19 pm

Sik wrote:You can manipulate the Z80 RAM while the Z80 is reset though, so any data that you want to pass before it starts can be just passed through RAM.
You sure about that? I just ran a test on both my VA1 Model 2 and my pre-VA6 (haven't cracked it open to get the exact board revision) Model 1 and I seem to get open-bus values back when attempting to read Z80 RAM unless !RESET is not asserted and !BUSREQ is. The wait state for access to the Z80 area is still present though.

Sik
Very interested
Posts: 934
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?

Post by Sik » Sat Oct 31, 2015 8:38 pm

I recall testing that and it working...

Ugh. We definitely need to do some sort of mass testing on every single possible signal on every hardware revision, it seems every revision broke or fixed something that is potentially likely to trip in a real program.
Sik is pronounced as "seek", not as "sick".

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

Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?

Post by Nemesis » Mon Nov 02, 2015 1:06 am

The best way to approach that is to write test roms that produce simple, visual results. It's easy for a bunch of people to load a ROM onto a flashcart, run it on their system, and report a pass/fail kind of result. It also then becomes an extremely valuable test for emulators. We need to build up more of these kind of tests, and someone needs to host them in one logical place.

Heck, I might even do this. I've written enough of these tests, but the only way you can find virtually any of them is buried in random threads on this forum. I'll make it part of an official regression test repository for Exodus. Any interest in me setting up a bitbucket repository filled with source files and a buildchain for a bunch of Mega Drive test roms, and a simple webpage listing them and providing compiled binaries?

Sik
Very interested
Posts: 934
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?

Post by Sik » Mon Nov 02, 2015 4:46 am

Honestly I'd rather have a single ROM that has tests for just about everything you could think on so there's a single cartridge I can use to check what hardware revision it is. One thing that annoyed me from testing the clones I had around here is that I have the Overdrive cartridge that makes it a dead giveaway whether they're superclones or not... but the 512 colors screen is in the second half of the demo (so, several minutes in). Argh. (both clones turned out to pass that test happily :v)
Sik is pronounced as "seek", not as "sick".

Natsumi
Very interested
Posts: 81
Joined: Mon Oct 05, 2015 3:00 pm
Location: 0x0
Contact:

Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?

Post by Natsumi » Mon Nov 02, 2015 11:30 am

I'd like something like that Nemesis. And I can test them out, when I hace money for a flash cart, as I have 3 machines mysel (2x model 1 MegaDrive, 1x model 1 Genesis; need to open up to see board revision)

RetroGames
Interested
Posts: 34
Joined: Mon Oct 19, 2015 12:34 pm

Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?

Post by RetroGames » Mon Nov 02, 2015 9:58 pm

Eke wrote:I don't know, maybe it's because when you need to reset z80, /RESET must be asserted long enough while Z80 has control of the bus to be effective. I'm not sure if that's really needed though.
Maybe it has something to do with the 26ms wait period for /RESET the sound programming part of the manual talks about?
Eke wrote:You can read them using Z80 instructions and storing the result in Z80 RAM for 68k to read it later but direct access from 68k to Z80 CPU internal state is physically impossible.
Yeah, I figured, but just wanted to make sure. Now I think I see what the resetting is all about: it's the only way the 68k can directly change the Z80's program counter. Otherwise, there's no way to force the Z80 to execute whatever code the 68k writes to Z80 memory, since the Z80 wouldn't have any way to know where the code is supposed to start. Is that right?
Eke wrote:My bad, it's indeed the opposite. 0 means the Z80 bus can be accessed (/BUSACK asserted and/ZRESET released).
Heh, now you see why I started this thread. It's hard to keep this stuff straight, let alone learn it, if you're a noob like me! :D
Sik wrote:You can manipulate the Z80 RAM while the Z80 is reset though, so any data that you want to pass before it starts can be just passed through RAM.

Unless you're using Regen. For some reason, it won't let the 68000 write to Z80 RAM while reset is asserted (this is why Echo releases reset and keeps the bus during initialization). On real hardware you can write to Z80 RAM regardless of the reset state, only thing that matters is bus request.
Writing to Z80 RAM while /RESET is asserted doesn't work on MAME either. You can only write to Z80 RAM if /RESET is released and /BUSREQ is asserted. No other combination works for me. (I'm on MAME v1.65, by the way.)
Mask of Destiny wrote:You sure about that? I just ran a test on both my VA1 Model 2 and my pre-VA6 (haven't cracked it open to get the exact board revision) Model 1 and I seem to get open-bus values back when attempting to read Z80 RAM unless !RESET is not asserted and !BUSREQ is. The wait state for access to the Z80 area is still present though.
Sorry, could you explain what you mean by "open-bus values"? (Also, how long is the wait state? The manual says "26ms" but is that milliseconds or MICROseconds? I'm getting paranoid and doubting everything it says unless I can test it myself -- which I can't, 'cuz I have no hardware. :D)
Sik wrote:I recall testing that and it working...

Ugh. We definitely need to do some sort of mass testing on every single possible signal on every hardware revision, it seems every revision broke or fixed something that is potentially likely to trip in a real program.
Nemesis wrote:The best way to approach that is to write test roms that produce simple, visual results. It's easy for a bunch of people to load a ROM onto a flashcart, run it on their system, and report a pass/fail kind of result. It also then becomes an extremely valuable test for emulators. We need to build up more of these kind of tests, and someone needs to host them in one logical place.

Heck, I might even do this. I've written enough of these tests, but the only way you can find virtually any of them is buried in random threads on this forum. I'll make it part of an official regression test repository for Exodus. Any interest in me setting up a bitbucket repository filled with source files and a buildchain for a bunch of Mega Drive test roms, and a simple webpage listing them and providing compiled binaries?
:shock: Yikes... Writing code that will reliably run on real hardware is sounding more and more like a huge ordeal... But yeah, I support any idea to make Genny dev and/or emulation easier and better. And if there's anything a noob with no hardware (or money :( ) can do to help, let me know. I don't mind doing boring stuff like compiling info or writing / editing documentation or tutorials or whatever, just as long as someone can verify the accuracy of whatever source material you want me to work from. (Man I wish I had my own hardware!)

Mask of Destiny
Very interested
Posts: 594
Joined: Thu Nov 30, 2006 6:30 am

Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?

Post by Mask of Destiny » Tue Nov 03, 2015 12:06 am

RetroGames wrote:Sorry, could you explain what you mean by "open-bus values"?
The values you get when nothing is driving the CPU data bus. On the Genesis, this is typically the last value that the 68000 read and in most cases that will be a pre-fetched instruction word.
RetroGames wrote:Also, how long is the wait state? The manual says "26ms" but is that milliseconds or MICROseconds?
I'm not sure we're talking about the same thing here. What I'm saying is that a normal 68K memory request takes 4 cycles, but a request to the Z80 memory area takes 5. This is not terribly relevant unless you're trying to write an emulator and get the timing right.

It sounds like you're asking about how long you need to assert !RESET. According to the Z80 manual (which is not necessarily trustworthy given that it contains a few obvious errors), it only needs to be asserted for 3 full clock cycles. Since the Z80 has a /15 clock divider and the 68K has a /7 divider, that works out to ~6.5 68K clocks. Given that the the fastest instruction that could be used to change !RESET takes 8 cycles, I would not worry too much. Throw in a few nops if you want to be sure.
RetroGames wrote:I'm getting paranoid and doubting everything it says unless I can test it myself -- which I can't, 'cuz I have no hardware. :D)
The official Sega documentation is definitely not free of errors and none of the existing emulators get everything 100% identical to the real hardware (especially not things that only makes bad code break as catching these sorts of things is more difficult unless someone writes a test for it specifically). In general, the plight of those trying to develop without access to hardware has definitely improved between better community written documentation and more accurate emulators, but it's still pretty easy to get yourself into trouble if you're trying to push the limits of the hardware.

Along those lines, any particular reason you're using MAME? I haven't done any extensive testing, but I was under the impression that it's Genesis emulation wasn't especially accurate by modern standards.
Nemesis wrote:The best way to approach that is to write test roms that produce simple, visual results. It's easy for a bunch of people to load a ROM onto a flashcart, run it on their system, and report a pass/fail kind of result. It also then becomes an extremely valuable test for emulators. We need to build up more of these kind of tests, and someone needs to host them in one logical place.

Heck, I might even do this. I've written enough of these tests, but the only way you can find virtually any of them is buried in random threads on this forum. I'll make it part of an official regression test repository for Exodus. Any interest in me setting up a bitbucket repository filled with source files and a buildchain for a bunch of Mega Drive test roms, and a simple webpage listing them and providing compiled binaries?
I'd certainly be willing to contribute to such a repository of tests.

RetroGames
Interested
Posts: 34
Joined: Mon Oct 19, 2015 12:34 pm

Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?

Post by RetroGames » Wed Nov 04, 2015 12:27 am

Mask of Destiny wrote:The values you get when nothing is driving the CPU data bus. On the Genesis, this is typically the last value that the 68000 read and in most cases that will be a pre-fetched instruction word.
Ah, so the 68k goes to read from somewhere, such as Z80 RAM, finds nothing because it can't actually access the resource in question, and instead returns some data it already has at hand, which isn't, strictly speaking, garbage data, but it's not the data that you actually want -- is that it?
Mask of Destiny wrote:I'm not sure we're talking about the same thing here.
It turns out you're right. :D I'm so new at this, I'm not entirely sure what I'm asking. But your info will help me figure out more things, so thanks for the help!
Mask of Destiny wrote:The official Sega documentation is definitely not free of errors and none of the existing emulators get everything 100% identical to the real hardware (especially not things that only makes bad code break as catching these sorts of things is more difficult unless someone writes a test for it specifically). In general, the plight of those trying to develop without access to hardware has definitely improved between better community written documentation and more accurate emulators, but it's still pretty easy to get yourself into trouble if you're trying to push the limits of the hardware.
Yeah, the buggy official docs are a major stumbling block for me. The shakiness of the language (from translation, I assume) is almost worse for me than the outright errors. Plus, the community-produced docs you mentioned seem to be spread out all over the place. If I hadn't found Big Evil Corp's tutorial blog, I don't think I would've worked up the nerve to get started.

If there were a single place to go where you could get all the most accurate info the community has to date, like a revised Gen/MD programmer's manual plus an FAQ, that'd be a huge help. It's really tough when you have umpteen different docs from any of three decades to comb through, and you're not sure about what info you can trust. But I don't mean to complain, I know organizing all that would be just as much work as learning game development is, and I'm definitely thankful for all the work the international Genesis dev community has already done to make things easier and more accessible for aspiring homebrew devs.
Mask of Destiny wrote:Along those lines, any particular reason you're using MAME? I haven't done any extensive testing, but I was under the impression that it's Genesis emulation wasn't especially accurate by modern standards.
Well, I've never used a debugger before now, so I had tried to use Regen's debugger, but I couldn't figure out how to operate it. The Big Evil Corp tutorials mentioned MAME's debugger, so I tried it out, and I liked it pretty well, what with the built-in help docs and all. I'm starting to think I need to look into a Genny-specific emulator with debugging, though. MAME's interface is becoming a little tough to navigate as I start getting into more involved stuff like working with the VDP. MAME exposes a ton of info, but it's kind of a nightmare to find what you want if you're not sure where to look or how to interpret things. Maybe I should give Regen another chance now that I know a little about debugging in general. But hey, if you have any other suggestions, I'm all ears!

Mask of Destiny
Very interested
Posts: 594
Joined: Thu Nov 30, 2006 6:30 am

Re: Noob questions: DEFINITIVE info about Z80 BUSREQ, RESET?

Post by Mask of Destiny » Wed Nov 04, 2015 7:17 am

RetroGames wrote:Ah, so the 68k goes to read from somewhere, such as Z80 RAM, finds nothing because it can't actually access the resource in question, and instead returns some data it already has at hand, which isn't, strictly speaking, garbage data, but it's not the data that you actually want -- is that it?
That's more or less it. It's not garbage in the sense that is' completely random, but it's garbage in the sense that is' more of an accident of the way the hardware works than an intentional feature.
RetroGames wrote:Yeah, the buggy official docs are a major stumbling block for me. The shakiness of the language (from translation, I assume) is almost worse for me than the outright errors. Plus, the community-produced docs you mentioned seem to be spread out all over the place. If I hadn't found Big Evil Corp's tutorial blog, I don't think I would've worked up the nerve to get started.

If there were a single place to go where you could get all the most accurate info the community has to date, like a revised Gen/MD programmer's manual plus an FAQ, that'd be a huge help. It's really tough when you have umpteen different docs from any of three decades to comb through, and you're not sure about what info you can trust. But I don't mean to complain, I know organizing all that would be just as much work as learning game development is, and I'm definitely thankful for all the work the international Genesis dev community has already done to make things easier and more accessible for aspiring homebrew devs.
Yeah, the current state of things is definitely sub-optimal. There's a lot of information sprinkled in random threads and even if you know the right ones to look in finding the specific info you need can be a pain. Of course, it's certainly better than when we didn't have that info at all. I think there was a proposal to either start a wiki or start using one of the existing ones to collect documentation. Don't remember what came of that discussion.
Mask of Destiny wrote:But hey, if you have any other suggestions, I'm all ears!
If you need a debugger you might want to give Exodus, Gens KMod or BlastEm a try. I'm rather partial to BlastEm myself, but I may be a tad biased. :wink:

Post Reply