andreaorru

The article is missing benchmarks. Less instructions != faster execution.

Having worked in both places, yes, they still suck in comparison.

I'm definitely interested.

Apparently it was trained over GitHub repositories.

https://youtu.be/fZSFNUT6iY8

For now... :)

Hardware acceleration works just fine for me on Linux (granted, I had to flip a few values in about:config). And all the Wayland glitches have been fixed months ago.

It's significantly better (I would say on par with Chrome) if you set general.smoothScroll.msdPhysics to true in about:config. No one seems to talk about it but the difference is like night and day on my system. No clue why it's not on by default.

Also using Wayland (on Linux), gfx.webrender.all and a few other options can help quite a lot. For more details, I suggest you check out these two pages:

https://wiki.archlinux.org/index.php/Firefox https://wiki.archlinux.org/index.php/Firefox/Tweaks

I applied most of the recommended (and some of the not recommended) tweaks documented there, and I'm very happy with the results.

When I lived in New York, I was lucky enough to have the opportunity of hacking together pretty often. Seeing his intensity and dedication had a huge impact on me. Thanks Andy!

Jewish do indeed account for a disproportionate number of Nobel Prizes, among other things. At the very least, that seems to indicate that intellectual prowess is highly regarded inside the Jewish community and, as such, strongly encouraged as kids grow up. It's possible that the Jewish culture itself may provide members with a sense of structure and discipline that other cultures perhaps lack (at least on average).

I strongly disagree. Have you actually watched his lectures, read his books, and formed your own opinion?

What's wrong with Jordan Peterson? I think he's vastly misrepresented.

Are you still hiring?

Thanks. Guess my privacy settings are a bit on the paranoid side ;)

Is it just me or all the images are broken?

This is madness. Also, has anyone noticed the Brainfuck interpreter is written in assembly?!

Also I'm not the author of the HN submission... ;)

No problem, we are cool. I see your point.

I believe there is still a lot of room for improvement in terms of accuracy, clarity and code size. Note that this repository was more than 3 years old. Maybe this will motivate me to improve it even further.

Sorry, but that's really not fair. You are running that on all the folders inside the src/ directory (and the README?), including blargg's libraries that I'm using. I'm not counting that. Go ahead and include those if you want. It's code I didn't write, and bigger than the rest of the emulator! I don't think that's representative.

CPU and PPU implementations tend to be in the order of the thousands of lines -- they are around 200 and 300 lines respectively in LaiNES. In fact, most of the code is in the GUI that I could easily strip away if this was a competition. And this wasn't written to be small - it was written to be simple. It also came out small, but that's incidental.

Here's how I counted the lines and how I decided on the description for the repository, which by the way has been catapulted from totally unknown to worldwide attention overnight, and it's now object of unexpected, ruthless scrutiny that I couldn't foresee.

  [andrea@manhattan src]$ rm -rf boost nes_apu Sound_Queue.*
  [andrea@manhattan src]$ cloc .
        24 text files.
        24 unique files.                              
         1 file ignored.

  github.com/AlDanial/cloc v 1.70  T=0.03 s (780.3 files/s, 63170.2 lines/s)
  -------------------------------------------------------------------------------
  Language                     files          blank        comment           code
  -------------------------------------------------------------------------------
  C++                             11            210            110           1163
  C/C++ Header                    12             87              7            285
  -------------------------------------------------------------------------------
  SUM:                            23            297            117           1448
  -------------------------------------------------------------------------------

I'm the author.

I disagree with this statement. It takes a considerable amount of effort and research to reach cycle-accuracy, especially on the PPU side. Understanding how the PPU pipeline works will take you more time than everything else.

If you settle for frame-based emulation you can write the functions to emulate the opcodes without worrying about the order and duration of the internal operations. Once the opcode is emulated, you just add cycles to a global counter based on a table that contains the number of cycles per instruction.

After 29781 cycles (you may end up being a little off each time, if you are not cycle-accurate), you call a function to update the state of the PPU. There you can use familiar iterative constructs to perform the rendering.

Compare this with the state machine approach in my code (ppu.cpp) and how much more careful I have to be composing microinstructions to form opcodes (cpu.cpp). I came up with a (I think) clean design but it wasn't trivial.

I'm the author.

Everything you need is on the NESdev wiki or it's linked there. A couple of particularly helpful resources are linked in my README. The PPU diagram and the 6502 reference were especially useful.

I definitely encourage you to do it, it's a great learning experience and very rewarding. When games start running is pure programming ecstasy :)

I'm the author.

The reason for the single letters is that those are the actual names of the 6502 registers.

Glad you like it overall. :)

Hi Darius (it's a small world).

That looks really good, I'll have a look at it!

That's very cool. Are you aware of similar tools written in languages other than JavaScript?

To be fair I don't implement all the mappers, but I'm pretty confident the core parts of the emulator (CPU and PPU) are as small as it gets.

Thanks (for calling me the right person). There is a price to pay for power in C++ though. Keeping the code beautiful and readable is often a challenge, as the syntax gets convoluted very quickly. I'm not the biggest fan of the Standard Template Library either.

Lately I've been experimenting with D (https://dlang.org), created by Walter Bright and Andrei Alexandrescu, both well known expert C++ programmers. D feels a lot like C++ should have been had it dropped some C compatibility in exchange for clarity. Its meta-programming capabilities are also far more powerful. I can think of features (like template mixins) that would make this project even more compact.

It's not atomical. Note that the PPU is constantly updated in the middle of the CPU instructions in a way that respects the timing of the original hardware. The relative order of operations between CPU and PPU is respected.