
Turning the Apple //e into a lisp machine, part 1 - antics
http://blog.nullspace.io/apple-2-lisp-part-1.html
======
fsck--off
If you want to play with a Lisp Machine on Apple hardware, Symbolics is still
selling refurbished MacIvory boards. Even though the hardware is ancient the
latest model (MacIvory model 3) costs more than a top-of-the-line retina
MacBook Pro. The MacIvory 2 is more affordable, if you have an extra thousand
dollars to spend.

[http://www.lispmachine.net/symbolics.txt](http://www.lispmachine.net/symbolics.txt)

------
lisper
Another Lisp for the Apple II:

[http://www.flownet.com/ron/plisp.html](http://www.flownet.com/ron/plisp.html)

Complete with disk images so you can run it yourself on a real Apple or an
emulator.

~~~
msarnoff
The documentation link on that site isn't working, but it can be found here:
[http://jeffshrager.org/llisp/](http://jeffshrager.org/llisp/)

The last chapter is particularly interesting, as it describes the inner
workings of the interpreter.

~~~
richardjordan
I still have my original Apple II from when I was a kid. Have been meaning to
fix it up in a while. This is a great reason to do so! In other news, any
hardware hackers in Sunnyvale looking for a fun project...

------
jff
A Lisp machine is designed at the hardware level for running Lisp well. This
is a neat project to implement a bare-metal Lisp environment on top of Apple
//e hardware.

~~~
antics
This is true, of course, but our point is that there is not a lot of stuff
separating the lisp from the machine -- no OS for instance. It's just a
machine that runs lisp and nothing else.

~~~
lispm
I think its fine and a good project. I was once using Lisp on my Apple IIc.

Generally a Lisp Machine is also really a piece of hardware designed to run
Lisp. The CPU of a Symbolics for example is a (mostly) stack machine which
knows all kinds of Lisp data types and Lisp function calling conventions. The
memory then also contains Lisp data (with tags for data types and GC which are
used by the CPU directly). Additionally the Lisp that runs on top of it is
providing OS services: device control, I/O, keyboard, disks, tapes, expansion
cards, graphics, sound, network, scheduling, ...

Getting a Lisp on an Apple II to the level of the built-in Apple Basic with
access to keyboard, graphics, etc. should be fun. I'm looking forward to read
more of your adventures!

~~~
jordanb
Right. Lisp machines came out of the assumption that general purpose hardware
would be very bad at running lisp, in an era where custom single-purpose
computing hardware seemed to make sense.

As it turned out, Unix workstations ran Lisp just fine. So when the 80s AI
winter drying up budgets, AI labs decided to buy cheaper SUN workstations and
the Lisp machine companies failed.

~~~
lispm
No, Lisp Machines came out of the assumption that there was no hardware to run
AI development environments as personal workstations. The concept of the Lisp
Machine dates back to the early seventies and the first machines appeared
mid/end seventies.

Lisp developers early on wanted to use the machines interactively. A single
Lisp developer could use a PDP with something like Macsyma, which probably was
thought to serve tens or hundreds of terminal users. And the memory of that
machine was still constraining for Macsyma or some of the other larger Lisp
programs.

At that time there were no useful 32bit (or more) microprocessors. Other
machines were either tiny or very large for multiple users. The 68000 appeared
in 1979 and just was good enough to run the console of the Symbolics Lisp
Machine a few years later.

So Lisp Machines were developed to run a very compact machine code
representation of Lisp and with very large main memories (1 Megabyte or more),
graphical user interfaces and all that for a SINGLE user - a $100k per
machine.

Thus when they appeared on the commercial market in 1981, there was nothing
like it.

Ten years later lots of other processors were fast enough, had enough memory,
and were available as capable personal computers or workstations. But
initially 'general purpose' hardware was not especially good at running Lisp.
The Intel chips were a bad match, the first 68000 was slow with tiny memories,
... It took a few years and the next generations were better: 68020, the
SPARC, better Intel processors, ...

But when Lisp Machines were designed at at Xerox/PARC (the Alto running Lisp
in 1974, then InterLisp-D), at MIT (the CONS in 1975 and CADR), at BBN (the
Jericho in 1979) general purpose hardware WAS unpractical for running Lisp,
Lisp applications and their development environments.

Later in the mid 80s the architectures were brought to microprocessors (TI
Explorer Megachip, Symbolics Ivory). It was also tried to design RISC based
chips: SPUR, Xerox, Symbolics, ... but then the market for Lisp went away.

~~~
mjn
I agree w.r.t. the 1970s, but the Lisp Machines were having cost-competition
issues even before the Intel/SPARC machines caught up, due to the advent of
lower-cost, smallish minicomputers that could be used as single-user machines
if you had the budget. By 1985 you could get a MicroVAX II for ~$20k, plus
another ~$8k for a copy of VAX Lisp, and have a quite reasonable Lisp system,
with the downside of having to store a reasonably big cabinet (but not full-
VAX kind of big).

~~~
lispm
The basic MicroVAX II was quite slow, with tiny memory, just a text terminal
interface, ... To get anything comparable to a Symbolics 3640 one would have
to invest quite a bit more money and it would still be slower as an 11/780.

The lab at our University was using a lot of Lisp on a DEC 10 and VAX 11/750
and 11/780\. Nobody I know was keen to move their Lisp development to a
Microvax (though there were some),

There were some Symbolics 3640 users. Then later Apollo/SUN/Compaq/Mac II, ...

------
hvs
Aw crap. Now I may have to setup my Apple IIGSs and begin another marathon
Apple hacking session. My wife always finds these times
trying/amusing/annoying.

------
antitrust
The Apple //e was the hacker-friendliest machine ever. It's probably the ideal
learning platform for anyone looking to go into computer science, although
perhaps not app programming as a career, which requires a narrower skill set
and more focus.

~~~
zwieback
I was a die-hard Apple fan until the Mac came out, which felt like a betrayal
to the original Wozniak-driven Apple philosophy. The PC, ironically, became
the continuation of what Apple meant to me.

~~~
analog31
I suspect that their experience with the //e influenced the decision to make
the Mac a closed box. Like you, I found the PC to be a much more comfortable
transition.

Because the Apple ][ was a locked design, folks started poking directly into
ROM and RAM locations, for instance directly manipulating system variables, or
even jumping into the middle of ROM subroutines. A book called "What's Where
in the Apple II" documented almost every known hook.

My mom had that book. She's my hacker role model.

As a result of the way that software interacted, it became virtually
impossible for Apple to update the ROMs without breaking popular apps.

The next generation of personal computers all represented different approaches
to avoiding this problem by providing well documented entry points while
offering no guarantee of long term code stability. IBM made one mistake: They
let people hard code the address of video RAM, which is what led to the
legendary 640k barrier.

~~~
antitrust
I wish they'd taken a middle path.

Having BASIC (or another language) built into the machine was a big plus and
encouraged people to see continuity between the OS, the hardware and the code.

If that BASIC had to use built-in functions and data-types instead of simply
POKE-ing and PEEKING-ing as a de facto interface with the underlying machine
code, that would still have been hacker-friendly without being inflexible.

It was such a weird relationship between desktop machines and UNIXes back
then. It's like the desktop designers had to re-learn the lessons of UNIX in
the small. So much was forgotten.

~~~
analog31
I agree. In my view, the "walled garden" of iOS is just the next step in what
Apple had already intended to establish for the original Mac. To be
charitable, I can imagine it being based on the idea of protecting the user
from Bad Software.

But lots of us wanted to write Bad Software such as little programs for our
own use, or for limited, specialized use by other people. I found the Mac
programming docs (Inside Mac) to be impenetrable, and the overhead for writing
Hello World enormous.

Then I fell in love with HyperCard. But we all know what happened to that.

~~~
antitrust
> In my view, the "walled garden" of iOS is just the next step in what Apple
> had already intended to establish for the original Mac.

I imagine this is a quandary that shows up not in computing, but anywhere that
users interact with a single source of definitive rules.

For example, it might be easier for government to erect certain walled
gardens... or for companies to do this with their employees, parents with
their kids, etc.

It's not that I don't understand their position or view it as probably the
best way to herd cats (I mean, "consumers").

But hacker-friendliness is what gets you the top echelon of users drifting
toward your hardware and software. As a result, it's a huge (but invisible)
business draw.

------
tcarey83
I'm gonna stick my neck out here and say these guys are choosing the worst and
most convoluted way to develop software, much less, a lisp system to for the
Apple IIe ever. And then, trying to make a sensation out of it.

I was alive and programming back when the Apple IIe was popular. While I
mostly wrote code for the Commodore 64 and Atari systems of the time, I did
write a bit of code for the Apple II and IIe.

Those computers are primitive by today's standards, but nobody was entering
hex codes. That ended with computers like the ELF II. A lot of the machine
code programming was done with a program called a 'monitor' program that was
much like the DOS debug program that allowed viewing and writing memory as
well as a single line assembly (i.e. inline assembly) that would allow writing
programs a line a time in assembly.

But most of the programming was being done using assembler's and compiler's
like the Aztec/Manx C compiler that is still availble today (google it) so
what they are doing and saying is BS.

------
hcarvalhoalves
Which makes you wonder, where would we be today if the Apple //e shipped with
LISP.

~~~
sehugg
In those days I'd just be happy with a language that let me quickly manipulate
16-bit integers. AppleSoft used floating-point for all intermediate
calculations, which made even simple loops very slow.

I enjoyed using GraFORTH, which was a 10 kb dialect of FORTH with bitmapped
and 3D wireframe graphics (!) that compiled to threaded code.

~~~
rumbler
Steve Wozniak's original Apple II Integer Basic had 16-bit signed integers,
but no built-in floating point support.

Applesoft (licensed from Micosoft) had 16-bit integer variables (such as A%)
as well as floating point, but you are right that it converted them to and
from real with every operation, which was slow. They were useful for saving
memory (2 bytes instead of 5) and not much else.

There were BASIC extensions published in places like Nibble and
Call-A.P.P.L.E. that added native integer math to Applesoft using the &
command, so you could write things like "A% = B% &\+ C%", and the operation
was performed without conversion to real.

Let's also not forget SWEET-16, Woz's software emulation of a 16-bit kind-of-
RISC processor on the 6502, that had 16-bit arithmetic. Reading the source
code of SWEET-16 blew my young, impressionable mind.

------
LarryMade2
> There is no assembler and no text editor, so the only development
> possibility other than BASIC is to implement directly in machine code.

Could have developed off machine then ported over to the ][ lots of resources
here: [http://6502.org/](http://6502.org/)

like XA65:
[http://www.floodgap.com/retrotech/xa/](http://www.floodgap.com/retrotech/xa/)

Much 8 bit development nowadays (and there still is a lot) is cross-platform.

plus many many apple ][ emulators for debugging... even some running via
browser.

~~~
billforsternz
Well yes, and that's exactly what they did; Developed off machine and then
ported over to the ][

~~~
LarryMade2
But.. there are assemblers/compilers... and available off-machine. Just
pointing out an undiscovered opportunity.

~~~
billforsternz
Presumably they used off-machine assemblers and/or compilers

------
cdjk
This is very cool. For a slightly easier way of experimenting with a lisp
machine it's possible to install OpenGenera. There are scattered tutorials
online, but here's one I've found:

[http://www.cliki.net/VLM_on_Linux](http://www.cliki.net/VLM_on_Linux)

I've been meaning to try this - perhaps I'll write up a better tutorial (or
better, an ansible playbook) to set it up.

------
zwieback
Nice blast from the past. I eventually built a serial port for my Apple ][. I
bet you could do a USB-FTDI-Apple interface pretty easily. The audio interface
was always really fiddly although we used cassette tapes back then and most of
the problems were due to the low fidelity of the tapes.

~~~
antics
Interestingly, in practice the laptop-to-A2e audio transmission almost never
fails -- the fidelity is probably not an issue anymore. FWIW, we would have
picked a better way to transmit the data if we'd had more hardware. This was
basically just a hack that ended up being kind of funny and cool.

------
sehugg
I wonder if Andrew Plotkin's "Lists and Lists" (a Scheme tutorial written for
the Z-machine VM) can run on a //e? Seems like it would.

[http://ifdb.tads.org/viewgame?id=zj3ie12ewi1mrj1t](http://ifdb.tads.org/viewgame?id=zj3ie12ewi1mrj1t)

------
rbanffy
One of my personal projects (one that'll most likely never happen due to time
constraints) is a Raspberry Pi-ish gizmo merged into an Apple Super Serial (or
something with a built-in terminal). This way, you could plug it into a slot
and boot into a terminal of a Linux machine.

------
lscharen
He should really look into using ADTPro. It even supports bootstapping over
the audio input like is described in the post.

[http://adtpro.sourceforge.net/bootstrapaudio.html](http://adtpro.sourceforge.net/bootstrapaudio.html)

~~~
antics
But then it wouldn't have been a hack! We wouldn't have had to understand
anything to get the job done!

... Though, credit where credit is due, the C code we used to generate the
audio signal actually is pretty much a direct port of the corresponding code
in ADTPro. One of the reasons it's released separately from our lisp code is
because ADTPro is LGPL and we prefer the MIT license. :) One of these days
I'll make the port more independent and less derivative, so they can all be in
the same project.

~~~
lscharen
Might I suggest adding something to your project description that acknowledges
this. I didn't see any mention of ADTPro or David Schmidt on the linked page
or the github repository.

David Schmidt has contributed a lot of free software to the Apple II community
over the years and, IMHO, deserves recognition for his work by those that
build upon it.

~~~
antics
The C code that encodes the audio is listed in the dependencies section [1],
and ADTPro is freely acknowledged there. However, I'm more than happy to add
some reference to the post because I think you're right.

EDIT: Aaaaaand acknowledgement pushed into post. Cheers.

[1]: Specifically located here: [https://github.com/hausdorff/apple2e-audio-
transport](https://github.com/hausdorff/apple2e-audio-transport)

~~~
david__schmidt
Thanks very much for the acknowledgement. Your project looks like a lot of fun
- very cool use of audio. And of course Lisp rocks. Another audio-based
project is the Apple Disk Server - loading games directly to the Apple via
cassette port:
[http://asciiexpress.net/diskserver/readme.html](http://asciiexpress.net/diskserver/readme.html)

