TurboForth V1.2 (Beta)--Evolution & Arcana

+Lee Stewart · September 1, 2012

Mark...

I can't tell from your note whether you really don't know what an arctangent is, so here it is: The arctangent of x (usually abbreviated arctan x and, less so, tan^-1 x) is the inverse function of the tangent, i.e., it is the angle (φ) whose tangent is x. Put another way: If tan φ = x, then arctan x = φ = arctan (tan φ).

"Knickers" are "panties" or "underpants" in the sense you used it. I like your term better!

...lee

Stuart · September 1, 2012

I think Mark has just set a new standard for how off-topic a thread can go ... ;-)

Edited September 1, 2012 by Stuart

+InsaneMultitasker · September 1, 2012

You might even say he 'went off on a tangent'..... :dunce:

Stuart · September 1, 2012

Groan .... ;-)

+Lee Stewart · September 1, 2012

<groan> :roll: I wish I'd thought of that!

Stuart · September 1, 2012

Why? 'cos it's a sine of bad humour?

+Lee Stewart · September 1, 2012

Secant ye shall find arcos is just!

+InsaneMultitasker · September 1, 2012

I'm off to suck more solder fumes as I attempt to fix Geneve #2 today... yet this thread reminded me of some Impure Mathematics and I feel compelled to share. Apologies in advance.

http://komplexify.com/math/humor_blue/PollyNomial.html

+Lee Stewart · September 1, 2012

I used to subscribe to The Journal of Irreproducible Results (where this appeared) when I was a grad student and for a few years after. This appeared about 5 years later, so I missed it. Believe it or not, JIR is still in business here.

...lee

+Lee Stewart · September 7, 2012

Here's the math for calculating arctan x in radians by the TI-99/4A:

The basis for both the TI-99/4A console and Geneve MDOS routines for calculating arctan x is the Taylor series expansion,

arctan x = x - x³/3 + x⁵/5 - x⁷/7 + ... , where -1 ≤ x ≤ 1

The equation converges to arctan x fairly rapidly as long as x is kept away from ±1. Generally, for each additional power term in the equation, two additional significant figures of accuracy are added to the answer. The 8-byte, radix-100 floating point numbers used by the console will support 13 to 14 significant figures (decimal). The polynomial used by the TI-99/4A terminates at x¹⁹. Because the series expansion is not continued closer to infinity, some precision is lost. The coefficients, a₀ = 1, a₁ = -1/3, a₂ = 1/5, a₃ = -1/7, ... , were adjusted to regain some of that precision. The following table shows the adjusted coefficients alongside the un-adjusted coefficients:

coefficient    un-adjusted         adjusted
------------------------------------------------
    a0       1.00000000000000   1.00000000000000
    a1      -0.33333333333333  -0.33333333333225
    a2       0.20000000000000   0.19999999978996
    a3      -0.14285714285714  -0.14285712697596
    a4       0.11111111111111   0.11111049925053
    a5      -0.09090909090909  -0.09089547919672
    a6       0.07692307692308   0.07673712439164
    a7      -0.06666666666667  -0.06506999940140
    a8       0.05882352941176   0.05027913843885
    a9      -0.05263157894737  -0.02535718798820

The routine first saves the sign of x (= tan φ) and then passes |x|, i.e., a positive value, to the next part of the routine. This limits the solution to the first quadrant (0 – π/2). Next, the routine forces x to the range: tan (π/8) to tan (-π/8) by performing one of the following actions:

1. If x ≤ tan (π/8), do nothing.

2. If tan (3π/8) < x ≤ tan(π/2),

a. Because tan (π/2 - φ) = 1/tan φ and -arctan x = arctan -x, pass -1/x = tan (φ - π/2) to the polynomial routine.

b. Because the result = φ - π/2, add π/2 to result to get φ.

3. If tan (π/8) < x ≤ tan (3π/8),

a. Because arctan α - arctan ß = arctan [(α - ß)/(1 + αß)] and tan π/4 = 1, let ß = 1, α = x, and pass (x - 1)/(1 + x) = tan (φ - π/4) to the polynomial routine.

b. Because the result = φ - π/4, add π/4 to result to get φ.

Finally, adjust the sign of φ to match the saved sign.

The polynomial routine in the TI-99/4A (GPL and assembly routines used) and the Geneve MDOS (only assembly routines used) both use Horner's Rule to evaluate the polynomial. Using Horner's Rule minimizes loss of precision and I will explain it later. Right now I am a little punchy and have probably already made some mistakes above. I hope I haven't bored everyone to tears.

...lee

Edited March 23, 2015 by Lee Stewart

Willsy · September 7, 2012

Wow! This is great stuff! The way you're going you'll be able to implement a full FP suite yourself in assembly!

