T40XB and T80XB

[senior_falcon]

 

 

Thought it would be good to make a new thread where these programs can be easily found.

 

First is T40XB which is much more powerful compared to the earlier version. Now you can specify a window on the screen where text will be printed or inputted. Word wrap can be used when printing text. You can load fonts used by the G32 screen, the T40 screen, and the T40 inverted  character font. This can now be a second font that you can use simultaneously with the first.

 

The zipped file contains T40XB, the documents for T40XB, and a folder containing the 60 fonts that will be used in XB 2.8 G.E.M.

Here is a program that loads and displays all 60 fonts from DSK8. Notice that they are loaded to the inverted font location and the text is printed with PRINTI. This lets you have 2 different fonts on the screen at the same time.

10 CALL LINK("T40")
20 FOR I=32 TO 127 :: A$=A$&CHR$(I):: NEXT I
30 CALL LINK("PRINTI",24,1,A$)
32 CALL LINK("SCROLL",3)
35 CALL LINK("PRINTI",24,1,"The quick brown fox jumped over the lazy dog.")
40 FOR I=1 TO 60
45 CALL LINK("PRINT",15,1,"FONT"&STR$(I))
50 CALL LINK("LFONTI","DSK8.FONT"&STR$(I))
60 CALL KEY(0,K,S):: IF S<1 THEN 60
70 NEXT I

Let me know if there are bugs in T40XB or if the docs need additional work.

 

(Edit) - The docs refer to enabling gram at >6000. That was disabled for XB 2.8 G.E.M. and so it will not do anything. I will re-enable it and repost the program. Also, you will see that many of the 60 fonts are not suitable for text mode because they need an 8x8 grid to look right

 

(Edit June 4) I have combined T40XB and T80XB on one disk, the "Betelgeuse" version. From the readme file:

For the “Betelgeuse” and future versions, files for both T40XB and T80XB are included in the package. Both are virtually the same program except that T40XB is designed to use the 40 column mode built into the 9918A VDP; while T80XB uses the 80 column mode that needs special hardware such as the F18A, or you can use the Classic99 emulator with the “80 column hack” enabled.

There are a number of useful additions.
1 - You can define an area of the screen as a window to be used when printing text to the screen, or inputting text from the screen. You can scroll just the window or clear just the window
2 – You have the option to use (or not use) word wrap when printing on the screen. Default is on.
3 – You can load and save entire fonts to disk for both G32 and T40/T80 modes.
4 – You can now define characters 0-31 if you need to use special graphics.
5 – A disk catalog program is now included for use in G32 mode.
 

(Edit June 6) BETELGEUSE1 - fixed error in limit check for CALL LINK("CHAR")

 

(Edit June 13) BETELGEUSE2:

Here is the text mode package BETELGEUSE2 which has these changes:

The message * T40XB *  or * T80XB * is printed on the screen when the loader runs, when an XB program breaks, or when you CALL LINK(“T40XB”) in the immediate mode. This message tells you that T40XB is loaded and active. In previous versions, the screen color would change.
The names of some subroutines are changed to be more consistent with The Missing Link and XB256. 
CALL LINK("T80ON")  is now CALL LINK("T80XB")
CALL LINK("T40ON") is now CALL LINK("T40XB")
CALL LINK("T80OFF") and CALL LINK("T40OFF") are now CALL LINK("OFF")

 

(Edit June 27, 2020) When a program breaks in text mode, CON should reset to the text mode when it resumes. That now works properly.

BETELGEUSE3.zip

Edited June 28, 2020 by senior_falcon

[Omega-TI]

Second?

[senior_falcon]

4 minutes ago, INVISIBLE said:

Second?

I assume you mean T80XB? Will be ready in a few days.

[Omega-TI]

41 minutes ago, senior_falcon said:

I assume you mean T80XB? Will be ready in a few days.

Excellent!  I'll be waiting!  Thanks!

[senior_falcon]

I've made a folder with both T40XB and T80XB in one convenient package, code named "Betelgeuse". From the Readme file:

For the “Betelgeuse” and future versions, files for both T40XB and T80XB are included in the package. Both are virtually the same program except that T40XB is designed to use the 40 column mode built into the 9918A VDP; while T80XB uses the 80 column mode that needs special hardware such as the F18A, or you can use the Classic99 emulator with the “80 column hack” enabled.

