[comp.sys.atari.st] Subject: Re: UniTerm discussion

K538915@CZHRZU1A.BITNET (03/18/88)

In article <496@csvax.liv.ac.uk> sqrkl@csvax.liv.ac.uk (Richard k. Lloyd) writes
>Firstly, Simon, I'm sorry about posting this up to the net, but I'm
>not convinced that I have access to your UUCP/Bitnet addresses...
You do, just try....
...........
>>If you want to design 6 fonts, three in a 4x4 cell, and the other half
>>in a 4*2.5 (:-)) cell, your welcome.  Seriously, designing fonts is a
>>LOT of work and adding more fonts means the program gets larger
>Obviously, this is a limitation of the Atari ST. I wrote a font designer
>program for my Archimedes and designed a complete (256 char, including
>the digital chars) character set that uses 8 * 10 pixels in about 2 hours.
>I don't need 6 fonts because I've written ARM routines that support all
>double height/double width modes on a VT100 (that took about 2 days of
>coding). I think that 6 fonts is over the top - you should be writing
>code to expand the original set (so you need only 1 font).

You're jumping to conclusions again....the scheme I use in UniTerm is:

HiRes:

Font(w*h)|  8*8 | 8*16  | 16*16 | 16*32 |  5*8 | 5*16  | 10*16 | 10*32 |
---------|-------------------------------------------------------------|
Normal   | N8*8 | N8*16 | N8*8  | N8*16 | N5*8 | N5*16 | N5*8  | N5*16 |
Special  | S8*8 | S8*16 | S8*8  | S8*16 | S5*8 | S5*16 | S5*8  | S5*16 |
Intern.  | I8*8 | I8*16 | I8*8  | I8*16 | I5*8 | I5*16 | I5*8  | I5*16 |

The 8 pixel high fonts are used for the 49 line mode, the double height/
width fonts are generated by from the smaller fonts, each of the character
sets are a full 128 characters. Transforming the 5 pixel wide fonts into
8 pixel wide fonts justs looks too ugly.

MedRes:

Font(w*h)|  8*8 | 16*8 | 16*16 |  5*8 | 10*8 | 10*16 |
---------|-------------------------------------------|
Normal   | N8*8 |   ?  | N8*8  | N5*8 |   ?  | N5*8  |
Special  | S8*8 |   ?  | S8*8  | S5*8 |   ?  | S5*8  |
Intern.  | I8*8 |   ?  | I8*8  | I5*8 |   ?  | I5*8  |

Since the trick with magnifying the font can't be done here, 3 16*8 fonts
and 3 16*5 fonts would have to made, something that I haven't done mainly
because of the additional ~10 kB memory (and size of the executable) this
would use.

[Just a remark on the side for the benefit of anybody still reading this,
 a number of people have asked me why their 'font-changers' don't effect the
 font UniTerm uses as 'Normal' font, UniTerm gets the address of the two
 system fonts it uses via the line-a variables, if the 'font-changer'
 changes these values everything should be ok. If the 'font-changer'
 changes the fonts the BIOS uses, you're out of luck, since UniTerm doesn't
 use the BIOS for character output ]

>>The vector
>>drawing is fast enough for 9600 baud, at least I've never had any

>I disagree. TERMINAL/ST version 2.1 has vector drawing at about twice the
>speed of yours (it was written in this department by a lecturer).

Richard, when you measure something, you say how you mesured it and what
you mesured. As an example: are you comparing drawing speeds  using the
playback function or the  zoom mode or just simply with vectors being
sent by a host computer?

Anyway there was an error in the code that made the vector drawing in
playback mode and while receiving from the RS232 port slower than
necessary (but still > 2000 byte/s, that's why I didn't notice it),
the new cursor postition was calculated after every received byte,
instead of after each complete vector.
(BTW I didn't claim it can't be done faster, just that it's not so slow
that it is something that would have to be improved tomorrow)

>>If you hold down the <Alternate> key, you've essentially got a one key
>>NO SCROLL key, anyway in the more recent versions you can actually put

>That's funny. I'm running UniTerm V2.0a 020 and the Alternate key doesn't
>do an awful lot (I haven't reconfigured the keyboard in any way).

You naturally still have to toggle it on/off with <Z>.....


>DCL on a VAX/VMS system already has an SLE, so I disabled it...with annoying
>results if I accidentally hit INSERT (this happens on V2.0a 020 as well).

...........and I didn't say that it doesn't happen with V2.0a 020, did I?

>>Wrong! No VT1XX, VT2XX or VT3XX compatible terminal works this way,
>>all clear the screen and home the cursor. The command set of D*C

>Again, rather strange. I am using a PT100 (Plessey VT100 compatible) and
>I can quite easily switch in and out of 132 column mode without a clear
>screen/home cursor (although the terminal can be configured to do so via
>the SETUP options).

With other words it isn't VT100 compatible, is it?

>Where does this mixed length business fit in ? I've never seen a terminal
>that has different screen widths on the same display at the same time !

May I quote your original letter:
|6) Retain the screen display when switching from or to 132 column mode, rather
|   than clearing the screen and homing the cursor.

and now the Oxford Dictionary:

    retain .....keep in place, hold fixed.....

Sorry, but you didn't say 'adjust' or 'truncate', you said 'retain', and
if you 'retain' a 132 column line it stays a 132 column line.

As I've said before truncating or adjusting the display is trivial, even
if not standard and I might implement it if there's enough demand.

>Again, V2.0a 020 DOES NOT switch the mouse on when it is moved. The I-bar
>only appears when you click on the mouse button first.

...... I never said it did, did I?

Richard, it might be worth getting used to the fact that you don't always
have the latest version of a program and that people don't just fall over
dead because the grand majestro wants something.

>I've got the 'intelligent listen-back' cursor movement routines in the
>Macintosh VT100 Terminal Emulator I wrote a couple of months ago. I'll
>send you either the (Turbo) Pascal source or a 'pseudocode' version of it
>if you want. It avoids the nasty skipping past tabs problem that all
>move mouse/click/work out diff/send arrow codes systems I've ever seen in
>ST and Mac terminal emulators.

The problem is that the 'skipping over tab problem' isn't the only problem...

>By the way, you might have worked out that I'm working on a VT100 terminal
>emulator for Acorn's wonderful new Archimedes machine. I bought one about
>10 weeks ago and ARM code is an absolute joy to write.

How nice to have enough money for things like that (I can't even afford
a printer for my ST).

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