Live data from Hacker News

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

medium.com

11–20 of 42 posts

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

#13
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…

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

#14
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…

I wouldn’t call it “myopic,” if anything it was forward-thinking...the cost of memory in the early 80s was high enough that including more than the 2 KB of built-in RAM might have made the Famicom/NES way too expensive. They designed the machine with internals that could be extended with extra memory and additional chips inside the cartridges, so that over the ~15-year lifespan of the NES as technology advanced and the cost of memory dropped, the cartridges enabled ever more powerful, impressive games, but stayed about the same price ($40 iirc) the whole time.

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

#15
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

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

#16
Congratulations for this nice project. I wonder, how to write such an emulator? My initial idea would be to write an interpreter for the processor instruction set with a big array representing the RAM. Then some callback functions are registered via openGL. They are called when there are some inputs (eg. joystick). When this happens, they put something in the simulated memory (some mapped area for I/O or specific registers) and set up some interrupt flags. Does it make sense? then how to simulate accurately the processor (and coprocessors ?) frequency? any other difficulties I haven't seen?

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

#17

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?

Probably a bit of these two, and a third one:

today, we have plenty of programmers who have been at it for thirty years. They got started on these very machines, and in the meantime they have been doing other things on other computers—but which were still programming—and now, if they decide to go back to the original computers, their instincts more than compensate for the lost familiarity.

In some of my last years as a student (late nineties), I dug up my old ZX81 from my parents' basement, and the effects of all three items were visible: I had access to a cross-assembler that I ran on a SPARC workstation. Techniques that may or may not have been known in the 1980s were now published and available on the Internet for anyone curious about them. And my ability to concentrate and understand the issues I was facing was better than when I was eight.

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

#18

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?

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.

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

#19
Related to this is Lizard, a Kickstarter project that got funded last year, where one person is writing a new game for the NES. He's posted some development blogs as updates to the project, and it's fascinating reading about the design considerations he's taken:

https://www.kickstarter.com/projects/1101008925/lizard/updat...

(Of note, this is the same one who made MOON8 - a cover project for Pink Floyd's Dark Side of the Moon for the NES [0] - and more recently, getting the "2A03 Puritans" album, a NES chiptune collaboration album, onto a rom and cartridge [1].)

[0] http://rainwarrior.ca/music/moon8.html

[1] http://rainwarrior.ca/projects/nes/2a03puritans.html

---

I've personally only messed with the NES from an audio perspective, having spent a lot of time a few years back in FamiTracker [2] to write music for it. I always found it interesting that the Famicom had the ability for cartridges to include their own audio hardware in addition to the mapper, battery-RAM, etc. Like the mappers, the vast majority of these games that included expansion audio chips kept to a small-ish set of chips. Chiptune (especially Famicom chiptune, due to the time I spent tinkering with it) is a fascination of mine, so I could point out some samples for the various expansion audio chips if anyone would like.

[2] http://famitracker.com/

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

#20

Congratulations for this nice project. I wonder, how to write such an emulator? My initial idea would be to write an interpreter for the processor instruction set with a big array representing the RAM. Then some callback functions are registered via openGL. They are called when there are some inputs (eg. joystick). When this happens, they put something in the simulated memory (some mapped area for I/O or specific reg…

I believe you're thinking along the right lines. If you're really curious to learn more, check out this series which I have enjoyed reading:

http://imrannazar.com/GameBoy-Emulation-in-JavaScript

Post reply on HN