Hi everyone,
Let's say I wanted to port a relatively simple NES game to custom hardware. Pair a 320x240 LCD with a Cortex M0 or AVR. What problems would I run into? I've done some assembly work before, but not 6502. I need help fleshing out the steps.
1. Get compilable game source. Done
2. Cut out unnecessary code to simplify initial port (ex. sound engine). Done
3. Choose modern, low-power processor that has similar instruction set
4. Choose LCD that has interface library for target chip
5. Write a utility to translate from 6502 asm to target arch
6. Preload character rom data into a rom chip
7. Select large enough RAM chip
8. Emulate (?) the NES PPU.
Step 8 is tripping me up the most. Should I route stuff sent to the PPU pins to another chip and code up a PPU clone, or just interleave the LCD graphics library code into the game and start blitting stuff on the fly?
I just don't know enough about the NES/PPU to know if this is feasible. I don't know, for instance, if the target game relies extensively on precise cycle timings to run properly. Would cutting code and inserting other code throw things off?
Things I want to avoid:
-Coupling a NOAC with an LCD (too easy)
-Using an FPGA / CPLD (cost)
Any help or pointers would be much appreciated! If this project is too crazy let me know too.
You can either have multiple chips that do the work, or run a emulator on one chip that does everything and the output. Probably more option, but I don't know them. And the NES's screen is 256 pixels, but I think that the 320 is because it's a common size/standard size. And I think as you move forward the NES CPU/PPU/APU emulation will become fairly straight forward, as they all run parallel with each other and you can make each seperate [sometimes] but I think one of the hard things with emulation is the quirks. Good luck!
How fast is your "modern, low-power processor"? If it's fast enough, perhaps one of the existing NES emulators could be ported. If it's an ARM, and you can make a simple tile display engine (read: a PPU less accurate than Nesticle's yet good enough), you can probably repurpose the PocketNES emulator to emulate the CPU and APU. PocketNES itself needs only about 16.8 MHz of an ARM7TDMI CPU, but it high-level-emulates the PPU by telling the Game Boy Advance PPU to display the same tiles.
tepples wrote:
How fast is your "modern, low-power processor"? If it's fast enough, perhaps one of the existing NES emulators could be ported. If it's an ARM, and you can make a simple tile display engine (read: a PPU less accurate than Nesticle's yet good enough), you can probably repurpose the PocketNES emulator to emulate the CPU and APU.
Interesting idea, but I was more interested in doing a source-level port. I don't have a good grasp on how I would do the tile-engine part. Maybe I should be referencing the emulators to see how they do it...
I figured it would be neat to have the game directly ported to another chip rather than emulated. Kind of like the SMB to Genesis port.
http://kotaku.com/5578821/super-mario-bros-finally-faithfully-ported-to-sega-genesis
What game are you trying to port? You'll run into a lot of issues if the game uses any timed code at all. Sprite 0-based status bars may be an issue too if you are not emulating the PPU.
Also if you are not going to emulate the PPU you will likely need to rewrite fairly large chunks of the code.
Sounds like an interesting project though.
This question isn't related to
the nD (found via
Slashdot), is it?
I really don't know if it'll work for what you're trying to do but it sounds like it's along the lines of your idea.
Have you looked at the UZEbox?
http://belogic.com/uzebox/index.asp
open sourced project with an atmega, RGB converter chip, and a bunch of resistors combined together for some surprisingly impressive graphical power.
With it being open source you could figure out your own way to add RAM/ROMs if you needed it.
The UZEBox is pretty freakin awesome
I got as far as making a Pong machine out of an ATTiny2313 and a simple R2R ladder, but this thing blows me away.
UZEBox is based on an ATMega644. That has 64KB of PRG ROM (32K instructions + data storage, minus UZEBox libraries and boot loader) and 4KB of RAM (minus the VRAM, don't know how much this is). I'd be willing to bet you could squeeze SMB1 on there if you coded it by hand. A machine translation might be ROM-constrained due to the 16-bit instruction word size.
qbradq wrote:
What game are you trying to port? You'll run into a lot of issues if the game uses any timed code at all. Sprite 0-based status bars may be an issue too if you are not emulating the PPU.
Also if you are not going to emulate the PPU you will likely need to rewrite fairly large chunks of the code.
Sounds like an interesting project though.
Super Mario Bros. I got a little concerned yesterday when I read that it's one of the toughest NROM games to emulate. I also remember reading about Sprite 0 stuff making it harder. Do you think this game will cause me issues with timing? Any workarounds?
Also, I'm not above simply cutting out the status bar for revision 1. I was considering using a cheaper, smaller LCD and it would help cut down the pixel count.
My end goal is to have a very cheap ($5-$10) keychain that can run off of watch batteries and play Super Mario Bros.
tepples, I didn't know about the nD but it looks very questionable.
infiniteneslives, the UZEbox does look awesome but unfortunately it's much too costly. I do like that it's only 2 chips though!
I did consider basing the project off of a hacked-down Microtouch, but I was hoping the commercial version was going to use Cortex M0's...
http://www.adafruit.com/products/330
$5-$10? You'll be out of money either with the PIC and the Keychain, or just the screen, hahahaha. Good luck! And unless you can make the screen a bitmapp [You'll need eitherm ultiple processors or a giant one] you'll have to use a computer with the ability to update scroll every scanline and pinpoint the position on the screen for the split. And that's just one part of the engine, I don't know what else is needed.
See if you can still get a Onestation (portable NES-on-a-chip based system with pirated games), and glue a keychain mount to that.
3gengames wrote:
$5-$10? You'll be out of money either with the PIC and the Keychain, or just the screen, hahahaha.
Cortex M0's can be had for around $2-3. The screen will probably be the most expensive part. Cheap Nokia knock-off's can be had for under $5, but the resolution is only 128x128...
I can't recall any existing device that has these specifications - size of a keychain, color display, enough processing power to run a platformer, low power consumption, and price of $5-10. Not even among all that chinese stuff.
Shiru wrote:
I can't recall any existing device that has these specifications - size of a keychain, color display, enough processing power to run a platformer, low power consumption, and price of $5-10. Not even among all that chinese stuff.
Part of the reason I'm doing this is to see if it can be done. The price is not the driving factor though.
Edit: So minimally, I'd need:
32 KB for program ROM
8 KB for character ROM
2 KB RAM
2 KB video RAM
256 bytes OAM
28 bytes palette RAM
Is there any way I could preload some stuff into RAM and bypass some of the requirements? I'm really interested in the concept of "flattening" the code... since the system doesn't need to be able to play different games, where can I take shortcuts?
Dwedit wrote:
This is awesome, thanks! I wish his version used an LCD, but I'm pretty sure that's what the Microtouch is for.
Anybody know of a good wholesale source of LCDs?
Okay, after digging through some old threads I figured out how to remove the Sprite 0 check (as well as disable the status bar). I now have a copy of SMB that has
1. No sound engine
2. No status bar
Can you guys think of any other code that could be removed / simplified to make porting easier?
Also, I have a bunch of NOPs scattered throughout and even more .byte $ff, [...] at the end of the code. Is there a way to automatically pad the rom to a certain size?
Any help would be awesome, thanks!
I'm thinking about changing strategies. To cut costs I would use a lower resolution screen, something closer to Gameboy Color resolution.
Is it going to be very difficult to modify SMB to run at a lower / different aspect ratio resolution? It looks like I can modify GetScreenPosition to be 160px wide rather than 256.
Change the camera logic to center on the area to the right of Mario within the first 256 pixels? That would give you limited backwards scrolling, and would still handle almost like a fully wide screen. You could just use a "second camera", run the game logic against the first camera, but run the drawing logic against the second camera.
sfchead wrote:
To cut costs I would use a lower resolution screen, something closer to Gameboy Color resolution.
Is it going to be very difficult to modify SMB to run at a lower / different aspect ratio resolution?
Super Mario Bros. Deluxe already runs on Game Boy Color. Look at whatever solution it uses.