PCM scaling and mixing

Quote:

Originally Posted by Kamahl

Since you guys have actually programmed the Z80... When changing the bank register, what happens if you write a value different from 0 or 1 into it? Does it read the first bit only, does it consider any byte not equal to $00 to be 1, or does it mess up?

It only examines one bit. Unless you're trying to write a fixed bank value, the usual approach looks something like this (assuming the low 8-bits of the new bank value is in A)

Code:

ld hl, $6000 ld (hl), a rrc ld (hl), a rrc ld (hl), a rrc ld (hl), a rrc ld (hl), a rrc ld (hl), a rrc ld (hl), a rrc ld (hl), a ld (hl), l

l is used in that last write under the assumption that the MSB is always zero. Given that you can't read from 68K work RAM, that's probably a pretty good assumption unless you're on the 32X (though if you're on the 32X, you would probably use the PWM output for samples anyway). As an aside, the generally uselessness of the MSB makes it doubly annoying that Sega cheaped out and used a shift register for this. Needing that many cycles just to change the bank is a real PITA.

Well, you can save 4 cycles per bank you don't care about :p. I mean, the code you wrote can access 8MB (with a capital B), how many games spend that much on audio? How many games are 8MB period xD, that's Pier Solar sized!

But yeah, not using a parallel banking register, mind boggling decision by Sega, many of those on the machine.

Quote:

Originally Posted by Kamahl

Well, you can save 4 cycles per bank you don't care about :p. I mean, the code you wrote can access 8MB (with a capital B), how many games spend that much on audio? How many games are 8MB period xD, that's Pier Solar sized!

That was just a quick example from memory, but you're right of course. Pier Solar uses bank switching and does not extend into the range reserved for the expansion port so even it has no need for addresses in the 4MB-8MB range. Thinking about it more, the best option might be to use the same value for the last 3 bits. This gives you access to the bottom and top 4MB so you can set a bank to access RAM (you can't read it, but you can write it which may be useful for synchronization with the 68K in some cases). With those changes the code becomes:

Code:

ld hl, $6000 ld (hl), a rrc ld (hl), a rrc ld (hl), a rrc ld (hl), a rrc ld (hl), a rrc ld (hl), a rrc ld (hl), a ld (hl), a ld (hl), a

You can obviously save an additional 4 cycles for each halving of the addressable range (either by eliminating the ability to access RAM or by halving the range on either side). That said, even for the case in which you're loading a fixed address and can skip all the rrc instructions, it's still a whopping 63 T-states to change the bank (assuming $6000 is already in HL).

Yes, that's about right. It really is ridiculous that it takes 10x longer than it should for no good reason.

Ok, so writing to z80 ram is byte only and there's a +1 penalty per write.

I was thinking maybe lower the output frequency to 15.3khz, which is 256samples per 1/60th frame. 256*(12+1) is ~3,328 68k cycles total. I was thinking along the lines of: the 68k scales the streams, but the z80 does the volume and accumulation. Since, well, the z80 isn't doing much. So the initial transfer per frame is 3,328 cycles on the 68k, which obviously needs to be broken up over installments, but if there's only 8k of ram on the z80 side then that means a double buffer system of 4 streams at 256bytes is 2k. And then there's the issue of transferring 1024 bytes instead of 256. That's an additional 9,984 68k cycles. Plus whatever overhead of stopping and starting the z80 for multiple transfers.

So let me ask you this; is there any memory in which both the z80 and the 68k can both access without stopping the z80? Maybe save ram?

Okay, rather than updating the original post, I'll post an initial routine to work with - a starting point:

And some notes about the registers..

d0 = chan 0/1 = 16bit fractional number
d1 = chan 2/3 ""
d2 = chan 0 = whole number incrementor
d3 = chan 1 ""
d4 = chan 2 ""
d5 = chan 3 ""
d6 = free
d7 = sample accumulation

a0= chan 0 wave pointer
a1= chan 1 wave pointer
a2= chan 2 wave pointer
a3= chan 3 wave pointer

Code:

;// channel 0 swap d0 ;4 move.l a0,d6 ;4 add.w (Chan0Frq.frac).w,d0 ;12 addx.l d2,d6 ;8 move.l d6,a0 ;4 move.w (Chan0Volume).w,a4 ;12 eor.l d6 ;4 move.b (a0),d6 ;8 move.b (d6,a4),d7 ;12 bne @Channel_1 ;10 for branch taken ;78 cycles

