Live data from Hacker News

I made an NES emulator – What I learned about the original Nintendo

medium.com

21–30 of 42 posts

Re: I made an NES emulator – What I learned about the original Nintendo

#22
post #2

If 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…

A 6502 in ~2500 lines of C? Really? Bookmarked :)

Re: I made an NES emulator – What I learned about the original Nintendo

#23
post #6

Watching 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…

In Battletoads, Rare went a step further and kept only a single frame for each player loaded in CHR RAM, copying over it for each frame of animation.

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

#24

Earlier 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.

I don't know about that - I've been following the Oric scene for a while and my perception is that there are indeed old programmers returning to the systems of their youth with renewed vigour, but also a better understanding for how to organize their project - and sources - in a way that makes more sense. 30 years of optimizing code does tend to turn you into a better developer, and when you return - for no reason other than the pure joy of it - to these old systems, often things are done in unique ways. Twilighte found a new video mode for the Oric-1 which inspired him to write games that were a bit more modern in their sense of quality and playability - I think the machines that came after the Oric inspired him quite a bit.

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

#25

Earlier 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?

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.

Re: I made an NES emulator – What I learned about the original Nintendo

#26
post #2

If 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?

Re: I made an NES emulator – What I learned about the original Nintendo

#27

Great! 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

wow ! this one is cool ! From looking at the Repo - I see that you have used pygame in your project. So , how did it help in implementing the Emulator ?

Re: I made an NES emulator – What I learned about the original Nintendo

#28
post #25

Earlier 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.

Official NES mappers allowed up to 1 megabyte of ROM (512kb program ROM, 512kb graphics ROM). I can't really imagine needing more than that for an NES game.

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

#29
post #8
post #6

Watching 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.

I've coded a NES emulator for my C++ programming course (https://github.com/JaCzekanski/AnotherNES) and one of the features is live view of RAM and PPU registers (check out Screenshots at bottom of Readme). As for now only RAM can be changed during game play but I plan to carry on with development and create emulator with ability to change every register of console in realtime (like ICU64 here: https://www.youtube.com/watch?v=tjcvR5McmSg)

Re: I made an NES emulator – What I learned about the original Nintendo

#30
post #26
post #2

If 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?

Use a ROM dumper! You need access to the original hardware, then the dumper reads out the chip.

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.

Post reply on HN