It would be really great to be able to move away from the GPL code. Some folk may have reservations about the amount of memory required for a FP suite, but, the nice thing about Forth is that you only have to load what you need. So, if designed appropriately, one could load the FP core, then load just the functions they need, saving memory.

In TF you have pretty much the full 32 K (about 31.2K) available, plus SAMS support. I'm sure a similar amount of RAM will be available to TI Forth users if Lee's project to port it over to a cartridge is successful.

+Lee Stewart · September 7, 2012

OK, Horner's Rule says, for a polynomial in x, to factor powers of x to reduce the number of multiplications and the likelihood of large-number subtractions that introduce unnecessary errors into the calculation. For example,

1 + 3x + 4x² + x³ + 6x⁴ can be factored into ((((6)x + 1)x +4)x + 3)x + 1.

This allows setting up a calculation loop that initializes the result to 0, starts with the innermost '()', adds the next coefficient, multiplies the result by x, repeats the loop with the next coefficient through the next to last term, exits the loop and adds the final coefficient to give the result.

For the arctan x polynomial,

arctan x = a₀x + a₁x³ + a₂x⁵ + a₃x⁷ + ... = (((((a₉)x²+ a₈)x² + a₇)x² + a₆)x² + ... + a₀)x.

The only difference between the arctan x equation and the first example is that the recurring factor is x² and the loop result is multiplied by x to get the result because there is no remaining constant term.

...lee

Edited March 31, 2015 by Lee Stewart

+Lee Stewart · September 8, 2012

@Willsy...

It might be convenient to have two or three additional 8-byte areas in scratch-pad RAM for floating point math for the GPL-less routines we :twisted: <hint> <hint> are developing. I don't think your memory-map document is up to date on what is actually available without reloading TF inner interpreter stuff. I suppose we could just use the FP stack. It would probably be faster than the stack in VDP RAM used by some of the GPL FP routines.

And, while we're at it, do you think we should add an additional place to the exponent for FP strings displayed in scientific notation? It seems a bit silly that perfectly legitimate 3-digit exponents are displayed as two asterisks. For example, 1.234 x 10¹²⁰ is displayed as 1.234E+**. It's a good TI FP number and IMHO ought to be displayed as 1.234E+120. This is a function of the console conversion routines, so TI Basic, XB and TI Forth all suffer the same malady; but, while(if) we rewrite those routines, we have the power |:) to change it.

...lee

Willsy · September 9, 2012

I'll send you the latest build of TF later today. It's faster than all previous versions, three instructions having been removed from the inner interpreter due to reversing the direction of the return stack.

This means that yes, the footprint of scratchpad is different.

Since we wouldn't be using GPL for the FP stuff I don't see why you can't use the GPL workspace at >83E0 for storage.

I imagine KEY may use that area (as it uses the TI Rom KSCAN routine). Would also need to check the interrupt routine in the console. However, even if they do use the same area this may not be a concern: in TF vdp interrupts only fire during words that access vdp and KEY is called by EXPECT - neither of which would affect a running forth program doing fp stuff, if you see what I mean...

Mark (by phone - typos!)

+Lee Stewart · September 9, 2012

Using the GPL workspace sounds good and may be sufficient. We'll need to work that out after deciding exactly how to implement the FP and Transcendental package. At the least, the MDOS package is about 6KB as it stands. There are obvious reductions in size possible, but I have no clue whether they would sacrifice speed. For example, there are many places where the same 8 bytes are used inline to move 4 words. Lifting those out to a subroutine won't save 8 bytes every time; but, some of those bytes would be saved every time, reducing the footprint of the package. I am certain there are other places we could save space.

Another option would be to exactly reproduce the GPL/XML package in AL. This process would be very painful, however. The routines are very convoluted in that each routine is littered with calls to other, smaller routines in console GROM and ROM. This was undoubtedly done to pack a lot of stuff into the smallest possible space, making any attempt at translation to our package extremely difficult, but not impossible.

...lee

Willsy · September 9, 2012

Lee,

Attached: Latest build of TF V1.2 - not tested on a real 4A.

Scratchpad usage is from >8300 to >835B inclusive, as follows:

$8300 - $831F - Workspace registers. TF only uses one register file.

$8320 - $8325 - DOCOL

$8326 - $832B - NEXT

$832C - $8331 - EXIT

$8332 - $8339 - bridge routine to jump to an address in bank 1

$833A - $833F - bridge routine to return to the calling routine in bank 0

$8340 - $8349 - get speech synth status subroutine

$834A - $834B - data read from speech synth

$834C - $8353 - ISR despatcher for ISR in bank 1

$8354 - $835B - ISR return subroutine