Code explanation:
A0 is the sample address (pointer). The fraction part of the phase accumulation is in the 16bit lower half of D0. Chan0Frq.Frac is the fractional delta to add to the PHA (phase accumulator). D2 is the whole number part, and along with any overflow in X, gets added to the sample pointer. The Chan0Volume is an offset to a volume table, held as a variable so it can be changed, and the 8bit sample read from the new sample offset is used as the index into that volume table. D6 has to be cleared first. In order to set up a per sample loop point, the value of zero is used as a trap (which I haven't written that part yet, but that doesn't matter for this segment). The initial swap instruction is there because of the loop. Also, the top half of A4 is kept at zero so no need clear it.

So, not really optimized. And it's slow. The next three channels use an add.b (d6,a4),d7 instead of move.b, so that increases by 4 cycles. Plus, I'm using 2's complement, so that needs to be converted to the native DAC format. In it's current state, it would take [(82*3)+78] *256 = 82,944 cycles or roughly 65% cpu resource. That doesn't include the loop overhead or conversion from 2's complement overhear, or the 3k to transfer to z80 ram. Not for the initial step, but not good either. It needs to get down to 50 cycles or less.

If you look at the above, the pointer to the sample data is actually 48bits wide; A0[:]D0 where A0 is 32bit and D0 is 16bit. Part of the problem, right there, is that ADDX doesn't allow An registers. So there's an 8cycle overhead of moving it to a temp reg.

Let's see if I can optimize this on the low level approach:

So some regs get repurposed:

d0 = chan 0 = 16bit:16bit - the upper part is the whole number, the lower part the fractional part
d1 = chan 1 ""
d2 = chan 2 ""
d3 = chan 3 ""
d4 = chan 0/1 = chan0 volume LUT pointer / chan1 volume LUT pointer
d5 = chan 2/3 ""
d6 = volume index: upper 24bits need to remain clear
d7 = sample accumulation

a4 = needs the top 16bit clear for the volume pointer.

Code:

swap d4 ;4 add.l (Chan0Frq.frac).w,d0 ;18 (12+6) move.w d4,a4 ;4 swap d0 ;4 move.b (d0,a0),d6 ;12 swap d0 ;4 move.b (d6,a4),d7 ;12 bne @Channel_1 ;10 for branch taken ;68 cycles

So that drops it down by 10 cycles, but that's not enough. I can think of small optimization that might save about 4 cycles, but I think this needs to be re-approached on a higher level. One of the big offenders here, is adding a 32bit value from memory to the register (18 cycles). There's not enough registers to keep both the delta and the accumulator in registers. This approach, as it is now, accumulates all four channel samples in sequence. So maybe dividing this into a two pass system would save some cycles; do 256 samples for one pair of channels, then do 256 with the next pair of channels. The initial savings would be the removal of the first and third instructions for 8 cycles saved. Add.l can be optimized as An,d0 to save 10 cycles. So 18 cycles saved initially. That would bring the first channel down to 50 cycles. The second channel isn't going to be so lucky, because it needs to write the accumulated value back to an array - so that overhead will average across the two channels. But.. if we did a semi-unrolled loop and use the swap instruction on D7, the write back to ram could be done as a single 32bit write and every 2 samples. I think two 2 cycles can also be shaved if the BNE was an 8bit branch (it just might fit/work too). That still won't bring it below 50 cycles per channel though...

Quote:

Originally Posted by tomaitheous

Ok, so writing to z80 ram is byte only and there's a +1 penalty per write.

Strictly speaking you can do word (or even longword) writes, but only one of the bytes of each word will actually be written. The Stuck Somewhere in Time demo I linked earlier in the thread takes advantage of this to write two bytes with a single longword write. Wastes some space in the Z80 buffer, but you gain a few cycles at least

Quote:

Originally Posted by tomaitheous

One of the big offenders here, is adding a 32bit value from memory to the register (18 cycles). There's not enough registers to keep both the delta and the accumulator in registers.

It only gains you 4 cycles, but you could put the code in memory and make the delta an immediate operand. Then just modify the code when you want to change the playback speed. It also looks like you've got 2 address registers free (3 if you can live without a proper stack pointer for a little while) and those are valid as a source operand for an add.

Haven't really had a chance to look at the code in any depth for more significant savings.

Quote:

Originally Posted by Mask of Destiny

