[LispM-Hackers] Portability, Graphics, Etherboot, etc, etc

[Paul Fuqua]

Assorted rambling comments on various recent issues (and remember I
missed weeks or months of discussions, so I may be re-hashing old
stuff):

- The Explorer did all its display through miscops like %draw-char,
bitblt, %draw-filled-triangle, and the like.  We could do anything we
want underneath that interface.  I'm not familiar with the color
hardware, but the mono frame buffer was one big chunk of bitmap memory;
it was possible to make an array indirected to the right physical
address and thus get direct access to pixels.

- X has no trouble representing the extra modifiers on the Explorer
keyboard, but I think the only big use of Super was for debugger
proceed-types and Hyper maybe somewhere in UCL.  The oddball keys like
Abort can probably be mapped to X keysyms pretty easily -- End to End,
Abort to Cancel, and so on.  The problem is input.  The debugger was
already accepting ^Z for Abort for historical reasons so we could
conceivably map everything to keystrokes available on modern keyboards.
The Symbolics telnet server had a standard mapping, but I don't remember
what it was.

- I have the basic Explorer fonts as .bdf files, thanks to the X server
code.  Cptfont has been my default X font for years.

- My home platform is FreeBSD/x86.  I can occasionally check things out
on the Solaris/Ultrasparc at work.  Assuming we don't do anything
stupid, I don't see why portability would be a big problem.  Write
common C++ code, avoid OS specifics, and handle endianness, and the core
should run on anything.  Isolate the graphics well, and we could use X
on Unix and whatever on MS-Windows and everyone will be happy.

- I don't see the motivation for bare-iron usage.  It seems to add
startup complexity and a third kind of graphics interface without much
benefit.  But if you really want it ...  PicoBSD is a project that gives
you a full BSD, aimed primarily at router applications, on a floppy.
Penguin Backup is a neat little hack that puts a Linux kernel and
PalmPilot backup tools on a floppy.  Explorer on a floppy, anyone?

- The Explorer clock interrupt would, I think, just kick the process
scheduler and poll the mouse.  X mouse-motion events ought to be
sufficient for mouse tracking and the scheduler doesn't have to be
*that* precise.  The Ethernet software was used to talking to a couple
of specific cards, though I think the microExplorer may have done some
simpler internal communication to get to the Mac's net card indirectly.
Similarly, the disk code expected to talk to the NUPI (and a lot of it
was in microcode), but the microExplorer did local NFS if I remember
correctly.  So controllers may or may not be a problem.

Probably more things to say, but I want to get this message out before
the weekend computer shutdown.

                              pf