[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.    ]