Beginner questions, CGRAM/OAM/VRAM DMA, Program flow

Hello, I've been attempting SNES development again. I'm using the official dev docs, Fullsnes docs, wikis, Yoshi docs, these forums etc for info but there are lots of things I don't understand.
Lots of questions:

1. The flow chart in chapter 23 in the dev docs doesn't mention shadow OAM. Is it commonly used in SNES games? I reserved space for my OAM data from WRAM page 2 anyway. I guess a VRAM buffer and a CGRAM buffer would be good to have too.

2. There seems to be three CPU speeds. I guess 1.79MHz mode is used in emulation mode for compatibility with 6502? It's also used for controllers it seems.

3. . According to the dev docs, low 8 kB WRAM can be accessed from any bank between $00~$3F and $80~$BF. If you access them rom bank $80+, wouldn't they gain the benefit from high speed mode, or are they too slow chips?

4. When doing DMA for CGRAM, I couldn't load the colours unless I picked source bank 1 for DMA. But I put the data in bank 7! What's going on? I'll upload my code soon.

5. When using DMA, do I need to wait a bit before using the same channel again so it won't interfere with the first transfer? The dev docs flow chart says to initialize CGRAM and OAM "using 2 channels DMA", what do they mean by that? I just put two DMA transfers after each other using channel 0 for CGRAM and channel 1 for OAM. But in that case wouldn't you need to use at least three channels for BG, sprites and a tilemap when initializing VRAM? The dev docs is a bit confusing for this part.

6. The flow chart also says to make a loop for the VRAM DMA transfers like this:

How would this be done in practice? I'd guess I'd read the VRAM using $2139 and $213A and somehow compare it with my data in ROM to see if it's been transferred properly. I haven't seen anyone do this though.

7. Although SEI was used at the beginning of the program, it seems I don't need to use CLI to enable interrupts again like on NES. I don't understand why.

8. The flow chart in chapter 23 says to enable NMI and controllers at $4200 in the beginning of every main program loop. Is this really needed? Haven't seen anyone enabling it more than once.

Thanks in advance!

As far as I can tell, ultra-slow (1.8) mode is used only for the controller ports, with everything else at 2.7 or 3.6.


It's still slow RAM. If you want a small amount of fast RAM for a tight loop, set D to $4300 and use unused DMA registers as your direct page.


Perhaps the idea is that you can set up the channels during draw time, when writing to video memory is forbidden, and then just activate them all once vblank hits so as not to waste valuable vblank CPU cycles on poking in a new address.


If you use only the vblank NMI, not NES's mapper or DMC IRQ or the Super NES's HV IRQ, you don't need to CLI on either platform.


I'm guessing it means before the loop, not during the body of the loop. A game might turn off NMI and controller reading while sending new data to the S-PPU and S-SMP.

Ah thanks for these answers. I'll upload my code in the attachment of this post.


This part is before the main loop when forced blanking is still in effect. I'm pretty sure it's about copying data to VRAM for drawing the initial screen. But I guess it's enough to fill buffers and let the next NMI take care of the copying to VRAM.

I see, I always thought SEI/CLI affected all interrupts on the CPU side.


In the flow chart it's clear that it's in the main loop (display period). Maybe it's just a safety measure in case the registers just randomly corrupts for whatever reason? But that would go for all registers set in the beginning too.

Here is the flow chart I spoke of (it's just 3 pages so it should be OK). The diagram itself is pretty clear, but the language is a bit weird. I think the whole document was a bit badly translated sometimes.
http://s2.postimg.org/ga4ygkxjd/23_1.png
http://s22.postimg.org/lyhen52wh/23_2.png
http://s15.postimg.org/xja13i68r/23_3.png


And here's my code at the bottom. I got CGRAM loaded (but seemingly random results) but OAM and VRAM still doesn't show up in the VRAM viewer of no$sns emulator. I'd appreciate any tips. I'm trying out bass (included in archive) for assembling at the moment which has a bit weird syntax, sorry about that.

You can only copy about 5 to 6 KiB to VRAM in one NTSC vblank. I haven't had a problem performing consecutive transfers to tile VRAM, map VRAM, and CGRAM because the CPU pauses until completion while a DMA copy is running.


This is what it's probably trying to say:

Find the parallels to how things are set up on the NES:

Oh of course I can't update the whole screen in vblank, I forgot. So the CPU pauses during DMA, then what is the meaning of 2 channel DMA for OAM and CGRAM if they can't be used at the same time?



Aha so it's not like they mean to use an actual loop in your code, just that you should keep adding DMA transfers to your code until you have covered all your initial data you want to upload to VRAM.


Do they mean anything with "Recognize beginning of VBLANK period by NMI"? The NMI flag at $4210 is automatically cleared at the end of vblank, and according to Fullsnes you normally don't need to clear it (although in Bazz tutorial they do clear it at the end of NMI).

You don't have to use two channels if you don't want. Not being a licensed developer, I can only speculate why they used 2 channels instead of 1. Perhaps it saved having to activate DMA twice.


Likewise on the NES, the NMI flag at $2002 is automatically cleared at the end of vblank, and according to Everynes you normally don't need to clear it (although in a few tutorials they do clear it at the end of NMI).

So anyway, per NMI on the wiki, what normally happens on the NES or Super NES is that the NMI handler sets a flag somewhere in memory, and the main thread spins on that to see whether NMI has occurred.

This is the "main thread only" option described at NMI thread. It's also possible to run your VRAM update code or even your entire game in the NMI handler.

(For those with NES experience: wai is a 65816 instruction that pauses the CPU until the next IRQ or NMI. It reduces power consumption on hardware, reduces host CPU usage on emulators, and reduces jitter on either one. The f: prefix in ca65 forces a "far" (24-bit) address, making the code independent of the value in data segment register B. The rep #$20 instruction sets a processor status flag such that instructions dealing with register A or with read-modify-write operations handle 16-bit, not 8-bit, values.)

If you enable multiple DMA channels at once, each one will start as soon as the previous one finishes, and the CPU will only start executing instructions again after all of them are done.

Also if I recall correctly the controllers are the only thing in the SNES that is still mapped to the registers the NES used. So I wouldn't be surprised if it was indeed originally for compatibility (obviously pointless later on).

Yup they even have the same address $4016/$4017. Apparently if auto-controller-reading is turned off the old registers can be used instead the same way as for NES. Also in order to use special peripherals like multitap or mouse, the old registers must be used.


Alright I figured out the problem! I was misunderstanding how $420B works. It enables DMA channels 0~7 by setting the corresponding bit 0~7, of course! Now everything works as expected!


It's just question 4 that remains unanswered. You'd have to download my code and check the DMA settings for CGRAM, VRAM etc in "main.asm". There I'm using bank 1 as source bank, yet my data is supposed to be placed in bank 7. It might just be something with bass I just don't understand.