I stumbled across some Game Boy Color ROMs the other day I remember seeing ages ago, and I'm glad I did. The ROM titles are:
NES Conversion - Donkey Kong [C].gbc
NES Conversion - Donkey Kong 3 [C].gbc
NES Conversion - Duck Hunt [C].gbc
NES Conversion - Hogan's Alley [C].gbc
NES Conversion - Mario Bros [C].gbc
NES Conversion - Popeye [C].gbc
NES Conversion - Tennis [C].gbc
NES Conversion - Urban Champion [C].gbc
NES Conversion - Wild Gunman [C].gbc
I opened a few and checked them out. They do, in fact, contain working conversions of those games. They aren't just clones of those games, but are real conversions! They run on the Game Boy color with the proper palettes and everything, but they will execute on a Game Boy as well, though palettes will be wrong.
Inputs are mapped as you would expect, with one exception - the select button allows you to move the viewport around with the D-pad as the Game Boy's 160x144 resolution is almost 1/4 that of the NES's 256x240 region.
The games run extremely slowly, and doubly slow on the original Game Boy. I'm impressed that attention has been put towards ensuring the attribute table is well respected and - well, rather that anything works at all! There is also some extremely limited APU support. Pitches are relatively well respected, but the duty cycle is always 50% for PU1 and PU2 and the envelope is the same each time (a moderately fast decay). The WAVE channel outputs an appropriate triangle tone. You can make out the title screens of a lot of games.
Sprites generally work well, but some are just missing. Probably the games' attempts at sprite multiplexing are causing some trouble for the game. Here you can see sometime Stanley is missing the bottom half of his body, and Donkey Kong does not have the beehives he is striking.
The attribute table is not perfect. Sometimes it is perfect, sometimes it is a little off, sometimes it is absolutely crazy. Fortunately, sprite / backdrop layer priority is correctly emulated in the cases I can see.
If I hold space in VisualBoyAdvance to unrestrain the emulation speed, the games do seem to run pretty well. The emulation speed (on the Game Boy) varies strongly based on what's going on. Lots of sprites bring things down a lot, and you can tell when activity is going on because the speed drops a lot. Conversely, there are times when some events make things go a lot faster. The game logic for Donkey Kong is very slow, but when Mario gets hit, or the hammer strikes a barrel, everything speeds up since all the game logic is being bypassed.
Mario Bros plays the level starting theme, then does not get past this point:
I'm led to believe it was a mostly automatic process. If someone was to do this manually, I don't think they'd be satisfied with leaving it as is, even though at this point it is pretty impressive. In addition, the image name is "FC" for all of the ROMs. This appears to be a true emulator in here, which is quite a feat given the system. Using a hex editor I verified that the ROM begins at 0x4000 after a lot of padding (sans NES header). I believe this alignment was done so that only a minor modification (subtract $0x4000) must be made to reads and writes of the NES program ROM, so the Game Boy doesn't need to load the game into RAM. This is probably one element of slowdown, transforming memory writes into many multiples of their original size in terms of cycle penalty. All the games that are shown working are NROM games, naturally. I tried to splice Zooming Secretary in there after stripping out the NES header but could not get it to work at all.
Does anyone know the origin of this software or any other interesting tidbits?
NES Conversion - Donkey Kong [C].gbc
NES Conversion - Donkey Kong 3 [C].gbc
NES Conversion - Duck Hunt [C].gbc
NES Conversion - Hogan's Alley [C].gbc
NES Conversion - Mario Bros [C].gbc
NES Conversion - Popeye [C].gbc
NES Conversion - Tennis [C].gbc
NES Conversion - Urban Champion [C].gbc
NES Conversion - Wild Gunman [C].gbc
I opened a few and checked them out. They do, in fact, contain working conversions of those games. They aren't just clones of those games, but are real conversions! They run on the Game Boy color with the proper palettes and everything, but they will execute on a Game Boy as well, though palettes will be wrong.
Inputs are mapped as you would expect, with one exception - the select button allows you to move the viewport around with the D-pad as the Game Boy's 160x144 resolution is almost 1/4 that of the NES's 256x240 region.
The games run extremely slowly, and doubly slow on the original Game Boy. I'm impressed that attention has been put towards ensuring the attribute table is well respected and - well, rather that anything works at all! There is also some extremely limited APU support. Pitches are relatively well respected, but the duty cycle is always 50% for PU1 and PU2 and the envelope is the same each time (a moderately fast decay). The WAVE channel outputs an appropriate triangle tone. You can make out the title screens of a lot of games.
Sprites generally work well, but some are just missing. Probably the games' attempts at sprite multiplexing are causing some trouble for the game. Here you can see sometime Stanley is missing the bottom half of his body, and Donkey Kong does not have the beehives he is striking.
The attribute table is not perfect. Sometimes it is perfect, sometimes it is a little off, sometimes it is absolutely crazy. Fortunately, sprite / backdrop layer priority is correctly emulated in the cases I can see.
If I hold space in VisualBoyAdvance to unrestrain the emulation speed, the games do seem to run pretty well. The emulation speed (on the Game Boy) varies strongly based on what's going on. Lots of sprites bring things down a lot, and you can tell when activity is going on because the speed drops a lot. Conversely, there are times when some events make things go a lot faster. The game logic for Donkey Kong is very slow, but when Mario gets hit, or the hammer strikes a barrel, everything speeds up since all the game logic is being bypassed.
Mario Bros plays the level starting theme, then does not get past this point:
I'm led to believe it was a mostly automatic process. If someone was to do this manually, I don't think they'd be satisfied with leaving it as is, even though at this point it is pretty impressive. In addition, the image name is "FC" for all of the ROMs. This appears to be a true emulator in here, which is quite a feat given the system. Using a hex editor I verified that the ROM begins at 0x4000 after a lot of padding (sans NES header). I believe this alignment was done so that only a minor modification (subtract $0x4000) must be made to reads and writes of the NES program ROM, so the Game Boy doesn't need to load the game into RAM. This is probably one element of slowdown, transforming memory writes into many multiples of their original size in terms of cycle penalty. All the games that are shown working are NROM games, naturally. I tried to splice Zooming Secretary in there after stripping out the NES header but could not get it to work at all.
Does anyone know the origin of this software or any other interesting tidbits?