Sumez

No rotated version, and none are in the plans as it is, sorry It's limited how far I'm going to take a hobby project based on a property I have no rights to

Hey Kosmic. Check out the first quoted response in my post further up, where I address this. I wanted to keep the game as simple as possible, hardware wise, but ended up using save ram since it helps with making collision detection work like in the original arcade code, as well as saving the high score list. Saveram on the cartridge has absolutely nothing to do with the mapper chip, so it's kind of stupid that flash carts don't support it. "Mapper 0" is an emulator concept (as are all the mapper numbers) and really just means that the game doesn't use a mapper. I can send you a MMC3 version of the game if you're interested.

I'm a shmup player myself, so tate'ing is natural to me as well But the reception to the port has been funny in that regard as a lot of people who aren't used to it find the idea of putting a CRT on its side absurd. Yeah lots of weird wasteful code like that in the game! I didn't spend too much time optimizing that stuff, as I had plenty of CPU time left over, and cartridge space was much more of an issue to me. There is however a ridiculous amount of redundancy in the code, and like you're pointing out, the code to move the big metasprites around is really weird, as it tends to almost always place them in the same areas. It feels like they were intending to do a lot more with the game than what we ended up with. That goes double for the stages. The game is coded to support a ton of different possible screens with very little added overhead in storage space or anything else, yet the game ended up with only four different ones (five counting the intro animation). Getting a deep look into the code of a classic arcade game was definitely one of the most interesting parts of this project for me. I used this disassembly as a reference almost the entire way. There's a lot in there that isn't too well documented though, or downright wrong, as well as some stuff that whoever commented it never bothered figuring out, such as what the physics algorithm does. If you need help identifying the purpose of some variables or code blocks, feel free to ask away. Don't know anything about D2K's code, though.

To address a few of the comments people made: Yes, I designed the game based on the most basic PCB needed to reproduce the game - not with the intention of replicating existing mappers. The game uses no mappers (which was one of my initial goals), but relies on RAM expansion. My own dev cart is a MMC3 clone though, so I have a MMC3 version of the ROM somewhere if anyone wants it. It's basically the same with some added initialization code and a ton of unused space which I figured would have been stupid to release. Basically, the idea of making a "tate" version of Donkey Kong for NES was what started this entire project, so that would defeat the purpose. For a serious player, scrolling like that would probably also mess with muscle memory and the perception of the game, and in my opinion it compromises the whole idea of making an "accurate" port. To put things into perspective, the (at the time) world record holder of the arcade game played around with my version, and apparently there's a small error in the position the "popup points" are rendered at, which was enough to throw him off. Donkey Kong is an insane high precision game. It's not really needless. The only remaining items you could theoretically convert into background tiles would be 1. the barrel stack, 2. the oil can, and 3. Parts of Donkey Kong's body on non-conveyor screens. All of those would introduce issues though. The exact alignment of their position would cause a lot of issues not only with what graphics can be used, but also palette usages. And once again, moving them around would compromise the entire idea of the port (see above). A large part of Donkey Kong (who is also our main offender) could be converted without too much issues, but it would require a lot more unique graphic tiles and introduce extra graphics banks and a lot of bank switching into the code. I might consider doing it at some point, but as of now it's outside of the scope of the project. Btw, playing the game on a real CRT, I don't think the flickering is really much of an issue. But it's a lot more obvious on a LCD screen - and in a 30hz recording, it's completely awful. Thanks for noticing this! Those two samples use up a ton of ROM space, but I considered them necessary. During development I did include the option to completely customize the stage order, it was snipped out to fit everything in a single PRG bank eventually. It should actually be very easy to hack the rom to put in the japanese stage order. Actually not really! I avoided messing too much with the original routines (which causes a lot of performance overhead, but not enough to cause slowdown anywhere), so the game literally converts horizontal sprite coordinates to vertical right before rendering them, and adding a setting to change that would be absurdly easy. Even for the background tiles, I'm using a huge RAM buffer (part of what the cartridge RAM is used for) to avoid messing too much with the game's original routines (it reads from video RAM during screen rendering, something the NES isn't able to do), so even if that's a bit more complex, it shouldn't be too much trouble to convert that data when moving the buffer to the NES's video RAM. Of course all the graphic tiles would have to be rotated though, which I would imagine doing with bank switching to enable the choice of "yoko" and "tate" settings. No C&D. My video is still up there as far as I can tell, and I haven't heard anything from Nintendo. Doing this port really opened my eyes to how effecient the 6502 can be at certain things compared to other processors. I didn't really do a lot of optimization, as I wanted to make sure the original logic was kept completely intact, but a lot of iterating through 16 bit addresses was done much more effeciently on the 6502 than the original Z80 code, despite the latter's 16 bit registers. In general most instructions also simply only use half as many cycles as the Z80 equivalents. That said, the original arcade code isn't particularly nice in the first place, and it is very obvious it was created by at least three different programmers (a lot of redundancy, and wildly different ways of doing the same things), not counting the leftover code from Radarscope.

The developer of the port here. Thanks all for picking up on this project and commenting on it. I appreciate all the suggestions and criticism, though I'm probably not gonna follow up on any of it, since this was just an unambitious "for fun" project. It literally came out of a conversation with some friends about wether the NES would be technically able to run Donkey Kong accurately. One of the first counter-arguments was that it wouldn't be able to do the same resolution as DK is a vertical game in the arcade, which spawned the whole sideways TV (tate) thing. I looked into whether there would be any potential issues and deemed that it would definitely be relatively easy to pull off, but I sure as hell didn't want to spend the time doing that. Then one month later I ended up putting this out >_> The gist of it all, is that this was created to prove what the NES was capable of (in the face of the famously horrible official port), not what I was personally capable of. I don't consider myself a particularly skilled NES programmer.