[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] libs...
> Which brings us back to the initial point:
> we need stv52 to become real VT100 to avoid having to deal with un-
> cooperative admins.
I agree. (Actually, it would be VT102, but that's a superset. <g>) I'm trying
to implement it in vconsd at the moment - I'll churn out another beta when I
can get it to a usable state. I would also like to see TosWin-II implement
proper emulation of vt100 (including the CR-LF linefeeds); I know it's
emulation is far from complete, looking at the /* TODO: */ parts in the source
code. ;)
> Let's face it: MiNT is probably the only platform on this planet that has
> _no_ VT100 emulation; everybody and their mom has VT100, so basically, people
> never have to play nicie to their admin. Why should we?
Fair enough. The windowing stuff looks like it might be, uh, interesting to
implement, but I can see vt100 or 102 making an ncurses-based package a little
quicker. Who knows, maybe even vim will run at a usable speed. ;)
Much of the base of vconsd's vt100 parser will be lifted from TosWin, but many
of the specifics will need to be changed owing to vconsd's more optimised way
of working. It's proving interestingly difficult to get *full* information on
the terminal protocol, but the basic principle is pretty simple.
I'm a little concerned about vconsd growing in size owing to supporting both
these emulations. In particular, we can't really lose st52 compatibility
completely - all the native Atari apps use it. So, codes in stv52 that are not
precluded by codes from vt100 will be kept. I'm still trying to work out how
many of these there are...
In short; I'm working on it, and as I've had to cancel my Florida visit owing
to circumstances beyond my control :(, I will at least have the time to give it
my full attention.
I'm also concerned about two other things: The fatal error on shutdown... IMO
as least partly the AES's fault... what the *hell* does it do to the tty?!... I
think the error is connected in some way to the problems with the console tty
caused when N.aes is started as a login shell (the old "aes user" approach,
inadvisable anyway because starting the shell - aes - again really confuses
things).
However, there is also an issue in that when vconsd is killed, it doesn't seem
to behave totally as it ought to. In particular, it doesn't change back to the
console screen, which might be a rather good idea!... I can fix that, at
least, and more closely scrutinise the way it shuts down. Possibly it is
vconsd's fault *as well*. :)
That would allow me to issue a shutdown command from a virtual console, and not
have to worry about *very* rapidly hitting Alt-F10 to restore the screen. I
want vconsd to be fully restartable and killable - at the very least it'll make
my development easier. ;)
Comments, anyone?
--
.[ Weird person,... ].[ -:*:- Steven Moore -:*:- ].[ ...by appointment. ].
.[ smooreg@essex.ac.uk ].[ ICQ #: 29020448 ].[ http://sentroid.tsx.org/ ].
[ The taglines are out of order. We apologise for the inconvenience. ]