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

[James A. Crippen]

Hey all, I've had pneumonia for the last two weeks and have been
bedridden.  I'm finally back at work and slogging through 300 messages...

On Fri, 23 Mar 2001, Paul Fuqua wrote:

> - 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.

The question is how often TV writes to the frame buffer directly and how
often it uses the miscops.  If we can rely on the miscops being used in
almost all cases then we won't have much trouble at all, and we can
isolate the particular cases where the frame buffer is written to directly
and handle it via some sort of trap when the frame buffer memory is
directly accessed.  I'm thinking along the lines of not synchronizing the
emulated frame buffer memory to actual UI display unless absolutely
necessary.  This would speed things up a bit, I think.  But this is just
hypothetical musing, and I'm not certain.

> - 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.

Hyper on the Symbolics is pretty much reserved for user bindings.  Super
is used frequently with no particular method, although C-M-<key> is more
common than any S-<key>, I think.  I'm pretty sure that most of the
bindings in Zwei are the same between the two, but outside of that it's
debatable.  Some of the low level TV bindings are the same too.  But the
keybindings for most of these are stuck in the sources in various places.

>  The oddball keys like
> Abort can probably be mapped to X keysyms pretty easily -- End to End,
> Abort to Cancel, and so on.

Symbolics has a set of bindings for PC keyboards supporting Resume, Break,
Abort, Undo, etc.  Not sure how to support the family of
{Caps,Bold,Italic,Mode} Lock.  Left, Middle, and Right should be fun
too.  I'm certain that F[1-4] should probably be bound to the same on the
PC keyboard, even though they were on the opposite side of the board on
the Explorer.

I'll try to sit down and work out an appropriate key map when we start to
support keys other than the alphanumerics.

> 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've got the Symbolics mapping somewhere on my Lispm.  It uses C-_ for a
prefix key, similarly to C-x in Emacs.  So C-_ A is Abort.  That can be
used for tty-only interaction.  But under X I'd like as realistic a
keyboard as possible.  We'll have to do some mapping hacks to get this.

If you look at Jamie Zawinski's XKeyCaps application for generating
xmodmap mapping files for X, available at http://www.jwz.org/xkeycaps,
you'll find that it supports the TI Explorer keyboard.  Grab the sources
and compile it and then do a "Select Keyboard" and look for "Texas
Instruments" under "Vendors".  You should see "Explorer" listed.  Select
that and you'll see the X mappings for the Explorer keyboard, which
supported the Explorer X server.  The source for the support for that
keyboard should be somewhere in the XKeyCaps source tree, and should
describe all the keycodes that X would receive for the keyboard.  We can
probably use this to emulate the keyboard in reverse, I think, generating
those keycodes and passing them to the emulator?

Even more entertaining will be the ability to make X mappings for the
Explorer keyboard running under e3.  X under Explorer under X.  Should be
interesting...

I personally use Control, Meta, Super, and Hyper in my keyboard mapping,
which coincidentally resembles the Symbolics keyboard very closely (with
Control closest to the spacebar, Meta next, etc.).  I have no problem with
this in most X apps.  They always see Meta as Alt when necessary (because
both use the mod1 modifier), and those apps that support Super and Hyper
work.  Apps not written with explicit support for these keys, or which
lack some form of keybinding (with X resources, say) can't support them,
but the important ones like XEmacs do.  XEmacs frankly loves Super and
Hyper.  Makes it very easy to add new keybindings too, since neither key
is supplied with bindings by default.

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

I hadn't looked for those.  Where is the source for the X server in the
Explorer tree?  I'll have to hunt them up and try them.
 
> - 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 agree, portability shouldn't be much of a problem.

> - 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?

I've often thought that it would certainly be more effective to use the
Linux kernel and run e3 as /bin/init rather than making e3 boot
independently.  A stripped down linux kernel should suffice for such
work.  But the bare-metal booting is JM's particular obsession, and I say
we can tackle that when we have something working under X a/o Windows.

> - 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.

Could we fake the clock interrupt in some asynchronous manner (inside a
while loop somewhere) or should we actually tie it down to the underlying
system's clock?  I suppose it depends entirely on the underlying system.  
I think some exploration of both approaches is warranted.  We'll see which
idea works best.

  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.

I am pretty sure that under Linux you can write raw ethernet frames by
hand and pass them to your ethernet card.  I do know that there are
methods for doing this between user space processes, namely the 'tun/tap'
device.  This allows for writing raw ethernet frames from one process to a
char device, the associated output device being read by another user space
process which picks up the ethernet frames and does whatever you want with
them.  This stuff is mostly for testing network protocols, but can be used
by anything when enabled in the kernel.  We could have a separate process
that acts as a one hop router between the Explorer and the rest of the
network, maybe even listening to multiple devices to fake an ethernet
network for all running e3 processes on a system.  If any IP packets
within the network need to be routed somewhere else then it passes the
packets (not the ethernet frames, but the packets within them) on to the
kernel IP stack, which will send them out to the rest of the *real*
network, whatever that might be (it could be anything that speaks IP, not
just ethernet).

None of this applies for other operating systems, though.  But we could
probably work something similar out with IPC on other Unices.  Not sure
about Windows.  I don't know anything about how it does networking, other
than knowing that Trumpet Winsock is still in there somewhere.

> 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.

I think we have most of the docs on the NUPI in the ESDN manual.  That's a
pretty detailed section.  Basically IIRC the NUPI was a certain chunk of
IO memory that things wrote to.  I think it was all simple MMIO.  I forget
and don't have the manual handy right now, but I recall thinking about
this before and it seemed that it would be possible to emulate a disk
without much problem.  The actual disks would probably be files in the
host OS.  Emulating a SCSI controller probably wouldn't be too hard, since
SCSI is well known.

Here's a random question -- should e3 be threaded in any way?  Should we
do some of the backend administrative stuff (like managing non-emulator
buffers and cache, etc) in a separate thread?  This would certainly
improve performance on SMP machines.  But I'm not sure how to go about
threading in a portable manner.  I'd like to particularly have a debugging
thread run separately from the emulator, so the emulator can be inspected
while running.  Thoughts on threading?

At some point I'll get my Symbolics Lispm networked at home and suck all
the sources off of it and put them in a tarball for people to
examine.  The only thing I lack is the microcode sources, and I have no
idea how to get them.  But I have sources for pretty much everything else
in the system, and I think they'd be at least useful for comparison to the
Explorer.

JM, you've got a Symbolics Lispm too, right?  Do you have ucode sources
for it in your installation?  I can't find any on any of the distro CDs
that I have.

'james

-- 
James A. Crippen <james@unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.