CADR simulator
10/21/04
Brad Parker
brad@heeltoe.com

What is this?
-------------

This is a simple hack designed to emulate the CADR microprocessor
hardware.  A CADR is a second generation MIT lisp machine.  A good
description can be found in "A.I. Memo 528" from the MIT AI Labs
entitled, "CADR".

The CADR was a 32 bit microcoded microprocessor designed to run the
lisp language.

This program attempts to interpret the microcode found in the machine
starting with the "prom" microcode which runs when the machine is
first powered on.

What state is this in?
----------------------

It boots a world!

The emulation is about 90% done.  It gets through the prom code, loads
the microcode band, copies the band to swap and executes the load band
cleanly.

It displays an X windows and tracks the mouse and keyboard.  The
simplest way to run it is

	./usim

If you want to see a trace of macrocode function names try:

	./usim -n -Tl >output

If you want to see a raw voluminous trace of every microcode instruction try:

	./usim -n -t >output

The disk emulation reads from a 'disk image' file which is constructed
with 'diskmaker'.  The disk image looks like a Trident T-300 disk
to the microcode, complete with a parition table.

The display board and iob are emulated.  An X window displays in
monochrome at 768x1024.  The mouse and keyboard are tracked.  The
keyboard is "mapped" to the old Knight keyboard.

The internal microsecont clock and the 60hz tv interrupt currently try
and use wall clock time for a more realistic simulation.

There is basic emualtion of the chaosnet board.  Packets sent are
looped back. (currently the lisp code is rejecting my packets because
of a bad bit count; can't see why.  needs debugging)

The basic machine emulator seems to be (mostly) correct.

There are some hacks for noticing unibus access but no xbus/unibus
mapping support.  The two machine lash-up/debug interface is not (yet)
supported.  I want to add this, however.

I finally fixed the divide code.  Naturally the Q shift and the ALU
shift (with a bit conditional on the Q sign) happen at the same time
in the hardware (but not in the C code :-).

There's a long delay when booting, even though the world is running
and system-x works fine.  I need to track this down - possibly waiting
for a time packet?  The system is available right away, however, try
"F2-p".

What needs to be done?
----------------------

- cleanup keyboard emulation
- cleanup mouse emulation
- cleanup chaosnet emulation

The keyboard mapping is a crock.  The mouse emulation works but
doesn't track exactly.  The chaosnet emulation needs to be somehow
made to work with 'real' ethernet.  I have a chaosnet implementation
for linux so this should be doable.  Clearly we need a file server.

f1	network
f2	system
f3	abort
f4	clear
f5	help
f6	end
f7	call
delete	rubout

I need to make this programmable with a reasonable default.  Ok, I was
in a hurry :-)

Long term I want to do some recompiling of the microcode into C and
assembler, both statically and on-the-fly.  This is the interesting
part...

What programs are here?
-----------------------

usim		- the emulator
diskmaker	- program to make CADR disk images from .mcr files and
		  .lod files
lod		- utiltity to pick apart load bands and show their insides

