I made an NES emulator – What I learned about the original Nintendo
21–30 of 42 posts
Re: I made an NES emulator – What I learned about the original Nintendo
#22If you're into this kind of thing, just dig in and give it a shot! Old systems are surprisingly understandable after a few hours' research and fooling around. There's a community that looks for unused content that remains in games. The main wiki for this community is http://tcrf.net/ >, which contains a fascinating amount of material. If you don't see your favorite old game on there, why not dissect it and try to fin…
>Old systems are surprisingly understandable after a few hours' research and fooling around. This is why I say old computers never die - their owners do! Old systems have lots of technology to engage the hacker mind. By the way, my favourite emulator is Oriculator, which emulates the Oric-1/Atmos/Telestrat/Pravetz 8-bit machines that never had much of a chance in the 80's .. just look at this beautiful code, for exam…
Re: I made an NES emulator – What I learned about the original Nintendo
#23Watching the sprites in vram while the game runs is really neat, and shows a bit about how the game is put together. For instance in Kirby's Adventure, (IIRC)Kirby's walking sprites take up about half the available RAM, and they get swapped out for the flying sprites when he jumps. Compare this to some of the early non bank switched games where the all sprites fit entirely in memory, with some creative tweaks (bushes…
As for mappers, the 6502 (along with most other 8-bit CPUs from that era) has 16 address lines, imposing a hard-limit of 64 kilobytes of CPU-side address space. Without bank switching hardware somewhere, there was just no other practical way to access any more program ROM than that. Now, Nintendo could have pulled a PC-Engine/TurboGrafx-16 and embedded a bank switching unit somewhere in the console itself, but hindsight is 20/20.
Re: I made an NES emulator – What I learned about the original Nintendo
#24Earlier quoted context omitted.
I wonder why it's possible to get "better" programs for old hardware now. Is it because the field of CS has advanced further, which means that we can apply modern ideas and algorithms? Or is it because we can cheat and have a toolchain running on vastly superior hardware, which enables us to use it in ways that would have been too time-consuming to develop back in the day?
I don't think fancy algorithms and data structures are common or particularly useful in retrocomputing. I think it's primarily because programs were written back then under strict time and financial constraints, whereas now retroprograms and homebrew are written as hobbies, with the lack of deadlines and abundance of passion that entails.
It also helps that the toolchains are far superior to what we used to have .. I never would have thought, in my youth, that I'd be writing C code for the Oric-1, but indeed the OSDK has a C compiler that makes the effort of packing code into 48k a lot more fun than it used to be!
But in the end, you don't write software for these old machines unless you have a lot of passion, and that's what counts, I think. There is a lot of passion for the Oric-1 these days, that is for sure .. at least in the small scene that keeps the machines alive.
Re: I made an NES emulator – What I learned about the original Nintendo
#25Earlier quoted context omitted.
>Old systems are surprisingly understandable after a few hours' research and fooling around. This is why I say old computers never die - their owners do! Old systems have lots of technology to engage the hacker mind. By the way, my favourite emulator is Oriculator, which emulates the Oric-1/Atmos/Telestrat/Pravetz 8-bit machines that never had much of a chance in the 80's .. just look at this beautiful code, for exam…
I wonder why it's possible to get "better" programs for old hardware now. Is it because the field of CS has advanced further, which means that we can apply modern ideas and algorithms? Or is it because we can cheat and have a toolchain running on vastly superior hardware, which enables us to use it in ways that would have been too time-consuming to develop back in the day?
Re: I made an NES emulator – What I learned about the original Nintendo
#26If you're into this kind of thing, just dig in and give it a shot! Old systems are surprisingly understandable after a few hours' research and fooling around. There's a community that looks for unused content that remains in games. The main wiki for this community is http://tcrf.net/ >, which contains a fascinating amount of material. If you don't see your favorite old game on there, why not dissect it and try to fin…
Re: I made an NES emulator – What I learned about the original Nintendo
#27Great! It's an interesting experiment, eh? A couple of other students and I did this same thing, but in Python, for the final project in our Python class. The result was excruciatingly slow. It still has some bugs, and we haven't touched it in almost a year, but we all learned a lot along the way. If you're interested in taking a look, or providing some feedback, the repo is here: https://github.com/billymeter/pynes
Re: I made an NES emulator – What I learned about the original Nintendo
#28Earlier quoted context omitted.
I wonder why it's possible to get "better" programs for old hardware now. Is it because the field of CS has advanced further, which means that we can apply modern ideas and algorithms? Or is it because we can cheat and have a toolchain running on vastly superior hardware, which enables us to use it in ways that would have been too time-consuming to develop back in the day?
It sounds like there's at least some "cheating" going on. The article talks about "mappers" which were embedded into the cartridge to take advantage of extra memory included in the cartridge. Back in the 80s, that form of cheating allowed the cartridge to double the amount of memory, but on today's hardware, you could use the same technique to get considerably more memory.
Yes, theoretically you could stick an ARM processor in a cartridge and run most of the game off that, using the PPU as a glorified framebuffer. But many (most?) retroprogrammers are in it largely for the engineering/optimization challenge (or else, why wouldn't you just write a retro-styled PC game), so they draw the line for "cheating" much more strictly than even you have. e.g. some fan translators refusing to expand the ROM size of a game and butchering the translation to fit (Japanese text is much more dense than English), instead of using a larger ROM to fit a better translation. Or some NES homebrew programmers not using mappers at all and working within the constraints of NROM (32kb program rom and 8kb graphics rom). So I wouldn't accuse any of these homebrew programmers of "cheating," because if they were actually guilty of it, those in "the scene" would have called their bluffs long ago.
Re: I made an NES emulator – What I learned about the original Nintendo
#29Watching the sprites in vram while the game runs is really neat, and shows a bit about how the game is put together. For instance in Kirby's Adventure, (IIRC)Kirby's walking sprites take up about half the available RAM, and they get swapped out for the flying sprites when he jumps. Compare this to some of the early non bank switched games where the all sprites fit entirely in memory, with some creative tweaks (bushes…
That's really cool... I thought about writing a visualizer to display stuff like that but I haven't yet.
Re: I made an NES emulator – What I learned about the original Nintendo
#30If you're into this kind of thing, just dig in and give it a shot! Old systems are surprisingly understandable after a few hours' research and fooling around. There's a community that looks for unused content that remains in games. The main wiki for this community is http://tcrf.net/ >, which contains a fascinating amount of material. If you don't see your favorite old game on there, why not dissect it and try to fin…
I have always wondered how did they get all the ROMS for the games. Any insight?
To make a dumper you first need to find the ROM pinouts for the chips they used. This tells you which pins select an address, which pins output data, etc. Then, build a dumper (for example writing an Arduino program) that selects each address one by one, and outputs the response from the chip in a format your computer can read.