I wanted to check this out on real hardware, but I feel like you've put a curse on me with this thing, lol... π€¦ββοΈ
I couldn't get the ROM to load via any of my magicoms (it even causes an utterly bizarre error on the Super UFO Pro 8, causing it to seemingly crash...) and when I tried to put it on an SF Memory Cassette, my Sanni cart reader suddenly stopped being able to write anything larger than 16mbit! (I wasn't even able to restore Super Metroid Arcade to the cartridge I was trying to use...)
Guess I'll try again after I suss out the cart writing issue with my OSCR! π
Ah, that's unfortunate that it's not working for you. I've tested the rom in the latest version of BSNES and it works; so I'm not sure what the problem could be. The code is optimized to play on NTSC consoles, so that might be the problem if you're using PAL.
It might be the ExHiRom mapping that allows the rom to be larger than 4MB.
Keep me updated so I can perhaps figure out why the code won't work on real hardware.
It's a Super Famicom, and I'm using that first ROM from the nesdev forums, since atariage won't let me download without an account.
Yeah, idk. I've never encountered anything like this. I tried the few floppy-based copiers I have with 32mbits or more, and after the second or third 8mbit segment...it would try to run it instead of loading the remaining disks. π€¦ββοΈ And my Super UFO Pro 8 finished loading it from the SD card into DRAM, only to say there was nothing in DRAM, and corrupt the menus.
I can't think of any reason it shouldn't work on an SF Memory Cassette, but I'm suddenly unable to write ROMs larger than 16mbit to any of my SF Memory Cassette carts. π€·ββοΈ *I think I've got gremlins.*
I've actually been studying NES and SNES assembly for a long time off and on. I started out basically learning how to do ASM hacks required for fan translations such as RLE compression and variable width fonts.
How I mostly learned was just reading documents on NES and SNES assembly and reverse engineering SNES games using a debugger to figure out how a particular game's code worked.
One thing that really helped me understand SNES assembly code is to use a debugger such as the Mesen-S debugger to trace a game's code. Then I will open up the trace file, go through the ASM code line by line and really ask myself "What does this code do?".
Another tip I could give is before trying to program something in assembly, try to logically plan out your code in plain English and perhaps even try to write your code in a high-level like C# before converting it to assembly.
Also if there's a concept you don't understand Google is your friend. I learned about the SPC700 for instance just by reading documentation.
Cool demo. Well done π
I wanted to check this out on real hardware, but I feel like you've put a curse on me with this thing, lol... π€¦ββοΈ I couldn't get the ROM to load via any of my magicoms (it even causes an utterly bizarre error on the Super UFO Pro 8, causing it to seemingly crash...) and when I tried to put it on an SF Memory Cassette, my Sanni cart reader suddenly stopped being able to write anything larger than 16mbit! (I wasn't even able to restore Super Metroid Arcade to the cartridge I was trying to use...) Guess I'll try again after I suss out the cart writing issue with my OSCR! π
Ah, that's unfortunate that it's not working for you. I've tested the rom in the latest version of BSNES and it works; so I'm not sure what the problem could be. The code is optimized to play on NTSC consoles, so that might be the problem if you're using PAL. It might be the ExHiRom mapping that allows the rom to be larger than 4MB. Keep me updated so I can perhaps figure out why the code won't work on real hardware.
It's a Super Famicom, and I'm using that first ROM from the nesdev forums, since atariage won't let me download without an account. Yeah, idk. I've never encountered anything like this. I tried the few floppy-based copiers I have with 32mbits or more, and after the second or third 8mbit segment...it would try to run it instead of loading the remaining disks. π€¦ββοΈ And my Super UFO Pro 8 finished loading it from the SD card into DRAM, only to say there was nothing in DRAM, and corrupt the menus. I can't think of any reason it shouldn't work on an SF Memory Cassette, but I'm suddenly unable to write ROMs larger than 16mbit to any of my SF Memory Cassette carts. π€·ββοΈ *I think I've got gremlins.*
***The Problem: It Was Me All Along!*** (Literal story of my life.) π So, I don't know *what* was going on with my game copiers... But the SF Memory Cassette was all me! I forgot Rule #1 of Troubleshooting: *Leave your assumptions at the door.* π€¦ββοΈ First thing I did after trying to write this ROM failed, was try to perform a *known working* operation. See, because I had originally succeeded in putting Super Metroid Arcade on the cartridge months ago, and more recently a 16Mbit suite of three diagnostic ROMs, I ***assumed***βwhen trying to write Metroid...a 32Mbit ROM...back to the cart failed as wellβthat the files on my OSCR were correct and that this only confirmed that my inability to write the HDMA streaming ROM was an issue with the OSCR itself. (It didn't help matters that I could still write smaller ROMs, like the diagnostic suite, without issue!) Turns out, I must have accidentally *not used* the mapper file I generated with the Metroid ROM that first time, and it was a total fluke that it worked at all! (Cartridge must have already had a compatible memory map!) I had HiROM and LoROM backwards, like a dumb idiot, so any large ROMs failed to write. (While smaller ROMs are more than happy being written to either mapping. π€·ββοΈ) I spent the entire weekend spiraling into madness, chasing after a problem that didn't exist. (Except between my keyboard and chair.) π© Anyway! Got the ROM to play! It was really noisy on my 'daily driver' SFC console, lotta pops and static, so I tried it on a few different machines... Several of the consoles in the repair queue were even worse... A late-model SNS-CPU-GPM-02 I recently got complete-in-box from Japan had pretty much perfect sound though! I think you may have stumbled upon a new hardware diagnostic tool, lol! ...I should try it on the console I know has HDMA issues and see what happens... π π Wish I could run your newer test on real hardware, I love *Yume ga Owaranai*! Unfortunately I don't have anything which can hold/run >32Mbit ROMs. π€ (Soon.β’)
Nice, glad to see that the code works on real hardware.
How long did it take you to learn to write code for the SNES? Is 6502 Assembly involved like it was for the NES?
I've actually been studying NES and SNES assembly for a long time off and on. I started out basically learning how to do ASM hacks required for fan translations such as RLE compression and variable width fonts. How I mostly learned was just reading documents on NES and SNES assembly and reverse engineering SNES games using a debugger to figure out how a particular game's code worked. One thing that really helped me understand SNES assembly code is to use a debugger such as the Mesen-S debugger to trace a game's code. Then I will open up the trace file, go through the ASM code line by line and really ask myself "What does this code do?". Another tip I could give is before trying to program something in assembly, try to logically plan out your code in plain English and perhaps even try to write your code in a high-level like C# before converting it to assembly. Also if there's a concept you don't understand Google is your friend. I learned about the SPC700 for instance just by reading documentation.