BASIC floating point routines in GPL or native 9900 code?

[JamesD]

Are the TI-99/4A's BASIC floating point routines written in GPL or native 9900 code?

The topic of benchmarks came up again in another thread and the Creatavision is faster than the TI for AHL's benchmark which depends heavily on floating point but then the Creatavision is much slower for other benchmarks.

Both machines are crippled for CPU RAM and mostly use video RAM. I'm sure the Creatavision's BASIC sucks so why the slow floating point lib on the TI?

[+Lee Stewart]

Are the TI-99/4A's BASIC floating point routines written in GPL or native 9900 code?

...

*

Yes.

 

The ADD, SUBTRACT, MULTIPLY, DIVIDE and COMPARE, as well as all but one of the conversion routines (STRING-TO-NUMBER, FLOATING-POINT-TO-INTEGER and INTEGER-TO-FLOATING-POINT) are native 9900 code. One version each of the first five routines uses the Value Stack (in VRAM). I'm guessing that version is used by TI Basic, so would slow it down a little.

 

The really time-consuming routines are GPL code: INT, ^, SQR, EXP, LOG, COS, SIN, TAN, ATN and NUMBER-TO-STRING. They also make extensive use of the Value Stack in VRAM.

 

TI Extended Basic reinvented the wheel for a lot of what TI Basic does. I don't remember whether that includes some or all of the FP routines.

 

...lee

[JamesD]

How big is the Value Stack? Just wondering if more scratchpad RAM and some patches could speed things up.

[+Lee Stewart]

How big is the Value Stack? Just wondering if more scratchpad RAM and some patches could speed things up.

 

128 bytes—enough for 16 FP numbers. It's not protected, however. You can move it around in VRAM by changing 836Eh, which points to it. I neglected to say that there is another area that cannot be moved that is used by the GPL routines—the VDP Rollout Area, which is 32 bytes at VRAM 03C0h. You probably cannot patch the console GPL and ALC that is used for those routines.

 

I adapted the Geneve MDOS FP Library (5740 bytes) to run in the lower 8KB of the expansion RAM. It is all ALC and uses FAC and ARG in PAD RAM for passing arguments back and forth. There is a LOT of discussion in this thread: TurboForth V1.2 (Beta)--Evolution & Arcana. If you want to look at the source, I can post it. I'm not sure it's in the aforementioned thread.

 

...lee

[JamesD]

I don't think I'll need the source. I have too many partially completed projects already.
I took a quick look at 'TI Intern' and it shows stack values are fetched through calls. That would be easy enough to patch to use a different address.
The parser that pushes values onto the stack... not so easy and then there's GROM handling which I only glanced at.

All the stack operations that go through the VDP are 8 bit if I'm following the code correctly.
By moving the stack to 16 bit RAM, floats could be moved 16 bits at a shot in and out of the floating point accumulators which would offer a speed improvement all by itself.

Has anyone taken the ROMs and turned them back into assembly source that can be reassembled?

Edited December 18, 2013 by JamesD

[Tursi]

I don't think I'll need the source. I have too many partially completed projects already.

I took a quick look at 'TI Intern' and it shows stack values are fetched through calls. That would be easy enough to patch to use a different address.

The parser that pushes values onto the stack... not so easy and then there's GROM handling which I only glanced at.

 

All the stack operations that go through the VDP are 8 bit if I'm following the code correctly.

By moving the stack to 16 bit RAM, floats could be moved 16 bits at a shot in and out of the floating point accumulators which would offer a speed improvement all by itself.

 

Has anyone taken the ROMs and turned them back into assembly source that can be reassembled?

 

I copied the source out of TI Intern and reformatted it into a file that could be assembled in Asm994A -- I didn't test the output extensively but I compared a few random addresses and it looked correct. (I did the GPL as well but I did not test that it assembles). You'll find that here: http://atariage.com/forums/topic/185697-sound-list-demo-in-xbasic/?p=2866896

[JamesD]

 

I copied the source out of TI Intern and reformatted it into a file that could be assembled in Asm994A -- I didn't test the output extensively but I compared a few random addresses and it looked correct. (I did the GPL as well but I did not test that it assembles). You'll find that here: http://atariage.com/forums/topic/185697-sound-list-demo-in-xbasic/?p=2866896

Thanks, that's kinda what I was looking for. I'll have to use the original book to find the required addresses but that's minor..

 

Disassemblers that generate source that can be reassembled usually build a table of all addresses called, remove all addresses from the start of line except those called and then convert all called addresses to labels in order to make patching easier. Disassemblers usually an L to the addresses when they turn them into labels so $0455 would be L0455.

 

[Tursi]

Disassemblers that generate source that can be reassembled don't usually start with a textual disassembly of the code in question.