1. 3

    I’ve been fascinated with Babbage’s difference and analytical engines since I read about him in Gödel, Escher & Bach. A true genius for sure. I had a lot of fun understanding and implementing the method of finite differences in software (the one he used in the difference engine):

    https://hackerclub.io/charles-babbage-and-the-method-of-finite-differences/

    1. 4

      This is a really awesome post, but I wish this blog had an RSS feed, so I could follow it in Newsboat.

      1. 5

        Thanks, that’s quite the compliment :) I really only write very occasionally and the topics are all over the place, but I’ll try and set up a feed.

        1. 2

          Me too! An RSS or Atom feed would be awesome! I was franticly searching for one after seeing this article. :P

        1. 5

          Another “quirks” question: did you find any unexpected quirks of Go that made writing this emulator harder or easier?

          1. 5

            In this particular case, it feels like the code isn’t too far from what C code would be: here are some basic data structures and here are some functions that operate on them, mostly on the bit level. No fancy concurrency models nor exciting constructs. I think given the fact that this is an inherently low level program, most nicieties from Go weren’t immediately needed.

            I did use some inner functions/closures and hash maps, but could’ve just as well done without them. The bottom line is that the language didn’t get in the way, but I didn’t feel like it was enourmously helpful, other than making it easier to declare dependencies and handling the build process for me.

            1. 4

              Did you run into any issues with gc pauses? That’s one of the things people worry about building latency sensitive applications in go.

              1. 3

                Not the OP, but I would assume this kind of application generates very little garbage in normal operation.

                1. 2

                  The gc pauses are so miniscule now, for the latest releases of Go, that there should be no latency issues even for realtime use. And it’s always possible to allocate a blob of memory at the start of the program and just use that, to avoid gc in the first place.

                  1. 2

                    The garbage collector hasn’t been an issue either. Out of the box, I had to add artificial delays to slow things down and maintain the frame rate, so I haven’t done much performance tuning/profiling. I am interested in scenarios where this would be critical though.

                    1. 1

                      Go’s GC pauses are sub-millisecond so it’s not an issue.

                  2. 3

                    Interested in this as well. I’ve toying with the idea of writing a CHIP-8 emulator in Go and would love to hear about how is the experience of writing emulators.

                    1. 3

                      I did exactly this as a project to learn Go! I used channels in order to control the clock speed and the timer frequency and it ended up being a really nice solution. The only real hangup I had was fighting with the compiler with respect to types and casting, but having type checking overall was a good thing.

                  1. 6

                    That looks fun! Any particular unexpected NES hardware quirks you found?

                    1. 10

                      Definitely! I think it is particularly interesting to see some of the tricks used to get around with so little resources. For instance, there is only 2kB of CPU ram and 2kB of video ram, with usually ROM on the cartridges. One of the things I found specially clever is the use of “mappers” on the cartridges. Mappers allow memory banks to be switched by the program, so that different memory banks can be accessed on the same memory address by both the cpu and ppu. This allows cartridges to pack more data than would be initially addressable by the console. This is one of the reasons why the NES was able to handle more complex and pretty games. Take for instance Super Mario Bros. 1 (an older game, with a very straightforward cartridge wiring) and Super Mario Bros. 3. They feel like even different platforms, also because smb3 was able to get away with using a more complex mapper.