[LMH]Musing

[James A. Crippen]

Nyef <nyef@softhome.net> writes:

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

There's no problem with higher resolutions. A window in X can be any
arbitrary size. If the user is dumb enough to use it at 800x600 then
they get what they deserve. That's how I feel, anyway. This isn't an X
application so it can't have resizing windows (yet...). And like many
game console emulators, a fixed window size isn't much of a surprise
for users.

As well, I don't think that very many people use anything less than
1024x768 on their desktops. Those that use that res will need to have
a larger virtual screen and turn panning on. This is XFree86 specific
but people with non-XFree86 servers probably have larger resolutions
anyway (eg Sun's 1152x960).

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

I don't think we should. It adds an extra level of complexity. Maybe
it would be useful but I really think that getting the native display
working is a better idea. This makes it useful for bare metal work in
the future if people want to do that.

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

I wasn't thinking of keyboards when I mentioned that. Yeah, stuffing
the chars in manually is really the best way for that. But for mice,
which generate tons of interrupts with every move, this might be kinda
difficult. But I haven't looked into the area yet and have no clue how
the hardware supports the mouse.

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

Yup.  Which is why I mentioned that next. ^_^

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

I know it is. And I absolutely agree. But it's the sort of thing you
can put on a bootable CD-R with minimal effort and show off
anywhere. Of course, getting this done is just some scripting and
Linux OS building work, and has really nothing to do with the
Explorer.

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

Getting Lisp to play nice with crufty Intel hardware is
'interesting'. I think of a bare metal Lisp OS as the sort of project
that is really just talked about and never done. It's a huge
undertaking, equivalent to that of Linux, GNU, XFree86, and KDE/Gnome
combined. Enormous.

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

Right. Our strategy, which I don't think has changed since it was last
discussed, is to just build the emulator and make it work first,
without caring about the source copyright. Since we're not making
modifications to them I don't see a big issue right now. Later we can
use the working emulator as an argument for TI's opensourcing or
public domaining of the code. It has after all done absolutely nothing
for thing in ten years and probably will continue in that position
even with our emulator complete.

And if TI won't open the sources, well, then we'll just have to start
over on some new system software, won't we? I'm sure we could get the
CADR sources from somewhere. I keep hearing about them occasionally.
The compiler should support many of the same instructions, and the
CADR was 32 bit (SMBX was responsible for the 36 bitters). It'd be a
big step backward and we'd lose things like Visidoc and CLIM, but it's
the only next step to take. Of course, those lucky people possessing a
source license already could probably run the system software on their
working emulator. Which would be convenient if they were developing a
new set of software for the thing...

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

I doubt somehow that it will ever make it to slashdot. But maybe it'd
get 'clikied'. O_o

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

Hear hear. Twenty years ago is a good place to start from and not have
to undo or work around the mistakes in today's systems. But it's still
twenty years ago and needs to be progressed, forcibly, into the future.

'james

-- 
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, -149.8964W                     Recursion 'R' Us
Anchorage, Alaska, USA, Earth            Y = \f.(\x.f(xx))(\x.f(xx))