There are so many topics to discuss. It would be very difficult to cover 100%. Let’s briefly mention a few of the things I forgot to mention.
Multiplication and Division
SNES has hardware to perform multiplication and division. Actually, it has 2 ways to do multiplication. You can look at my EasySNES code to find examples of these (link below, search for multiply: and divide:). They are a little slow, so you can’t expect to do this 100x a frame. You have to wait a several cycles before you get a result for the regular multipy and divide functions (see the NOP opcodes, which do nothing but wait).
If you aren’t using Mode 7, there is a second multiply function (signed) which is much faster. I need to rewrite that function (TODO). But the regular Multiply function works fine.
Any other higher level math will have to be done with LUTs (look up tables), precalculated byte arrays.
I have a Super Everdrive, made by Krikzz, from Ukraine. And, ooh, they even have one that supports the SuperFX chip. I wish I had that one.
Well, this one is over $200 US, but the basic model is less than $100, and it is well worth it. It works great. It uses a MicroSD card to hold the game ROMs.
This is the big enchilada, but I haven’t quite figured out this mode. Especially, setting up a tool chain for editing. Mode 7 can stretch and zoom and rotate. Many of the coolest SNES games use this in some way. It’s just currently above my skill level.
I do plan to work on this in the future. I wrote a tool called M8TE which can import an image to Mode 7 and create mode 7 maps.
This is for timing mid screen events. You should try to use HDMA instead. If all 8 HDMA channels are being used, you could do a 9th thing with IRQ timers.
You need to enable IRQ timers (probably just the V timer). and CLI to enable IRQs on the CPU. And you need to add code to the IRQ handler. Once set, the counter will trigger an IRQ signal once the PPU reaches a specific scanline. H counter would fire an IRQ signal every scanline, and you probably don’t want that.
Another thing that is a bit over my head. The SA-1 chip is just a much faster 65816 chip, and that might be the easiest to use.
Some chip names = DSP1, DSP1A, DSP1B, DSP2, DSP3, DSP4, GSU1 (aka MarioChip1 aka SuperFX), GSU2, GSU2-SP1, OBC1, SA-1, S-DD1, S-RTC, SPC7110, ST010, ST011, ST018, CX4.
Some of the functions they do…
image zooming and rotation
converting bitmaps to tiles
drawing vector graphics, triangles
real time clock
enemy AI functions (probably wouldn’t be useful to you)
The cool chip is the SuperFX chip (GSU). That’s what StarFox used. It would be nice if I could figure it out, and explain it. But, I can not.
Hi resolution. Modes 5 and 6 are double horizontal resolution. They can also, optionally, do an interlaced mode which doubles vertical resolution. Very few games used hi resolution.
Offset per tile Modes 2 and 4. I need to investigate these a bit more. I don’t want to put incorrect information here.
For LoROM, SRAM is mapped to banks $70–$7D in the $0000-$7FFF addresses. And also in the $FE-$FF banks in the $0000-$7FFF addresses. (7e and 7f banks are the WRAM, so that couldn’t be used for SRAM). That gives a total possible 512kB SRAM (battery backed save RAM).
HiROM, as usual, is completely different.
You will also need to indicate in the header that the ROM is using SRAM. I think that’s mapped to $FFD7, but it’s this line in the header.asm file
.byte $00 ; backup RAM size
The value is (2^# in kB). 3 is 8kB, 4 is 16kB, 5 is 32kB, 6 is 64kB, 7 is 128 kB, 8 is 256kB, and 9 is 512kB. 0 means 0kB.
Oh, and the previous line, mapped to $FFD6, should have the d1 bit (0000 0010) set. To indicate a battery for the SRAM.
Once you have correctly set this, the emulator should automatically be creating SRAM save files, that persist after power off. You can freely read and write to this anytime, and you can save your game by keeping the progress stored in the SRAM.