Ever since I worked with Kent Hansens "NESRev" (the pretty intelligent disassembler), I've been thinking about if it was possible to port NES games to other platforms. Converting the 6502 to fit the desired platform and then manually adjust the graphics/soundcode.
I quickly discovered that automatically translated code would be pretty inefficient so I guess it has to be done in some other way.
Question is.. how?
I'm just playing with the idea for fun. We can disassemble the 6502 code but then what. Manually converting each subroutine? But it would be a pretty gruesome task since each subroutine could call ten other subroutines. And how about testing? This kind of manual conversion would be very difficult to trace for bugs.
So, anyone with some brilliant ideas? The question perhaps remain why I want to convert the code when we could use emulators. Well, for fun.
Are you talking about other third- and fourth-generation platforms (such as Game Boy, Master System, Genesis, Super NES)? Inefficiency of statically recompiled 6502 code isn't quite as much of a barrier on PlayStation and higher platforms.
I seem to remember that Super Mario Bros. was statically recompiled to 68000 for a pixel-perfect homebrew port to the Genesis, called "MULS" or something.
I was perhaps thinking of trying to port to the Amiga-platform (since I'm pretty familiar with that one).
Line-by-line conversion is pretty cool, but how do you detect bugs in your code if you do it manually? A simple typo would be close to impossible to detect
unless some other smart ways was used.
EDIT: I read about the MULS-project, he used some kind of converter software.
The static recompilation of SMB1 was mostly automated, which means the Genesis version reproduces it bug for bug. Any bug outside the low-level graphics and audio code is either A. a bug in the translator or B. something that ShaneM fixed in his recent FDS mega-hack.
Unlike the display model of the Game Boy, TG16, Genesis, Super NES, GBA, and Nintendo DS, the Amiga's display model is probably different enough from that of the NES that you'll probably need to completely rewrite the graphics part. Does it even support smooth, rapid scrolling? Or is it a dumb frame buffer like the Apple II and PC? Google amiga scrolling returned results from lemonamiga, which is currently giving me "phpBB : Critical Error / Could not connect to the database".
The Amiga hardware is very capable of scrolling, however I am no expert in that area. Currently, I am just interested in the CPU conversion. I read that the tools used for creating MULS should have been released but I haven't seen them yet.
The Amiga is the reason that Europeans used to refer to sprites as "bobs" instead (blitter objects), so yes, it can do sprites.
Link
Dwedit wrote:
The Amiga is the reason that Europeans used to refer to sprites as "bobs" instead (blitter objects), so yes, it can do sprites.
LinkAre we supposed to refer to them as "bobs" ? I never heard this term. But pehaps it was common in the 80s and then "Sprite" take up because of the internet.
The C64 official doccumentation in french calls it "Sylphe" which is a litteral translation of "Sprite", the mythological creature (which has nothing to do with computer science). Using this term in french instead of the english word "sprite" is incredibly weird and confusing.
As for porting to other platform, I don't know if you mean coding a game to be multiplatform or if you mean converting an existing game. In all cases you'd want to look into virtual machines and/or decompiled code.
Has any progress been made figuring out the relationship between Hello Kitty World (NES) and Balloon Kid / Balloon Fight GB / Hello Kitty World (GBC)? The low framerate, nearly identical gameplay / timings, and other strong similarities point towards some shared code between the two. This thread reminds me of that because I am wondering which of those games came first, and in what language. Perhaps some amount of automatic conversion was involved.
I got the source for the 6502-68000 converter ("Mos2Mot") and is working on updating it a bit (with permission). If anyone's interested, the download is located on my website (
http://nes.goondocks.se) and it requires .NET framework 2.0 (and probably Windows aswell).
It actually converts disassembled code (*.asm) not binaries so it requires a good disassembly to work good.
Appearently the download for your converter is broken as of this writing, It says 404 not found!
This is a great idea, but I'm sure you have to be somewhat proficient at the Amiga's hardware to pull it off. IIRC, the Amgia has scrolling functionality (X/Y) just like a console, but you're scrolling a bitmap plane (or two, if you use two 3 bit planes mode). I don't think this would be much of a problem since SMB is only updating the edges of the 'tilemap'. You should be able to replicate that functionality with the blit hardware of the Amiga. Maybe a few address translation tables to speed it up.
The Amiga has weak sprite support though, and as most games use a one (4bit coupled) for the main sprite, the remaining 2bit sprites with copper reloading for 'bullets' and such, and everything else just object blitted (IIRC, there are logical operations that can be tied to the hardware blitting, so probably a two pass system. One for the mask, and one for the data/object). That said, if the sprites were to remain in 2-bit color mode, then you have the same limit as the NES (8 per scanline). But you'll still have to devise 'copper' code to reload those sprite entries on a per scanline basis (there are only 8 registers for the entire screen, unlike 64 on the NES). Tricky, but doable.
As far as sound, couldn't you use the double channel method (there two methods, the simpler is to interleaving sample data on every channel). Square wave channels should be fairly easy to simulate (even with a fixed pointed dirty frequency scaler). Same for triangle and noise. DPCM might be a bit trickier (probably easier to replace with regular samples).
In fact the old ANES and DarkNESs emulators on the Amiga did various tricks like these... used the hardware as a "high-level emulation" of various NES features to gain speed. Unfortunately, games that did scanline trickery, etc broke a lot of this functionality.