Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!phigate!prle!prles2!cst!meulenbr From: meulenbr@cst.philips.nl (Frans Meulenbroeks) Newsgroups: comp.os.minix Subject: Re: ST 1.5 patch2.uaa (1/3) Message-ID: Date: 4 Sep 90 06:17:23 GMT References: <29283@nigel.ee.udel.edu> Sender: news@prles2.prl.philips.nl Lines: 54 I5110401%DBSTU1.BITNET@cunyvm.cuny.edu (Kai-Uwe Bloem) writes: >"Felix A. Croes" writes : >>You mean for each virtual console? That is not nesseccary. Instead of >>2 * 32k * no_of_virtual_terminals, only 32k + 32k * no_of_virtual_terminals >>should be needed, if the code is written right. >Yes, that might work. Haven't thought about it yet. But it implies that one >has to copy 64 KB on every virtual console switch, or do i overlook some >points here ? No you don't. If you want to do it decently, you'll require 32k for each screen and 64k to do the hard scrolling in. Otherwise you'll end up in the situation that when switching consoles you'll have to exchange the data between the "real screen" and the "new screen". This will give an administrative hassle to deal with. Not very nice. Still, with the new stvdu, I prefer to add 30 buffers instead of giving up 32k for hard scrolling. The gain here is much more. Of course if you have > 1MB you can have the best of both worlds. >>It might be even better to keep a copy of the characters on the screen in >>memory, instead of a copy of the screen image. The speed penalty should be ver >>small, only the screen buildup after a console switch is much slower. >>Or are you intending to add screen graphics? >I thought about this when when i was about to rework stvdu.c. I decided that >(a) it would be a lot of changes to the existing code. The current virtual > console implementation has not involved that big changes. >(b) maybe there will be screen graphics some time in the future, and then > the whole screen contents must be saved anyway. >However, the much smaller memory allocation for virtual consoles makes it >very interesting for people with memory shortage. It is indeed interesting for people with memory shortage. However, in the future it is quite possible that screen graphics are added to minix. I know someone is busy porting MGR. In that case the effort to keep a copy of the characters is useless. I would suggest not to invest time in this issue. It has little chance of becoming "the" standard. Speaking of virtual consoles. I believe I have 3 different implementations of it. Currently I use the one from Kai-Uwe, because it came with his tty/rs232 port. In the future I might switch to the one from Gordon Irlam, because it looks like that one is going to be the standard on the PC. I haven't studied the various implementations in great detail, but at first glance I saw no big differences between them. On the other hand, I don't know if I really want virtual consoles. I think I prefer something which would allow me to create multiple consoles dynamically. This would perhaps require pty's and the possibility to access the screen memory. -- Frans Meulenbroeks (meulenbr@cst.philips.nl) Centre for Software Technology ( or try: ...!mcsun!phigate!prle!cst!meulenbr)