There are a number of useful additions.
1 - You can define an area of the screen as a window to be used when printing text to the screen, or inputting text from the screen. You can scroll just the window or clear just the window
2 – You have the option to use (or not use) word wrap when printing on the screen. Default is on.
3 – You can load and save entire fonts to disk for both G32 and T40/T80 modes.
4 – You can now define characters 0-31 if you need to use special graphics.
5 – A disk catalog program is now included for use in G32 mode.

 

Post #1 has also been updated with the 'Betelgeuse" version.
(Edit June 6 - "Betelgeuse1" - fixed bug in limit check for CALL LINK("CHAR")

 

BETELGEUSE1.zip

Edited June 7, 2020 by senior_falcon

[Omega-TI]

Excellent job on the documentation too!

[pixelpedant]

Oh, wow.  This is awesome.  I'd been using the older version of T80XB just earlier today, having expected to use it in a present project.  And here I find this awesome upgrade.  The addition of the window feature is huge.  Thanks so much for your work on these invaluable XB resources!  I also really appreciate the built in solution for storing the routines in high memory along with the program.

[senior_falcon]

The default font for T40XB and T80XB is made by raising the standard TI font by one pixel and then loading a new lower case font with descenders. There is room in the programs to include the 96 characters making up a complete font. One possibility is the font used in XB2.7. In this font the capital letters are 6 pixels high and the lower case characters are smaller. Is there a preference for this font, or you you happy with the default font that I have provided?

[RXB]

Turns out many people have different preferences for fonts.

One of my pet peeves is fonts that touch above and below like when descenders on lower case seem to merge into next line down Capitals.

Also if the fonts look way to blocky.

RXB has fonts you can see in source and load your own if you choose it shows you the location and are 6 x 7 bytes for each character to save GROM space.

(XB loaded 8x8 characters even though >00 was on top of every single character wasting a ton of GROM space in XB Module.)

[senior_falcon]

36 minutes ago, RXB said:

RXB has fonts you can see in source and load your own if you choose it shows you the location and are 6 x 7 bytes for each character to save GROM space.

(XB loaded 8x8 characters even though >00 was on top of every single character wasting a ton of GROM space in XB Module.)

XB doesn't waste any grom space in the XB module on character definitions. They are loaded from console Grom and each pattern in the console grom is 7 bytes long for both upper and lower case letters. 

 

RXB, XB2.7, XB G.E.M. all use grom space for the fonts. The most efficient is the original XB G.E.M. which uses console grom to load the capitals one pixel higher and thus only needs patterns for the lower case characters, plus 3 changes to the capitals. RXB and XB2.7 must store patterns for a complete font so at 7 pixels high the capitals require 448 bytes for 64 characters. Of course, the advantage of that is you have complete control of every character.

[RXB]

8 hours ago, senior_falcon said:

XB doesn't waste any grom space in the XB module on character definitions. They are loaded from console Grom and each pattern in the console grom is 7 bytes long for both upper and lower case letters. 

 

RXB, XB2.7, XB G.E.M. all use grom space for the fonts. The most efficient is the original XB G.E.M. which uses console grom to load the capitals one pixel higher and thus only needs patterns for the lower case characters, plus 3 changes to the capitals. RXB and XB2.7 must store patterns for a complete font so at 7 pixels high the capitals require 448 bytes for 64 characters. Of course, the advantage of that is you have complete control of every character.

LOL you do know I have the ORIGINAL and I was the one that released the XB source code (GROMs and Assembly ROMs) to the public right?

RXB 2012 and RXB 2015 do not use the original XB routines to load character sets.

This is the original XB source in GPL for Loading Color, Characters and Sprites.

*************************************************************
* Data for the color tables (starts at >0800)               *
* BYTE >D0,>00,>00,>00,>00,>00,>00,>00                      *
* BYTE >00,>00,>00,>00,>00,>00,>00,>10                      *
* BYTE >10,>10,>10,>10,>10,>10,>10,>10                      *
* BYTE >10,>10,>10,>10,>10,>10,>10,>10                      *
*************************************************************
CHRTA2 ALL  >20+OFFSET        Clear the screen
       DST  >3567,@>83C0      Initialize random number gen
       MOVE 16,G@SPCCHR,V@>03F0 Cursor character
CHRTAB DST  >0400,@FAC        Address of chracater tables
       CALL CHAR2Z            Load the character set
       CEQ  >01,V@CONFLG      99/4A console?
       BR   G6939             NO
       DST  >0600,@FAC        Load the lowercase char set
       CALL CHAR3Z
G6939  BACK 4                 Border color = BLUE
       CLR  V@>0800
       MOVE 14,V@>0800,V@>0801
       ST   >F0,V@>080F       WHITE fore/transparent back
       MOVE 16,V@>080F,V@>0810
       CALL SPRINT
* This part might be moved up later, load special characters
* here. Don't load before hiding all sprites.
       MOVE 6,G@VDPREG,#1
       RTN
*
****** Initialization of sprites. Enable 28 sprites. ********
*
SPRINT CLR  V@>0780           Clear motion of all sprites
       MOVE >6F,V@>0780,V@>0781
* Replace the line for speeding up XB. 5/22/81
*      ST   28,@MOTION        All in motion
       CLR  @MOTION           All not in motion
       ST   >D0,V@>0370       Sprites 29 to 32 unavailiable
       DST  >C000,V@>0300     Hide the first sprites
       DCLR V@>0302           Make first sprite transparent
       MOVE 108,V@>0300,V@>0304 Ripple for the rest
       RTN

 

[senior_falcon]

 

LOL you do know I have the ORIGINAL and I was the one that released the XB source code (GROMs and Assembly ROMs) to the public right?

 

Now it's my turn to LMFAO. What you have posted is in exact agreement with what I said.

 

From your code posted above:

CHRTAB DST  >0400,@FAC        Address of chracater tables
            CALL CHAR2Z            Load the character set
            CEQ  >01,V@CONFLG      99/4A console?
            BR   G6939             NO
            DST  >0600,@FAC        Load the lowercase char set
            CALL CHAR3Z

 

And what are CHAR2Z and CHAR3Z?

From RXB code:

CHAR2Z EQU  >18               CHARACTER TABLE ADDRESS
CHAR3Z EQU  >4A               CHARACTER TABLE ADDRESS

 

What do the 6 lines starting at CHRTAB do? 

They call the grom routines at >0018 and >004A. And what are these routines?

They are in console grom 0 and they copy the character patterns from console grom at >06B0 to VDP at >0400 and g0870 to VDP at >0600.

Since the patterns are in console grom they clearly take up no room in the XB cartridge. I've gplnk'd to these many times in my assembly programming.

 

But let's say you didn't have the source code or didn't feel like wading through it. But you still wondered where the character patterns were stored, as I did last night. 

In Classic99, get into TI Extended BASIC and write a simple XB program:

1 FOR I=32 TO 127::CALL CHAR(I,"FFFFFFFFFFFFFFFF")::PRINT CHR$(I);::NEXT I

When this program runs it prints all the characters from 32 to 127 and defines them as solid black. When it ends the standard character set is reloaded.

Set up the Classic99 debugger to break when grom >08E8 is read from:  <G08E8 is how you set up the breakpoint.

In TI INTERN we see that grom >08E8 is in the middle of the lower case set; it turns out that it is the "p"

You can press F2 to single step and watch as "p" is defined as the grom is read from starting at that address.

[RXB]

2 hours ago, senior_falcon said:

 

LOL you do know I have the ORIGINAL and I was the one that released the XB source code (GROMs and Assembly ROMs) to the public right?

 

Now it's my turn to LMFAO. What you have posted is in exact agreement with what I said.

 

From your code posted above:

CHRTAB DST  >0400,@FAC        Address of chracater tables
            CALL CHAR2Z            Load the character set
            CEQ  >01,V@CONFLG      99/4A console?
            BR   G6939             NO
            DST  >0600,@FAC        Load the lowercase char set
            CALL CHAR3Z

 

And what are CHAR2Z and CHAR3Z?

From RXB code:

CHAR2Z EQU  >18               CHARACTER TABLE ADDRESS
CHAR3Z EQU  >4A               CHARACTER TABLE ADDRESS

 

What do the 6 lines starting at CHRTAB do? 

They call the grom routines at >0018 and >004A. And what are these routines?

They are in console grom 0 and they copy the character patterns from console grom at >06B0 to VDP at >0400 and g0870 to VDP at >0600.

Since the patterns are in console grom they clearly take up no room in the XB cartridge. I've gplnk'd to these many times in my assembly programming.

 

But let's say you didn't have the source code or didn't feel like wading through it. But you still wondered where the character patterns were stored, as I did last night. 

In Classic99, get into TI Extended BASIC and write a simple XB program:

1 FOR I=32 TO 127::CALL CHAR(I,"FFFFFFFFFFFFFFFF")::PRINT CHR$(I);::NEXT I

When this program runs it prints all the characters from 32 to 127 and defines them as solid black. When it ends the standard character set is reloaded.

Set up the Classic99 debugger to break when grom >08E8 is read from:  <G08E8 is how you set up the breakpoint.

In TI INTERN we see that grom >08E8 is in the middle of the lower case set; it turns out that it is the "p"

You can press F2 to single step and watch as "p" is defined as the grom is read from starting at that address.

These lines check to see if it is an TI99 or TI99/4A computer:

       CEQ  >01,V@CONFLG      99/4A console?
       BR   G6939             NO

I could post the GPL code that loads the Cursor character, but what would be the point.

Not many like the Console Character set, especially the lower case ones.

I did release a patch years ago for PGRAM or GRAMULATOR to load a alternate set of these into GROM 0, and wondered why some carts do not do this.

You know replace TI Basic with EA cart and Disk Manager or something else.

Any way we both know this stuff I think, this was just for others that may not have known.

[pixelpedant]

Apologies for interrupting a more in depth conversation with such a rudimentary question.  But I wonder if anyone could corroborate or explain an observation. 

 

It seems to me, in T80XB, I am able to define and display all of characters 0 to 31 using CALL LINK("CHAR",#,pattern).  But in T40XB, 16-31 are definable, while any values between 0 and 15 result in "BAD VALUE IN [line]". 

 

Is this expected behaviour?  Just want to make sure I'm not missing something really obvious.  The (wonderfully readable, incidentally, as Omega says) documents don't seem to make a distinction in this regard, between the two versions, that I can find. 

[senior_falcon]

Hopefully we are done with that foolishness, which was hardly an in depth conversation. Just a couple of cranky old men who don't like to back down.

I initially made it so you could redefine characters 16-31, then realized there is no problem expanding that to 0 - 31. I must have forgotten to change T40XB. I will repost

If you want to get a head start on this, CALL LOAD(13111,0) will change the lower limit check.

Edited June 6, 2020 by senior_falcon

[senior_falcon]

"BETELGEUSE1" - bug fix: CALL LINK("CHAR") for T40XB can now define characters starting at 0. Post #1 and post #5 have the updated version.

[pixelpedant]

Thanks so much for the fix and quick update! 

 

Oh, and incidentally, it works fine for my on real iron (F18A+SAMS+TIPI) with one minor difference: in immediate mode, text is white on yellow, rather than black on yellow, as it is in Classic99:

 

 

 

That having said, CALL LINK("COLOR",#,#) works exactly as expected, in program code.  i.e., CALL LINK("COLOR",2,12) results in black on yellow. 

 

Edited June 7, 2020 by pixelpedant

[senior_falcon]

XB2.7 and other variants use white letters on a blue screen. The screen color is changed, but not the letters, hence the white on yellow. 

[+Vorticon]

Nice work! Too bad we can't have the XB editor in 80 columns as well... Is that even possible? 

[senior_falcon]

I have modified T80XB to report "T80XB running" instead of changing the screen color. This eliminates the problem pixelpedant had of white letters on a yellow screen which is almost unreadable.

Try it out and report back on which way you like best.

 

(edit) Users of TI XB will not see a difference in screen colors. XB2.7 and RXB use white characters on a dark blue background. The earlier versions of T80XB changed the screen color to show that T80XB was loaded and running. Since they didn't change the white characters, this would lead to the problem that pixelpedant noted. 

T80XB

Edited June 8, 2020 by senior_falcon

[senior_falcon]

There has been no feedback on this, so let me make responding as easy as possible.

To show that T80XB is loaded and running:

A - I prefer to have the screen change color.

B - I prefer the printed message "T80XB running" with no screen color change.

C - I have no preference

[pixelpedant]

I'd say I definitely prefer just a printed message, myself.  Though I'm fine with XB256's black on grey.  So if there has to be a colour distinction, I guess that'd be my vote.

[+Lee Stewart]

I would prefer that the color change only when I ask it to.

 

Making it obvious that T80XB is running with some sort of text display, such as a text prompt, is sufficient for me in command mode. In fbForth 2.0, I do this by clearing the screen and coming back with the Forth “ok:0” followed by the blinking, input cursor, both of which make it obvious the change took place. If “T80XB running” is the only text display, then that would be useful.

 

If the mode change is part of program execution, there is no indication in fbForth 2.0 except a cleared screen. I think a cleared screen is sufficient in program mode. Otherwise, an error message should indicate failure.

 

...lee

[+Vorticon]

I think a text prompt is sufficient. Color preference is a very personal thing

[GDMike]

26 minutes ago, Vorticon said:

I think a text prompt is sufficient. Color preference is a very personal thing

No, I think, therefore it's written! All text colors should be green on a black screen. There! I solved the problem.

Nexxxt... Bwahahha so easy.