When can HDMA and DMA be used at the same time?

[Near]

> I think Uniracers does the same thing.

That is incorrect. Uniracers writes to OAM during Hblank, which the SNES "forbids".

But because it's done on a scanline with no sprites, the OAM write cursor is pointed by the PPU at address 0x218. I really don't have a clue how the Uniracers devs figured that out. I presume they just got lucky and their code worked by sheer accident.

> I assume the developers considered this difference an acceptable engineering tradeoff.

I should add, I played the game in both modes. I only found out about it because my HDMA code had a bug in it (this was pre-libco, so it was a terrifyingly complex state machine) back then, and the bug mysteriously went away when FitzRoy changed the CPU revision from 2 to 1.

There is no difference in speed. It's just creating two possible failure points instead of one.

> If you have a copy of The Lion King, BARRY will tell you.

Right, or select on Final Fantasy: Mystic Quest's status screen. Or you can heat a Bic pen to melting point and jam it into the screws to create a temporary bit (never worked when I tried it.) That's still an unreasonable requirement.

> Maybe that's why sometimes the IRQs are used instead of HDMA?

Very possible.

> Edit 3 (sorry): Looks like bsnes-plus emulates CPU revision 2.

I can't speak for all the forks, but I emulate some differences of CPU r1 and r2. Not all of them. But the setting is currently not changeable once the emulator is compiled.

I don't know how to emulate the HDMA/DMA crash of CPU r1, so that's why I default to r2. My emulator is a more faithful r2 emulator than r1 emulator.

[tokumaru]

yellow as fucc

That's easily reversible if you have access to hydrogen peroxide and sunlight. I've done this successfully many times.

[Revenant]

I can't speak for all the forks, but I emulate some differences of CPU r1 and r2. Not all of them. But the setting is currently not changeable once the emulator is compiled.

-plus can emulate the r1 CPU (using a config file variable rather than a compile-time setting), which affects HDMA and DRAM refresh timing.

[psycopathicteen]

This is honestly asking too much. There's 1324 usable cycles per scanline, the setup time to trigger the DMA is going to add some cycles to that, the CPU<>DMA and DMA<>CPU syncs add time, there's DRAM refresh in the mix, and you have to add the transfer lengths * 8 cycles per byte, and then you also have to consider if your DMA goes over HDMA transfers (which are even more complex, and can vary timing based on indirect transfers and reloading counters) ... and most likely, DMA transfers are going to be longer than one scanline, so that's most likely certain.

You can set up the DMA registers before waiting for H-blank and then all that's left is writing to $420b. Also, I don't need more than 64 bytes at once. I'm trying to make a self-updating level map, so I can have longer levels, and also do tricks like making a level repeat during a boss fight.

[Sik]

Er, is 64 bytes really worth the effort? I bet there are other things that could deserve optimization way more.

[psycopathicteen]

I guess now is a good time to try 10.6 coordinates since I got the game to work within a 1024x512 playfield. I'll make a copy of the source code, in case something goes wrong.

I also might also simplify my animation engine a bit since I have a better idea of how many sprites I need. Instead of mixing 32x32 and 16x16 slots together, I might have 20 32x32s, 32 16x16s and 4 static 32x32 explosion frames. I'll still cheat when it comes to fireballs.

[Ramsis]

Either you give up on 1/1/1 users, or you only use DMA during Vblank.

I don't agree.

if the speed is the same, just use the r1 version; and if the speed is different, what a horrible idea that half your users will be complaining of slowdowns. Regular end users have no way of knowing which revision their SNES is: they can't even remove the security screws to find out.

How would the knowledge about CPU revisions help them, anyway?

This is honestly asking too much. There's 1324 usable cycles per scanline, the setup time to trigger the DMA is going to add some cycles to that, the CPU<>DMA and DMA<>CPU syncs add time, there's DRAM refresh in the mix, and you have to add the transfer lengths * 8 cycles per byte, and then you also have to consider if your DMA goes over HDMA transfers (which are even more complex, and can vary timing based on indirect transfers and reloading counters)

As a programmer, you know your program. You know what's going on. So what's your point?

It's way too complex.

It's complicated, yes. Complex, not really.

I can't think of anyone who knows more about SNES timing than I do (a couple of people who know as much as I do.)

You're my hero. (No joke/irony/sarcasm intended.)

