uLisp is cool (code is a bit scary in places though),

I'm working on a virtual game console which uses an AVR.

I added some simple drawing functions.

http://fingswotidun.com/cruft/lisptri.gif

The emulator is at http://fingswotidun.com/avr/ but it's very alpha. If you have a small screen you can't even click on the run button because of an old debugging div is sitting on top of it.

I would like to read a blog post about your virtual game console if you have or ever write one.

I have one from the very early days.

http://blag.fingswotidun.com/2015/09/8-bit-machine.html

I've been planning on an update talking about Getting C programs running on it then building avr BASIC and Lisp for run time languages.

Probably far more likely to do updates given someone has actually shown interest in reading them. I kind of assumed My blog posts went into a void.

It's also on github https://github.com/Lerc/kwak-8

Huh. I thought about doing this, figured it would be impossible / pointless, and that (apparently wrong) assumption led me on a year-long journey:

The core problem, I thought, would be that AVRs have very very little memory. 316 Lisp cells sounds about right. I figured, well that's pointless. How can I do better?

I wasn't able to find a microcontroller that you can attach external memory to (without cheating and using something like an SPI RAM chip, although that's super easy). So I ended up figuring out how to build a real computer instead, around a Z80, with 64k total address space. The one I'm working on now has 32k RAM (still not great for Lisp) but you can divide up the address space between RAM and ROM however you want, so I'm planning for the next version to have the whole thing be RAM and use an AVR to "boot" it by loading code into RAM from an SD card.

If you build a compiler without runtime eval, you can use all the AVR's memory for user data. Still tiny, but not as cramped as this interpreter: http://microscheme.org Then again, if it doesn't have runtime eval, is it really a lisp?

Good question. It's hard to say.

As for microscheme, it looks cool. Although I am annoyed, because it implicitly claims to be Scheme (it's not), and it explicitly claims to be functional (scheme most definitely isn't). But those are just nitpicks.

Scheme fits the common definition of a functional language, even if it's not pure in the same way as Haskell. Especially since idiomatic Scheme uses pure functions and recursion (as opposed to idiomatic CL which is a lot more imperative).

To the contrary, idiomatic Scheme also uses a lot of stateful data.

Nope; it's absolutely clear right on the front page that it's a subset of Scheme.

What I meant was the name, although it's up for debate. The micro- would imply a subset, so it's much better than the many languages that call themselves Scheme, and really, really aren't.

Some of the devices in the Mega AVR line support external memory. The ATmega640 is an example. Generally you'll only find it on higher pin-count devices which aren't available in DIP packages. If you need something that's a bit easier to work with, the Teensy 2.0++ is an option.

As for your Z80 computer, another option would be to add some simple bank-switching hardware to allow you to boot from ROM. Probably more work and less flexible than just using an AVR for boot though.

I'm fine working with surface-mount stuff, I can solder it by hand, it's not actually as hard as it looks. Bank switching seems like a pain to manage though.

I wish I had learned this stuff in school. I majored in CS, and we didn't go any lower level than C++.

Once one starts getting into the high pin-count devices, just make the leap to ARM and using something like [0] which has 1MB of Data RAM.

[0] http://www.mouser.com/search/ProductDetail.aspx?R=0virtualke...

You just had to think that IBM 704 had 18432 bytes.

Nice work. Now you can make a programmable pocket calculator, that's programmed in Lisp!

The article links to http://www.technoblogy.com/list?1GLV calling it the full code listing for this Tiny Lisp Computer, however, that link leads to code for a ATtiny841 "I2C Display Module" which is from the "Make your own I2C peripherals" blog post at http://www.technoblogy.com/show?1G29. Hope the author sees this so he can change the link to be the correct one.

I notified the author about it on the uLisp forums. He has now updated the link.

In my opinion, this is among the coolest / revolutionary computer products that I have seen in the last 30 years of my usage of computers. It is also great to see that LISP is gaining more and more popularity as people realize the advantages of the stateless, reentrant, idempotent functional programming paradigm.

I don't mean to sound snarky in the least, genuinely curious, but haven't a large proportion of tinkerers, especially with an EE bent, tried to put a simple lisp interpreter on some limited hardware at some point in their lives? I certainly know that a bunch of people learning FPGA programming in a user group i once belonged to all tried to put a lisp machine on one after working through the last chapter of SICP, and there's that lovely article about lisp interpreters running on old JPL probes back in the day. What about this makes it revolutionary?

Of course it's not revolutionary. Lisp is the past technology of the future. And indeed lots of people have done things like this, with Lisp or Forth or Basic or microPython or Lua.

I believe a very early Raspberry Pi prototype was an Atmel chip that ran a Lua interpreter with bit-banged VGA display. It was extremely cheap but ultimately deemed not capable enough.

The JPL probe ran a fully compiled Common Lisp.

Another option for running a lisp (like language) on a small package is esp-lisp [1] running on ESP8622. The ESP8622 has a 32 bit processor running quite fast, and comes with 64K of RAM, so it's clearly not as challenging a platform to run lisp on as the Atmega used here. Its just a software project, though, and leaves the hardware part for others to design.

[1] https://github.com/yesco/esp-lisp

it's basically a uLisp shell on Arduino?

it will be shuned by the Haskell elite unless you need a monad to toggle the led, since it's intrinsically a non functional side effect :)

>it will be shuned by the Haskell elite

Seems like a feature, not a bug :^)

Lisp made its choice long ago: flexability over constraint, freedom over guarantees, call it what you will.

It does make it a hard language to optimize though. Thankfully, it got significantly easier once functions became opaque. But it's still a PITA.