Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Implementing a NES Emulator in Rust

michaelburge.us

Post reply on HN
Print view View original

21–30 of 93 posts

Re: Implementing a NES Emulator in Rust

#21

Post by codetrotter »

maeln wrote: post #15

If you like the subject of emulator and Rust, I suggest you take a look at Ferris youtube : https://www.youtube.com/channel/UC4mpLlHn0FOekNg05yCnkzQ/vid... He stream is development of a Nintendo 64 and Virtual Boy emulator in Rust.

And here is a video [1] and free to read online book [2] that someone else made about implementing a Game Boy emulator in Rust.

[1]: RustFest Rome 2018 - Ryan Levick: Oh Boy! Creating a Game Boy Emulator in Rust - https://youtu.be/B7seNuQncvU

[2]: DMG-01: How to Emulate a Game Boy - http://blog.ryanlevick.com/DMG-01/

Re: Implementing a NES Emulator in Rust

#23

Post by wiremine »

MichaelBurge wrote: post #19
Bulbasaur2015 wrote: post #16

What was the most challenging part for you in building this emulator?

It took 14 days to get it functionally-complete, where I could beat Mario using savestates. The PPU took 7 days, the CPU took 5 days, the APU took 1 day, and there's a spare day for everything else. The CPU was easy to make: Its natural unit of output is a single CPU instruction. Even if there are many details, it's a straightforward process to compare an instruction-by-instruction log with a reference log until ther…

That's impressive. A few follow up questions:

1. Was this your first NES emulator?

2. Your first project in Rust?

Re: Implementing a NES Emulator in Rust

#24

Post by tyingq »

You mentioned fighting the borrow checker a bit around the emulated CPU address space. Did this come up anywhere else, like frame buffers?

Edit: Ugh. Never mind...not being familiar with NES I didn't recognize what a PPU was :)

Re: Implementing a NES Emulator in Rust

#25

Post by hopler »

bionicbits wrote: post #11
FartyMcFarter wrote: post #5

Earlier quoted context omitted.

It seems that unsafe references were used, so the advantages of Rust appear to have been somewhat relinquished in this case.

I am not sure you can not use `unsafe` in an embedded type of project. `unsafe` isn't necessarily bad, but when used at least makes it very clear where extra attention should be paid.

Emulating a system of a few 2Mhz with a 4x3Ghz chipset ought to be doable using managed memory.

Re: Implementing a NES Emulator in Rust

#26

Post by MichaelBurge »

wiremine wrote: post #23
MichaelBurge wrote: post #19

Earlier quoted context omitted.

It took 14 days to get it functionally-complete, where I could beat Mario using savestates. The PPU took 7 days, the CPU took 5 days, the APU took 1 day, and there's a spare day for everything else. The CPU was easy to make: Its natural unit of output is a single CPU instruction. Even if there are many details, it's a straightforward process to compare an instruction-by-instruction log with a reference log until ther…

That's impressive. A few follow up questions: 1. Was this your first NES emulator? 2. Your first project in Rust?

Yes to both of these. I usually use C for projects like these, and wanted to see how Rust compared.

Re: Implementing a NES Emulator in Rust

#27

Post by codetrotter »

MichaelBurge wrote: post #26
wiremine wrote: post #23

Earlier quoted context omitted.

That's impressive. A few follow up questions: 1. Was this your first NES emulator? 2. Your first project in Rust?

Yes to both of these. I usually use C for projects like these, and wanted to see how Rust compared.

Follow up to that: Did you write any other emulators in the past?

Re: Implementing a NES Emulator in Rust

#29

Post by MichaelBurge »

tyingq wrote: post #24

You mentioned fighting the borrow checker a bit around the emulated CPU address space. Did this come up anywhere else, like frame buffers? Edit: Ugh. Never mind...not being familiar with NES I didn't recognize what a PPU was :)

The borrow checker is mainly a problem when the same data needs to be modified in two different places. Only the PPU writes to a frame buffer(that it owns), so it wasn't a problem there.

The game controllers were another case: They are mapped in CPU address space, so the CPU needs a permanent mutable reference to them. But the top-level also needs to update them with inputs read from my Xbox 360 controller.

Post reply on HN