nanogui: Thread: pk-0.9.1

Greetings,

Okie, I've released pk 0.9.1, the second beta version.  It includes the
640x480x16 grayscale VGA driver and uses it to do an 80x30 console using a
fixed-width graphics font.  I havent done any windowing stuff, thats what
I'm hoping someone here can tell me about, whether it would be a good
match or not.  Theres a source code gzip'd tarball, pk-0.9.1.tgz with
the source code and a gzip'd bootable floppy disk image, pkfloppy-0.9.1.gz.
Just gunzip the image file and dd it to a floppy, or start it up in bochs
if you have that.

Enjoy!

Later,
FM

--
Frank W. Miller
Cornfed Systems Inc
www.cornfed.com

: Okie, I've released pk 0.9.1, the second beta version.  It includes the
: 640x480x16 grayscale VGA driver and uses it to do an 80x30 console using a
: fixed-width graphics font.  I havent done any windowing stuff, thats what
: I'm hoping someone here can tell me about, whether it would be a good
: match or not. 

Frank -
	I've been meaning to run your new OS, but haven't yet found time.
I would like to see MicroWindows running on your OS, and, now that
you've got a graphics screen driver going, it should be fairly easy.

	The MicroWindows and Nano-X designs run on top of three drivers,
which handle all device-dependent aspects of screen, mouse, and keyboard
interfacing.  The screen entry points handle open/close as well as read/write pixel
and drawhline and drawvline. All graphics operations, including fillrect, text draw
etc run on top of thes primitives.  We have already written a few vga screen drivers,
running on top of linux framebuffer, svgaLib, msdos, elks and bare hardware,
that will give you a quick idea of how to interface it.
	The keyboard drivers use /dev/tty for Linux, and bios for DOS.  The
hardware serial mouse driver currently runs on top of the OS serial port
mechanism, and supports MS, Logitech, and PC mice.

	The mid level engine requires a select() like mechanism for UNIX
like systems, and works by waiting for an event from the mouse or keyboard
file descriptors.  For systems that don't support select(), a  polling version
is implemented.  For other systems, a slight recoding would be necessary.
I plan on doing this for a win32 port (yes, lets run win32 on win32... ;-)

	If you want to talk about how your OS implements these type of
features for applications programs, I'd be glad to help port microwindows over.
Your's will be the third operating system we support!

Greg

pk has no explicit device model.  printf and getchar are implemented as
system calls under the assumption that there is a single screen.  This will
be problematic first off.  There needs to be a way to tie a window to
a thread for its stdio.  Need to think about this one a bit.



> interfacing.  The screen entry points handle open/close as well as read/write pixel
> and drawhline and drawvline.

The screen driver can be handled easily.  I even had someone donate a
drawvline routine for the driver today too so I can add that one to the
next release.


> 	The keyboard drivers use /dev/tty for Linux, and bios for DOS.  The
> hardware serial mouse driver currently runs on top of the OS serial port
> mechanism, and supports MS, Logitech, and PC mice.
> 

Keyboard driver probably needs to be expanded.  It only handles shift right
now, no ctrl or alt or multiple combinations.


> 	The mid level engine requires a select() like mechanism for UNIX
> like systems, and works by waiting for an event from the mouse or keyboard
> file descriptors.  For systems that don't support select(), a  polling version
> is implemented.  For other systems, a slight recoding would be necessary.
> I plan on doing this for a win32 port (yes, lets run win32 on win32... ;-)
> 

pk provides an event mechanism that has semantics similar to a barrier.
You define an event and then threads can wait on it.  When the event occurs,
all waiting threads are scheduled for execution.  There is no mechanism
for a single thread to wait on multiple events simultaneously yet.


Later,
FM


--
Frank W. Miller
Cornfed Systems Inc
www.cornfed.com

> -----Original Message-----
.
> I plan on doing this for a win32 port (yes, lets run win32 on
> win32... ;-)

Fscking Bloody Microsoft 128meg for the DX7SDK - I wrote a simple
640x480 (windowed and fullscreen) DirectDraw app that supports ReadPixel
and WritePixel, how I make that compile into the rest I'm yet to work
out (VC++5) But I'll throw you a zip when it pretends to be a video
driver.  What do you need to recode mid-level to get Wins32 running?
Anything I can pass to my other coder bloke?

	-Darran

: Fscking Bloody Microsoft 128meg for the DX7SDK - I wrote a simple
: 640x480 (windowed and fullscreen) DirectDraw app that supports ReadPixel
: and WritePixel, how I make that compile into the rest I'm yet to work
: out (VC++5) 

	I told you Darran to just use win32, but NO, you've got
to go drag in DirectX, _of course_ it's big - how else does microsoft do anything ;-)



But I'll throw you a zip when it pretends to be a video
: driver.  What do you need to recode mid-level to get Wins32 running?


Send it all over to me, I'll hack it

: pk has no explicit device model.  printf and getchar are implemented as
: system calls under the assumption that there is a single screen.  This will
: be problematic first off.  There needs to be a way to tie a window to
: a thread for its stdio.  Need to think about this one a bit.

	Frank - I pulled down your pkos right after I sent the last message,
and now understand where the os is at.  So microwindows will basically
be linked in with the kernel.  Stdio is is not strictly required, since currently
microwindows doesn't really do file i/o.  The printf's are there just for debugging.
Perhaps the microwindows thread can do polling for the keyboard and/or serial
port.  (this is just for the v0.1)  In this way, you set the .Poll entry point
for the keyboard and serial port to query the os state of the keyboard and
serial port.
	If you need various versions of stdio, I have some, but I don't think you need them

 : The screen driver can be handled easily.  I even had someone donate a
: drawvline routine for the driver today too so I can add that one to the
: next release.

	Great.  Remember we have all the VGA routines already written,
you can just copy them into your own driver file for pkos.  You will want
a hardware palette set routine, for 16 colors.

: Keyboard driver probably needs to be expanded.  It only handles shift right
: now, no ctrl or alt or multiple combinations.

	Doesn't matter, microwindows uses ESC to exit, else just regular ascii
chars for now

: pk provides an event mechanism that has semantics similar to a barrier.
: You define an event and then threads can wait on it.  When the event occurs,
: all waiting threads are scheduled for execution.  There is no mechanism
: for a single thread to wait on multiple events simultaneously yet.

	This is why you might want to just use a polling mechanism to get it
off the ground.  then, you can implement a kernel structure that keeps
a list of waiting threads, and whenever an event is fired, this list is checked
in addition, and if matched, the associated thread is scheduled in addition.

Greg