From nox  Sun Jan 15 19:53:14 1995
Subject: virtual console(s) (v0.8)
From: Juergen Lock <nox@jelal.hb.north.de>

here is something you've all been waiting for... virtual terminals
for MiNT :-)  now you can...

 use up to 10 shells/whatever without magnifying glasses or 19" screens
 run GEM on the console, top on ttyv1 and gdb' a GEM program from ttyv2...
 send MiNTs debug output to another terminal than the debugged program
 run cu, rlogin-over-ppp, etc. at 19200 bps (or 38400 on modem2)
and actually use the speed, no more crawling GEM terminal windows
eating up all your CPU!
 when some stupid program hangs and MiNT is still alive just switch to
another terminal and send the thing a signal. (ever heared of vp/ix?
oops, wrong CPU...)
 temporarily suspend GEM while you need your cycles for something more
important than polling the mouse in a tight loop...  i.e. just send
SIGSTOP and later SIGCONT, see end of this file.
 show people that its not MiNT that is slow, only GEM :-)  also the
screen writing code in vtdev.c + paint.c is mostly based on MiNTs
fasttext device (including hardware scrolling for all terminals except
console even on vanilla ST), so i guess output is faster than any GEM
window writing could ever get.
 and of course show people what gcc -O2 can do, the days of `if you
want performance do everyhing in assembler' are over i would say...

 how to use:

 this should run ok on any machine where MiNTs /dev/fasttext worked
(worked because you won't need it anymore then) and where
Setscreen (-1, base, -1) allows setting the displayed screen
independent of the one GEM (or VDI actually) writes to.  on some
configurations (currently vanilla ST(e), TT, and falcons with VGA
screen) where it knows how to save/set a complete video mode ttyv1..9
have their own fixed mode like e.g. st-hi, see screen.c for details.
otherwise all terminals have to use the consoles video mode, which can
be slow and a waste of RAM and bus bandwidth when it is some big hi-res
many-colours one...  and then switching modes later makes ttyv1..9
unreadable too, including GEM doing it when configured so in
desktop.inf.  thanx atari there is no standard how to change video
modes independent of GEM...

 there are 4 different versions (make targets) now,

1. vconsd: `standard version'.  if this doesn't work for you you can
still try vconx (always uses only Setscreen), or better yet try to fix
screen.c to know about your video hardware too.  (mail me the changes
or if you need help...)

2. vcons1d: stripped-down version that only knows about characters 8 or
16 pixel high and one plane.  needs either a monochrome mode or screen.c
needs to know how to save/set the palette.  try this if you want a bit
more speed and don't care about colour on text terminals...

3. vconx: like vconsd only with the video mode stuff disabled, try this
one when the others don't work.

4. vcon: another test version that also speeds up console (ttyv0) output.
this is no longer default because there are GEM programs that expect
console writes to always go thru the xcon* vectors, i.e. they hook a
terminal window there and then write to console.  although MiNT has ptys...

 installation:

before `make' make sure filesys.h points to either a recent kernels
file.h (this is a bit of a hack and may no longer work with future MiNTs)
or (if you don't have a newer one by then) use a patched MiNT 1.12
doc/appendix.d, see 1.12-filesys.h-diffs.

then with init simply put something like this into your rc.local:

--------cut------
vt=con
if [ -f /usr/etc/vcons1d ]; then
	echo "starting virtual consoles"
	if nice --20 vcons1d; then
		mv /dev/console /dev/con00
		mv /dev/ttyv0 /dev/console
		vt=vt
	fi
fi
rm /etc/ttytab
ln /etc/ttytab.$vt /etc/ttytab
-------------

 (the mv.s are for programs that open /dev/console so they get the
new one... writing to the old one should be no problem, but reading is.)

 ttytab.vt has entries for console and ttyv1..9 (of course not all of
them need be `on' :), ttytab.con only has the original console.  and
remember GEM can only run on console...  without init do something
similar in mint.cnf (and then set CON= the new console).  of course
without init you'll have to do all its work yourself, i.e. put gettys
or shells etc. on the new terminals, respawn them when exited...
see runtt.c.

 you can also add this to termcap:

stv52|MiNT virtual console:\
    :ti=\Ev\Ee\Ez_:am:te=\Ev\E. \Ee\Ez_:\
    :al=\EL:bs:cd=\EJ:ce=\EK:cl=\EE:cm=\EY%+ %+ :co#80:\
    :dl=\EM:do=\EB:ho=\EH:it=#8:le=^H:\
    :li#25:se=\Eq:so=\Ep:up=\EA:nd=\EC:\
    :rs=\Ez_\Eb@\EcA:\
    :ue=\EzH:us=\EyH:md=\EyA:me=\Ez_:mr=\Ep:\
    :ms:pt:\
    :sr=2*\EI:\
    :sf=2*^J:\
    :kb=^H:kl=\ED:kr=\EC:ku=\EA:kd=\EB:\
    :kI=\EI:kh=\EE:kP=\Ea:kN=\Eb:\
    :k0=\EY:k1=\EP:k2=\EQ:k3=\ER:\
    :k4=\ES:k5=\ET:k6=\EU:k7=\EV:k8=\EW:k9=\EX:\
    :s0=\Ey:s1=\Ep:s2=\Eq:s3=\Er:\
    :s4=\Es:s5=\Et:s6=\Eu:s7=\Ev:s8=\Ew:s9=\Ex:\
    :vi=\Ef:ve=\E. \Ee:vs=\E.":\
    :cQ=\E. :cV=\E.":cR=\E.!:
stv52c|MiNT virtual console (k?=scancodes):\
    :kb=^H:kl=#K:kr=#M:ku=#H:kd=#P:\
    :kI=#R:kh=#G:kH=#O:kP=#I:kN=#Q:\
    :k0=#D:k1=#;:k2=#<:k3=#=:\
    :k4=#>:k5=#?:k6=#@:k7=#A:k8=#B:k9=#C:\
    :s0=#]:s1=#T:s2=#U:s3=#V:\
    :s4=#W:s5=#X:s6=#Y:s7=#Z:s8=#[:s9=#\\:\
    :tc=stv52:

(and add a new console type to gettytab that sets tt i.e. TERM =stv52),
then less, elvis etc know how to do underline/boldface text and use
different cursors for (elvis) command/input/replace mode...  stv52c is
the same for programs that use scancodes instead of escape sequences
(like the TOS/MiNT elvis before 1.7, with MiNT 1.7 understands both).
oh and scancodes are not portable btw, they cannot work over sockets
or serial lines which means on hosts you cu' or telnet/rlogin to
stv52c is useless.  and if you have something that still hasn't heared
of TERM or termcap yet but is hardcoded for vt100 try running it in
a `screen' session (-> man screen, you can also install it locally
on the MiNT box and then do the rlogin/whatever.)

 also depending on the video mode lines and columns can differ, if you
have programs that don't know about TIOCGWINSZ/SIGWINCH, (or hosts that
don't i.e. *sigh* SYSV :) adjust the numbers after li# and co#, for
example on a falcon with VGA screen ttyv1..9 have 30 lines -> li#30.
there are also programs that don't look in termcap but check environment
variables LINES and COLUMNS (also on SYSV...?)  and there are probably
still old TOS binaries around that only look in linea, they will always
get the size of the console. (and usually be CPU hogs too because of
TOS polling and single-byte IO so thats not the only reason to get
rid of them.) one last special case is for those GEM terminal windows
accessed as /dev/console instead of thru ptys, because of them ioctl
TIOCGWINSZ now returns `size unknown' i.e. ws_row and ws_col == 0
for ttyv0 (console) if its xconout vector changed since startup.
(does Gemini know ptys now?  some time ago it didn't...)

 to switch between terminals just hit alt-fkey, f10 is the console.  you
might have to hold down the alt key a little longer sometimes until the
daemon gets to read it, thats because the TOS keyboard interrupt that
MiNT still uses doesn't normally save shift/alt key status with the keys
and certain things like disk IO can still halt the whole system for
noticable time.  when it `bing's at you that means the terminal has no
screen memory because no process has it open, with init then enable the
tty in /etc/ttytab and SIGHUP init (kill -1, tells it to reread ttytab)
or use runtt...  and when it `bing's at you while you type that means
the terminals `keyboard queue' is full, to empty it hit alt-undo.  (if
its empty alt-undo gets passed thru so programs can still use it.)

 new features in 0.7:

1. at special request of one user :) there is another way to `enable'
free ttyvs now:  define a command (execl args) in Makfile to `runtt'
something like a getty (TGETTY), then when you hit ctrl-alt-num(
that is exec'd on the first free ttyv so that you can login there.
note as init doesn't know about ttys used like this (for init they
are still disabled) it still won't respawn anything when you log out
there, this also means your utmp entry would still show you logged in
(the place where programs like `finger' and `last' look), if you want
the daemon update that as well define TGETTYUTMP also.  see Makefile...