TF does not use any other PAD locations, apart from the normal offenders that are dictated by the TI ROM/GROM. For example: The key detected by the KSCAN routine is loaded into >8375 - nothing I can do about it. The address of the PAB length byte in VDP must be loaded into >8356 etc.

Hopefully you can find 8 or more bytes to steal out of the spare space. Looking at >835C onwards in the classic99 debugger it looks like there are a few 'windows' where you can safely steal 8 bytes here or there.

Another place you can steal 8 bytes (if using machine code) is by stealing the last 8 bytes of TF's register file. You could use the pad covered by R12 to R15 inclusive during the execution of assembly code. TF actually uses R12 as a pointer to NEXT, but you could restore that at the end of your assembly code.

It's unlikely that PAD usage will change at this point. As long as it runs on the real deal, we should be good.

Mark

TF-V1.2-9-Sept-2012.zip

Willsy · September 9, 2012

Lee,

As I think you're already aware, V1.2 currently has WORDS removed. I'll try and shoe-horn it in when I've done all the other changes that I want to implement.

In the meantime, here is a quick version I just knocked up:

: wwrap ( len -- len)
 \ move to next line if string won't fit on remainder of line
 dup xy? drop + xmax >= if cr then ;

: .name ( dict_addr -- )
 \ display name of word at dict_addr
 2+ dup @ 15 and swap 2+ swap wwrap type  2 spaces ;

: words
 0 \ word count
 latest \ dictionary entry to start from
 begin
   @ dup while
   dup .name
   swap 1+ swap
 repeat
 drop  cr . ." Words found" CR
;

For some reason it displays EXIT twice at the end with a little bit of garbage. I don't know why - it took about 4 minutes to write so I haven't spent any time on it

Mark

+InsaneMultitasker · September 10, 2012

Just a note for future consideration -- DSR level 2 opcodes (ie, direct write, direct read, rename file, etc) require the use of PAD RAM. The programmer can tell the DSR which bytes to use but if you ever want to write programs using those routines, you'll need 14-28 bytes depending on the routine. Of course, you can always save and restore PAD RAM before and after the operation in a pinch...

+Lee Stewart · September 10, 2012

Does anyone know whether there are any documented bugs in the console GROM/ROM FP and transcendental routines?

...lee

Willsy · September 11, 2012

I've never heard of any. I think the TI FP implementation has a very good reputation - for accuracy, if not speed

+Lee Stewart · September 12, 2012

H-m-m-m... The reason for the garbage at the end is that the LFA of EXIT does not contain 0 as it should IMHO. It points to the address immediately preceding, which does contain 0. By that time, however, words is still going, strips off the last nybble of the LFA of EXIT , which is Ah; so, it dutifully prints out the last 10 characters we see. The definition of words will work if you add @ between dup and while to test for 0 in the preceding word's LFA. I do think that EXIT's LFA should contain 0, however.

...lee

Willsy · September 12, 2012

Ohhh... You're such a genius, Lee! I wish I could be you for a day! That "bug" has been in TF since day one! My goodness me! Thank you for pointing that out... Good job you have the source code, eh?! ;-)

+Lee Stewart · September 12, 2012

You're far too generous, Mark. I do have a bit more discretionary time than you. It is, indeed, nice to have the source code to inspect; but, this one I found by dumping memory around the dictionary entry for EXIT .

...lee

Rod Van Orden · September 16, 2012

Hello All!

I was double- checking some things on all the emulator / simulator environments, and I came across something

unusual..... I don't know how I missed it. Everything seems to load and work great with other emulators, however,

I am unable to get the Floating Point Library to load and run under either TF V1.1 or V1.2 for Ti994w. The last time

I checked it was under TF V1.0, and the FP library does load successfully when running TF V1.0.

The error message says there is an unknown opcode. I will be more specific tomorrow when I have my notes in front of me.

Naturally, I suspected the most likely problem might be a bad file (any type....), so I re-installed several things.

And I get the same error. That value is: $835C. I thought that a bit odd, because that value is the hex value assigned

to FP Constant _arg......

Does anyone get the same thing from Ti994w ?

Rod

+Lee Stewart · September 17, 2012

Rod...

It works fine for me. Are you using the latest build of TF1.2? It's in post #41 above. For Ti994w, you need to rename the BIN files in the System directory by first erasing the old TF BIN files (TurboForth_B0.bin, TurboForth_B1.bin) and renaming the 'C' and 'D' BIN files (TurboForthC.bin, TurboForthD.bin) to TurboForth_B0.bin and TurboForth_B1.bin, respectively, to replace the files you just erased. Attached is my latest BLOCKS file to compare what I have for FP stuff with yours: BLOCKS_LES02.zip

...lee

Edited September 17, 2012 by Lee Stewart

TurboForth V1.2 (Beta)--Evolution & Arcana

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members