5 ms·

A 6502 lisp compiler, sprite animation and the NES/Famicom

114 points by shioyama 10y ago

brudgers 10y ago
Language repository: https://gitlab.com/nebogeo/co2 https://gitlab.com/nebogeo/co2
bitwize 10y ago
Nifty. This after I start a project to emit 6502 assembly using Scheme -- for VIC-20 development rather than NES.
pelle 10y ago
Very cool. I'm a lisp programmer now, but this reminded me that as a teenager I was learning how to do games programming on my C64 using an incredible Forth compiler and games framework called White Lightening. https://www.youtube.com/watch?v=H8609Pel_RU https://www.youtube.com/watch?v=H8609Pel_RU http://www.forth.org/lightning.html http://www.forth.org/lightning.html
- vidarh 10y ago
  There was also a BASIC version of Lightning. I never had the Forth version, but played around with the BASIC variant. BASIC implementations of everything in that Youtube video came with it, and it had funky things like pre-emptively multitasking for BASIC programs (fairly simple - just use an interrupt or hook into one of the BASIC entrypoints and count time slices and shift some pointers around) + separate programmable sprite animations (so you e.g. could start sliding a sprite over the screen and let your BASIC program keep doing other stuff
lisper 10y ago
A vintage 6502 Lisp: http://www.flownet.com/ron/plisp.html http://www.flownet.com/ron/plisp.html
- rahimnathwani 10y ago
  Another: http://www.acornelectron.co.uk/info/electron/acornsoft/Lisp.html http://www.acornelectron.co.uk/info/electron/acornsoft/Lisp....
pcwalton 10y ago
Related: Game Oriented Assembly Lisp (GOAL), used in a few shipping PlayStation 2 games: https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp Writing a good compiler to target the 6502 is difficult, because the CPU is so unlike modern hardware (8-bit with 16-bit addressing, only one register that isn't crippled, zero page, no arbitrary shift amounts, no multiply, weird addressing modes, etc. etc.) I'm always impressed when anyone gets something working :)
- Flow 10y ago
  You forgot fixed stack location and size. :) Basically every code on it it super-hardcoded for one thing. Sure, you can use the zero page(the first 256 bytes of the memory) to act like 128 16-bit registers, but you know, it feels like a cycle waste most of the time. Self-modificating code is easier most of the time, but not reentrant.
  - vidarh 10y ago
    When thinking back to my C64 days at the sheer number of loops that I did with self-modifying code [1], I shudder to think what a nightmare it would've been if larger systems had been written with it... But it as oh so pleasant to do small stuff on the 6502 series... [1] For those who don't have any exposure to 6502 assembler, here's a basic subroutine to copy blocks of memory - after ~25 years of not touching it so bear with me (and corrections welcome) especially with respect to syntax. Lets say we have the high byte of a 16bit address we want to copy from in the A register, and the high byte of a 16bit address we want to copy to in the X register (often it wouldn't be unusual for the calling code to directly modify the src/dest addresses instead to set up the loop...), and for simplicity the low byte of both is 0, and the number of 256 byte chunks we want to copy in Y. STA $src+2 ; the 6502 is little endian + 1 byte for opcode STX $dest+2 outerloop: LDX #$00 innerloop: src: LDA $0000,x ; the STA above overwrites the first two digits dest: STA $0000,x ; the STX above overwrites the first two digits INX BNE $innerloop ; branch back to start unless X has wrapped INC $src+2 ; update the high byte. INC $dest+2 DEY ; reduce counter of blocks to copy. BNE $outerloop RTS I'm sure I've forgotten some more efficient way of doing this - it was all cycle-counting all the time, and lots of ugly (uglier) tricks, but the basic mechanism of directly modifying the high bites of addresses all over the place to deal with loops beyond 256 iterations was pretty common.

114 points by shioyama 10y ago

brudgers 10y ago

Language repository: https://gitlab.com/nebogeo/co2 https://gitlab.com/nebogeo/co2

bitwize 10y ago

Nifty. This after I start a project to emit 6502 assembly using Scheme -- for VIC-20 development rather than NES.

pelle 10y ago

Very cool. I'm a lisp programmer now, but this reminded me that as a teenager I was learning how to do games programming on my C64 using an incredible Forth compiler and games framework called White Lightening. https://www.youtube.com/watch?v=H8609Pel_RU https://www.youtube.com/watch?v=H8609Pel_RU http://www.forth.org/lightning.html http://www.forth.org/lightning.html

vidarh 10y ago
There was also a BASIC version of Lightning. I never had the Forth version, but played around with the BASIC variant. BASIC implementations of everything in that Youtube video came with it, and it had funky things like pre-emptively multitasking for BASIC programs (fairly simple - just use an interrupt or hook into one of the BASIC entrypoints and count time slices and shift some pointers around) + separate programmable sprite animations (so you e.g. could start sliding a sprite over the screen and let your BASIC program keep doing other stuff

lisper 10y ago

A vintage 6502 Lisp: http://www.flownet.com/ron/plisp.html http://www.flownet.com/ron/plisp.html

rahimnathwani 10y ago
Another: http://www.acornelectron.co.uk/info/electron/acornsoft/Lisp.html http://www.acornelectron.co.uk/info/electron/acornsoft/Lisp....

pcwalton 10y ago

Related: Game Oriented Assembly Lisp (GOAL), used in a few shipping PlayStation 2 games: https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp Writing a good compiler to target the 6502 is difficult, because the CPU is so unlike modern hardware (8-bit with 16-bit addressing, only one register that isn't crippled, zero page, no arbitrary shift amounts, no multiply, weird addressing modes, etc. etc.) I'm always impressed when anyone gets something working :)

Flow 10y ago
You forgot fixed stack location and size. :) Basically every code on it it super-hardcoded for one thing. Sure, you can use the zero page(the first 256 bytes of the memory) to act like 128 16-bit registers, but you know, it feels like a cycle waste most of the time. Self-modificating code is easier most of the time, but not reentrant.
- vidarh 10y ago
  When thinking back to my C64 days at the sheer number of loops that I did with self-modifying code [1], I shudder to think what a nightmare it would've been if larger systems had been written with it... But it as oh so pleasant to do small stuff on the 6502 series... [1] For those who don't have any exposure to 6502 assembler, here's a basic subroutine to copy blocks of memory - after ~25 years of not touching it so bear with me (and corrections welcome) especially with respect to syntax. Lets say we have the high byte of a 16bit address we want to copy from in the A register, and the high byte of a 16bit address we want to copy to in the X register (often it wouldn't be unusual for the calling code to directly modify the src/dest addresses instead to set up the loop...), and for simplicity the low byte of both is 0, and the number of 256 byte chunks we want to copy in Y. STA $src+2 ; the 6502 is little endian + 1 byte for opcode STX $dest+2 outerloop: LDX #$00 innerloop: src: LDA $0000,x ; the STA above overwrites the first two digits dest: STA $0000,x ; the STX above overwrites the first two digits INX BNE $innerloop ; branch back to start unless X has wrapped INC $src+2 ; update the high byte. INC $dest+2 DEY ; reduce counter of blocks to copy. BNE $outerloop RTS I'm sure I've forgotten some more efficient way of doing this - it was all cycle-counting all the time, and lots of ugly (uglier) tricks, but the basic mechanism of directly modifying the high bites of addresses all over the place to deal with loops beyond 256 iterations was pretty common.