gil@limbic.UUCP (Gil Kloepfer Jr.) (06/16/88)
In article <2167@rtech.UUCP> daveb@llama.UUCP (Dave Brower) writes: |>In article <4447@killer.UUCP> loci@killer.UUCP (loci!clb) writes: |>> Another program, an animation routine was submitted by Sid Grange |>> (sid@chinet) which uses raster op's. Fiddling with it a bit |>> (removing the delay loop), I was able to get it to write at |>> 300 frames per second. That seems pretty fast to me, so I'm |>> wondering why rastop's wouldn't be prefered. |> |>Rastops only work inside a window. If you want to write elsewhere on |>the screen, you are in trouble. Say, for example, you wanted a |>different window manager... |> |>-dB |>{amdahl, cpsc6a, mtxinu, sun, hoptoad}!rtech!daveb daveb@rtech.uucp This has nothing to do with window management. If you want a new window manager, all you have to do is kill the current one and write your own. You open a window icon in the corner of the display (a separate window), and you can do just what the current window manager does now (see the window driver manual pages). I think what you mean is to write a new window DRIVER. To that, I say, "Good luck!" :-) If the question posed is what the use of Mike Ditto's routines were as opposed to just using rastop -- Mike answered this question when he posted the driver routines. They were meant to be educational more than operational (even though they were both). It is also kind of neat to be able to have this kind of low-level control of the screen memory like you could have on the Commodore and Atari low-end 6502-based PC's. I think Mike even said in his README file that his driver was not something he recommended using -- not only because it bypasses the window driver and can do wierd things to the display, but because using rastop is supposed to allow some kind of upward compatibility should the hardware change or some such thing...and because it and the window manager work together. (hardware changes, ha ha :-) Hope this is somewhat informative. +------------------------------------+----------------------------------------+ | Gil Kloepfer, Jr. | Net-Address: | | ICUS Software Systems | {boulder,talcott}!icus!limbic!gil | | P.O. Box 1 | Voice-net: (516) 968-6860 | | Islip Terrace, New York 11752 | Othernet: gil@limbic.UUCP | +------------------------------------+----------------------------------------+
daveb@llama.rtech.UUCP (Dave Brower) (06/17/88)
In article <138@limbic.UUCP> gil@limbic.UUCP (Gil Kloepfer Jr.) writes: >In article <2167@rtech.UUCP> I write: >|>In article <4447@killer.UUCP> loci@killer.UUCP (loci!clb) writes: >|>> 300 frames per second. That seems pretty fast to me, so I'm >|>> wondering why rastop's wouldn't be prefered. >|> >|>Rastops only work inside a window. If you want to write elsewhere on >|>the screen, you are in trouble. Say, for example, you wanted a >|>different window manager... > >This has nothing to do with window management. If you want a new window >manager, all you have to do is kill the current one and write your own. You >open a window icon in the corner of the display (a separate window), and you >can do just what the current window manager does now (see the window driver >manual pages). I think what you mean is to write a new window DRIVER. To >that, I say, "Good luck!" :-) Bzzt, disagreement on design philosophy ahead. It's not at all clear that a driver is the right way to do windows at all. If someone is ever going to port X windows to the 3b1, it is NOT going to be on top of the existing window drivers. It is much more likely to be on top of /dev/fb {framebuffer}, which is exactly what this driver provides. If I'm providing a whole new window system, I am not going to layer on top of the existing brain damaged one, I'll want to get at the actual display hardware. The only question would be whether using one whole screen window, and replacing {w,s,ph}mgr with an X server using wrastop would be faster than having X use /dev/fb. The four problems porting X to the 7300 are: 1. Compiler (use gcc). 2. Getting raw access to the display (use viddev or maybe a window) 3. Getting at the mouce the right way. May need to hack a driver to get at the raw mouse data. This should not be too hard. 4. No select on non-existant sockets. You can emulate sockets with named pipes, though it will be ugly. Faking a select is harder, and it may be necessary to write a driver that fakes it. This is hard. Why X instead of wmgr? Because there are actually people writing new applications that are effectively in the PD using X. No one is writing anything to run under wmgr. With X, the 7300 would be an absolutely bang-up personal workstation. -dB {amdahl, cpsc6a, mtxinu, sun, hoptoad}!rtech!daveb daveb@rtech.com <- FINALLY!
gil@limbic.UUCP (Gil Kloepfer Jr.) (06/20/88)
|>In article <138@limbic.UUCP> I write: |>>In article <2167@rtech.UUCP> Dave writes: |>>|>In article <4447@killer.UUCP> loci@killer.UUCP (loci!clb) writes: |>>|>> 300 frames per second. That seems pretty fast to me, so I'm |>>|>> wondering why rastop's wouldn't be prefered. |>>|> |>>|>Rastops only work inside a window. If you want to write elsewhere on |>>|>the screen, you are in trouble. Say, for example, you wanted a |>>|>different window manager... |>> |>>This has nothing to do with window management. If you want a new window |>>manager, all you have to do is kill the current one and write your own. You |>>open a window icon in the corner of the display (a separate window), and you |>>can do just what the current window manager does now (see the window driver |>>manual pages). I think what you mean is to write a new window DRIVER. To |>>that, I say, "Good luck!" :-) |> In article <2180@rtech.UUCP> daveb@llama.UUCP (Dave Brower) writes: |>Bzzt, disagreement on design philosophy ahead. It's not at all clear |>that a driver is the right way to do windows at all. If someone is ever |>going to port X windows to the 3b1, it is NOT going to be on top of the |>existing window drivers. It is much more likely to be on top of /dev/fb |>{framebuffer}, which is exactly what this driver provides. This part is OK. I probably agree with you (I know of the X window system, not a lot about it .. and I know it IS the way to go)... Read on... |>If I'm |>providing a whole new window system, I am not going to layer on top of |>the existing brain damaged one, I'll want to get at the actual display |>hardware. The only question would be whether using one whole screen |>window, and replacing {w,s,ph}mgr with an X server using wrastop would |>be faster than having X use /dev/fb. Problem right here. You DO NOT understand the function of {w,s,ph}mgr. These are **NOT** the window drivers. You can blow these away as I have and still have windows. The window DRIVER is "/dev/window" and the associated "/dev/w*" devices which are the physical windows that /dev/window assigns on each open. This is very, very similar to (choke) VMS's WTAx: devices under VWS (VMS Workstation Software). wrastop uses /dev/window and the unix-pc window management device functions -- so you probably want to scrap the driver altogether and work with /dev/fb like you said. When you migrate to X, you will want to probably dump /dev/window, but you will lose the functionality of the rest of the UNIX-pc's canned software. This may not bother you at all, but be prepared. The only way you could continue using it under X would be to simulate /dev/window by providing kernel-level calls to X. Also note that the window driver is a "required" driver (whatever this means), and is also a permanent part of the UNIX-pc kernel. This is a big problem... |>The four problems porting X to the 7300 are: |> 1. Compiler (use gcc). Oh, ok?! |> 2. Getting raw access to the display (use viddev or maybe a window) See above. Getting raw access to the display is fine, but part of X should probably be done as a loadable device driver. (yes or no? I don't know). |> 3. Getting at the mouce the right way. May need to hack a driver |> to get at the raw mouse data. This should not be too hard. No, it shouldn't. The mouse is connected-in with the keyboard driver so you would hack the keyboard driver to provide a /dev/mouse also. Also note that doing this would kill some more UNIX-pc canned-ware. |> 4. No select on non-existant sockets. You can emulate sockets with |> named pipes, though it will be ugly. Faking a select is harder, |> and it may be necessary to write a driver that fakes it. This |> is hard. Sorry, I forgot my Berkeley sandals for this one. I'll have to take your word for it! |>Why X instead of wmgr? Because there are actually people writing new ^^^^ |>applications that are effectively in the PD using X. No one is writing |>anything to run under wmgr. ^^^^ This is what I was refering to before. wmgr only handles program function keys that let you bounce around from window to window. More accurately would be that you would like to trash /dev/window. |>With X, the 7300 would be an absolutely bang-up personal workstation. Probably. I, personally, would trash tam and /dev/window and rewrite the whold damn thing -- make all the current UNIX-pc software work under X. Problem is getting the source to unix for this machine so I could make the transition a bit easier for those with applications written under the old system. |>-dB |>{amdahl, cpsc6a, mtxinu, sun, hoptoad}!rtech!daveb daveb@rtech.com <- FINALLY! Dave -- this isn't a personal attack (BTW) at all... I agree with you wholeheartedly. But it isn't the *mgr programs only that you are doing away with -- its the device driver that does the windows -- which really isn't married to those programs at all. And my good luck was to try to get around the current window driver. That will be something that will make you climb the walls! Let me know how it all works out if you decide to take this on! +------------------------------------+----------------------------------------+ | Gil Kloepfer, Jr. | Net-Address: | | ICUS Software Systems | {boulder,talcott}!icus!limbic!gil | | P.O. Box 1 | Voice-net: (516) 968-6860 | | Islip Terrace, New York 11752 | Othernet: gil@limbic.UUCP | +------------------------------------+----------------------------------------+