[LispM-Hackers] Keyboard problem

John Morrison jm@mak.mak.com
Tue Mar 26 04:13:00 2002


Hi Alastair (et al);

First, thanks for clueing me in regarding reading the keyboard port to
reset the controller.

On Tuesday 26 March 2002 12:58 am, Nyef wrote:
> I'm given to believe that many free OSes out there use this method or a
> full realmode switch to access the VESA graphics mode controls. There are
> likely just as many that switch graphics mode before hitting protected

Well, this is what I had done to date.  I picked a reasonably vanilla
console type graphics mode and switched to it before going to
protected mode.  I figured this would help debug the native code prior
to going to protected mode (and believe me, it has helped because I
have not figured out how to use GDB for cross-debugging -- if you have
any ideas there, that might be a Real Win).

> mode and don't change it afterwards. These are certainly approaches I
> would consider for my next standalone system.
>
> It's quite possible to get code to switch between various VGA modes, but
> once you get into SVGA territory it's a heck of a lot easier just to use
> the VESA BIOS any way you can.

Correct me if I'm wrong, but we would need an SVGA type resolution in
order to show at least 1024x808 (or thereabouts).  Thus, it would be
really nice to use the BIOS to get there.

> I don't recommend using the BIOS for anything that you can reasonably do
> yourself. It's just too easy to write more suitable floppy and IDE drivers
> than the BIOS ones (the BIOS drivers block the entire system until they
> complete, for example).

I think I understand that.  I was kind of hoping to do them in Lisp
later, anyways.

> Stuff you can't reasonably do without BIOS assistance include APM support,
> SVGA mode switching and initial startup.

That seems to be the rub.  I have a thousand-page-plus (more than a
little out of date, I guess) PC VGA book here, with overwhelming
amounts of information.  Seems quite daunting.

Correct me if I'm wrong, but the most portable ersatz "microcode load"
that gets booted (in terms of having as close to only one binary
version as possible), I would be smart to use the BIOS to switch to
the best possible graphics.

Thinking out loud, I figure I've got three options:

(1) Figure out how to get GDB cross-debugging working between the two
PCs.  Switch to the most appropriate graphics mode possible using the
BIOS before protected mode.  Use GDB for debugging.  (I think I'd have
to either port or write a special stub -- I've done this before in a
past life -- about 20 years ago -- for a different debugger for an
embedded system, and it was a pain in the ass.)

(2) Implement the v86 mode, and use that to write debugging info to a
virtual screen.  Implement a "magic" keystroke to switch graphics
modes (and foci) from emulated Explorer to microcode console.

(3) Live without debugger, and without ASCII debugging printouts.
Either: (a) do some stupid stunt like writing color-coded pixels to
the extra "border" in 1280x1024 mode to give me some clue as to what
the microcode THINKS it's doing (kind of like blinking LEDs in POST or
using Morse code); or (b) figure out how to write ASCII text to that
border using SVGA fonts or something like that.

Any other ideas?

-jm

-- 
==== John Morrison
==== MAK Technologies Inc.
==== 185 Alewife Brook Parkway, Cambridge, MA 02138
==== http://www.mak.com/
==== vox:617-876-8085 x115
==== fax:617-876-9208
==== jm@mak.com