TI FORTH Version 3.0 dated October 20 1982

[JonnyBritish]

Just noticed I have this complete manual from Texas Instruments

 

Is there already a scan of this out there?

[+Lee Stewart]

Just noticed I have this complete manual from Texas Instruments

 

Is there already a scan of this out there?

 

I am unaware that there was ever but one version of TI Forth that made it out to the public and it had no version number. It was placed in the public domain by Texas Instruments on December 21, 1983. The two source code disks that were also released had dates of November 3, 1982 and December 8, 1982. The TI Forth system disk released along with the manual to the officially recognized TI user groups had no date on it.

 

I found a scanned and OCRed document, TexSoft-TIForth.pdf (I forget where) that claims to be version 4.5 but is missing the "Dedication" chapter that puts it in the public domain. I have the original manual in mimeographed form and on TI Writer disks in files labeled A, B, ... , P, which I converted to Open Office Writer (ODT) format, corrected, extensively edited and augmented. It is available on this forum in this thread: TI FORTH Instruction Manual in PDF Format (with updates). The link to the PDF version of my completed edition in that thread is here: TI_FORTH_Manual-ed(LES).pdf

 

...lee

Edited February 20, 2012 by Lee Stewart

[glefebvre]

I have looked around for the TI-FORTH disk images but I'm not able to fine any. Are there any disk images available for TI-FORTH?

[rocky007]

probably here : http://ftp.whtech.com/emulators/TI99%20Disks%20(tosec%20001).rar

Edited February 24, 2012 by rocky007

[rocky007]

mmh, more easy :

TI FORTH v3.0 (1982-10-20)(Texas Instruments)PHD 5098req. PHM 3055DSK1.FORTH.zip

Edited February 24, 2012 by rocky007

[glefebvre]

Thanks rocky007.

[+Lee Stewart]

mmh, more easy :

 

Your attachment does not have all the bug fixes. It has only the fix of PAB_ADDR to PAB-ADDR on line 5 , screen 72. I posted one [here] with all the fixes detailed in "Appendix J" of my edition of the TI Forth Instruction Manual [here].

 

...lee

[ti99iuc]

Dorung Conversione and catalog of my disks i found two TI original disks contents the source of Forth...

i attach here, maybe someone could need it ?

 

TI-Forth Source.zip

 

Note: Disk one have a Bad Sector, i looking for recover it and will upload the recovered version if it could be interesting for someone.

[+Lee Stewart]

Dorung Conversione and catalog of my disks i found two TI original disks contents the source of Forth...

i attach here, maybe someone could need it ?

 

...

 

Note: Disk one have a Bad Sector, i looking for recover it and will upload the recovered version if it could be interesting for someone.

 

They are available in several user-group directories on Western Horizon's FTP site (whtech). In the Cedar Valley group's library, they are CV182.DSK and CV183.DSK.

 

...lee

[ti99iuc]

Good... thank you for news, so i will take that copy and not lost time to recover mine

[apersson850]

_{I went up to see if my TI 99/4A still works. It does, but that's another thing. Noticed that I have the source code for TI-Forth 3.0, and also a disk with TI-Forth 4.5, according to the label. Other flavors are PB-Forth (Swedish Programbiten's Forth) and Wycove Forth.}

 

_{There were indeed a number of them...}

Edited February 28, 2012 by apersson850

[+Vorticon]

Incidentally, some of the disk functions for TI Forth seem to corrupt the system under Classic99, but work fine with Win994a.

I was intrigued by its 64 column bitmapped editor, and I have to say that, while being very simple, it's also very easy to use, allowing the user to see an entire Forth screen (block) without scrolling.

I'm not good enough yet with Forth to create a decent perfomance comparision test, and I was wondering if anyone here has compared TurboForth and TI Forth from a performance standpoint.

Edited February 29, 2012 by Vorticon

[Willsy]

Here's a very simple one:

 

: TEST 20000 0 DO I . LOOP ; 

[Willsy]

