www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - NES emulator written in D

reply blahness <nospam example.com> writes:
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
Feb 03
next sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
Very cool!
Feb 03
prev sibling next sibling parent docandrew <x x.com> writes:
Really cool work!
Feb 03
prev sibling next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
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.
Feb 03
parent reply blahness <nospam example.com> writes:
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.
Feb 04
parent reply welkam <wwwelkam gmail.com> writes:
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
Feb 04
parent Martin Nowak <code dawg.eu> writes:
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
Feb 07
prev sibling next sibling parent welkam <wwwelkam gmail.com> writes:
Could you share your experience with us? How it compares to go 
implementation? Did D made it harder or easier to implement 
emulator?
Feb 04
prev sibling next sibling parent bauss <jj_1337 live.dk> writes:
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.
Feb 07
prev sibling next sibling parent blahness <nospam blah334.net> writes:
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.
Nov 12
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On Sat, Feb 3, 2018 at 5:55 AM blahness via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> 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
Nice work. Oh wow, this is pretty rough! ``` void createTable() { this.table = [ &this.brk, &this.ora, &this.kil, &this.slo, &this.nop, &this.ora, &this.asl, &this.slo, &this.php, &this.ora, &this.asl, &this.aac, &this.nop, &this.ora, &this.asl, &this.slo, ... ``` Here's one I prepared earlier: https://github.com/TurkeyMan/superemu (probably doesn't work with DMD from the last year or 2!) Extensible architecture, supports a bunch of systems.
Nov 12
parent reply blahness <nospam blah334.net> writes:
On Tuesday, 13 November 2018 at 05:59:52 UTC, Manu wrote:
 Nice work.

 Oh wow, this is pretty rough!
 ```
 void createTable() {
   this.table = [
     &this.brk, &this.ora, &this.kil, &this.slo, &this.nop, 
 &this.ora,
 &this.asl, &this.slo, &this.php, &this.ora, &this.asl, 
 &this.aac,
 &this.nop, &this.ora, &this.asl, &this.slo,
     ...
 ```

 Here's one I prepared earlier: 
 https://github.com/TurkeyMan/superemu (probably doesn't work 
 with DMD from the last year or 2!) Extensible architecture, 
 supports a bunch of systems.
That's an artifact from the original code which was written in Go. My main focus was adding missing instructions & fixing any timing issues. It now passes nearly every NES specific CPU instruction & timing test I can throw at it so I'm fairly happy with it. Any improvements are always welcome though.
Nov 12
parent reply Manu <turkeyman gmail.com> writes:
On Mon, Nov 12, 2018 at 10:30 PM blahness via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:
 On Tuesday, 13 November 2018 at 05:59:52 UTC, Manu wrote:
 Nice work.

 Oh wow, this is pretty rough!
 ```
 void createTable() {
   this.table = [
     &this.brk, &this.ora, &this.kil, &this.slo, &this.nop,
 &this.ora,
 &this.asl, &this.slo, &this.php, &this.ora, &this.asl,
 &this.aac,
 &this.nop, &this.ora, &this.asl, &this.slo,
     ...
 ```

 Here's one I prepared earlier:
 https://github.com/TurkeyMan/superemu (probably doesn't work
 with DMD from the last year or 2!) Extensible architecture,
 supports a bunch of systems.
That's an artifact from the original code which was written in Go. My main focus was adding missing instructions & fixing any timing issues. It now passes nearly every NES specific CPU instruction & timing test I can throw at it so I'm fairly happy with it. Any improvements are always welcome though.
A great test is to emulate an Atari2600; you'll know your 6502 is 100% perfect if you can play pitfall or some other complex 2600 games ;) I can't see how your cycle counting logic works, it looks like it's missing a lot of cycles. How do you clock your scanlines against your CPU? Can you run Battletoads or Super Mario Bros? They're pretty sensitive to proper timing.
Nov 13
parent blahness <nospam blah334.net> writes:
On Tuesday, 13 November 2018 at 08:24:05 UTC, Manu wrote:
 A great test is to emulate an Atari2600; you'll know your 6502 
 is 100%
 perfect if you can play pitfall or some other complex 2600 
 games ;)
 I can't see how your cycle counting logic works, it looks like 
 it's
 missing a lot of cycles. How do you clock your scanlines 
 against your
 CPU?
 Can you run Battletoads or Super Mario Bros? They're pretty 
 sensitive
 to proper timing.
Every cycle is accounted for via a memory read or write. Notice both memoryRead & memoryWrite call nextCycle. In nextCycle you'll notice after every CPU cycle the PPU gets 3 cycles (equivalent to 1 CPU cycle) & the APU gets 1 cycle. Super Mario Bros runs fine but Battletoads has some issues unrelated to the CPU. It is highly dependent on correct sprite 0 collision detection timing. It's a PPU timing issue. I'm relying on these CPU tests: https://wiki.nesdev.com/w/index.php/Emulator_tests. Notice one of the authors of one of the most extensive tests is kevtris who's most famous for his FPGA recreations of the NES & Super Nintendo for Analogue (https://www.analogue.co/). I'm pretty confident about the CPU being cycle accurate at least as far as the NES is concerned.
Nov 13