Technical Breakdown of a new NES game written in Lisp

This was an incredibly enjoyable read. A lesson to take away is that many of the ideas of Lisp can be taken advantage of without reeling in the entirety of an existing stack.<p>Writing a Lisp parser is easy. Walking Lisp code is easy. Serializing Lisp code is easy. Adding a new primitive is easy. Adding very basic syntax transforming macros is easy. All of these are virtually trivial if your host language is a Lisp, as was the case with Co2.<p>What they didn’t do is what many people might think are table stakes with Lisp: writing a garbage collector, writing a runtime, supporting lambdas, and so on. Those are unreasonable asks for 2K RAM on a 6502. I wouldn’t say they wrote a bonafide Lisp, but they made use of many ideas of Lisp successfully to write a game that is very surprisingly readable while not being too abstract over assembly.<p>Since Lisp began in the 1950s, it has always needed to stay tied to the low level. Even today, with SBCL or CCL, you can write your own assembly code. One relevant thing to the article is Baker’s COMFY 6502 language for writing assembly code [0]. A few implementations can be found on GitHub.<p>[0] <a href="http:&#x2F;&#x2F;home.pipeline.com&#x2F;~hbaker1&#x2F;sigplannotices&#x2F;sigcol04.pdf" rel="nofollow">http:&#x2F;&#x2F;home.pipeline.com&#x2F;~hbaker1&#x2F;sigplannotices&#x2F;sigcol04.pd...</a>

I loved Lisp upon my first exposure in the late 80s in university. Then I &quot;had&quot; to professionally abandon Lisp leanings because I entered the game industry which required, at the time, a commitment to 8-bit assembly code. No problem. Lisp remained a hobby. Fast forward! Unexpected intersect! I love this so much and thank you for the great writeup!<p>There&#x27;s a podcast for present day NES developers called The Assembly Line.[1] I&#x27;m sure they&#x27;d enjoy this story and talking to you.<p>[1] <a href="https:&#x2F;&#x2F;soundcloud.com&#x2F;nesassemblyline" rel="nofollow">https:&#x2F;&#x2F;soundcloud.com&#x2F;nesassemblyline</a>

This is a complete and absolute hack and I love it. When reading the README file of their github it is possible to see how &quot;impure&quot; pragmatic decisions were made like for loops and not supporting proper recursion. I wish there would be more projects like this one porting lisp runtimes to more and more hardware.<p>In the other hand the racket lisp behind the scenes _generates_ the assembly code based on some of the scheme primitives rather than porting its whole Racket runtime there, which in spite of not being the same as running a lisp in the NES hardware is still impressive.

I&#x27;m struggling with the same problem: I&#x27;m a Lisp programmer who&#x27;s writing a commercial game, in my case a Unity engine game, which requires C#.<p>I&#x27;ve opted for a less elegant, but technically simple strategy: I&#x27;m writing all the build tools&#x2F;content tools in Clojurescript, and then writing only the core game engine in raw C#.<p>Next, I&#x27;m using <a href="http:&#x2F;&#x2F;bridge.net" rel="nofollow">http:&#x2F;&#x2F;bridge.net</a> to cross-compile the game engine into javascript, which I can then link to from clojurescript so that all unit tests and 90% of all QA testing can be done via clojurescript tooling, without any C# in sight.<p>This allows me to deploy a commercial game in &quot;native&quot; C# without any performance penalty, but with as few lines of C# as humanly possible.

One of the advantages of lisp is REPL-driven development. I imagine you can&#x27;t just edit a fn, eval it and then see the changes immediately. What is the workflow like when creating a NES game using co2?

This is impressive. I appreciate you documenting the development of it and giving an overview of what&#x27;s going on inside. I wish there were more blog posts like this. Have you reached out to the Racket community about the game and co2? Also, would you say this Lisp is geared more toward people who already know 6502 assembly, and not toward people who just want to write a NES game in a Lisp?

If you like this, you should also check out the work around Retro City Rampage. RCR is a GTA1 clone for multiple platforms from a few years back, but the developer also made a real NES ROM of it. Here&#x27;s a great talk about that process: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=Hvx4xXhZMrU" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=Hvx4xXhZMrU</a><p>(I&#x27;m not related to the project, but it&#x27;s one of the few games I&#x27;ve 100% completed because it was just so good)

Looking at the code examples of the entity system in this article made me wonder what it&#x27;d be like to code a MUD in this language or in lisp generally.<p>Does anyone know if there are any MUDs out there coded in lisp? I didn&#x27;t find any good results in google aside from the MPI lisp-like language built on top of FurryMUCK.

I’d like to hear more about the compiled stack.<p>In extremely latency sensitive applications, the mix of stack and instruction cacheline faults can cause significant overhead.

Really cool article. I appreciated the &quot;engineering on the battlefield&quot; vibe. I&#x27;m curious why they first went with Lisp.

They made their language using Racket! Great to see Racket style Language Oriented Programming being used for something so cool

Lisp is and was the best programming language. I moved to Java many years ago and still regret :)

Cool! Thanks for sharing! Just picked up the game, it looks awesome.

Very impressive and readable. Congratulations!!!

I know it&#x27;s off-topic but I appreciate so much when somebody hosts their own blog rather than using Medium or some nag-ware hosting service.<p>I didn&#x27;t get any pop-up &quot;pardon[ing] the interruption&quot; or asking me to join a mailing list, or anything! To think this used to be the normal way of doing things on the web.