Here's TF & TI Forth running the 7's problem.

 

[Willsy]

Correction: that was FIG forth.

[+Vorticon]

Here's a very simple one:

 

: TEST 20000 0 DO I . LOOP ;

 

That I can do I was looking more for a mathematical or perhaps graphics comparision. Your Power of 7 demo clearly shows Turbo Forth being at least 35% faster Interestingly, XB is much faster than both for that specific test, at least until an overflow occurs, although it uses the scientific notation for large numbers.

I do plan to experiment with the bitmap capabilities of TI Forth at some point though to see how easy it would be to work in that mode, which is notoriously a bear to use with in assembly.

One annoying feature of TIF is the need to load modules at the beginning to access certain words, although this selective process likely saves memory. Another is the need to switch disks after boot because TIF can only FLUSH to DSK1, at least as far as I can tell. Overall though, not a bad implementation.

Edited February 29, 2012 by Vorticon

[+Lee Stewart]

Here's TF & TI Forth running the 7's problem.

 

What's the code?

 

...lee

[Willsy]

In here

[+Lee Stewart]

Correction: that was FIG forth.

 

Well, TI Forth is pretty much FIG Forth.

[+Lee Stewart]

Here's a very simple one:

 

: TEST 20000 0 DO I . LOOP ;

 

That really only tests how good the display routine is. TI Forth loses abysmally on that one on Classic99 (TF: 170 seconds; TIF: 630 sceonds). However, if you test only resident words that do not use the display, the two are very close on, for example, the following test that performs the operations (push inner and outer loop indices to the stack; add them; pop result off the stack to avoid overflow) in the inner loop a million times:

 

: TEST 1000 0 DO 1000 0 DO J I + DROP LOOP LOOP ;

 

TF: 250 seconds; TIF: 232 seconds---TI Forth wins this one, but not by much.

 

Turboforth obviously has a much faster display routine.

 

...lee

Edited March 1, 2012 by Lee Stewart

[+Lee Stewart]

...

 

I do plan to experiment with the bitmap capabilities of TI Forth at some point though to see how easy it would be to work in that mode, which is notoriously a bear to use with in assembly.

 

If you use the split or split2 bitmap modes, you can type bitmap commands on the command line and watch them execute without the need to change graphic modes all the time. Split mode uses the top 2/3 of the screen for the bitmap display and the bottom third for text display. Split is the mode that is used for the 64-column editor. Split2 mode uses the bottom 5/6 of the screen for the bitmap display and the top sixth for text. The dot-row values can be 0 -- 127 in split mode, 32 -- 191 in split2 mode and, of course, the full 0 -- 191 in graphics2 mode (no text panel). The dot-column values for displayable dots are the same in all modes: 0 -- 255.

 

One annoying feature of TIF is the need to load modules at the beginning to access certain words, although this selective process likely saves memory.

 

There's an easy fix for the annoyingly long time this kind of loading takes. When you find you need to load the same screens all the time for certain projects, you can BSAVE the non-resident part of the dictionary the way you use it to later BLOAD it, a much, much faster process than LOADing text screens because the text screens must first be interpreted, not to mention that text takes longer to read from disk than the shorter binary.

 

Another is the need to switch disks after boot because TIF can only FLUSH to DSK1, at least as far as I can tell. Overall though, not a bad implementation.

 

TI Forth has no problem with multiple disks. They do need to all be the same size, which is irritating. You just need to change 2 user variables, DISK_SIZE and DISK_HI . Both of these are initially set at 90, which does, in fact, limit you to only one disk. If you have 3 disks you wish to use as DSK1, DSK2 and DSK3 and they are all 90KB, then you would need to change DISK_HI to 270 (3 * 90). This means that screens 0 -- 89 are on DSK1, 90 -- 179 are on DSK2 and 180 -- 269 are on DSK3. So that you don't have to remember to change the value every time you boot up, you can put 270 DISK_HI ! somewhere on lines 12 --14 of screen 3 of the system disk (for three 90KB disks) [Back it up, first!].

 

...lee

[+Lee Stewart]

Incidentally, some of the disk functions for TI Forth seem to corrupt the system under Classic99, but work fine with Win994a.

 

Which disk functions?

 

I was intrigued by its 64 column bitmapped editor, and I have to say that, while being very simple, it's also very easy to use, allowing the user to see an entire Forth screen (block) without scrolling.

 

A long time ago (1984, I think) I set up my TI Forth system to always load the 64-column editor. I also developed my own true lowercase letters for all graphics modes and a black on gray screen (I hate the white on black screen TI did for the 64-column editor!). It all loads a lot faster than with LOADing text screens. I plan to do the same with a disk image to use with the emulators---I just haven't gotten around to it yet. If you are interested, I will post it when I actually do it.

 

...lee

[+Vorticon]

 

Another is the need to switch disks after boot because TIF can only FLUSH to DSK1, at least as far as I can tell. Overall though, not a bad implementation.

 

TI Forth has no problem with multiple disks. They do need to all be the same size, which is irritating. You just need to change 2 user variables, DISK_SIZE and DISK_HI . Both of these are initially set at 90, which does, in fact, limit you to only one disk. If you have 3 disks you wish to use as DSK1, DSK2 and DSK3 and they are all 90KB, then you would need to change DISK_HI to 270 (3 * 90). This means that screens 0 -- 89 are on DSK1, 90 -- 179 are on DSK2 and 180 -- 269 are on DSK3. So that you don't have to remember to change the value every time you boot up, you can put 270 DISK_HI ! somewhere on lines 12 --14 of screen 3 of the system disk (for three 90KB disks) [Back it up, first!].

 

...lee

I got that much from the manual, but how do you FLUSH to a drive other than DSK1 the program that is currently being edited?

Edited March 1, 2012 by Vorticon

[+Vorticon]

 

Turboforth obviously has a much faster display routine.

 

...lee

This is obviously crucial for games. However, I'm a big fan of the bitmap mode, and in that respect, TIF does seem to hold an edge over TF. The way I see it, I'll probably use TF for low res graphics applications, and TIF for my hi res mathematical explorations It is highly doubtful that I'll be using XB any time soon again And I can always imbedd assembly routines within Forth for even added flexibility.

[+Lee Stewart]

Another is the need to switch disks after boot because TIF can only FLUSH to DSK1, at least as far as I can tell. Overall though, not a bad implementation.

 

TI Forth has no problem with multiple disks. They do need to all be the same size, which is irritating. You just need to change 2 user variables, DISK_SIZE and DISK_HI . Both of these are initially set at 90, which does, in fact, limit you to only one disk. If you have 3 disks you wish to use as DSK1, DSK2 and DSK3 and they are all 90KB, then you would need to change DISK_HI to 270 (3 * 90). This means that screens 0 -- 89 are on DSK1, 90 -- 179 are on DSK2 and 180 -- 269 are on DSK3. So that you don't have to remember to change the value every time you boot up, you can put 270 DISK_HI ! somewhere on lines 12 --14 of screen 3 of the system disk (for three 90KB disks) [Back it up, first!].

 

...lee

I got that much from the manual, but how do you FLUSH to a drive other than DSK1 the program that is currently being edited?

 

I may not be understanding exactly what you want to do or what, if anything, you might be missing; but, if you will indulge me a moment: FLUSHing only copies dirty screen buffers to their associated screens on disk. When you edit a screen, you give EDIT a screen number to start editing ( 99 EDIT , perhaps). It is the screen number that determines what disk you are actually working with. Let's say you are using three 90KB disks with the system on DSK1 and you want to put a program on the 10th screen of DSK2. That would be screen 9 if the disk were in the first drive. That screen in this scenario is screen 99. If you want the contents of that just-edited screen to be copied to, say, screen 189 (10th screen on DSK3), you would type FLUSH 99 189 SCOPY . The FLUSH simply insures your edits are first saved to screen 99.

 

...lee