Hi everyone,

Not sure how interested people here will be with this but I've ported https://github.com/fogleman/nes from Go to D [1]. I should point out that I'm not the author of the original Go version.

The emulator code itself is 100% D with no dependencies. I've also created a little app using SDL to show how you'd put this library to use [2].

Its PPU & APU timing isn't 100% accurate (same as the Go version) so not all games will work correctly but this should be pretty easy to fix.

Links
--------------
[1] https://github.com/blahness/nes
[2] https://github.com/blahness/nes_test

Very cool!

Really cool work!

On Saturday, 3 February 2018 at 13:52:17 UTC, blahness wrote:
> Hi everyone,
>
> Not sure how interested people here will be with this but I've ported https://github.com/fogleman/nes from Go to D [1]. I should point out that I'm not the author of the original Go version.
>
> The emulator code itself is 100% D with no dependencies. I've also created a little app using SDL to show how you'd put this library to use [2].
>
> Its PPU & APU timing isn't 100% accurate (same as the Go version) so not all games will work correctly but this should be pretty easy to fix.
>
> Links
> --------------
> [1] https://github.com/blahness/nes
> [2] https://github.com/blahness/nes_test

How did it compare to the Go version?

I started implementing one myself as a learning experience and recall I looked at the Go version a few times (https://github.com/marler8997/hacknes).  Mine was in C++ though since I was also trying to re-familiarize myself with C++. Definitely curious on your thoughts on how the GO version compared to your D version.

Could you share your experience with us? How it compares to go implementation? Did D made it harder or easier to implement emulator?

On Sunday, 4 February 2018 at 04:51:00 UTC, Jonathan Marler wrote:
>
> How did it compare to the Go version?
>
> I started implementing one myself as a learning experience and recall I looked at the Go version a few times (https://github.com/marler8997/hacknes).  Mine was in C++ though since I was also trying to re-familiarize myself with C++. Definitely curious on your thoughts on how the GO version compared to your D version.

Quickly,

The code itself is pretty much a 1:1 copy. The style Go forces on you is easy to replicate in D.

A few things I learned that stood out:
1. It was incredibly easy to move the code from Go to D. Most of the work only took maybe 4 days. D is very flexible & made it easy.

2. DMD just doesn't produce fast code compared to other modern compilers. It's a shame LDC or GDC isn't the default D compiler.

* Gotchas
Go doesn't use the same operator precedence rules as C & D. Not sure why this surprised me but it lead to some initially confusing bugs.

* Code differences
The only major difference relates to state file serialization.

Go has a binary serialization/encoding library (encoding/gob) in its standard library which the Go author used to save/load the machine state.
Each component (CPU, APU, PPU, etc) is passed the binary stream & adds what it needs saved.

In the D version I use D's built-in associative arrays (equivalent to Go's map).
D makes it easy to convert to/from a string representation of most types so I just convert the AA to a string, compress it & save it to disk.

* Garbage collector
In the D version this doesn't even come into play because nothing is allocated during "step" execution. The only allocations are during console initialization or during things you won't be doing often like setting the APU sample rate.

On Sunday, 4 February 2018 at 20:56:32 UTC, blahness wrote:
> 2. DMD just doesn't produce fast code compared to other modern compilers. It's a shame LDC or GDC isn't the default D compiler.

For the core team improving DMD codegen is not a priority

On Monday, 5 February 2018 at 04:07:56 UTC, welkam wrote:
>> 2. DMD just doesn't produce fast code compared to other modern compilers. It's a shame LDC or GDC isn't the default D compiler.
>
> For the core team improving DMD codegen is not a priority

Indeed it's not, it's understood that it's too much effort, though we sometimes pick low-hanging fruits. Mostly dmd's backend is kept because it's still ~1.5-2x faster to produce debug binaries.
In case you're not on Windows, the install.sh script is a fairly easy way to switch compilers.

  curl -fsS https://dlang.org/install.sh | bash -s dmd
  curl -fsS https://dlang.org/install.sh | bash -s ldc
  curl -fsS https://dlang.org/install.sh | bash -s gdc

On Saturday, 3 February 2018 at 13:52:17 UTC, blahness wrote:
> Hi everyone,
>
> Not sure how interested people here will be with this but I've ported https://github.com/fogleman/nes from Go to D [1]. I should point out that I'm not the author of the original Go version.
>
> The emulator code itself is 100% D with no dependencies. I've also created a little app using SDL to show how you'd put this library to use [2].
>
> Its PPU & APU timing isn't 100% accurate (same as the Go version) so not all games will work correctly but this should be pretty easy to fix.
>
> Links
> --------------
> [1] https://github.com/blahness/nes
> [2] https://github.com/blahness/nes_test

This is really cool and has definitely got my interest.

I forked your project and will look through it!

Thanks for the work.

On Saturday, 3 February 2018 at 13:52:17 UTC, blahness wrote:
> Hi everyone,
>
> Not sure how interested people here will be with this but I've ported https://github.com/fogleman/nes from Go to D [1]. I should point out that I'm not the author of the original Go version.
>
> The emulator code itself is 100% D with no dependencies. I've also created a little app using SDL to show how you'd put this library to use [2].
>
> Its PPU & APU timing isn't 100% accurate (same as the Go version) so not all games will work correctly but this should be pretty easy to fix.
>
> Links
> --------------
> [1] https://github.com/blahness/nes
> [2] https://github.com/blahness/nes_test

Just to let anyone interested in this know it's been updated. The APU (sound) is much improved as is the overall cycle accuracy. It now passes several hundred accuracy tests (about halfway there). Most of the work left to do involves
improving the PPU (video) which really hasn't been touched much since the original port.

If you want to see it in action the best thing to do is grab & build nes_test or if you're using Windows you can download
the newest binary release from https://github.com/blahness/nes_test/releases.

The first version was a straight port but it's diverged a good amount by this point.