The SNESdev wiki has some code that provides those values, and the original system documentation Nintendo provided had some ideas for a reasonable initial state “for beginners” as well. With those out of the way, we load a sensible set of initial values into the graphics registers that start at $2100. VBLANK could jump us into code that will assume the system is already initialized HDMA can interfere with the VRAM write pointer. There are two of those: the VBLANK interrupt and a system called “HDMA” that we’ll get to later. Now that it’s actually safe to start talking to memory or I/O, the first thing to do is to disable any systems that might interfere with initialization. Our startup program bank always has I/O available, though. If this was a soft reset we could be pointing at anything, and might even be in a bank where the registers aren’t mapped in. I’ve decided further, here, to be a bit more explicit about that and give the stack the lowest 1KB of RAM exclusively, pointing the Direct Page just past it:Īt the end of that sequence I move us back into the 8-bit accumulator mode, and also ensure that the data bank register is back at bank zero where it belongs. When I set up my linking script, I decided that a 1KB stack will be sufficient and also that it shouldn’t be sharing any space with the Direct Page. Part of setting things up does require us to decide what some of our most basic memory layouts will be, though. This ends up being kind of a cross between the the NES startup code and escaping into full 65816 mode in ProDOS 8. The first thing we have to do is get the chip into a reasonable state. That means I can write a single initialization routine and let ld65 link it in for me. That said, assuming that you’re relying only on the stock hardware, the same startup code will generally work for every combination of SlowROM/FastROM or LoROM/HiROM/ExHiROM, as long as we can instruct the linker script to put the code in the high half of bank zero. The SNES has fewer moving parts than the Genesis, so setup is more straightforward here and feels more like setting up the NES, just with more switches to reset. The fourth part, which we do not provide here, takes up 16 bytes of space just before the game title, from $FFB0-$FFBF, and provides extra (legacy?) game identification bytes and more options for coprocessor registration. When we do proper releases, we’ll compute the checksum properly. We’re leaving dummy values there for now but respecting the complement part of it because emulators will often recognize a bad but properly-formatted checksum as part of a consistent header as marking a homebrew cartridge. The ROMINFO segment is rounded out by two words, the first of which is the checksum for the entire ROM and the second of which is the one’s-complement of that checksum. The final three zeroes represent region (0 is NTSC), developer ID (We don’t have one), and ROM version (first release). We don’t have any RAM, so that value is a zero, but we have 128KB of ROM, so we write a 7 into at slot. The third and fourth bytes represent the ROM and RAM size within the cartridge, as powers of two. The second byte describes what hardware is present on the cartridge a 0 here means we’re just a pack of ROM chips, but this byte lets us specify on-board RAM, a savestate battery, or one of a dozen coprocessors. If the game only saves at the specific save points, then what's the issue there? I know this is a problem in basically any console game though.The first byte specifies the cartridge layout $20, $21, and $25 represent LoROM, HiROM, and ExHiROM respectively, and adding $10 to this (so the first hex digit is 3 instead of 2) signifies that it is FastROM-capable. Try another snes first, I think this is caused by a serious hardware issue that is outside of the realms of just cleaning the pins.Īnd thanks for the quick response Simion, as for the saves, so what is it about a console abrupty being shut off that will break the checksums for a save file? I got really pissed at DKC3 once and threw the controller which upset the console enough to freeze. So word to the wise if anyone else gets this issue don't go beating the crap out of your cartridge. Lost my saves but I'm just glad I can finally play games again without any issues. Even after cleaning the pins on the bad one still no changes. Everything's working fine now that I'm using my other snes. I forgot I had another snes and at some point and time they got switched up. DKC1 has this issue where some background sprites get completely messed up, no matter how hard you try to fix it, and today I noticed vertical lines on some of the sprites in Super Adventure Island which I also could not fix. After some critical thinking, I realized I forgot about some other things.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |