dwex@cbnewsj.att.com (david.e.wexelblat) (05/03/91)
I am planning to put together a small replacement for wind.o for 3B1 systems that have pitched UA/wind.o. Basically, I am tired of the glass-tty when logged in without running MGR, and also want a screen-blanker that runs without MGR (I don't want to give up my loadable-driver space to wind.o for the small amount I need done). What I intend is to have a window driver that provides: - screen blanking, and can accept ioctls from scrset (I see no need to have yet another program to do this) - a vt100-subset console. I figure that I can get the screen blanking done pretty quickly; I have most of the interface figured out (anyone who knows how this is implemented in wind.o is free to help me out :->) from looking at the nkbd.c sources and a bit of judicous adb'ing. What I haven't figured out yet is, once I have this running on /dev/syscon (or whatever), how do I make the driver know to stop interpreting characters, and just pass them on when MGR is running? I've thought of a couple of schemes, which may be equivalent: - create a /dev/framebuf device, with the same major device as /dev/syscon, but a different minor number. When MGR opens this device, the character- interpretation stops. This allows getty to hang off of /dev/syscon, and when MGR exits, things go back to normal. - have an ioctl() to do the same thing, and have MGR call this on startup. Actually, it just dawned on me that MGR doesn't write to /dev/syscon; it writes directly to the frame buffer. So if my driver just implements write(), then there is no problem (except for turning off cursors and stuff, since I like blinking cursors). Please email me your suggestions, or post followups to comp.sys.3b1. I will take all suggestions into consideration, and will post the results when I am happy with it (which may be never - I have a tendency to get too fancy for my own good :->). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- David Wexelblat | dwex@mtgzz.att.com | I asked her her name. AT&T Bell Laboratories | ...!att!mtgzz!dwex | She said her name was 200 Laurel Ave - 4B-421 | | 'Maybe' Middletown, NJ 07748 | (201) 957-5871 | --Damn Yankees
ostroff@Oswego.EDU (Boyd Ostroff) (05/04/91)
In article <1991May3.163220.24448@cbnewsj.att.com> dwex@cbnewsj.att.com (david.e.wexelblat) writes: >I am planning to put together a small replacement for wind.o for 3B1 >systems that have pitched UA/wind.o. >Please email me your suggestions, or post followups to comp.sys.3b1. Personally, I would *love* to just see a wind.o replacement that allows access to the bottom 4 lines of the screen (as someone else suggested). |||| Boyd Ostroff / Tech Director / SUNY Oswego Dept of Theatre / 315-341-2987 |||| Sys Admin at cboard.UUCP / Serving the Performing Arts / 315-947-6414/8N1 |||| ostroff@oswego.oswego.edu / cboard!ostroff@natasha.oswego.edu
dwex@cbnewsj.att.com (david.e.wexelblat) (05/04/91)
In article <1991May3.181308.7065@oswego.oswego.edu> ostroff@oswego.Oswego.EDU (Boyd Ostroff) writes: > In article <1991May3.163220.24448@cbnewsj.att.com> dwex@cbnewsj.att.com (david.e.wexelblat) writes: > >I am planning to put together a small replacement for wind.o for 3B1 > >systems that have pitched UA/wind.o. > > >Please email me your suggestions, or post followups to comp.sys.3b1. > > Personally, I would *love* to just see a wind.o replacement that allows > access to the bottom 4 lines of the screen (as someone else suggested). > > ||||Boyd Ostroff / Tech Director / SUNY Oswego Dept of Theatre / 315-341-2987 > ||||Sys Admin at cboard.UUCP / Serving the Performing Arts / 315-947-6414/8N1 > ||||ostroff@oswego.oswego.edu / cboard!ostroff@natasha.oswego.edu Well, you won't get it from me! :-> (anyone else remember "The Prisoner"?) I have no intention of re-engineering the complete wind.o. All I'm going to do is provide something that allows the console to 1) screen blank 2) have a cursor (I like cursors) 3) Be able to back-space properly (what's the deal, dudes?) 4) handle ksh emacs-mode line editting (stop nuking the end of my line!!) 5) Do enough smart-terminal stuff to run less and vi/emacs/ex-open-mode 6) Anything else I get around to (or someone bribes me to do No windows, no icons, no menus, no pointers! If I want a WIMP, I'll go see my MGR (can I say that :-?). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- David Wexelblat | dwex@mtgzz.att.com | I asked her her name. AT&T Bell Laboratories | ...!att!mtgzz!dwex | She said her name was 200 Laurel Ave - 4B-421 | | 'Maybe' Middletown, NJ 07748 | (201) 957-5871 | --Damn Yankees
ostroff@Oswego.EDU (Boyd Ostroff) (05/04/91)
I wrote: >> Personally, I would *love* to just see a wind.o replacement that allows >> access to the bottom 4 lines of the screen (as someone else suggested). And dwex@cbnewsj.att.com (david.e.wexelblat) writes: >Well, you won't get it from me! :-> (anyone else remember "The Prisoner"?) >I have no intention of re-engineering the complete wind.o. I guess without source it's pretty tough, but it seems that there must only be a couple bytes somewhere that have to be changed to accomplish this. I (and probably others) just want the ability to use the same ugly windows ANYWHERE on the screen, without a useless no-mans-land at the bottom! I guess I need to learn how to do some serious hacking with adb... >No windows, no icons, no menus, no pointers! If I want a WIMP, I'll >go see my MGR (can I say that :-?). I wrote a little package called "wlogin" a couple years ago which just gives you simple, overlapping 24x80 text windows in a tiny font. It doesn't need wmgr, smgr, ua or anything and compiles to only a couple KB. If anyone is interested, I can (re)post it. MGR sounds neat, but I'm reluctant to hack at my hardware and I would be happy with what I've got if I could just get at those bottom 4 lines! If I want icons, menus and all that stuff, I'll use my Mac IIcx :-) |||| Boyd Ostroff / Tech Director / SUNY Oswego Dept of Theatre / 315-341-2987 |||| Sys Admin at cboard.UUCP / Serving the Performing Arts / 315-947-6414/8N1 |||| ostroff@oswego.oswego.edu / cboard!ostroff@natasha.oswego.edu
dt@yenta.alb.nm.us (David B. Thomas) (05/04/91)
dwex@cbnewsj.att.com (david.e.wexelblat) writes: >I am planning to put together a small replacement for wind.o for 3B1 >systems that have pitched UA/wind.o. I think you would do better to concentrate on building the features you want into mgr. For one thing, mgr writes directly to the video RAM, so if you were running a clock program (say) then a separate screen blanker wouldn't help. The next time something is drawn to the screen, it shows up. I'm currently working on some extensive mgr hacks. Here's the status so far: 1. I already have it start up from init when the system is booted and stay running until shutdown. When you want to log in, you just draw yourself a window and get a login prompt. Once you're in, a quickie utility (which I have yet to write) could make you as many extra windows running shells as you want. Nifty, eh? 2. The next step is to implement screen blanking. It's not too hard...roughly: select (with timeout) if (select returned due to kb or mouse) { time (&lasthit); if (isblanked) unblank(); } else { time (&now); if (!isblanked && now - lasthit > blanktime) { isblanked = 1; blank(); } The only tricky part is that the rest of the code needs to respect the blanked status, and only write changes to the memory images of the windows, and not to the screen. But I'll get it! 3. My new job has me writing bit blit routines in assembly languages all day long. What's one more? I'm going to code all of mgr's bitblits in 68010 assembler and get this baby cookin'. little david -- Unix is not your mother.
john@chance.UUCP (John R. MacMillan) (05/06/91)
[in reference to screen blanker for MGR] |The only tricky part is that the rest of the code needs to respect the blanked |status, and only write changes to the memory images of the windows, and not |to the screen. But I'll get it! One way to do this at the cost of some memory is to have memory for a screen, and switch the pointer that the bitblt routines write through to point at this memory when the screen is blank, or the real screen the rest of the time. (``All problems in computer science can be solved by adding another layer of indirection'' -- Unknown). So the blankout routine would look like: - copy video_screen to save_screen - set screen = save_screen And to unblank: - copy save_screen to video_screen - set screen = video_screen |3. My new job has me writing bit blit routines in assembly languages all day |long. What's one more? I'm going to code all of mgr's bitblits in 68010 |assembler and get this baby cookin'. Yeehaw! I'll name my first-born David...
dwex@cbnewsj.att.com (david.e.wexelblat) (05/06/91)
In article <1991May4.062447.7923@yenta.alb.nm.us> dt@yenta.alb.nm.us (David B. Thomas) writes: > dwex@cbnewsj.att.com (david.e.wexelblat) writes: > > >I am planning to put together a small replacement for wind.o for 3B1 > >systems that have pitched UA/wind.o. > > I think you would do better to concentrate on building the features you want > into mgr. For one thing, mgr writes directly to the video RAM, so if you > were running a clock program (say) then a separate screen blanker wouldn't > help. The next time something is drawn to the screen, it shows up. > [ stuff deleted] > > little david > -- > Unix is not your mother. There are a couple of reasons I want to do this: 1) I don't want MGR running except when I am logged (my personal preference). Given that, I need screen blanking outside MGR. 2) There are times when MGR doesn't work (e.g. you hack on MGR, and it breaks). If that is the only way to get into the system, you're dead. 3) MGR has a lot of overhead in terms of disk use. If your disk swallows a file (e.g. grows a bad block), you may lose a critical file, and you can't log in. Either you keep a spare on disk, and copy it over after booting off the floppy, or you restore a backup. With lots of possible files to get nuked, I want another way in. If a bad block eats my driver, the console will still work as it does now. And I just have to keep one spare file on the hard disk. 4) With a small driver, you can build a floppy unix with it already loaded in, like Lenny did for the tape driver. That way, if your hard disk gets badly trashed, you can get more and vi working with very little restoring actually done (you can put them on your floppy file system, if you have room. Anyhow, that's how I want to do it :->. If you want to use the result, that's fine. If not, that's fine too. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- David Wexelblat | dwex@mtgzz.att.com | I asked her her name. AT&T Bell Laboratories | ...!att!mtgzz!dwex | She said her name was 200 Laurel Ave - 4B-421 | | 'Maybe' Middletown, NJ 07748 | (201) 957-5871 | --Damn Yankees
dwex@cbnewsj.att.com (david.e.wexelblat) (05/06/91)
In article <1991May4.062447.7923@yenta.alb.nm.us> dt@yenta.alb.nm.us (David B. Thomas) writes: [stuff deleted] > > 3. My new job has me writing bit blit routines in assembly languages all day > long. What's one more? I'm going to code all of mgr's bitblits in 68010 > assembler and get this baby cookin'. > > little david > -- > Unix is not your mother. Are you away of the loop-mode instructions for the 68010? They are discussed on the last few pages of the 68000-68008-68010 book from Motorola. I did some testing, and for long copies (> ~100 bytes) they are a whole lot faster. Apparently the compiler doesn't use them. I wrote a memcpy()-type routine, and compiled it with and without the optimizer, and it did not use these instructions. The libc.a versions do use them, so either these were hand-coded in assembler, were hand optimized, used a different compiler, or I'm missing something. The MGR bitblt could be sped up a log just by using these instructions. The way they work (this is from memory; my book is at home) is as follows. Given a normal copy function: for (i=100; i > 0; i--) *dest++ = *src++; the compiler outputs something like: mov.l &100,%d0 mov.l dest,%a0 mov.l src,%a1 top: mov.b (%a1)+,(%a0)+ sub.l &1,%d0 bgt top Convert this to mov.l &100,%d0 mov.l dest,%a0 mov.l src,%a1 top: mov.b (%a1)+,(%a0)+ dbf %d0,top and the 68010 read this as loop mode (due to its prefetch), and does not fetch the move or branch instructions again, saving 4 memory accesses (1 for mov.b, 1 for sub.l, and 2 for bgt). This is a big win. Note that it only works for branches with a negative displacement of 4 (i.e. one instruction before the dbxx), which happens to be ideal for copies. Anyhow, I thing this would make a huge improvement to MGR, since it showed me approx 10 times the performance on a quick 1000-byte-copy benchmark. Check it out. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- David Wexelblat | dwex@mtgzz.att.com | I asked her her name. AT&T Bell Laboratories | ...!att!mtgzz!dwex | She said her name was 200 Laurel Ave - 4B-421 | | 'Maybe' Middletown, NJ 07748 | (201) 957-5871 | --Damn Yankees