I made an NES emulator – What I learned about the original Nintendo • Hacker News Board

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

#31

Post by throwawayspeccy » Thu, Apr 02, 2015, 9:44 PM UTC

fit2rule wrote: post #24

throwawayspeccy wrote: post #18

Earlier quoted context omitted.

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

You're right, decades of experience are also very important (though there are youngsters starting on platforms like the NES or TI graphing calculators doing cool stuff as well).

I'm not sure I agree about toolchains, though. The 6502 is not a very good target for C compilation, pretty much any assembly programmer can code circles around what cc65 produces. So, no offense to you or anyone else that writes C for 8-bit machines, but I don't think any of the new games and programs that really "push the limits" of these machines are written in C. So that leaves modern cross assemblers, which are indeed much more capable than common target/native assemblers of the olden days, but don't exactly afford a quantum leap of productivity either.

Then again, modern emulators are a godsend for debugging.

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

#32

Post by fogleman » Thu, Apr 02, 2015, 9:52 PM UTC

SyncOnGreen wrote: post #29

fogleman wrote: post #8

Earlier quoted context omitted.

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

Awesome!

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

#33

Post by curun1r » Thu, Apr 02, 2015, 11:13 PM UTC

throwawayspeccy wrote: post #28

curun1r wrote: post #25

Earlier quoted context omitted.

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

FWIW, I put cheating in quotes because it doesn't seem like cheating to me. It's only cheating the original specs of the machine. If the developers of actual cartridges were allowed to make use of that trick, why shouldn't modern day retroprogrammers have that option?

But if a retroprogrammer were to use a mapper to achieve a 1 meg ROM, modern hardware would make that a decision with very little negative consequences. A programmer at the time might have to live with a game that cost well over $100.

So cheating in quotes because people did it in their actual cartridges. Cheating without quotes would be something like breaking out of the emulator sandbox and embedding the Quake engine.

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

#34

Post by bigjoecumbo » Fri, Apr 03, 2015, 12:10 AM UTC

Check out the source code...it's surprisingly good!

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

#35

Post by yamaneko » Fri, Apr 03, 2015, 1:12 AM UTC

I would like to learn how to do that. For curiosity, why did you use Go? Is it a matter of speed or libraries? Would you get the same result if you used Python?

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

#36

Post by happycube » Fri, Apr 03, 2015, 1:37 AM UTC

Cyph0n wrote: post #22

fit2rule wrote: post #10

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…

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

I can top that :) (although it hasn't been used in a production emulator)

I wrote this a few years ago - it's ~500 lines taking advantage of the logic behind the instruction set (instead of a jump table) and it can run Apple I BASIC at least.

https://github.com/happycube/chadslab/tree/master/m6502

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

#37

Post by bitJericho » Fri, Apr 03, 2015, 3:23 AM UTC

jdalgetty wrote: post #5

coldpie wrote: 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…

MC Kids was one of your favorite games? My wife and I actually played that the other night and wondered who actually bought it when it came out? Was it something you wanted or was it a random gift of some sort?

Cinemassacre did a really good review of it here: http://cinemassacre.com/2006/09/01/mckids/

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

#38

Post by agumonkey » Fri, Apr 03, 2015, 5:43 AM UTC

brandons wrote: post #14

Scuds wrote: 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…

And in those days, any amount of additional RAM had huge impacts on games (then sales).

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

#39

Post by anewhnaccount » Fri, Apr 03, 2015, 9:22 AM UTC

happycube wrote: post #36

Cyph0n wrote: post #22

Earlier quoted context omitted.

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

I can top that :) (although it hasn't been used in a production emulator) I wrote this a few years ago - it's ~500 lines taking advantage of the logic behind the instruction set (instead of a jump table) and it can run Apple I BASIC at least. https://github.com/happycube/chadslab/tree/master/m6502

Yeah, imo trying to actually do some instruction decoding rather than just a massive switch case is a lot nicer.

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

#40

Post by fit2rule » Fri, Apr 03, 2015, 11:51 AM UTC

throwawayspeccy wrote: post #31

fit2rule wrote: post #24

Earlier quoted context omitted.

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

You're right, decades of experience are also very important (though there are youngsters starting on platforms like the NES or TI graphing calculators doing cool stuff as well). I'm not sure I agree about toolchains, though. The 6502 is not a very good target for C compilation, pretty much any assembly programmer can code circles around what cc65 produces. So, no offense to you or anyone else that writes C for 8-bit…

>>Then again, modern emulators are a godsend for debugging.

Hell yeah they are. I think thats also a key factor for why development on the old machines is experiencing a revival.