Strictly speaking you can do word (or even longword) writes, but only one of the bytes of each word will actually be written. The Stuck Somewhere in Time demo I linked earlier in the thread takes advantage of this to write two bytes with a single longword write. Wastes some space in the Z80 buffer, but you gain a few cycles at least

It only gains you 4 cycles, but you could put the code in memory and make the delta an immediate operand. Then just modify the code when you want to change the playback speed. It also looks like you've got 2 address registers free (3 if you can live without a proper stack pointer for a little while) and those are valid as a source operand for an add.

Haven't really had a chance to look at the code in any depth for more significant savings.

Yeah, -4 cycle for self modifying code and -2 if the branch logic is changed to 8bit offset. That's just the initial channel 0, the rest have to add/accumulate, which is +4 cycles, and the last has to write back to ram.

I ran some numbers and dividing the process up into two routines of accumulating 2 streams is overall faster than all 4 streams in a single pass. I'll post the code in a bit.

Also, trying to assemble (d16,An) addressing mode, I realized that d16 is not Dn.w but an immediate 16bit offset. The indexing mode I need is (d8,An,Xn), with d8=0, which increases an extra +2 cycles.

Ok, here's the split 2pass version:

First, the jump redirections for the optimized short branch.

Code:

check_chan0.a jmp check_sample.0a check_chan1.a jmp check_sample.1a check_chan0.b jmp check_sample.0b check_chan1.b jmp check_sample.1b check_chan0.c jmp check_sample.0c check_chan1.c jmp check_sample.1c

Now the channels 0/1:

Code:

.loop0 ;// channel 0.a Channel0.a add.l d1,d0 ;8 swap d0 ;4 move.b (0,a0,d0.w),d6 ;14 beq.b check_chan0.a ;8 swap d0 ;4 move.b (0,a1,d6.w),d7 ;14 ;52 ;// channel 1.a Channel1.a add.l d3,d2 ;8 swap d2 ;4 move.b (0,a2,d2.w),d6 ;14 beq.b check_chan1.a ;8 swap d2 ;4 add.b (0,a3,d6.w),d7 ;18 move.b d7,(a4)+ ;8 ;64

The infamous loop..

Code:

dbeq d5, .loop0 ;10

And code for channels 2/3:

Code:

.loop1 ;// channel 2 Channel2.a add.l d1,d0 ;8 swap d0 ;4 move.b (0,a0,d0.w),d6 ;14 beq.b check_chan2.a ;8 swap d0 ;4 move.b (0,a1,d6.w),d7 ;14 ;52 ;// channel 3 Channel3.a add.l d3,d2 ;8 swap d2 ;4 move.b (0,a2,d2.w),d6 ;14 beq check_chan3.a ;8 swap d2 ;4 add.b (0,a3,d6.w),d7 ;18 add.b d7,(a4)+ ;12 ;68

Some explanation:

Ok, so looking at channels 0 and 2, D0 holds the phase accumulation and D1 holds the delta. The high 16bits of the reg is used as the index, and D6 is the byte pulled from the sample stream. It's also used as the index into the volume table. All indexing increased by 2 because I misunderstood the (d16,An) address notation. Channels 0 and 2 only need to keep the move result in D7 reg. The loop is actually unrolled 10 times (hence the 0.a, 0.b, 0.c, etc), which reduces the 10 cycles for the decrement and branch if not even from 10 cycles per 2 samples, to 1 cycle per sample. Not all the branch locations fit at the top of the area, right above the loop point, so some are relocated before the DBcc instruction. A single jump instruction of the expired counter jumps past them. Also D6 needs to be initialized to zero, before the loop, in order for the indexing to be correct.

Channel 0 and 2 are identical in code, but channels 1 and 3 differ slightly. Channel 1 accumulates two samples and writes the data. But Channel's 3 code accumulates the two samples and adds it to the exiting array of data from the first pass.