Pretty much the only way it'd work is if your DMA and HDMA always transferred the same amount of data each time, and your HDMA didn't have weird indirect fetching going on, and you could align the DMA start to a fixed point (whether via $4212's Hblank status, or a timed IRQ/WAI)

These "ideal" conditions do occur, you know.

Thus, my strong advice is: don't do it. Find another way to make your code work. I don't care who pulled it off, it should never be done.

Whether you care or not, it has been done. Apart from that, I reckon anyone even asking the OP's question is familiar with best practice in this regard anyway. So yes, it definitely should be done, and be it only for testing purposes.

[HihiDanni]

As a programmer, you know your program. You know what's going on. So what's your point?

Wishful thinking, unfortunately. If you're using any kind of abstraction layer, you're likely going to be a lot less informed about side effects caused by the underlying implementation. Yes, even the SNES DMA registers are an abstraction.

[Myask]

Is it [well-]understood how FFMQ (/USA) and The Lion King learn CPU revision data? Is it small enough to be run in the firmware? A reason not to just include on cart and possibly make a warning "This may freeze on your SNES"?

Is there a testROM out there for it, as another option?

[lidnariq]

Yeah, it's just reported directly by reading from $004210.

The problem is that either you entirely avoid the possibility of DMA/HDMA conflicts, or you write defensively like Ramsis's code, or it will crash on a 1/1/1 system. You can't get away with a warning label like "might crash"; it's just too likely.

[Myask]

reported directly

I'm surprised it didn't make it into more games, unless it was against lot-check regs or something.

Unless whatever you're doing is in a[some] cutscene(s) and you grant the option to skip (or auto-skip if 1/1/1).

[psycopathicteen]

As a programmer, you know your program. You know what's going on. So what's your point?

Wishful thinking, unfortunately. If you're using any kind of abstraction layer, you're likely going to be a lot less informed about side effects caused by the underlying implementation. Yes, even the SNES DMA registers are an abstraction.

What do you mean by an "abstraction"?

[koitsu]

I'm surprised it didn't make it into more games, unless it was against lot-check regs or something.

It's as easy as (assuming 8-bit accum) lda $004210 / and #$0f / cmp #$02 / blt CPURevIs1Or0 (blt == bcc). I imagine the logical code would just check this at power on or reset (see what else $4210 does for why, re: bit 7), and either set a variable in RAM or DP somewhere that DMA/HDMA code refers to (to know which CPU-revision-compatible methodology to use), or load the address of the CPU-revision-compatible DMA/HDMA routine and stick it in RAM/DP somewhere and use that via an indirect jump or equivalent; there are several approaches.

My point being: the detection process for CPU (and PPUs, for that matter ($213e and $213f)) revision is very simple and only needs to be done once.

[Near]

> I don't agree.

That's your right. People can listen to you and your experience with writing an SNES RPG (something I haven't done, but which shows a lot of knowledge of SNES development.) Or they can listen to me and my experience writing the most accurate SNES emulator. Or they can make up their own mind.

(I'm not in any way trying to imply either of us are more knowledgeable or should be listened to more. I was trying to reflect that we both have a lot of weight in knowing what we're talking about.)

> Wishful thinking, unfortunately.

Definitely. I can probably count on one hand the number of devs that can count the actual cycles of their code, including penalty cycles (conditions 2, 4 and 6 in the WDC manual especially.)

Now throw in bus hold delays, DRAM refresh, CPU->DMA sync, DMA->CPU sync, possible IRQs, HDMA indirect fetch overhead, etc and throw in the fact that we don't even know when exactly this crash occurs, and yeah.

What's going to end up happening is people tweaking things until the game "seems to work fine", which is a terrible way to program and it's why certain games end up breaking on some systems/emulators but not others.

I'm sure I could study for a bit and prepare my own fugu sushi, or rewire my circuit breaker box. But even if I succeed, and I got some added benefit out of it, it was still not a very wise idea to attempt it.

> My point being: the detection process for CPU (and PPUs, for that matter ($213e and $213f)) revision is very simple and only needs to be done once.

There's no reason to do it.

There is no PPU1r2, and no one knows of any differences between the three PPU2 revisions.

I discovered two CPUr2 revisions that are extremely minor (HDMA init timing, and DRAM refresh trigger position), and nobody understands the DMA<>HDMA crash well.

But even if someone did, again ... you don't want your game to run like garbage on a 1/1/1 deck. And I'd bet money that if there was a really substantial difference, Nintendo would have disapproved the software in QA testing. In fact, they may well have done just that, hence we have no examples to the contrary.

Even worse about the revisions ... they clearly stopped bumping them at 2/1/3, despite the fact that changes continued to be made. The SNES Jr pretends to be a 2/1/3, despite many glaring and severe changes.

[Myask]

That is to say, I'm surprised that so few "display to user the CPU revs" instances exist. Not that I'm surprised that nobody (or almost nobody? Uniracers?) did differential-coding for the revisions, or even 2/1/3-only code; that's the sort of Hardware-Dependent Mystery that would not be good for consumer confidence in product.