Large Capital Letters in BASIC

[Casey]

Is it possible to access the large capital character definitions and use them in BASIC or Extended BASIC? I could see some definite uses for making titles or instructions stand out, and replace the lower case character set with the large capitals from the title screen. Anyone ever done that?

[+chue]

In Extended Basic, you can use CHARPAT to store the character patterns in a string variable.

This example grabs all of the uppercase definitions and uses them to redefine the lowercase 'a' character:

10 DIM X$(25)
20 FOR I=0 TO 25
30 CALL CHARPAT(65+I,X$(I))
40 NEXT I
50 PRINT "aaaaaaaaaaaaaaaa"
60 FOR I=0 TO 25
70 CALL CHAR(97,X$(I))
80 NEXT I
90 GOTO 60

Edited July 18, 2017 by chue

[Casey]

Sorry, I may have not been clear in what I meant. There are 2 sets of large capital letters built into the TI. One is the set you see when you are in TI BASIC or most other modules. The other is the set on the master title screen when you turn the computer on. The initial screen in TI Invaders is an example of a game that uses both fonts at the same time. It's that kind of thing I'd like to do in BASIC.

[+chue]

Ah, I missed that. No worries.

[+Lee Stewart]

There are three character sets stored contiguously in GROM 0:

 

Character Set Address ASCII Codes Bytes/Char

----------------------------------------------- ------- ----------- ----------

Standard (the large caps you seek), 04B0h 32 – 95 8

Small Capitals (capital letters used by Basic), 06B0h 32 – 95 7

Lowercase (actually, small caps), 0870h 96 – 126 7

 

It is easy enough to read these tables in Assembly Language. I am not sure how you would do it in Basic. They are listed in Heiner Martin’s TI Intern (available in the Development Resources sticky thread, post #1), pages 105 – 107 and 127 – 128. The GROM address of the three tables is 04B0h – 0948h.

 

The first character set can be read as is because it has 8 bytes/char. However, the other two sets are stored with only 7 bytes/char. For those, you must insert a zero byte in front of each pattern.

 

...lee

[RXB]

Using RXB:

100 CALL CLEAR
110 PRINT "WORKING..."
120 A=1204! A is the address in decimal of Hex >04B4
130 FOR C=32 TO 95! This counts standard characters 32 to 95
140 CALL MOVES("G$",7,A,D$)! Moves 7 bytes from GROM address in A to STRING D$
150 FOR F=1 TO 7! Count to fix from HEX to Decimal
160 R=ASC(SEG$(D$,F,1))+32! R is adjusted value of HEX converted to Decimal
170 NEXT F! Counter of string position
180 E$=E$&"00"! Adds in null bytes to make a full character definition
190 A=A+7! Increments A to next character definition in GROM
200 CALL CHAR(C,E$)! Load new definition of character
210 PRINT CHR$(C);
220 NEXT C
230 END

[S1500]

After all these years, how did I not notice that there's two sets of all-capitals fonts? Huh.

[sometimes99er]

Using RXB:

100 CALL CLEAR
110 PRINT "WORKING..."
120 A=1204! A is the address in decimal of Hex >04B4
130 FOR C=32 TO 95! This counts standard characters 32 to 95
140 CALL MOVES("G$",7,A,D$)! Moves 7 bytes from GROM address in A to STRING D$
150 FOR F=1 TO 7! Count to fix from HEX to Decimal
160 R=ASC(SEG$(D$,F,1))+32! R is adjusted value of HEX converted to Decimal
170 NEXT F! Counter of string position
180 E$=E$&"00"! Adds in null bytes to make a full character definition
190 A=A+7! Increments A to next character definition in GROM
200 CALL CHAR(C,E$)! Load new definition of character
210 PRINT CHR$(C);
220 NEXT C
230 END

 

It does not seem to work correctly. Since "the large caps" has 8 bytes and not 7 bytes, see Lee's post, that may be part of the problem.

 

In the case of working with 8 bytes (instead of 7), using CALL MOVE (instead of CALL MOVES) would probably make it much simpler, shorter and quite fast.

 

 

[senior_falcon]

You can do this using XB256. You need to be in screen2 with CALL LINK("SCRN2") and then CALL LINK("CHSETL") will replace the 7 pixel high font with the 8 pixel one.

 

I just discovered that the XB256 manual is incomplete. There is another subprogram: CALL LINK("CHSETD") which will load a character set with true lower case letters that have descenders on the p, y, etc.

[RXB]

 

It does not seem to work correctly. Since "the large caps" has 8 bytes and not 7 bytes, see Lee's post, that may be part of the problem.

 

In the case of working with 8 bytes (instead of 7), using CALL MOVE (instead of CALL MOVES) would probably make it much simpler, shorter and quite fast.

 

 

There is no CALL MOVE in RXB the only MOVE works in edit mode for lines and came from GK XB.

 

LOL now I see the problem!!!

 

My conversion from HEX to Dec failed.

Edited July 18, 2017 by RXB

[sometimes99er]

There is no CALL MOVE in RXB the only MOVE works in edit mode for lines and came from GK XB.

 

Hmmm. Okay. Guess the examples in the manual fooled me.

 

Anyways, a CALL MOVES (from GROM to VDP) should then be able to do the trick with "the large caps" in a sec or so.

 

[sometimes99er]

Is it possible to access the large capital character definitions and use them in BASIC or Extended BASIC? I could see some definite uses for making titles or instructions stand out, and replace the lower case character set with the large capitals from the title screen. Anyone ever done that?

 

Here are plain BASIC programs that simply redefine the characters to "the large caps" using CALL CHAR.

 

 

 

[Tursi]

 

 

The GROM address of the three tables is 04B0h – 0948h.

 

It's worth noting that the actual location of the characters in GROM can vary slightly -- when I did the loader for the multicarts I wrote code to look up the actual address by parsing the GROM branch vector. It was hacky but it worked.

 

Also, completely unimportant, but the 99/4 actually has an even smaller small capitals character set than the 4A, stored only 6 bytes to a character IIRC. (I remember I had to deal with a difference in count).

[Casey]

Thanks all! Good stuff. I figured you'd need assembly language to actually access the character definitions, but a CALL CHAR program works just as well, if not a bit slow.

 

Since we're on the topic of character sets, the Extended BASIC addendum comes with a small program that creates "lowercase" capitals for the 99/4 from the uppercase character definitions. They are... interesting. The 99/8 had yet another font - I still don't think the new lowercase letters are attractive, but they are better than the short capitals the 99/4A has.

[senior_falcon]

[sometimes99er]

On 7/18/2017 at 5:23 PM, RXB said:

LOL now I see the problem!!!

 

My conversion from HEX to Dec failed.

Okay. Here's what I meant for RXB.

 

100 for c=32 to 95::print chr$(c); ::next c::print : :
110 call moves("GV",512,1204,1024)
120 input i$
 

Edited February 18 by sometimes99er
Picture lost due to site update. New picture uploaded.

[sometimes99er]

Since we're on the topic of character sets, the Extended BASIC addendum comes with a small program that creates "lowercase" capitals for the 99/4 from the uppercase character definitions. They are... interesting. The 99/8 had yet another font - I still don't think the new lowercase letters are attractive, but they are better than the short capitals the 99/4A has.

 

Nice one. It's almost an okay small caps for the TI-99/4. The N should have been redefined as it looks like an M.

 

Works surprisingly well on the TI-99/4A, but off course you don't need it there. Almost a blueprint.

 

 

[RXB]

 

Hmmm. Okay. Guess the examples in the manual fooled me.

 

Anyways, a CALL MOVES (from GROM to VDP) should then be able to do the trick with "the large caps" in a sec or so.

 

Good catch I should not be up all night writing docs.

[sometimes99er]

There are three character sets stored contiguously in GROM 0:

 

Character Set Address ASCII Codes Bytes/Char

----------------------------------------------- ------- ----------- ----------

Standard (the large caps you seek), 04B0h 32 – 95 8

Small Capitals (capital letters used by Basic), 06B0h 32 – 95 7

Lowercase (actually, small caps), 0870h 96 – 126 7

 

 

It's funny how the lowercase small caps in the TI-99/4A takes up 7 bytes per character, when only 5 bytes are needed (per character). I suspect true lowercase was planned and space allocated. And then maybe Marketing found true lowercase to be too professional.

 

GfxRip:

 

[+mizapf]

The small caps have the advantage that they look like the standard font of the TI, but smaller, so this could be useful in games (like Parsec); on the other hand, maybe they did not want to encourage people to use lower-case, since everything in the TI world seems to be uppercase (up to the assembler language).

[sometimes99er]

The 99/8 had yet another font - I still don't think the new lowercase letters are attractive, but they are better than the short capitals the 99/4A has.

 

The TI-99/8 font is very similar to the TI-99/4.

 

[Casey]

Wow you are right there. I didn't realize just how similar they were! A rather curious choice indeed!

[Tursi]

What they chose to change there is interesting...!

[+TheBF]

There are three character sets stored contiguously in GROM 0:

 

Character Set Address ASCII Codes Bytes/Char

----------------------------------------------- ------- ----------- ----------

Standard (the large caps you seek), 04B0h 32 – 95 8

Small Capitals (capital letters used by Basic), 06B0h 32 – 95 7

Lowercase (actually, small caps), 0870h 96 – 126 7

 

It is easy enough to read these tables in Assembly Language. I am not sure how you would do it in Basic. They are listed in Heiner Martin’s TI Intern (available in the Development Resources sticky thread, post #1), pages 105 – 107 and 127 – 128. The GROM address of the three tables is 04B0h – 0948h.

 

The first character set can be read as is because it has 8 bytes/char. However, the other two sets are stored with only 7 bytes/char. For those, you must insert a zero byte in front of each pattern.

 

...lee

 

I had never played with GROMs before so I tried making a CHARSET word by reading the GROMs.

I found a neat trick in the SPECTRA.a99 file that moves directly from GROM to VDP.

 

I could simplify it a bit because my kernel has a sub-routine to set VDP write mode, so I did the same for GROM address,

It's a cool hack using 2 auto-incrementing devices.

 

Van Haartelijke dank Filip Van Doren (big Dutch thank you)

CROSS-ASSEMBLING
l: GRMWA!
        R0 GRMWA @@ MOVB,     \ Set GROM source address
        R0 SWPB,
        R0 GRMWA @@ MOVB,
        RT,

CODE: GVMOVE ( grom_addr vdp_addr cnt -- ) \ GROM->VDP direct move
        R0 POP,
        WMODE @@ BL,             \ Set VDP target address
        R0 POP,
        GRMWA! @@ BL,            \ Set GROM source address
@@1:    GRMRD @@ VDPWD @@ MOVB,  \ Copy from GROM to VDP
        TOS DEC,                 \ count in TOS register (R4)
        @@1 JNE,
        TOS POP,
        NEXT,
        END-CODE

Then in Forth I just had to do

HEX
: BIGCAPS  ( -- ) 4B0 PDT  200 GVMOVE  ;

But when I tried it my letters were scrambled. ?

 

I found the address for the start of the Font in GROM, in Classic99, is >04B4.

And with that it works great.

 

Is there a way to find where the Font data resides in the system?

 

BF

[+Lee Stewart]

...

But when I tried it my letters were scrambled. ?

 

I found the address for the start of the Font in GROM, in Classic99, is >04B4.

And with that it works great.

 

Is there a way to find where the Font data resides in the system?

 

BF

 

Well, the GPL jump table starts at >0010 in GROM 0. The “Load Standard Character Set” routine vector is at >0016. All of these vectors are “BR @address” GPL instructions, which will be >4000 + GROM address. If you extract that address and add 5 to it, the next 2 bytes will be the address of the Standard Character Set table. From Heiner Martin’s book:

Addr  Code  Source Instructions
----  ----  ---------------------------------------
0016  4393  BR   GROM@>0393
 ...
0393    31  MOVE >0200 TO VDP*>834A FROM GROM@>04B0
0394  0200
0396  B04A
0398  04B0

For Classic99 and my TI-99/4A (I think):

Addr  Code  Source Instructions
----  ----  ---------------------------------------
0016  4396  BR   GROM@>0396
 ...
0396    31  MOVE >0200 TO VDP*>834A FROM GROM@>04B4
0397  0200
0399  B04A
039B  04B4

Of course, this presumes that the jump table always starts at >0010 in GROM 0. All I know for sure is that it does so in the above two instances.

...lee