If one likes the article, as do I, there are couple of cool lisp projects related to the 6502 chip.
Brit Butler has written a 6502 emulator[0] and is now writting a NES emulator in lisp[1]
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]
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.
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.
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.
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.
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.
This is not only possible in Lisp, this is also possible in Prolog. In Prolog, Data is code. LISP can be viewed as a specialization of Prolog, where the data structure just lists. Prolog has more complex data structure compounds, where a list is nothing more but one type of said compound structure. One can write Prolog code to emit 6502 code or any code as well, and I suspect with as much ease as he did.
I came to the same revelations when writing my own 6502 assembler in CL. You even get access to the reader in CL which allowed me to write a parser that could read 6502 assembler source files and compile them.
You can start writing a debugger on top, disassembler, and an emulator. You're not restricted in Lisp from doing low-level bit-twiddling of this sort.
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.
Wow... programming in Lisp is already not that mainstream... and on top of it, for the NES?
Impressive.
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.
Hefner is not really programming the machine in Lisp. The developer appears to have created a 6502 assembler as a "domain specific language" in Lisp, and then is programming the machine in that notation. This could have tremendous advantages over using some clunky conventional assembler; it can likely be made smarter, with less work. You could probably use his tool without knowing Lisp, if it were suitably packaged or documented. (But not without knowing 6502 machine language, in all likelihood!)
Knowing Lisp would help you easily understand and extend the assembler, so you could do things like create yourself some badly needed program organization abstractions and then use them. Otherwise you could just ask the author, or people in a mailing list. "Hey I would like a feature whereby if I write (foo bar) in the code, such and such an effect takes place in the generation of the 6502 image."
I've already been productively using it for myself doing a bit of ROM hacking. It feels like a much nicer environment to me than the usual romhacking setup. Still has some rough edges, though.
One of the best parts of it for me is seeing the assembly assemble as I type it, telling where it goes in the file, what the PC should be at that point, and if the line has an error, it shows it. http://i.imgur.com/JfEwJ9U.png
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.
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 https://news.ycombinator.com/item?id=7408807)
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)
Brit Butler has written a 6502 emulator[0] and is now writting a NES emulator in lisp[1]
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]
[0]: https://github.com/redline6561/famiclom
[1]: https://github.com/redline6561/cl-6502
[2]: http://home.pipeline.com/~hbaker1/sigplannotices/sigcol03.pd...
[3]: https://github.com/jaoswald/cl-comfy-6502