The logic is setup a little bit different. Instead of directly changing the pointer (Address vector), indexing is used instead. That means at the end of each 256 sample pass, the address vector needs to be added to the index, and then stored back into ram/variable. The high 16bits of the phase accumulator can be thrown away (it's just the index), but the lower 16bits needs to be saved as it's a continuous state of the divider system.

The first pass has a cycle counter of [(52+64)/2]+1 = 59 cycles. The second pass is [(52+68)/2]+1 = 61 cycles. Because that's two streams, that averages together as 60cycles. 60*4*256 = 61,440 cycles for 15.3khz sample rate of 4 channels with volume and mixing. Or ~48% cpu resource. Yeah, there's some overhead of loading regs outside the two loops, but it's so small that it's less than 1% total cpu resource. I'm still assuming 2's complement values for accumulation, so the z80 would convert that to DAC format on the fly. No need to waste 68k cycles on that.

Also, the routine could be slightly faster if self modifying code was used for the volume table. If (d16,An) addressing is used, An could be used as the index while d16 is fixed until the software changes that immediate value (which is never faster than a single video frame).

Channel 2 (which is the same as channel 0):

Code:

;// channel 2 Channel2.a add.l d1,d0 ;8 swap d0 ;4 move.b (0,a0,d0.w),a5 ;14 beq.b check_chan2.a ;8 swap d0 ;4 .sm_chan2.a move.b (vol,a5),d7 ;12 ;50 ;// channel 3 Channel3.a add.l d3,d2 ;8 swap d2 ;4 move.b (0,a2,d2.w),a5 ;14 beq check_chan3.a ;8 swap d2 ;4 .sm_chan3.a add.b (vol,a5),d7 ;16 add.b d7,(a4)+ ;12 ;66

It doesn't save a whole lot and needs self-modifying labels for a total of 20 instructions. It reduces the average from 60 to 58, or 59392 cycles: 46.4% cpu resource on the 68k side.

If sram or save ram could be used between the two processors, then Channel 3's (a4)+ could directly point/write into there. Is this possible without disabling the z80? IIRC, I thought the z80 is stalled when ever the 68k is access the same bus (and vice versa). If not, what about using vram/VDP as a go between?

Edit: There is a way to get faster than 58 cycles per sample on average across 4 streams, but it involves pre-calculated code paths. Maybe I'll see if I can come up with some numbers. So... any feedback or suggestions?

The Z80 cannot access the VDP, SRAM is your best bet. When using SRAM you just gotta be smart with the scheduling, make sure that the Z80 is busy doing something else when the 68k is writing, and vice versa when the Z80 is reading.

I still think you're putting way to much emphasis on the 68k, the genesis has an audio processor for a reason, use it. You already had the right idea in making the Z80 do the conversion do DAC format, now make it do more. Don't mix the samples in the 68k side, just scale them and them send'em off to the Z80 for mixing.

Make it do the volume too. You don't even need to send the volume information, there's no reason the Z80 can't be looking at the same song data the 68k is.
Two things kill mod player performance on the Z80, the bank switching and the sample scaling. The Z80 by itself can do a 7khz mod player, why are you not taking advantage of this? If you handle the worst performance killers on the 68k, the Z80 can handle the rest.

Quote:

I still think you're putting way to much emphasis on the 68k

There's two parts to this, and the first part is what can the 68k do. You just don't jump into something; you explore what's possible. The first is what's possible with the 68k, the second is what's possible on the system as a whole. What can the 68k handle. What can the z80 handle. What balance can be fine tuned between them? Sometimes, just sometimes, when you re-invent the wheel, you discover something new. Maybe I have other ideas for the z80. Maybe I want the z80 to handle PSG PCM. Or maybe I want the z80 to do additional channel fetching/mixing (non PCM scaled streams, to mix with the 68k output). Or maybe something completely non audio related. I dunno - whatever. But knowing what the 68k can do, or rather how fast it can do it - is the first step. Because obviously the z80 can't handle what I want to do, alone. Let alone any expansion on the idea (whatever tangent it might go off on).

Quote:

the genesis has an audio processor for a reason, use it. You already had the right idea in making the Z80 do the conversion do DAC format, now make it do more. Make it do the volume too. You don't even need to send the volume information, there's no reason the Z80 can't be looking at the same song data the 68k is.
Two things kill mod player performance on the Z80, the bank switching and the sample scaling. The Z80 by itself can do a 7khz mod player, why are you not taking advantage of this? If you handle the worst performance killers on the 68k, the Z80 can handle the rest.

Hold your horses there, hoss. That's where this is heading. Have some patience.

The goal isn't 7khz mode player on the z80. The goal is to inch towards something fast as possible: a 32khz output. And when you start running into that high of an output, you start running into timing issues and other problems. This isn't my first PCM mixing rodeo.

There is the issue of stalling the z80 for transferring 4 streams of 256 bytes of data. That's 1024 bytes that would need to be transferred. Of course the z80 could do the volume and mix in under 232 T-cycles per sample. The problem is timing/stalling/jitter/etc. I need to know some of the z80 interfacing basics/quirks. I need to know what I'm dealing with on the z80 side, so I can see what options I have.

Stuff like: Is polling the Timer A on the 2612 reliable (on the z80 side)? Since it has to be polled, is there a chance to miss the status update? Where even is the status bit for this (which reg)? Are H-int interrupts available on the z80 side? What's delay between stopping the z80 and being able to write to z80 ram? Can non-z80 ram (cart ram) be written to from the 68k side, if the z80 has it mapped into its address space, without halting the z80? I've been told that the 2612 has direct access to the z80 without interfering with 68k (.i.e if z80 running code out of ram during vblank, writes to DAC port - VDP vdma's won't stall it) - is this true?

As I work my way up to 30khz, that's 2048 bytes that I need to transfer to the z80 side. That also means double buffering on the z80 side; half the ram is gone. A 16 level volume LUT is 4k of memory, which means it can't fit in ram if code needs to be in ram (for vblank period) - so now it's rom access or less volume levels or some realtime solution compromise. I'm also down to 116 T-cycles between sample writes to the DAC. The Timer A isn't a multiple of or close to 30khz, so that becomes an issue when trying to resolve jitter with syncing when the 68k has to stall the z80. Things start to get real tight, real quick.

Quote:

Originally Posted by Kamahl

The Z80 cannot access the VDP, SRAM is your best bet.

This is a bit pedantic, but that's not 100% true. The Z80 can access the VDP (in fact it has an area of memory dedicated to accessing VDP ports, though it's mostly there for PSG access), but it's limited in what it can do because the VDP doesn't handle 8-bit access very well when not in compatibility mode.

