[HN Gopher] Nestur: NES Emulator in Rust ___________________________________________________________________ Nestur: NES Emulator in Rust Author : tosh Score : 46 points Date : 2020-01-06 19:57 UTC (3 hours ago) (HTM) web link (github.com) (TXT) w3m dump (github.com) | zellyn wrote: | I noticed that both this and pcwalton's CPU emulation simply | perform the operation, and increment the cycle count. | | I'm curious: are the cycle-accurate reads and writes (and false | reads and writes -- see | https://github.com/zellyn/a2audit/issues/5) not necessary for NES | emulation? | | I've never emulated a NES, only an Apple II. The cycle-accurate | reads and writes are only mostly unnecessary, but they can make a | difference, as the discussion in that linked issue shows. | binarycrusader wrote: | Sort of related, there's a great cycle-accurate (well, that's | the goal I think) emulator project for the 6502 recently | discussed here: | | https://floooh.github.io/2019/12/13/cycle-stepped-6502.html | jchw wrote: | Sometimes, especially when dealing with interactions between | chips, even sub-cycle behavior needs to be emulated for | correctness. I suspect for basic emulation though, rigorous | cycle accuracy is not really necessary for most software... | monocasa wrote: | It's equivalent to Apple II. You can get pretty far with the | naive solution of atomically completing the instruction, and | incrementing the cycle count appropriately, but there'll be | some issues until you switch to a cycle accurate state machine | with all the warts (false accesses, etc.) | | NES actually gets a bit grosser because the PPU runs (IIRC) | five cycles for every three CPU cycles or something like that, | and you need to handle that case. I've seen some emulators that | just run it off of a 15x clock, and sparsely run cycles on the | CPU and PPU (but most of the master cycles don't do any work). | nycdotnet wrote: | literally fizzbuzz | MBlume wrote: | I see an SDL dll file in the repo, and on my mac the build fails | with `library not found for -lSDL2` -- is there something special | I need to do to get this to build, or is it Windows-only? | MBlume wrote: | Ah, `brew install sdl2` fixed it | lilyball wrote: | pcwalton wrote a NES emulator in Rust 7 years ago as a | demonstration of Rust: https://github.com/pcwalton/sprocketnes | | Also, a nitpick: | | > _One line of unsafe (std::mem::transmute:: <u8>() -> i8)_ | | You don't need unsafe for this, you can do that with an `as` | cast. | [deleted] | swolchok wrote: | They seem to be equivalent: https://play.rust- | lang.org/?version=stable&mode=debug&editio... | [deleted] | SlowRobotAhead wrote: | Like the that your hobby might be opening Rust code, searching | unsafe just for the thrills :) | | Edit: Jesus kids, learn a little chill it was a joke. Someone | didn't like this so much they went through and downvoted all my | other posts they could. Wow... that's real serious. | nevi-me wrote: | It's a quote from TFA | zellyn wrote: | It was mentioned in the README, and stood out to me as | surprising (surely you don't need unsafe to cast from | unsigned to signed bytes?) | slunk wrote: | Without knowing enough about Rust to speak | authoritatively... u8 can represent larger integers than i8 | (no sign bit). Surely it's _not_ completely safe. | p4lindromica wrote: | `mem::transmute` is roughly equivalent to a | `reinterpret_cast` in C++. It treats the bits of a u8 as | an i8. | | In the Rust definition of safety (mutable xor shared, no | data races, memory safety, etc), treating the bits of a | u8 as an i8 is safe and can be done with an `as` cast. | slunk wrote: | Thanks for clarifying that for me! | zellyn wrote: | Hmmm. I was assuming this was just changing | interpretations of the same underlying 8 bits. No? | | Edit: yeah, "Casting between two integers of the same | size (e.g. i32 -> u32) is a no-op" (https://doc.rust- | lang.org/reference/expressions/operator-exp...) | slunk wrote: | Yup, fair enough. ___________________________________________________________________ (page generated 2020-01-06 23:00 UTC)