[LispM-Hackers] Graphics questions

[Mike McDonald]

>From: "James A. Crippen" <james@UnLambda.COM>
>To: Mike McDonald <mikemac@mikemac.com>
>Subject: Re: [LispM-Hackers] Graphics questions 
>Date: Mon, 19 Mar 2001 18:24:57 -0900 (AKST)
>
>On Mon, 19 Mar 2001, Mike McDonald wrote:
>
>> 
>> >From: "James A. Crippen" <james@UnLambda.COM>
>> >To: John Morrison <jm@mak.com>
>> >Subject: Re: [LispM-Hackers] Graphics questions
>> >Date: Mon, 19 Mar 2001 17:19:28 -0900 (AKST)
>> >
>> >I haven't read your message yet JM, but here's a link to a toolkit that
>> >might be useful at least for the X and Windows ports.  I haven't looked at
>> >it closely yet though.
>> >
>> >http://www.fltk.org/
>> 
>>   What on earth would you need a widget set for? Unless TI did major
>> rewriting of the window system, all you're going to need to emulate a
>> dumb frame buffer with draw pixel. I can't even imagine a need to
>> scrollbar and pushbutton widgets. Personally, I'd say use Xlib to
>> start with.
>
>Primarily because programming in Xlib sucks, and secondly because we'll
>hopefully have more than just a frame buffer blitting pixels, but an
>actual user interface in which we can do things like configuring devices,
>selecting bands to load, etc.

  Creating a single window of fixed size and drawing pixels with
XPutPixel is trival. And if the emulator can be made to work with
that, than porting it to other graphics contexts will be easy.

  As for configuring the emulator, that more reasonably would be done
externally to the emulator its self. In which case, it can use
whatever graphics toolset you like, whether that be fltk, tcl/tk, ggi,
or whatever. I doubt the setup tool will be very portable, certainly
not to the "bare metal" case.

>Most importantly Xlib isn't portable to anything but X.  If we use a
>widget set that is portable to more than X *and* has a widget which
>consists of a dumb frame buffer then we wouldn't have so much to deal with
>in rewriting all the back-end graphics support cruft.

  The "cruft" is only a create screen routine and a draw pixel
routine. The easiest way to provide those two routines in our
developement environment is with Xlib calls. 

  But graphics output isn't the most important question. Keyboard and
mouse emulation is the much tougher question. How are you going to
emulate the extended keyboard of a LispM? How are you going to provide
mouse events? Having to trap every memory access to see if it's to a
hardware device instead of memory is going to be a bear.

  Here's a list of devices off the top of my head that I think are
going to have to be emulated:

  screen
  keyboard
  mouse
  clock
  disk controller
  ethernet

  Anyone think of any others?

  Mike McDonald
  mikemac@mikemac.com