Quote:

Originally Posted by Kamahl

The Z80 by itself can do a 7khz mod player

Well maybe. That was just a guess.

Quote:

Originally Posted by tomaitheous

32khz output.

I can't speak from personal experience, but others have said that you run into problems when trying to push samples to the YM-2612 faster than half the internal sampling rate. The internal rate is ~53 Khz so that gives you a max of ~26.6 Khz. Presumably this is why Stuck Somehwere in Time uses 26KHz as its output rate.

Quote:

Originally Posted by tomaitheous

Is polling the Timer A on the 2612 reliable (on the z80 side)?

Yes.

Quote:

Originally Posted by tomaitheous

Since it has to be polled, is there a chance to miss the status update?

Only if you're so late in polling that the timer expires a second time. The flag stays set until you reset it.

Quote:

Originally Posted by tomaitheous

Where even is the status bit for this (which reg)?

It's readable from the status port. You reset it with register $27.

Quote:

Originally Posted by tomaitheous

Are H-int interrupts available on the z80 side?

No.

Quote:

Originally Posted by tomaitheous

What's delay between stopping the z80 and being able to write to z80 ram?

Depends somewhat on what the Z80 is doing. The maximum delay is just a hair under a full M-cycle so the delay in T-states or 68K cycles will depend on the length of the M-cycle being executed. You should check out the Spritesmind thread I linked earlier as there's some good discussion about this topic.

Quote:

Originally Posted by tomaitheous

Can non-z80 ram (cart ram) be written to from the 68k side, if the z80 has it mapped into its address space, without halting the z80?

Yes. Having an area of the 68K's memory space mapped does not do anything to the 68K or its address space until you actually make a memory request to the bank area. When you do the 68K is automatically bus requested for the duration of the request and released afterwards. Typical delay from this on the Z80 side is 2 T-states, though if you do a word-wide operation the second byte will usually have a 3 T-state delay. DMA will completely block Z80 access to the bus though. Similarly if the 68K is blocked on a VDP write due to a full FIFO the delay can be significantly longer.

Quote:

Originally Posted by tomaitheous

I've been told that the 2612 has direct access to the z80 without interfering with 68k (.i.e if z80 running code out of ram during vblank, writes to DAC port - VDP vdma's won't stall it) - is this true?

That's not exactly how I would put it, but yes. The YM-2612 is on the Z80's bus so it does not have the bus request the 68K to access it. By the same token, the 68K can't access the YM-2612 without bus requesting the Z80.

