Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Programming NES (Games)

Hacking the NES With Lisp 80

Posted by Unknown Lamer from the covert-alien-technology dept.
Andy Hefner has a detailed blog post covering his quest to program an NES with the assistance of Common Lisp. He developed a new 6502 assembler, a mini-language for composing musical sequences, and a neat demo (rom image).

This discussion has been archived. No new comments can be posted.

Hacking the NES With Lisp More

Hacking the NES With Lisp

Comments Filter:

  • a strange mix of nausea and admiration (Score:5, Funny)

    by decora ( 1710862 ) on Monday February 06, 2012 @09:18PM (#38948847) Journal

    on the one hand, this guy has re-implemented assembler with lisp syntax.

    on the other hand, this guy has re-implemented assembler with lisp syntax.

    • Re:a strange mix of nausea and admiration (Score:5, Informative)

      by Dwedit ( 232252 ) on Monday February 06, 2012 @09:22PM (#38948863) Homepage

      Yeah, when you're writing Assembly, it's still assembly. Using lisp to make macros doesn't change the langauge.

      • Re:a strange mix of nausea and admiration (Score:5, Interesting)

        by ratboy666 ( 104074 ) <fred_weigel@hot m a i l.com> on Tuesday February 07, 2012 @12:22AM (#38949851) Journal

        Read the fine article. Using CL does substantially change the language. Specifically, note the higher order manipulation of the eventual low-level program that the author achieved using promises (delayed evaluations). Basically, "threading while assembling".

        Also, notice the ease of introducing higher-level flow control constructs (IF and UNTIL) into assembler. And the elimination of a second assembler pass by use of promises for forward references. It's kind of "magic" -- the correct data will be there when it's needed!

        In this use-case, CL is a notational system for NES programming. It probably shouldn't be called "assembler" anymore, as the power of CL can be brought to bear in the process of generating the desired machine code.

    • Re:a strange mix of nausea and admiration (Score:4, Interesting)

      by Hentes ( 2461350 ) on Monday February 06, 2012 @09:34PM (#38948919)

      Well he wasn't the first one to do it, Common Lisp already has a disassemble [psg.com] command.

    • Re:a strange mix of nausea and admiration (Score:5, Funny)

      by MightyMartian ( 840721 ) on Monday February 06, 2012 @09:35PM (#38948927) Journal

      Great. Now I can run Super Mario Bros. in Emacs!

    • Re:a strange mix of nausea and admiration (Score:5, Funny)

      by Anonymous Coward on Monday February 06, 2012 @10:07PM (#38949143)

      on the one hand, this guy has re-implemented assembler with lisp syntax.

      on the other hand, this guy has re-implemented assembler with lisp syntax.

      and on the gripping hand, it's the world's first assembler that requires you to start lines with seven parentheses and rewrites itself at runtime.

    • Re:a strange mix of nausea and admiration (Score:5, Informative)

      by Darinbob ( 1142669 ) on Tuesday February 07, 2012 @12:07AM (#38949777)

      The earliest lisps had assembler. It was sort of normal in a way because assembler was your language of choice for this sort of thing. C didn't exist yet, Fortran was just wrong, the other procedural languages were bulky, etc. Machines were low on memory and you often wanted to machine specific actions, you were writing your own runtime library as you went. So even as far back as Lisp 1.5 documentation discusses how to use assembler.

      The earliest lisps had compilers as well which went well with assembler written functions. Your programming environment was often a stack of cards that were loaded into a machine, or a tape that was read. So stopping to edit/compile/link/load was often impractical compared to just dumping some assembler while still in the interpreter (though of course if you crashed the machine you had to hide until pitchfork wielding mob stopped looking for you).

      The thing people remember most about Lisp other than parentheses are CAR and CDR functions. These are named for specific fields in a PDP 36-bit word which were accessible via machine instructions.

      • That it had the key word defun. I guess I've got to complement them on their honesty that one of the goals of the creators of lisp was to remove the fun from programming.(Because it certainly did for me.)

        • Re: (Score:2)

          by rmstar ( 114746 )

          I guess I've got to complement them on their honesty that one of the goals of the creators of lisp was to remove the fun from programming.(Because it certainly did for me.)

          Why is that? Must have been a bad teacher, because Lisp is really fun to program in. You need the help of an editor for the parentheses, but other than that its very easy and very powerful.

          • Oh this was back in the early 90's and we were using Emacs. Never heard anyone mention some sort of add on that would have helped with the parens. (I completely hate lisp because of that course btw.)

      • Re: (Score:2)

        by pz ( 113803 )

        The thing people remember most about Lisp other than parentheses are CAR and CDR functions. These are named for specific fields in a PDP 36-bit word which were accessible via machine instructions.

        Contents of Address Register
        Contents of Data Register

        • Close but not exact. I got it wrong too, it wasn't a PDP but an IBM.

          These both were fields from the same register ( bit words and the computer allowed either 15 or 16 bit word addresses). So according to Wikipedia the definitions were:
          "Contents of the Address part of Register number"
          "Contents of the Data part of Register number"
          And a couple other tiny fields that initially were in Lisp but were later dropped.

          Yea, it's kind of weird. The PDPs used at MIT later were 36 bit and also allowed sticking two wor

  • That's hot (Score:3, Interesting)

    by Anonymous Coward on Monday February 06, 2012 @09:22PM (#38948861)

    I think that is the coolest thing I have seen in a while. Nothing like the king of all high level languages generating low level machine code.

    • I think that is the coolest thing I have seen in a while. Nothing like the king of all high level languages generating low level machine code.

      They didn't write it in SmallTalk which would certainly be the king of all high level languages, not lisp.

      Lisps only quality is its known use of braces - which is also its greatest fault. A queen among queens.

  • But can it run Crysis?

  • This is what Slashdot needs more of (Score:5, Interesting)

    by comrade k ( 787383 ) <<moc.liamg> <ta> <kedarmoc>> on Monday February 06, 2012 @10:14PM (#38949179)
    Bravo, Slashdot. This is the kind of stuff that the geek crowd finds interesting. Is it useful? Nope. Is it cool and borderline bizarre? Yep!

    • Re:This is what Slashdot needs more of (Score:4, Interesting)

      by wierd_w ( 1375923 ) on Monday February 06, 2012 @10:44PM (#38949389)

      What I have always wondered about, is just how far can you push one of these old systems?

      Like the snes.. it was designed to accept a 3rd party cpu inside the cartridge, in addition to the game rom.

      What would happen if you built what would essentially be rom code toolbox routines to access the snes's hardware, and then switch execution to a more powerful/more modern low energy cpu, like an arm?

      You would use the snes as an input device (they did make a snes mouse.....), and as the graphics hardware, but run all the heavy lifting on the arm instead of the 6500 series cpu. Other than the rom routines to do the interface, everything else is handled by a shared ram bank and an sdcard slot put into the cartridge.

      Why? So you can run linux on the snes. Why? Because you could.

      I bet you could do some really clever stuff by simulating a framebuffer.

      • What would happen if you built what would essentially be rom code toolbox routines to access the snes's hardware, and then switch execution to a more powerful/more modern low energy cpu, like an arm?

        You'll have reimplemented Super Game Boy (for Super NES) or Game Boy Player (for Nintendo GameCube).

        • Didn't the gb have a z80 though? That's a bit less powerful than the 6500series cpu in the snes.

          Simply because the snes databus is 16bit doesn't mean the 3rd party cpu needs to be 16bit. The snes hardware could be treated like a 16bit peripheral, as far as the embedded SoC in the cart was concerned.

          I still think something more interesting than the superGB could be made this way.

          • Re: (Score:2)

            by tepples ( 727027 )

            Didn't the gb have a z80 though?

            It was an 8080-derivative made by Sharp with some but not all features of the Zilog Z80, nicknamed "GBZ80" by emulator authors. Some Z80 features, such as the separate bank of BCDEHL registers for interrupt handlers, were left out in favor of special fast addressing modes for $FF00-$FFFF to mimic the 6502's "direct page" at $0000-$00FF.

            That's a bit less powerful than the 6500series cpu in the snes.

            The old Commodore 64 vs. ZX Spectrum flamewars ended up with a consensus that the 6502 is roughly as fast as a Z80 clocked two to three times as fast, depending on workload.

    • Comment removed (Score:4, Interesting)

      by account_deleted ( 4530225 ) on Monday February 06, 2012 @10:59PM (#38949469)
      Comment removed based on user account deletion

  • 6502 assembler in Logo (Score:3)

    by leighklotz ( 192300 ) on Tuesday February 07, 2012 @12:23AM (#38949855) Homepage

    I wrote a 6502 assembler in Logo in 1981 and we shipped it with the utilities disk.

  • Just what I needed 35 years ago.

  • Paul Graham will definitely... (Score:3)

    by curious.corn ( 167387 ) on Tuesday February 07, 2012 @01:45AM (#38950243)
    send him a crate of beer ;)

  • Looks like Henry G. Baker's COMFY 6502 compiler (Score:4, Interesting)

    by dwheeler ( 321049 ) on Tuesday February 07, 2012 @03:50AM (#38950783) Homepage Journal
    Fun! This 6502-assembler-in-LISP looks similar to Henry G. Baker's "COMFY" 6502 compiler (described in "The COMFY 6502 compiler", SIGPLAN Notices, 1997 [pipeline.com]). You can check out the COMFY-6502 implementation that uses Common Lisp [nfshost.com] (sadly this appears to be entrapped in the ACM non-commercial-use-only license [acm.org], though for 6502 code that isn't very limiting). One cool thing about the approach of using LISP as an "assembler" in general is that unlike many traditional macro assemblers, this approach can easily do stuff like choose the optimal instruction set for branches because it can determine if it's in range for a short branch and use them when available. You can do it other ways, of course, but it's pretty elegant in LISP. Those interested in this sort of thing might like my page on 6502 Language Implementation Approaches [dwheeler.com] or my page on making LISP-based languages more readable (especially sweet-expressions) [dwheeler.com].

  • I hope all the HTML-5 "coders" are taking note.

    • Re: (Score:2)

      by Yvan256 ( 722131 )

      Coding != Programming.

      HTML5 and CSS is coding.
      PHP* and Javascript* is programming.

      I don't care if you hate those, it's still programming. Now go cry in the corner.

  • Here is a interesting article [archaeology.org] about the design of the 6502, on archeology.org of all places.

    But you already knew it was archeology.org, didn’t you?

Slashdot Top Deals

He who has but four and spends five has no need for a wallet.

Close