If I have an HDMA last longer than 224 lines, would it be safe on hardware or will it cause HDMA/DMA bugs?
HDMA stops once Vblank starts, and then will restart from the beginning once Vblank ends, so there shouldn't be any problems. Keep in mind that it still runs during forced blank, though.
Does that include forced blank at top of the screen? Or just the bottom or middle?
Forced blank doesn't affect HDMA at all, essentially, so it'll continue to go for 224/239 lines depending on what resolution is set.
So does that mean if I have an HDMA on the first line, the system can crash if V-blank runs a tiny bit too long?
Potentially, yes, if DMA ends around the time HDMA starts, just like without forced blank. I'm not sure whether or not the crash happens if HDMA doesn't actually transfer anything (that is, if it's been told to skip some lines).
In any case, if you want to make sure you avoid the DMA/HDMA crash during forced blanking, you should explicitly turn HDMA off. If that's at the start of your frame though, and you just want to turn HDMA off for those lines, keep in mind turning on HDMA mid-frame requires setting some extra HDMA registers manually.
Subject keeps coming up, I sound like a broken record.
Then why did when I hacked Street Fighter 2 to reduce the letter boxing the HDMA scrolling moved up with it?
Let's have a thread where each of us give one-liner responses, particularly about subjects that others partaking in the discussion have absolutely no familiarity with!
Yes, I understand that if the HDMA has already been started it will run through forced blank, but if there is forced blank before the HDMA starts, will the HDMA start by itself, or wait for a non-forced blank line to happen?
My first guess is that the same code turns off forced blanking and performs the extra manual steps to set up HDMA mid-screen. That's the only way I can think of where sliding the top of the letterbox up slides both of them up.
koitsu wrote:
Subject keeps coming up, I sound like a broken record.
The document refers to S-CPU v1, it almost sounds like it was fixed in v2. Do anyone know if this behaviour applies to v2 or not?
The DMA controller in S-CPU v1 exhibits undefined behavior when a DMA copy ends at the start of HDMA. This is fixed in S-CPU v2, which instead exhibits intended behavior. Do you plan to read RDNMI ($4210) and switch to an alternate, possibly slower code path for v1?
Something that I just realized was how much CPU time it takes to do HDMA window effects, because of how many scan lines there are.
tepples wrote:
The DMA controller in S-CPU v1 exhibits undefined behavior when a DMA copy ends at the start of HDMA. This is fixed in S-CPU v2, which instead exhibits intended behavior. Do you plan to read RDNMI ($4210) and switch to an alternate, possibly slower code path for v1?
So it was fixed in v2, thanks. Yeah maybe I'll read RDNMI if I need to, but first and foremost I want to take notes of all known differences between the S-CPU and S-PPU versions that may matter when developing. I don't want my games to be unplayable on older systems if it can be avoided.
Plus these kind of differences interests me.
The only other quirk I heard of is that v1 crashes if all 8 DMA channels are used at the same time.