What MoD said ^. If you poll the timers you can get really stable playback (as long as you don't go totally overboard when you stall the Z80).

The timer values aren't all that great, but you can get the timer do to 26632Hz, which is about the max you can get out of the genesis anyway.

Below that you have 17755Hz, 13316Hz, 10653Hz, 8877Hz, 7609Hz and a few more that are too low to matter.

Quote:

Originally Posted by Mask of Destiny

Well maybe. That was just a guess.

Well we know for sure it can mix 4 fixed channels with volume control at 14Khz, and this while having to deal with bank switching. It can manage.

Honestly i never saw that 26khz limit with my tests on all my systems. It looks like it accepts 32 khz and probably even higher but imo that would be overkilling.
My 4 pcm driver consumes about 85% of Z80 CPU time to mix 4 channels of 8 bits PCM at 16khz with 16 volumes level. Still adding PCM scaling is a big thing and I think you really need a smart and optimized code to maintains just about 12khz...

Quote:

Originally Posted by Mask of Destiny

I can't speak from personal experience, but others have said that you run into problems when trying to push samples to the YM-2612 faster than half the internal sampling rate. The internal rate is ~53 Khz so that gives you a max of ~26.6 Khz. Presumably this is why Stuck Somehwere in Time uses 26KHz as its output rate.

I've heard this as well (the internal rate figure)... but that doesn't make sense. If the internal DAC value is read and output around 53khz, why would the limit be half that? Does it have something to do with the slow interface with the YM chip? I do remember something about a BUSY flag/state. I thought I remember TmEE telling me that he could get 30khz and higher output working, with only a few sample misses here and there, but dialed back his engine because he needed multiple channel mix support. My memory is fuzzy, but I'm remembering him saying he blitzed the dac port (much more than just 2 times). But that aside, putting the 53khz in Tcycle time frame window, that's every 67.67 T cycles on the z80 side. So as long at the DAC reg value is updated within that time frame, it should be updated on the output (not missed).

Quote:

Only if you're so late in polling that the timer expires a second time. The flag stays set until you reset it.

The reason I ask is because I've seen devices/setups where the cpu reading the status port and the status flag updating at the same time, clears the update but doesn't get transferred to the cpu read/fetch (though NES is what comes to mind). It's a rare condition, but and it's commonly said that unless it (and such devices) is specifically design for that behavior - use the interrupt service to set a variable/flag instead (and polled that variable state). I suspect the normal setup for the YM timer usage is an interrupt service (albeit not connected in this MD setup) and not polling - is this true? If people are using it, I wonder if that would account/contribute for some missing sample outputs (using the ~26khz timer setting).

Quote:

Depends somewhat on what the Z80 is doing. The maximum delay is just a hair under a full M-cycle so the delay in T-states or 68K cycles will depend on the length of the M-cycle being executed. You should check out the Spritesmind thread I linked earlier as there's some good discussion about this topic.

I did skim through it. I'll give it a proper read, though. Yeah, I'm thinking I'm gonna have to take some of these questions over there.

Quote:

That's not exactly how I would put it, but yes. The YM-2612 is on the Z80's bus so it does not have the bus request the 68K to access it. By the same token, the 68K can't access the YM-2612 without bus requesting the Z80.

Ok. I just wanted to confirm this. I had talked with tmee years ago about all of this, but from the stuff I've done the MD - it was 68k and video only. I've never touched the 2612 or z80. Just trying to make sure my memory is correct.

Quote:

Originally Posted by Stef

Honestly i never saw that 26khz limit with my tests on all my systems. It looks like it accepts 32 khz and probably even higher

That's what I remember TmEE saying as well. That 26khz was a practical limit, not because of the DAC or the 2612, but because other stuff he was doing on the z80 side.

Quote:

Yes. Having an area of the 68K's memory space mapped does not do anything to the 68K or its address space until you actually make a memory request to the bank area. When you do the 68K is automatically bus requested for the duration of the request and released afterwards. Typical delay from this on the Z80 side is 2 T-states, though if you do a word-wide operation the second byte will usually have a 3 T-state delay. DMA will completely block Z80 access to the bus though. Similarly if the 68K is blocked on a VDP write due to a full FIFO the delay can be significantly longer.

Forgive my ignorance on this, as I never used the z80 when coding for the Genesis, but the bus request is automatic if rom (or cart memory) is mapped into the z80 address range? Then what is the manual bus request for? ($a11100 ?) Is that only for the z80 dedicated ram and the ym2612?

Quote:

Originally Posted by tomaitheous

Forgive my ignorance on this, as I never used the z80 when coding for the Genesis, but the bus request is automatic if rom (or cart memory) is mapped into the z80 address range? Then what is the manual bus request for? ($a11100 ?) Is that only for the z80 dedicated ram and the ym2612?

Yes, as far as I know at least.