I'd like to implement midframe HDMA but I'm getting mixed results in emulators.  Snes9x works as I'd like it to, ZSNES and bSNES do not.  Since bSNES doesn't like it, I suppose I'm doing something wrong.  I set $4308 to what I would in $4302, the bank is set as normal.  Leaving $430A untouched doesn't seem to stop it from working in Snes9x (I am guessing you put your first line count in there?).  In ZSNES and bSNES, nothing triggers.  Snes9x behaves the same if I disable the channel.

Is there something more to it?

It's difficult to debug other's software, and you picked one of the most difficult things to attempt on the SNES, so instead I'll explain how mid-frame HDMA works, and hope that will help point you in the right direction.

First, at the start of every frame, the following is called no matter what:


Next, if and only if $420c is not clear, the below is called:


Next, on every scanline, the below is called, if any [ i ]active[/i], non-terminated channels remain.


Notice hdma_do_transfer? This is likely where your problem lies. If $420c == 0 at the start of the frame, do_transfer will be set to false. But fortunately (for you at least), hdma_completed is also set to false, so you can still enable HDMA with trickery. Notice in hdma_run(), which runs every line, that it decrements hdma_line_counter. Then, it sets the important flag, do_transfer.

You need this to get set, the test is do_transfer = bool(line_counter & 0x80), so you'll have to set your starting position to $81 in $43xa, [ i ]one line in advance of where you want mid-frame HDMA to start[/i]. This will turn on your transfer (anything < $80 will not), as well as fulfill the next condition, (line_counter & 0x7f) == 0. Remember, the decrement happens first, before those two tests, hence $81 and not $80. We use $81 to minimize the number of lines you have to setup HDMA in advance to just one. The hdma_update() that is called will load a new line counter value (directly or indirectly, depending on how you setup HDMA), so obviously your transfer won't be stuck in continuous mode or anything. It's just a one line thing to trick HDMA to start.

Lastly, you basically have to simulate hdma_init above, since that won't be called when $420c.dN is 0 at the start of the frame. But you probably already know that part.

I thought I knew quite a bit of how HDMA works. 

*DaMarsMan crawls into a hole and starts to cry*

I don't know. I just took another look at the BSNES source code. I don't think it's very easy to find what you're looking for quickly.

Let's take this case as a specific example. I didn't even initially think to look in sCPU for information on hdma. The first association in my mind was PPU or screen related functionality. Then while I was browsing around some of the bPPU files, it wasn't entirely obvious to me until I looked at a few files that general PPU register information could be found in 'bppu_mmio.cpp'.  I'd say you definitely need to spend 5 or 10 minutes of looking around to start to know where you should be looking to find the information you may be looking for. There are many files and it's not always clear what is in them until you look at them.

It's not plainly obvious where to look immediately. I'm sure looking for something more obscure may be even more difficult to locate the information.

On another note, you have very nice comments in certain files, but plenty of other files have very little if any. Maybe you thought they didn't need any, but I've always preferred too many comments as opposed to not enough.

Walk through the process of how you would have expected this guy or anyone to use the BSNES source to find the answer. I'm interested to know your thought process.


Those are my observations after looking through there for a few minutes. I can understand how somebody may not have found the answer they were looking for. Of course, you also have to understand many people probably don't yet think of BSNES source as a document to go to. I'm very aware of it and it still doesn't pop in my head as something to use for reference very often.

Let's not call apples 'oranges', here.  Source is not documentation.  No matter how clear a program's source is, someone would still have to decipher what it's doing.  Compare that to a document which describes the details of a behavior, and possibly even includes examples and snippits of other information that might provide a more clear picture of what's going on.

I'm not saying source isn't a good tool for learning this kind of stuff.  I'm just saying it can't be a replacement for (or fill the shoes of) actual documentation.  The two serve two entirely different functions.

Not to mention understanding something from an emu standpoint is much different from a hacker/homebrewer standpoint.  Understanding how to emulate the behavior doesn't necessarily tell you how to utilize that behavior from the ROM's end.  This very topic is a perfect example of that.  Someone can look at the code byuu posted and understand the step by step... but they'd still have to fumble around with that information to figure out how to get HDMA to work mid-frame.

A good document, on the other hand, could easily list the steps required to make HDMA work in this fashion.  In fact...  Anomie's doc does exactly that:


This little snippit tells exactly which regs someone would need to write to in order to make HDMA work.  And exactly which ones are needed to make it work when starting mid-frame.  Compare that to the much larger and much more difficult to understand code snippit (or rather, multiple code snippits) byuu posted.


Note again I'm not saying source isn't useful.  It most certainly is.  I've learned a lot of great stuff by examining others' source that I couldn't have gotten from documents.  But I never liked the "look at the source" response to behavioral questions.


EDIT - I think creaothceann was trying to say more or less the same thing I was, actually  ^^;