[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
pk-0.9.1
From: "Frank W. Miller" ####@####.#### Date: 8 Oct 1999 01:54:01 -0000 Message-Id: <199910080120.VAA01973@macalpine.cornfed.com> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: pk-0.9.1
From: Greg Haerr ####@####.#### Date: 8 Oct 1999 16:10:54 -0000 Message-Id: <01BF1175.0C53AF40.greg@censoft.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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: pk-0.9.1
From: "Frank W. Miller" ####@####.#### Date: 8 Oct 1999 17:49:13 -0000 Message-Id: <199910081733.NAA04425@macalpine.cornfed.com> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: pk-0.9.1
From: "Darran D. Rimron" ####@####.#### Date: 8 Oct 1999 18:15:17 -0000 Message-Id: <NCBBLCEDENCINNMFNPBCIEGADCAA.darran@getreal.co.uk> > -----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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: pk-0.9.1
From: Greg Haerr ####@####.#### Date: 8 Oct 1999 18:23:00 -0000 Message-Id: <01BF1187.92B006D0.greg@censoft.com> : 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: pk-0.9.1
From: Greg Haerr ####@####.#### Date: 8 Oct 1999 18:29:42 -0000 Message-Id: <01BF1188.7CBBF360.greg@censoft.com> : 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |