fbForth fbForth—TI Forth with File-based Block I/O [Post #1 UPDATED: 06/05/2024]

[+Lee Stewart]

Almost done coding the high-level Forth for the floating point library! I have the fixed-format output word(s) to write—then on to testing.

 

...lee

[+Lee Stewart]

OK—It looks like I need to assemble the Floating Point Library (FPL) separately from the rest of fbForth. Otherwise, things get hinky with the number of labels. Now I need to patch the FPL binary into the binary of Bank 3. @Tursi's DF802BIN.EXE won't do because it fills all banks out to 8KB. It looks like I'm going to have to do it with a hex editor unless someone has a simple technique for doing it—anyone?

 

...lee

Edited August 23, 2014 by Lee Stewart

[+Lee Stewart]

I got things working so I can begin testing; but, I would surely like to automate the compilation of the binary! As it is now, I have two batch files to automate part of the process. The first extracts the binaries from the OBJ files and pads each bank to 8KB bytes (@Tursi's DF802BIN.EXE). Then, I must open a hex editor to cut the FPL from its binary and paste it to the bank 3 binary before running the second batch file, which packs everything up for Classic99, MESS and the cartridge.

 

The cutting and pasting is not too onerous; but, like I said, I really would like to automate that part as well. But—at least, now, I am well on the way to finishing the fbForth 2.0 cartridge!

 

...lee

[+Lee Stewart]

So far, so good! All the high-level words are working except that the word used to display FP numbers needs some work. I may also add a handful of FP words that I added to TurboForth's FP library more than a year ago that are not currently part of TI Forth or fbForth 1.0. I should have another beta to release in a day or two.

 

I need to get an EPROM programmer post haste so I can start building and testing an actual cartridge!

 

...lee

[Willsy]

Nearly there!!

[+Lee Stewart]

Everything seems to be working!

 

I will post beta 8 in a little while to post #1 after I get it packed up.

 

The floating point words I have so far implemented are:

 

FDUP FDROP FOVER FSWAP FVARIABLE FCONSTANT F! F@ F+ F- F* F/ INT ^ SQR EXP LOG COS SIN TAN ATN PI F->S S->F FRND >F F0< F0= F> F= F< FLERR ?FLERR FFMT.

 

The new words in the above are:

 

FVARIABLE FCONSTANT FFMT.

I do not plan to implement the following TI Forth/fbForth 1.0 words unless someone can make a compelling argument for them. With the exception of the last 4 words, they were primarily needed as the interface to XMLLNK and GPLLNK routines in TI Forth and fbForth 1.0:

FAC ARG >FAC >ARG SETFL FADD FSUB FMUL FDIV S->FAC FAC->S FAC>ARG VAL F. F.R FF. FF.R

Words I implemented for @Willsy in TurboForth that I may include, if I have enough room, are:

FNEGATE FABS FLOOR (same as INT ) CEIL TRUNC FRAC RAD/DEG DEG/RAD EULER_E >RAD >DEG LOG10 EXP10

I replaced the formatted and unformatted typing words ( F. FF. ) with FFMT. . The right-jusitifying words ( F.R FF.R ) can be implemented another way that I will work out later. |

I will post usage notes on FVARIABLE , FCONSTANT and FFMT. within the next couple of days. You can probably figure out the first two, but the last one will need explanation. All of the others are described in Chapter 7 of the fbForth 1.0 Manual located in the development thread as well as post #1 of this thread..

...lee

Edited August 27, 2014 by Lee Stewart

[+Lee Stewart]

Notes promised on FVARIABLE , FCONSTANT and FFMT. :

 

FVARIABLE ( f — )

 

A floating point (FP) number must be on the stack prior to using this word. The name of the new FP variable must follow this word in the input stream. You can push an FP number to the stack with >F . The following code will place the FP number, 1.234567890123E-7 on the stack and store it in the parameter field of an FP variable named FPVAR . The variable's address is pushed to the stack by typing its name, the value is pushed to the stack with F@ , and the value is displayed in TI Basic free format with 0 FFMT. :

 

>F 1.234567890123E-7 FVARIABLE FPVAR ok:0

FPVAR F@ ok:4

0 FFMT. 1.23457E-07 ok:0

 

FCONSTANT ( f — )

 

The same thing obtains here for FCONSTANT as for FVARIABLE , except that typing the new word's name pushes the word's FP value to the stack:

 

>F 1.234567890123E-102 FCONSTANT FPCON ok:0

FPCON ok:4

0 FFMT. 1.23457E-** ok:0

 

FFMT. ( f [intLen fracLen] optMask — )

 

This word can handle free-format, TI Basic-style output of FP numbers as well as fixed-format output that includes F-, E- and extended E-type formats. For free-format output, only the FP number and optMask = 0 is required on the stack. This type of format was demonstrated in the previous two examples.

 

optMask is composed of the following bits:

 

bit 0: 0 = free form TI Basic style

+no other bits should be set

+intLen and fracLen should not be on the stack

1 = fixed format

bit 1: 2 = explicit sign

bit 2: 4 = show '+' for positive number instead of space

+bit 1 must also be set

bit 3: 8 = E-notation (2 exponent digits)

bit 4: 16 = extended E-notation (3 exponent digits)

+bit 3 must also be set

 

If optMask is not 0, intLen and fracLen must be on the stack, as well. If the sum of intLen and fracLen exceeds 16, an error message will be displayed:

 

intLen: number of places before decimal point, including sign position

fracLen: number of places after decimal point, including decimal point and excluding E-notation

 

Various examples, using the above-defined FP constant, FPCON , follow:

 

FPCON FDUP FDUP FDUP FDUP ok:20

2 14 1 FFMT. .0000000000000 ok:16

2 10 9 FFMT. 1.234567890E-** ok:12

2 12 25 FFMT. 1.23456789012E-102 ok:8

2 14 31 FFMT. +1.2345678901230E-102 ok:4

2 15 9 FFMT. field too big! ok:0

 

...lee

[+Lee Stewart]

At least one more floating point (FP) word I think I may add to fbForth 2.0 is FROT to move the third FP number down on the stack to the top: ( f1 f2 f3 — f2 f3 f1 ).

 

There are other words that come to mind because fbForth uses the parameter stack for FP number manipulation. I am not sure that this accommodation is actually necessary. Perhaps I should leave it to the user. The possible 2-number scenarios that adding FP numbers into the parameter-stack mix presents are

 

stack bottom: f s

stack:bottom: s f

stack bottom: d f

stack bottom: f d, where f is an 8-byte FP number; s is a 2-byte, single-precision integer; d is a 4-byte, double-precision integer.

 

Of course, there are the 3-number scenarios....

Maybe I will just provide two words that will move an FP number to and from the return stack:

 

F>R ( f — ) ( R: — f ), where "R:" represents the return stack

R>F ( — f ) ( R: f — )

 

Thoughts?

 

...lee

[+Lee Stewart]

After moving code around a little and before I add the remaining FP words, I now have the following room in each bank:

• Bank 0—608 bytes
• Bank 1—206 bytes
• Bank 2—550 bytes (This bank was down to 48 bytes left and I need at least 196 bytes for the additional dictionary headers!)
• Bank 3—1928 bytes

It looks like I'll be fine, so I think I will go ahead and add almost all of the words itemized in the last few posts. If anyone convinces me I should scale back, I can always remove the challenged words.

 

Once I'm finished with these in a day or two, we can begin the beta-testing in earnest with beta 9. Soon after that, I will post fbForth 2.0 and work out something with real cartridges—maybe first at the Faire in Chicago, which is little more than 2 months away!

 

...lee

[+Lee Stewart]

Wow—I feel like such an idiot! I just wasted a few hours fighting with my implementation of F>R and R>F until I realized that those two words should only be used in definitions in which they are balanced, i.e., there should be an equal number of each of them in a definition or fbForth will veer off into the weeds! I knew this because >R and R> carry the same caveats that are clearly stated in any Forth manual. They are working fine, though I wonder now at the advisability of including them. I will definitely include clear warnings. They are convenient and two commands do beat eight!

 

Oh, well—a brain fart now and then is to be expected, I guess. Did I tell you I was old?!

 

...lee

[+Ksarul]

Sounds like you had a good beer moment there. Lee! Time to sit down, chill out and sip a good cold one. All will become clear in short order, and if it doesn't, pop the top off the next one, as the condition requires more intensive treatment.

[+Lee Stewart]

Sounds like you had a good beer moment there. Lee! Time to sit down, chill out and sip a good cold one. All will become clear in short order, and if it doesn't, pop the top off the next one, as the condition requires more intensive treatment.

 

I like the way you think, Jim! In this particular case, lying down for a bit and watching a little TV was the distraction I needed. A beer or two would have delayed the "aha!" moment 'til morning, I'm afraid—though it certainly would have been worth it!

 

...lee

[+Lee Stewart]

FNEGATE —

 

I really want this word to have the above name, but that presents a dilemma: The TI Forth programmers named its 16-bit-integer counterpart, MINUS and its 32-bit-integer counterpart—you guessed it— DMINUS , which is fig-Forth, I guess. At least, Derick and Baker's FORTH Encyclopedia (fig-Forth based) defines MINUS and DMINUS and says that Forth-79 calls them NEGATE and DNEGATE . So, it wasn't caprice on the part of the TI Forth programmers, which means I probably should call it FMINUS to maintain expectations—oh, well!

 

...lee

[Willsy]

MINUS - yack.

 

Imagine:

 

: TEST 1.123 2.345 FMINUS ... ... ... ;

 

Now, that to me, says do a subtraction. Whereas FNEGATE is clear.

 

That said, it's easy to cure on an ad-hoc basis. For example:

 

"Yack, I don't like FMINUS!"

 

Okay then:

 

 

: FNEGATE ( f:n -- f:-n) COMPILE FMINUS ; IMMEDIATE

 

Ta da!

Edited August 25, 2014 by Willsy

[+Lee Stewart]

Yeah, I know—but the compatibility thing, dontcha know.

 

...lee

[+Lee Stewart]

I ran into another problem—this time with precision-related accuracy in converting degrees to radians. It has to do with how FP numbers are stored in radix-100 format. As you probably know, because one radix-100 digit represents exactly two radix-10 (decimal) digits, there is always an even number of decimal digits on either side of the decimal point. The factor for converting radians to degrees is degrees/radian = 57.295779513082320876798154814105 and has 14 digits of precision stored in an 8-byte FP number because '57' is stored in the first byte as the first radix-100 digit. However, the inverse factor for converting degrees to radians, which is necessary for all of the trigonometric functions, is radians/degree = 0.01745329251994329576923690768489 and has only 13 digits of precision represented in an 8-byte FP number because '01' is the first radix-100 digit stored. You would think 13 digits of precision might be enough; but, for the TAN function, using the latter conversion factor to convert 45 ° to radians results in a value, the tangent of which is calculated as 0.98000002—not very close to 1, if you ask me!:

 

>F 45 >RAD TAN 0 FFMT. .98000002 ok:0

 

If I divide by the inverse factor with the one higher digit of precision, I get

 

>F 45 DEG/RAD F/ TAN 0 FFMT. 1 ok:0

 

which is what it should be. It's just that dividing with F/ takes a lot longer than multiplying with F* .

 

I could increase precision by using two factors that would result in a sum that would likely reuslt in the best value:

 

>F 45 FDUP RPD1 F* FOVER RPD2 F* F+ TAN 0 FFMT. 1 ok:0

 

The part of the calculation represented by

 

FDUP RPD1 F* FOVER RPD2 F* F+ ,

would be handled in ALC, of course, and is the equivalent of

 

45 * 0.0174532925199 + 45 * 4.329576923691 x 10^-14

 

which would preserve precision, but, of course, take more time—probably more than the single division mentioned somewhere above.

 

I could add an option for the increased precision for all calculations, I suppose. Sorry, I'm rambling. I'll let you talk now.

 

...lee

[Willsy]

I could add an option for the increased precision for all calculations, I suppose. Sorry, I'm rambling. I'll let you talk now.

 

...lee

 

That sounds preferable to me, something that can be turned on/off, rather than having to remember the names of separate words, or remember specific 'gotcha' cases.

[+Lee Stewart]

Any ideas about the name of a word to display the radix (number base) in decimal? The only name I have so far contrived is BASE_DISP . I suppose that is sufficient; but, if anyone can manage a shorter but still descriptive word, I would be much obliged! {EDIT> @Willsy thought of something better! .BASE }

 

The word BASE is the name of a variable that contains the base; but, if you type BASE @ , you will always get "10" as the contents. The high-level code for BASE_DISP is

 

: .BASE ( <--final name)

BASE @ BASE->R DECIMAL . R->BASE ;

 

Here's how it would work for radices 2 (binary), 10 (decimal) and 16 (hexadecimal) [output from fbForth is underlined {EDIT> and BASE_DISP is now .BASE } ]:

 

2 BASE ! ok:0

BASE @ . 10 ok:0

.BASE 2 ok:0

DECIMAL ok:0

BASE @ . 10 ok:0

.BASE 10 ok:0

HEX ok:0

BASE @ . 10 ok:0

.BASE 16 ok:0

...lee

Edited August 27, 2014 by Lee Stewart

[+Lee Stewart]

If I don't get any better ideas, I think I will include BASE_DISP in the resident dictionary and pack up beta 9 tonight. I hope a few of you folks will test it and report back to me so I can feel confident in soon releasing fbForth 2.0 in its "final" form.

 

I will be trying it on the real iron this week because I just got a programmer and should be getting the EPROMs.in a day or two—can't wait!

 

...lee

 

{EDIT> @Willsy had a better idea, viz., .BASE — I'll be using that.}

Edited August 27, 2014 by Lee Stewart

[Willsy]

Forth nomenclature says (at least to me) .BASE

[+Lee Stewart]

Forth nomenclature says (at least to me) .BASE

 

Okey, dokey— .BASE it is! I'll even edit my previous post.

 

...lee

[+Lee Stewart]

OK—the latest beta (beta 9) will be in post #1 in a few minutes. Please—those few of you interested in Forth—test beta 9 and let me know of any problems. Feel free to ask questions.

 

As I said somewhere above, I'll be testing fbForth 2.0 in a real cartridge sometime this week—I can't wait!

 

...lee

[Willsy]

Actually, the idea of displaying the base in decimal is good idea. Never thought of that. You can really tie yourself up in knots sometimes if your program changes base and then doesn't put it back afterwards. (ahem!)

 

I'll load up the latest beta this weekend and take it for a spin. Is the manual also in post #1? (I'll check now)

[+Lee Stewart]

I'll load up the latest beta this weekend and take it for a spin. Is the manual also in post #1? (I'll check now)

 

It is now! —for fbForth 1.0, that is. It was always in the development resources thread at the top of this forum. I'm working on the 2.0 manual. I will try to put together a readme file soon; but, burning and testing a cartridge will likely get in the way this week and next.

 

...lee

[+Lee Stewart]

Due to significant changes in the layout of VRAM for fbForth 2.0, I decided to post "Chapter 4 Memory Maps" in post #1, q.v. That chapter is the only one of the new manual that is complete.

 

...lee