If one likes the article, as do I, there are couple of cool lisp projects related to the 6502 chip.<p>Brit Butler has written a 6502 emulator[0] and is now writting a NES emulator in lisp[1]<p>Henry baker wrote a compiler for a simple lisp named 'comfy' for the 6502 chip which intended to replace it's assembly in emacs lisp[2] which has been ported to common lisp[3]<p>[0]: <a href="https://github.com/redline6561/famiclom" rel="nofollow">https://github.com/redline6561/famiclom</a><p>[1]: <a href="https://github.com/redline6561/cl-6502" rel="nofollow">https://github.com/redline6561/cl-6502</a><p>[2]: <a href="http://home.pipeline.com/~hbaker1/sigplannotices/sigcol03.pdf" rel="nofollow">http://home.pipeline.com/~hbaker1/sigplannotices/sigcol03.pd...</a><p>[3]: <a href="https://github.com/jaoswald/cl-comfy-6502" rel="nofollow">https://github.com/jaoswald/cl-comfy-6502</a>
The thing that is fascinating——and only possible in Lisp——is that by extending the DSL that he started as the assembly language he could, eventually, actually program his 6502 in... Lisp.<p>A typical assembler reads the program in assembly language syntax and translates the lines into binary instructions. And you could write a Lisp compiler that reads in Lisp and produces maybe C which is then compiled into assembly language which is finally fed to the assembler. But he started by writing the assembler in Lisp and instead of parsing and translating assembly language he wrote his assembly program by calling Lisp functions such as (inc) (txa) (lsr) which just emitted the appropriate instruction codes.<p>However, at this point there was no barrier left between his host-side Lisp and target-side machine code. He could write constructs in Lisp that, by running the Lisp program, expand to the corresponding machine code. And given some well-chosen Lisp constructs he could elevate the code into a much higher level but still output 6502 machine code. He could write Lisp macros to produce Lisp code that produces 6502 code.<p>And because everything was still tightly integrated in a single running Lisp program, he could keep doing the low-level stuff as well because he was still in control of what machine code instructions would be written out.<p>This IMHO is a much better way to write assembly language than the usual syntax that assemblers parse. But it's not possible unless code is data is code.
High-level assemblers can greatly reduce the tedium of programming for older systems. Just a small amount of structure -- loops, conditionals, symbolic definitions -- improves assembly immensely.<p>Here's one dev's experiences making a GTA-like game for the NES, using his own high level assembler: <a href="https://www.youtube.com/watch?v=Hvx4xXhZMrU" rel="nofollow">https://www.youtube.com/watch?v=Hvx4xXhZMrU</a><p>Here's one for CHIP8: <a href="http://johnearnest.github.io/Octo/" rel="nofollow">http://johnearnest.github.io/Octo/</a>
Wow... programming in Lisp is already not that mainstream... and on top of it, for the NES?<p>Impressive.<p>I so want to start learning to program in NES now. Not really in Lisp as I would like to learning curve to be gentler, but this article definitely sparked my interest into learning one of the devices I used most during my childhood.<p>Great work!
Nice! I've been using python to augment my 6502 assembly. I haven't programmed the NES, but I've read that acommon way to wait for a particular raster line on it without using fancy mapper hardware is to use sprite-to-background collision interrupts. Collisions aren't triggered until they happen "on screen" with respect to the monitor beam position (same on C64 or Atari 2600), so you can effectively use it to get a line- or even a pixel interrupt.
Beautiful.<p>I've actually been walking around for a few days just now pondering if one could do the corresponding thing for contemporary graphics processors. Seems like communicating with them in Lisp could be a great thing.
(That idea was inspired by another HN post <a href="https://news.ycombinator.com/item?id=7408807" rel="nofollow">https://news.ycombinator.com/item?id=7408807</a>)
Do you know of any attempts at that?
For those interested in NES programming in a similar style (DSL that is basically an ASM assembler), there's a Python version of this concept (titled PyNES)<p>I find it to be very readable:<p><a href="https://github.com/gutomaia/pyNES/blob/0.1.x/pynes/examples/mario.py" rel="nofollow">https://github.com/gutomaia/pyNES/blob/0.1.x/pynes/examples/...</a> example file, I like it