2. loadable fonts.  there are some new ioctls to load char bitmaps
and keyboard translations for chars >= 0x80, and there is a small
example program that uses these to load raw bitmap files or monospaced
GDOS (pixel) fonts of the `right' size.  run ttyvfont --h for a
help screen... (and improve it if you like, send me the diffs.)

3. and now for something completely different...

 coping with GEM
(this should probably go in some general MiNT FAQ, at least parts of it)

GEM still is not a nice citizen for a multitasking environment...  once
started you can't shut it down, it does strange things to its tty that
can raise job control signals (SIGTT*), and apparently only in the last
multitos beta GEM no longer sucks up all CPU cycles it can get hold of,
slowing down any parallel processing to a crawl...  and the versions
before multitos have the additional `feature' that they like to run
in supervisor mode for great length of times, effectively stopping
multitasking completely for seconds.

 to get around the last problem install nohog.acc from the minixfs
distribution (also necessary for minixfs update daemon; btw everyone
runnig MiNT should try out minixfs, its just so much better than this
slow and stupid GEMDOS thing...)  to stop the SIGTT* signals (symptom
is a `hanging' GEM) use execgem, it turns off job control (process group)
checks on the console before it starts GEM, see execgem.c.  the only
thing you can do about the wasted cycles is run GEM at lowest priority,
i use this alias (ksh):

	alias 'gem=cd /dev/c; mv nohog.acx nohog.acc ;LESS=-c exec nice -40 u:/home/nox/ksh/execgem'
(or you can even turn off console in ttytab entirely and use something like
	alias 'startgem=(cd /dev/c; mv nohog.acx nohog.acc ;LESS=-c exec runtt -t console nice -40 u:/home/nox/ksh/execgem)'
from another terminal then hit alt-f10)

then when i run other processes at highest priority they get at least a
bit more CPU than GEM. :)  the can't-leave-GEM problem still waits for a
solution, the closest thing is stop it while you don't need it, then it
only takes up memory but no more cycles. (SIGSTOP, continue with SIGCONT.)
or if its not multitos run a .tos program fullscreen from desktop, then
it stops polling and releases some of its memory too, see select0.c.
still GEM should really catch SIGHUP etc. and do a clean exit...
(hey you can even shut down a mac cleanly, or look at X...)

 and thats still not it.  said multitos beta no longer polls everything
but instead it has a race condition that now makes short evnt_timer calls
often `hang' for > 3 min, especially with MiNT >1.08...  if this hits you
the easiest cure is to get the latest MH-MiNT 1.12 (aka FreeMiNT by now),
it has a kludge in select() that hacks around this GEM bug in the kernel.
(what your still waiting for a new multitos release from atari!?
forget it!)  and the built-in GEM in at least TOS 1.(0)4 sometimes
apparently `forgets' to initialize pointers in (M)allocated memory i.e.
often crashes while loading .accs unless, hack #x+1, the kernel is told
to zero everything returned by Malloc for it.  (F_ALLOCZERO bit used by
execgem, also added in MH-MiNT 1.12.)

 and finally another one nothing to do with virtual consoles:  things
like funny screen layout in GF*bugsic programs can sometimes be `fixed'
by setting BIOSBUF=n in mint.cnf.  i already doctored minixfilesystems
with an old SED (diskeditor) on console and fsck on ttyv2...

 but most of the time i just don't run GEM, and i guess now you know why...
	Juergen
