🚀 go-pugleaf

Ah! For once Jos and I in total agreement...
Anyway I was going to write something along the same lines, so now just
a few comments:

t68@nikhefh.hep.nl (Jos Vermaseren) writes:
>To make another BIOS traphandler doesn't look like a solution, as most of
>the screen writing time sits in the trap handler and the saving of registers
>that comes with it.

Most of the trivial BIOS calls take 0.08 to 0.1 mS (measured with calls
from CCD/OOS Pascal and assembler), so the time spent just doing the trap
is in the same order of magnitude as a fast screen output routine.

>The reason that some programs like Tempus have such a fast screen has several
>reasons:
..........
>2:      In Tempus the font files have been reshuffled to make the order of
>        the pixels different from the GEM format.

As far as I know they use DEGAS format fonts, which means you can address
the scanlines of the font with the address register relative with post-
increment addressing mode (with other words: you save an adda.w instruction).
DEGAS format fonts naturally have other limitations.

>What is missing from the BIOS would be an equivalent of Cconws. Let us call tha
>Bconws. It would have to accept a device number and the number of characters
>in the string because the raw output should not be stopped by a 0x00. That
>would avoid the traphandler for most of the output....................

It yould be nice if such a thing existed for input too.

>..................................................If you install such an
>extra function your screen will become much faster than the Bconout(5,c) call.
>All other BIOS calls will become a little slower then, unless you find a
>version independent way to copy the BIOS jumptables at the installation of
>your program.

And Tempus naturally (well at least I assume so) doesn't do single character
output, it outputs strings.

The problem with BIOS traps slowing things down is a problem in UniTerm too,
one thing I did was to pack as much as possible in to one call of the XBIOS
supexec function: it returns the number of characters in the RS232 buffer,
if a key has been pressed, the state of the DCD and Break bits and a mouse
status bit, all with the overhead of one trap. On the other hand there is
no way  to  read more than one character at a time from the serial port
without rewriting the RS232 handler, so you still have to do one trap per
character. Matter of fact the most annoying thing is, that due to the fact
that the kbshift variable isn't accessible legaly in pre Blitter-TOS ROM's,
UniTerm spends a bl**dy 0.08 mS per main loop just finding out if somebody
pressed <CapsLock>.


                                Simon Poole
                        UUCP:   ...mcvax!cernvax!forty2!poole
                        Bitnet: K538915@CZHRZU1A