Thanks for the explanation. I would agree that it would require advanced skill. I have worked with Assembler some at work. Some of our 3M vendor applications are written in assembler, and our older 3270 mapsets for our green screens.
Its definitely not very user friendly or intuitive. I always thought it would be fun to dabble in this on the side. I haven't coded since 2006 though, and I'm rusty. This would prob require more time than I have to commit at the time.
To be honest, it's not really the assembly syntax/language that poses the more complex issues - it's the hardware. Beside a few calculation look-up tables that I use for video addressing, almost all the code is for the emulation backend is nothing fancy. It's everything around the processor. NES video isn't clean in design/interface, and games rely on these weird quirks (you get dumby/pre-buffered data on the first read from vram port, etc). NES programmers turn off the display while in vblank, and this causes a problem for the PCE which doesn't need this. On the PCE if BG/Sprites aren't enabled by the time active display starts on the PCE, it's disabled for the whole screen - you can't turn it back on mid screen. A serious pain in the ass when NES code runs into active display area of the PCE. I had to cache/buffer this for a whole frame on the PCE side, so I could tell the difference between normal vblank code or if the game is really turning off the screen on the NES. I had to test for this case. Stuff like that. While that's working now, everything is still timing sensitive, since the NES code isn't perfectly synced (running) as with a real NES. I mean, it gets re-synced every frame due to v-blank interrupt. Usually not a big deal, but it can cause problems to where you need to tweak or replace some NES specific code (like sprite 0 trick on NES to make fixed status bars). Or some stuff isn't straight up emulated yet because games I worked with hadn't used that feature yet.
I actually have three main PPU emulation cores that I tweak depending on the game. One is for games that use 8x16 sprites, one is for certain tilemap mirroring, one is for vrom vs vram, etc. I don't emulate everything straight out because the overhead of case checking makes the code slower and more complex. For instances, if I wanted to get Blaster Master up and running, I'd have to make a new PPU core than can handle both 8x16 and 8x8 sprites, because this game switches between these modes (overhead mode VS tank mode). Most NES games don't do this. 8x16 sprites on the NES aren't just large sprites; it also allows sprite cells (access to them) to cross into the BG only cell bank (which otherwise isn't capable of doing in 8x8 mode). It's common for 8x16 sprite cells and BG cells to be in same BG bank, so I have to double write to vram on the PCE to compensate for this; I write/convert the data into two locations in PCE vram (since PCE sprites DO NOT use the same cell format as PCE tiles, like it does on the NES). I could write code to switch between with core to use by testing a PPU reg status bit, but if the game updates vram/vrom BEFORE changing the PPU to this bit - then I won't be able to tell. This is crucial. The game would have to be hacked to fix this timing issue, if this were the case.
Stuff like that. So the core(s) I wrote are reusable across different games, but they still need to be tailored/tweaked per game. Thus the requirement for both in depth/advance knowledge of NES and PCE. The commenting of my code is the least of the problem
The negative stuff out of the way, I do have a positive side; upgrades. Since I'm emulating the PPU in realtime, I've actually gone in and expanded the NES PPU capabilities. I took the unused bits in the sprite tables for the PPU, and gave it larger sprites with larger subpalettes. This basically gives a hacker a level of translation for PCE capabilities, but without learning PCE side of the system. So an experienced NES hacker could upgrade something like Megaman 1 or 2 with better graphics, without having to learn the PCE's much different hardware side. And they could write code as if it was on the NES system (6502, typical mapper, etc). But I have yet to get any interested hackers out there though, sadly.
NightWolve: Yeah, I haven't made public the released the updated audio core for those games. Although they sound better, the lack of sweep emulation still makes them sound broken at parts. Once I get that working, I'll update it. Those games were more of just a proof of concept and practice (those games only took about a day to get up and running). Megaman 1, 2, and Dragon Warrior (unreleased) were tweaked to run as perfect as I could - because I cared more about those games.
