Cool to see F# here! Emulators are a great way to learn a language. On first sight you chose well between more or less idiomatic F# for each job.
Some low hanging fruit to reduce allocations: the discriminated unions in Instructions.fs could be [<Struct>], reusing field names to reuse internal fields.
Also, minor nitpick but I'm confused about some of the registers. They are already of type byte, the setters with `a &&& 0xFFuy` don't add anything over `member val A = 0uy with get, set`. I'm guessing this changed over time.
// Registers can't be a record type because the values need to be truncated to 8 bits when writing, so setters are needed
// This is for the web renderer as Fable transpiles uint8 to Number (more than 8 bits) in JS and doesn't apply any truncation
// Known non-standard behaviour in Fable (https://fable.io/docs/javascript/compatibility.html#numeric-types)
So, I think, it's just conservatively cleaning the data due to Fable's widening via js Number on the web target.
I haven't used Fable much, but apparently it maps .NET arrays to js TypedArray. Presumably you could keep the registers in 8-element array and fable will properly produce a Uint8Array. I'd like to benchmark that.
Even if you use AI, there's a certain point where it's not clear that an AI would make you faster. F# is my favorite language, and I've been programming in it so long (since 2012) that I feel like I think in F#. Asking an AI for something can be faster if I can state my requirements informally; but if I need to specify many things precisely to an AI... why not just write the code in F#? Part of the beauty of good functional designs is that they are declarative, not imperative, so in some sense you're really just stating what you want, at finer and finer granularities, until what you want is trivial.
Even when I want code written in a different language (e.g., C/C++), I often still start by making a prototype in F#. This helps me nail down the logic without having to worry about things like allocation or layouts. Perhaps I could ask an AI to do this second step for me, and then use the F# implementation as an oracle. Anyway.
> I probably spent over 20 hours debugging, scanning the emu-dev Discord, creating tests, and even throwing the issue at earlier AI models. Nothing worked. But then after a few weeks away from the emulator I tried Claude Opus, and it found the issue in just a few minutes.
Even if you want to write all the code yourself (which is a fine decision), the only reason in 2026 to bang your head against a problem like this for 20 hours is if you really enjoy doing so.
(I'm surprised that "earlier AI models" didn't work for the author. For me, free-tier Gemini gets stuff like this correct all the time.)
> Asking an AI for something can be faster if I can state my requirements informally; but if I need to specify many things precisely to an AI... why not just write the code in F#?
One reason I realized recently - when you work it through with an LLM you get full process history linearly serialized, the back and forth, thinking traces, web lookups.
When I need to get back into the task it's much easier to get back in to "the flow".
I think it'll be common practice to start commiting agent logs with the code pretty soon.
I'm of the mindset that you can use AI however you want to get the speed improvements you're looking for. Personally, I use Agile methods to incrementally implement manually testable features, refine and debug, then commit. Then I use another chat/agent to keep tabs of the overall progress (giving it a summary from the agent that did the work), and then move to the next task by asking the coordinator to draft a prompt for the next bit of work I describe.
I feel like trad coding would be more along the lines of 'I work 10 hours a day coding for minimum wage because that's a worker's place in life, and I love it!'
As a longtime F# developer and longtime recipient of STEM academic bullying[1] I refuse to use LLMs in large part because ChatGPT-3.5 was so ridiculously bad and obvious about copy-pasting from F# GitHub repos. I never felt the AGI, I just saw a plagiarism machine whose decorations had fallen off.
Eventually I am sure someone at Microsoft noticed and rang the RLHF alarm, so GPT improved substantially. It seems pretty usable for F#. I am sure some unprincipled F#er is crushing it with agents these days. But I didn't think "oh boy they solved the plagiarism problem, let's go generate some slop!" I thought "oh great, now it's no longer going to be blatantly obvious when ChatGPT plagiarizes." I really don't want to roll a d100, or even a d1000, to completely compromise a core value of mine in in exchange for a productivity benefit. I'll just be slow and jobless, thanks. This is serious: I am getting into solar installations and junk hauling.
[1] The "students don't want to think" problem is much older than LLMs. In 2007 I took a senior-level PDEs class, and almost everyone copied my homework because I was actually motivated to study PDEs, and too psychologically weak to resist those mean lazy math majors. Then it happened again in math grad school! Actually unbelievable. Why are you even in the program?
Ah F#, my greatest love. How I wish the C# guys and girls would see this instead of further bastardizing (don't hate me) C# into being everything but poorly.
Don't you see that if you would use F# instead, creating projects with C# and F#, that you would get what is being added to C# but actually working and ergonomically? Interop is great!
It's a shame though that if you come from the world of OCaml, F# feels like its stuck in C#'s shadow a bit. You can get pretty far with F# by using it as a functional language, but eventually you'll want to interop with the rest of the .NET ecosystem and suddenly you're writing in a weird OOP/Functional hybrid style.
F# is a good language, but I feel like it's forever stuck in C#'s shadow. A lot of the library code is C# and .NET handmedowns. Not interfaces or libraries crafted with F# in mind, often having no explicit documentation for use with F# either.
Yeah there is some degree of awkwardness created by the interaction, but I think it’s less about needing specific libraries to map well and more about getting a good understanding of what the interop rules are, and what the shape of the underlying generated output actually looks like.
C# interoperability loosens guarantees (particularly immutability) that F# code normally relies on. There are surprising limits that come up in generics because of how they map to C#.
That's so cool! I love F#, but I wrote a little Smalltalk interpreter in it and I can confirm it isn't exactly a speed demon for that kind of thing if you use it as intended lol
I've found that with F#, I get better performance if I do dumb imperative stuff, but keep the side effects within a function. At that point, the functions can basically be "pure" but you can get decent speed.
For example, I usually like using the `Map` data structure, and that's a pretty neat immutable structure and is usually fine for most stuff, but when performance becomes critical, it's easy enough to break into a boring imperative loop with a regular hash map. If I keep everything contained into one function, I usually can avoid feeling super dirty about it.
Yes! That's exactly how you should do it while working with a language that doesn't have a compiler that will aggressively analyze, and rewrite and optimize your code for you. (So, most languages with "heavy runtimes" that support a bunch of dynamic stuff and JITs)
There are basically two points to programming with immutable-first data. One, eliminate certain classes of data race concurrency bugs. Two, less mutable state in a given context makes it easier to reason about.
So, if you're inside a function scope and you aren't launching any concurrent operations from inside that function, you don't have to worry about benefit #1. If you're inside a function (and you're not reaching out for global mutable state), then the context you need to keep in your working memory is likely fairly small, so a few local mutable variables doesn't significantly harm "understandability" of the implementation (in most cases). So, you really don't have to worry about #2, either. Make your functions black boxes with solid "APIs" (type signatures), and let the inside do whatever it needs to make it work the best.
Just because premature optimization is the root of all evil, it doesn't mean we need to jump right to premature pessimization...
Yeah, and even if you need concurrency/parallelism within the function, it can be forgivable to use ConcurrentDictionary or ConcurrentBag or one of the many, many other thread safe mutable data structures built directly into .NET.
I will personally almost always prefer the pretty functional versions of things, and that's almost always what I start with. I like immutable data structures, and they are usually more than fast enough. Occasionally, though, you hit a bottleneck of some kind (usually in some form of loop), and you have to avoid all the beautiful functional stuff and go back to sad imperative stuff. When I do that, I usually try and keep it scoped to one function. Even within one function, I do find the persistent structures easier to reason about, but as you stated it's a small enough surface area to not be too irritating.
There are exceptions to this, of course. Sometimes for caching/memoizing I will make a global ConcurrentDictionary, and I'll use the interlocked thing to do global counters sometimes.
I find algo performance is a consideration, but so is overall system performance especially in the face of concurrency, staleness, update rate, data processing size, consistency of data, etc. I think persistent collections are just another tool which is sometimes appropriate; and it has saved me over the standard Concurrent collections in some interesting cases. There are significantly faster immutable collection libraries than the standard F# Map class though online you can use if I recall from awhile back - still not quite mutable perf though. It tends to be appropriate to use for almost the opposite case than a single thread in a tight loop which is the usual benchmark I guess. As usual YMMV/depends on problem at hand.
Out of curiosity when did you write that interpreter? The entire dotnet ecosystem has seen massive speed improvements over the years, particularly for anyone who last tried them during the Framework era. Hell they even put work in to improving tail calls which the c# compiler doesn't even take advantage of (also either in the dotnet 9 or 10 timeframe f# added an attribute to make it so a recursive call that isn't a tail call throws a compiler error so you can't accidentally screw that up).
It's .NET 10 lol. It's not so slow you can't write stuff for it, I have implementations of Conway's game of life, Huffman compression, and a minimal TUI. The main problem is doing almost anything in it involves a method lookup. And there are almost certainly places I could have done things more smartly.
One thing I do want to try out is publishing it with native AOT. I had a lot of luck with that on one of my other F# projects, I got like a 75% speedup out of it. I understand the JIT is supposed to outperform native AOT in the long term but I haven't seen it reach that speed.
Author here! I actually tried using AOT and it actually decreased the performance by about 35%. I think it's because Game Boy games tend use a small number of instructions a lot more than the others, so the JIT can optimize for them, while AOT has to be more conservative.
With some care about what features to use and when, F# can be very fast. Which is nice, use functional paradigm when you want, or low level imperative code in hot loops if you need. But yeah if you use linked lists and sequences and immutable data types everywhere it sure isn't Rust.
I always find emulators written in functional languages impressive. It tends to be much easier to map hardware to an imperative language. I enjoy seeing the functional abstractions people come up with.
Yeah I did see that part. Although he mentioned his Chip8 emulator which was fully immutable. Still interesting so see when people use the mutability escape hatches.
Interesting, enjoyable post. Like the bit about data modeling. I've been dabbling in some OCaml and that kind of modeling is the best part. Also interesting to learn of CAMLBOY. Feedback to the author: Skip the AI edit step. I'd have preferred grammar errors or inelegance to what we have here, which is a bit stale.
Insanely cool. I've had it in the back of my mind to write a Rust compiler for the game boy for a long time and everytime I see something like this I think about brushing off that project.
mildy related but wasn't there an emulator (maybe not GB but NES or SNES?) which had a visual panel showing each CPU cycle step by step? afaik it was very slow but the 1000% accuracy was the goal not playability.
See also Higan, formerly BSNES, which among other things is a cycle-accurate emulation of the SNES hardware and its enhancement chips (like the SuperFX used in StarFox/StarWing):
Sorry for the tangent - does anyone have some really zoomed in views of GB, GBColor, GBA screens in operation? I'd love for retro shaders to be able to more faithfully reproduce.
I mean, ideally, we'd run different color test patterns through, in different lighting conditions, to build a really detailed model, right?
Building emulators is cool but everyone does it, and the end result is more or less the same. Is there some things that could be done during the process to perhaps make an emulator a little more unique instead of a perfect replica?
I'm actually starting a new project to create a gba emulator in zig, and also starting with chip8. I'm going to skip nand to tetris because I played Turing complete. Cool to see I'm on the right track!
Yes, CHIP-8 is kind of the standard "I want to get into emulators" first project. In my latest book Computer Science from Scratch we go CHIP-8 -> NES in chapters 5 to 6. GBA is quite a step up from CHIP-8. I would suggest doing NES or GameBoy next, but of course with today's LLM help GBA is very reasonable if you are going that route.
Cool to see F# here! Emulators are a great way to learn a language. On first sight you chose well between more or less idiomatic F# for each job.
Some low hanging fruit to reduce allocations: the discriminated unions in Instructions.fs could be [<Struct>], reusing field names to reuse internal fields.
Also, minor nitpick but I'm confused about some of the registers. They are already of type byte, the setters with `a &&& 0xFFuy` don't add anything over `member val A = 0uy with get, set`. I'm guessing this changed over time.
The Register source has this comment:
So, I think, it's just conservatively cleaning the data due to Fable's widening via js Number on the web target.Oof, thanks for pointing that out, I hadn't noticed and I've only ever used F# on .NET.
That's terrible on Fable's part, the least they could do is truncate. I wasn't aware Fable's translation is so naive.
Fable is great but it has a surprising number of these hidden behaviour changes that are really hard to detect when writing code against it.
It’s really hard to please everyone all of the time on this front.
This kind of thing is why Roc compiles to WASM but not JS.
I haven't used Fable much, but apparently it maps .NET arrays to js TypedArray. Presumably you could keep the registers in 8-element array and fable will properly produce a Uint8Array. I'd like to benchmark that.
It's actually discussed in the article in the part where he ports it to fable (he also tried blazor)
I admit I skimmed from there on because I don't find web dev exciting, but you're right, it is. That's a terribly naive translation on Fable's part.
Finally someone putting in actual human effort to learn something, and not a LLM helped me build X in Y minutes.
There is some hope for humanity after all I suppose.
It's always going to exist. People still build things with hand tools in the year 2026. Let's call it Artisanal Coding.
Even if you use AI, there's a certain point where it's not clear that an AI would make you faster. F# is my favorite language, and I've been programming in it so long (since 2012) that I feel like I think in F#. Asking an AI for something can be faster if I can state my requirements informally; but if I need to specify many things precisely to an AI... why not just write the code in F#? Part of the beauty of good functional designs is that they are declarative, not imperative, so in some sense you're really just stating what you want, at finer and finer granularities, until what you want is trivial.
Even when I want code written in a different language (e.g., C/C++), I often still start by making a prototype in F#. This helps me nail down the logic without having to worry about things like allocation or layouts. Perhaps I could ask an AI to do this second step for me, and then use the F# implementation as an oracle. Anyway.
> I probably spent over 20 hours debugging, scanning the emu-dev Discord, creating tests, and even throwing the issue at earlier AI models. Nothing worked. But then after a few weeks away from the emulator I tried Claude Opus, and it found the issue in just a few minutes.
Even if you want to write all the code yourself (which is a fine decision), the only reason in 2026 to bang your head against a problem like this for 20 hours is if you really enjoy doing so.
(I'm surprised that "earlier AI models" didn't work for the author. For me, free-tier Gemini gets stuff like this correct all the time.)
> Asking an AI for something can be faster if I can state my requirements informally; but if I need to specify many things precisely to an AI... why not just write the code in F#?
One reason I realized recently - when you work it through with an LLM you get full process history linearly serialized, the back and forth, thinking traces, web lookups.
When I need to get back into the task it's much easier to get back in to "the flow".
I think it'll be common practice to start commiting agent logs with the code pretty soon.
I'm of the mindset that you can use AI however you want to get the speed improvements you're looking for. Personally, I use Agile methods to incrementally implement manually testable features, refine and debug, then commit. Then I use another chat/agent to keep tabs of the overall progress (giving it a summary from the agent that did the work), and then move to the next task by asking the coordinator to draft a prompt for the next bit of work I describe.
But it already has a name; this noble art is called "programming", or better yet: "hacking".
Languages evolve
trad coding
I feel like trad coding would be more along the lines of 'I work 10 hours a day coding for minimum wage because that's a worker's place in life, and I love it!'
... while live streaming actually earns the money :-P
Eh you should have give up hope in humanity sometime around when the soviet union fell
Emulators are cool as hell though, and GBA ones are a nice one to tackle yourself
As a longtime F# developer and longtime recipient of STEM academic bullying[1] I refuse to use LLMs in large part because ChatGPT-3.5 was so ridiculously bad and obvious about copy-pasting from F# GitHub repos. I never felt the AGI, I just saw a plagiarism machine whose decorations had fallen off.
Eventually I am sure someone at Microsoft noticed and rang the RLHF alarm, so GPT improved substantially. It seems pretty usable for F#. I am sure some unprincipled F#er is crushing it with agents these days. But I didn't think "oh boy they solved the plagiarism problem, let's go generate some slop!" I thought "oh great, now it's no longer going to be blatantly obvious when ChatGPT plagiarizes." I really don't want to roll a d100, or even a d1000, to completely compromise a core value of mine in in exchange for a productivity benefit. I'll just be slow and jobless, thanks. This is serious: I am getting into solar installations and junk hauling.
[1] The "students don't want to think" problem is much older than LLMs. In 2007 I took a senior-level PDEs class, and almost everyone copied my homework because I was actually motivated to study PDEs, and too psychologically weak to resist those mean lazy math majors. Then it happened again in math grad school! Actually unbelievable. Why are you even in the program?
Ah F#, my greatest love. How I wish the C# guys and girls would see this instead of further bastardizing (don't hate me) C# into being everything but poorly.
Don't you see that if you would use F# instead, creating projects with C# and F#, that you would get what is being added to C# but actually working and ergonomically? Interop is great!
It's a shame though that if you come from the world of OCaml, F# feels like its stuck in C#'s shadow a bit. You can get pretty far with F# by using it as a functional language, but eventually you'll want to interop with the rest of the .NET ecosystem and suddenly you're writing in a weird OOP/Functional hybrid style.
F# is a good language, but I feel like it's forever stuck in C#'s shadow. A lot of the library code is C# and .NET handmedowns. Not interfaces or libraries crafted with F# in mind, often having no explicit documentation for use with F# either.
Yeah there is some degree of awkwardness created by the interaction, but I think it’s less about needing specific libraries to map well and more about getting a good understanding of what the interop rules are, and what the shape of the underlying generated output actually looks like.
C# interoperability loosens guarantees (particularly immutability) that F# code normally relies on. There are surprising limits that come up in generics because of how they map to C#.
Translating library usage from C# to F# is pretty mechanical so not sure if specific docs are needed.
The larger issue is the C# community loves OOP so you often have to wrap these libraries into something more “FP” if that’s how you want to work.
Overall it’s far better than having nothing (looking at Haskell, OCaml as much as I enjoy them!)
That's so cool! I love F#, but I wrote a little Smalltalk interpreter in it and I can confirm it isn't exactly a speed demon for that kind of thing if you use it as intended lol
I've found that with F#, I get better performance if I do dumb imperative stuff, but keep the side effects within a function. At that point, the functions can basically be "pure" but you can get decent speed.
For example, I usually like using the `Map` data structure, and that's a pretty neat immutable structure and is usually fine for most stuff, but when performance becomes critical, it's easy enough to break into a boring imperative loop with a regular hash map. If I keep everything contained into one function, I usually can avoid feeling super dirty about it.
Yes! That's exactly how you should do it while working with a language that doesn't have a compiler that will aggressively analyze, and rewrite and optimize your code for you. (So, most languages with "heavy runtimes" that support a bunch of dynamic stuff and JITs)
There are basically two points to programming with immutable-first data. One, eliminate certain classes of data race concurrency bugs. Two, less mutable state in a given context makes it easier to reason about.
So, if you're inside a function scope and you aren't launching any concurrent operations from inside that function, you don't have to worry about benefit #1. If you're inside a function (and you're not reaching out for global mutable state), then the context you need to keep in your working memory is likely fairly small, so a few local mutable variables doesn't significantly harm "understandability" of the implementation (in most cases). So, you really don't have to worry about #2, either. Make your functions black boxes with solid "APIs" (type signatures), and let the inside do whatever it needs to make it work the best.
Just because premature optimization is the root of all evil, it doesn't mean we need to jump right to premature pessimization...
Yeah, and even if you need concurrency/parallelism within the function, it can be forgivable to use ConcurrentDictionary or ConcurrentBag or one of the many, many other thread safe mutable data structures built directly into .NET.
I will personally almost always prefer the pretty functional versions of things, and that's almost always what I start with. I like immutable data structures, and they are usually more than fast enough. Occasionally, though, you hit a bottleneck of some kind (usually in some form of loop), and you have to avoid all the beautiful functional stuff and go back to sad imperative stuff. When I do that, I usually try and keep it scoped to one function. Even within one function, I do find the persistent structures easier to reason about, but as you stated it's a small enough surface area to not be too irritating.
There are exceptions to this, of course. Sometimes for caching/memoizing I will make a global ConcurrentDictionary, and I'll use the interlocked thing to do global counters sometimes.
I find algo performance is a consideration, but so is overall system performance especially in the face of concurrency, staleness, update rate, data processing size, consistency of data, etc. I think persistent collections are just another tool which is sometimes appropriate; and it has saved me over the standard Concurrent collections in some interesting cases. There are significantly faster immutable collection libraries than the standard F# Map class though online you can use if I recall from awhile back - still not quite mutable perf though. It tends to be appropriate to use for almost the opposite case than a single thread in a tight loop which is the usual benchmark I guess. As usual YMMV/depends on problem at hand.
Out of curiosity when did you write that interpreter? The entire dotnet ecosystem has seen massive speed improvements over the years, particularly for anyone who last tried them during the Framework era. Hell they even put work in to improving tail calls which the c# compiler doesn't even take advantage of (also either in the dotnet 9 or 10 timeframe f# added an attribute to make it so a recursive call that isn't a tail call throws a compiler error so you can't accidentally screw that up).
It's .NET 10 lol. It's not so slow you can't write stuff for it, I have implementations of Conway's game of life, Huffman compression, and a minimal TUI. The main problem is doing almost anything in it involves a method lookup. And there are almost certainly places I could have done things more smartly.
One thing I do want to try out is publishing it with native AOT. I had a lot of luck with that on one of my other F# projects, I got like a 75% speedup out of it. I understand the JIT is supposed to outperform native AOT in the long term but I haven't seen it reach that speed.
Author here! I actually tried using AOT and it actually decreased the performance by about 35%. I think it's because Game Boy games tend use a small number of instructions a lot more than the others, so the JIT can optimize for them, while AOT has to be more conservative.
AOT vs JIT is always interesting since JIT depends on the runtime actually deciding to bother running the later passes to get more optimized code.
And sorry for the paranoia, I find a lot of people tried f# or even c# back in 4.x Framework era and think it hasn't changed.
With some care about what features to use and when, F# can be very fast. Which is nice, use functional paradigm when you want, or low level imperative code in hot loops if you need. But yeah if you use linked lists and sequences and immutable data types everywhere it sure isn't Rust.
I always find emulators written in functional languages impressive. It tends to be much easier to map hardware to an imperative language. I enjoy seeing the functional abstractions people come up with.
Did you look at the code? F# has mutable variables/arrays and this uses that for eg memory.
Yeah I did see that part. Although he mentioned his Chip8 emulator which was fully immutable. Still interesting so see when people use the mutability escape hatches.
Interesting, enjoyable post. Like the bit about data modeling. I've been dabbling in some OCaml and that kind of modeling is the best part. Also interesting to learn of CAMLBOY. Feedback to the author: Skip the AI edit step. I'd have preferred grammar errors or inelegance to what we have here, which is a bit stale.
F# is super fun, awesome work!
Insanely cool. I've had it in the back of my mind to write a Rust compiler for the game boy for a long time and everytime I see something like this I think about brushing off that project.
When I read F# I always have to think of the song with the same name by Tim Minchin and it starts playing in my head.
dsyme nodding proudly meme here
Really Cool!
mildy related but wasn't there an emulator (maybe not GB but NES or SNES?) which had a visual panel showing each CPU cycle step by step? afaik it was very slow but the 1000% accuracy was the goal not playability.
My guess is you're thinking of no$gmb, a very early Game Boy emulator:
https://gbatemp.net/threads/no-gmb-2-5-dos-full-version.6039...
I've got fond memories of using this to get a preview of Pokemon Gold before it was released in NA!
Found it
MetalNES, transistor level NES emulation https://github.com/iaddis/metalnes
While searching I also found a new one, VisualNES https://kaiokendev.github.io/nes/about
There is also one for GB https://github.com/aappleby/MetroBoy
See also Higan, formerly BSNES, which among other things is a cycle-accurate emulation of the SNES hardware and its enhancement chips (like the SuperFX used in StarFox/StarWing):
https://en.wikipedia.org/wiki/Higan_(emulator)
I'm not sure if this is the one you are talking about but I remember seeing this a little while ago. https://mtmc.cs.montana.edu/
Found it
MetalNES, transistor level NES emulation https://github.com/iaddis/metalnes
While searching I also found a new one, VisualNES https://kaiokendev.github.io/nes/about
There is also one for GB https://github.com/aappleby/MetroBoy
This is awesome. Love seeing projects like this.
Very cool. Makes me want to build something with F*
How about a Game Boy Game?
Same. I've been wanting to learn F# for a while now but never had the right excuse.
Sorry for the tangent - does anyone have some really zoomed in views of GB, GBColor, GBA screens in operation? I'd love for retro shaders to be able to more faithfully reproduce.
I mean, ideally, we'd run different color test patterns through, in different lighting conditions, to build a really detailed model, right?
I guess buying the second hand devices wouldnt be that expensive.
I wonder at what point even a still functioning device no longer looks the same?
I've been going through a lot of very old stuff recently and a lot of it is well preserved in a way but given enough years everything changes.
I don't think any original Gameboys have been made in twenty years or more.
Building emulators is cool but everyone does it, and the end result is more or less the same. Is there some things that could be done during the process to perhaps make an emulator a little more unique instead of a perfect replica?
What do you mean? It has to mirror the behavior of the hardware pretty closely otherwise... well... the games don't run.
I'm actually starting a new project to create a gba emulator in zig, and also starting with chip8. I'm going to skip nand to tetris because I played Turing complete. Cool to see I'm on the right track!
Yes, CHIP-8 is kind of the standard "I want to get into emulators" first project. In my latest book Computer Science from Scratch we go CHIP-8 -> NES in chapters 5 to 6. GBA is quite a step up from CHIP-8. I would suggest doing NES or GameBoy next, but of course with today's LLM help GBA is very reasonable if you are going that route.
Got it
Now I would like to see the other way around, F# running on Game Boy.
> No code is free from the influence of AI these days, even learning projects
Speak for yourself
I misread Fem-Boy and I was not understanding the context anymore lol