: You killed my baby?? Exactly how has it stopped working? It's not a very
: complete implementation, only half-a-dozen ANSI commands are supported.
Killed your baby? Why, it seems this one died from neglect ;-)
try typing ESC [ H on the console. Nothing happens.
:
: > o added TERM=elks to /bin/login exported environment.
:
: It's almost worth making sash source a .profile, and putting TERM in there
: instead, since this is where it really should be done.
Yes, but it doesn't cost much at all to put it in login, and we're trying
to get ELKS running a screen editor, and there's only one termcap entry that works,
which isn't ansi and barely vt52...
: The reason bcc wouldn't run was because it was too large (> 64k) to even
: link. This is where the fat has to be trimmed first, before anyone even
: starts to worry about running it.
Yes, but I created a version with the -Mf model that will compile
into less than 64k. So I have a bcc that runs.
I've wondered if it's possible to use
: temporary files in some way, and break down the compiler into multiple
: steps. From memory, this is sort of how minix does it (minix runs more
: than 2 programs to get .c to .o).
That will take a lot of work. I'll post my bcc makefile soon, along with
a working as86!
:
: > o all string functions need rewriting, the libc code is *really* slow.
: > I will rewrite both of these in assembly for speed
:
: I thought these were already done in assembly? They were the last time I
: looked.
As an example, strcat is coded to strcpy(d+strlen(d), ...)
By the time that strlen has finished, the strcat could have nearly completed.
Check it out. Also, the kernel uses for loops rather than memset functions,
which are really slow.
:
: > o dircon and bios tty drivers could use some massaging for vt52/ansi.
:
: There's a couple of issues here, the first (that I mentioned above) is
: that the code is just scratched up and is rather incomplete. Also there
: was a reason for me writing ANSI support into dircon and not bioscon, I
: just can't remember what it is at the moment.
Yeah I agree. But the ANSI or vt52 driver shouldn't care about the
low-level character output method.
:
: > With these mods, ELKS has works alot better, and now runs a full-blown
: > editor using a termcap file.
:
: Sounds like you've done an excellent job with these changes. How much
: change is actually made in the kernel? Is most of it simply changes, or
: new code? If it's new code, how much larger does the resultant kernel
: come out to?
Well, the bell code was 200 bytes or so, and I think most of the other
kernel changes amounted to very little. I see all sorts of areas that the kernel
size can be reduced... Look at the scheduling code for instance. A complicated
nightmare, which round robin scheduling would most like work just fine.
:
: Well done.
:
Thanks. So - do you want me to rewrite the ansi console driver so
that it works? Also, should elks have a ansi as its default console ( I vote yes,
and will do the work....)
Greg
