• he/him

Chronicling writing a simple NES emulator to learn Swift, macOS APIs, and retro architecture.


I've been spending the last week trying to read up on Swift. On the surface, it seems quite nice. Familiar syntax, very good type safety, mandatory optionals (heh!), enumerations with associated data (à la tagged unions or variants), automatic memory management, and a value types first approach. Some of the vagaries of classes and closures look like they will take quite some time and use to understand, and I haven't even looked at the asynchronous and concurrency support. The language reference is quite easy to work with and reasonably easy to understand.

Tougher is the APIs and libraries, as they don't seem to resemble ones I am familiar with, and Apple's API documentation, at first glance, seems quite inscrutable. For example, I might like to read a memory image from a file in as a blob of bytes, and I can't even find the simple equivalent of open(path).readAll(). The Swift Standard Library doesn't even seem to have a file object.1

I do think I understand the core language enough to be able to start modelling the 6502 CPU used in the NES though, as that is almost all pure computation and not reliant on much beyond the core language syntax and some basic collection and enumeration APIs.


  1. It looks like my fundamental misunderstanding is expecting the standard library to provide core filesystem features, but at least in Apple Land, these appear to be part of the totally separate Foundation Library.


You must log in to comment.

in reply to @swift-nes's post:

The way you’d typically read in a binary blob like an image is to use Foundation’s Data type, and specifically its init(contentsOf:options:) initializer. Foundation has file handles if you need them, but the thought is that it’s usually better to let the framework decide if it wants to, say, mmap the data instead of reading it in through a stream.