Turning the Apple //e into a lisp machine, part 1
blog.nullspace.io
blog.nullspace.io
http://www.flownet.com/ron/plisp.html
Complete with disk images so you can run it yourself on a real Apple or an emulator.
The last chapter is particularly interesting, as it describes the inner workings of the interpreter.
http://www.pjrc.com/store/teensy3.html
Never finished it, but if you like these kinds of challenges maybe you'd like to collaborate on it.
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!
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.
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.
A good post, and some other analogies I can think of are/were the concept of specialized "word processor" computers, specialized CAD stations, specialized gaming hardware... Pretty much if there was marketing material with words like "accelerator" "turbo" "extreme" it probably fits right in.
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, ...
> Later in the mid 80s the architectures were brought to microprocessors
I wonder when will someone build one onto an FPGA.
It's the ultra-übergeek version of the Jeri Ellsworth's C-One.
I'm currently reading all the papers/talking to people so I can design one (still torn between doing something historically accurate or modern, new, and potentially useful).
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.
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.
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.
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.
It should be noted that during this time period, outside of a few affluent districts, virtually all teaching of programming at the K-12 level was done on an ad hoc basis by teachers who volunteered their time and money.
Edit: Not "was" a hacker but "is" a hacker. ;-)
] CALL-151
* !
! 300: LDA 1000
The day I discovered the mini-assembler was absolutely mind-blowing.
I have very fond memories of the Apple //e (and I have some with broken PSUs that I must get around to fixing) I bootstrapped my own assembler on DOS3.3 using the mini-assembler.
On Prodos I bought the full development kit which came with an assembler and a nice debugger. Wrote a Forth for the Apple with help from Loeligers Threaded Interpretive Languages and a copy of Starting Forth by Leo Brodie (both borrowed from the library) good times...
If all you want is LISP, burn it into an EPROM and replace the stock one.
I don't have access to my Apples at the moment, so can't check the details, but I'm now curious to know exactly what might have changed between various II+ - what did others gain that we were missing, or why did we have room for it when they didn't...
Two years later I got a '386 clone, bought Turbo C and all the fun came back at once.
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.
I enjoyed using GraFORTH, which was a 10 kb dialect of FORTH with bitmapped and 3D wireframe graphics (!) that compiled to threaded code.
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.
Could have developed off machine then ported over to the ][ lots of resources here: http://6502.org/
like XA65: 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.
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.
... 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.
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.
EDIT: Aaaaaand acknowledgement pushed into post. Cheers.
[1]: Specifically located here: https://github.com/hausdorff/apple2e-audio-transport