[LMH]Musing

[Nyef]

On Mon, 25 Aug 2003, James A. Crippen wrote:

> Before I go to bed tonight I wanted to babble a little bit about my
> thoughts of when this project is a little more mature.

Now that I've worken up this morning, I wanted to babble some responses 
to your thoughts. ^_-

> Graphics Interface. We've had this discussion before, and I honestly
> think we should use X11. This of course require that you have an X
> server available, which makes it annoying for MacOS and Windows
> users. But... I think that if we use X11 at first we'll still end up
> with a not-too-terribly-painful implementation, and I really don't see
> why the glue layer between the Exploder hardware emulation and the
> 'real' display couldn't be abstract enough to port to other display
> systems later, like Quartz or WinAPI. This seems to be how things are
> going for the McCLIM people.

X11, no question. We're only dealing with a DFB, possibly with 
dirty-rectangle updates. I have basic DFB code for X11 and Win32 in 
DarcNES, so I'll probably be ripping that code off. The real problem is 
that the display is 1024x808, which means running the host at an even 
higher resolution.

The real question is if we decide to do anything with MX emulation, which 
appears to have support for host-native windowing. The micronet protocol 
doesn't look that hard to deal with, either.

> Input Devices. This mostly seems to be dependent on the display
> system. Each provides its own system of input as well as the output. I
> figure though that we'll be converting every single event into some
> sort of faux hardware interrupt on the Explorer. I forsee this as
> being a significantly ugly area, involving a lot of work on speed
> improvement. Making it portable however shouldn't be too hard, since
> all the various display systems provide the same basic set of input
> primitives.

Mmm... Actually, I was thinking of stuffing the keyboard buffer directly. 
No point in doing all the interrupt stuff unless we're either doing a 
microcode-level simulator or we want to use the same I/O code for a 
microcode-level simulator.

> Raw Disk. Having a low-level disk access seems like a good idea to

Only if we're doing bare-metal booting. No real point otherwise.

> Bare-Metal Booting. While I think this could be an interesting hack I

Interesting hack? Maybe. But, as a purist, I find the idea of using Linux 
and X11 as "bare metal" more than a little cheesy.

Somewhere among the stuff littering my various hard drives I have
preliminary designs for a 'real' Lisp OS, where even the interrupt
handlers can be written in Lisp. Unfortunately, it's beyond my skill to 
implement for the present time (mainly because of having to write or 
hack up a compiler, deal with fasloads, etc).

> System Software. Eventually we'll have a system that boots and
> runs. Software will work on it. I'd like to see us start to maintain
> two forks of the System Software, one for physical Exploders and one
> for our noncorporeal Exploiter. The initial code base should be the
> last and best available set of sources from someone's working Exploder
> machine, maybe or maybe not the set of sources that I already have. We
> then suck this stuff into a CVS repository and branch it. The branch
> becomes the hardware Explorer sources, and the trunk becomes the
> emulated Explorer sources.

Not unless you can guarantee that the sources are under an open-source 
license before we start hacking on them. This is absolutely essential. If 
we don't have this, we are doomed before we start.

> With a working emulator there's no reason why we shouldn't keep
> polishing it, but I'd like to see work begin on the design of a *new*
> system, based on the emulator but with a lot of the unnecessary

Again, get an open-source license for the existing system source first.

> Basically what I'm getting at is that getting the emulator working is
> just the first step in a long process of improvement. A working
> emulator, as John Morrison put it, "brings the LispM to the
> masses". But once the masses are involved we can expect lots of
> interest in work on improvement. We'll need to be ready and have
> thought about it beforehand, or we'll end up like the Lisp community
> just before Common Lisp, a bunch of well-defined groups going in a
> bunch of completely different well-defined directions.

No, once the masses are involved, you can expect your server to get 
slashdotted.

But I do see what you're getting at, and I agree with you on the basics. 
It is not enough to emulate. We should aspire to something more than the 
state of the art -twenty years ago-.

> That's what I'm dreaming about.

---------------------------
All programming can be viewed as an exercise.
---------------------------
Alastair Bridgewater
e-mail: nyef@softhome.net