Reciprocating Bill

A couple more datapoints: Cortex BASIC, 16-bit RAM in console, running entirely from 16-bit RAM: 231 seconds Cortex BASIC, 16-bit RAM in console, running from FinalGrom99: 297 seconds (I don't have a stock console set up to run this on)

Interesting to see this thread resurrected - not only with the Dimension 4 photos (amazing!) but also the Foundation CP/M scans globeron posted on the first page. The Foundation literature is weirdly barefaced about its unfairness, at least regarding their use of benchmarks to contrast the 9900 and the Z80a. The second benchmark, a block move of 1000 bytes from one location to another, exemplifies this. The Z80a accomplishes this in a fast 5.25 ms, using a single dedicated block move instruction. That’s a cool feature, but one cherry picked to give the Z80a maximum advantage over the 9900. Foundation calculates the 9900 will require a miserable 29+ ms to accomplish the same block move. But that's with everything arranged in the worst possible light. Here are some numbers I obtained. They speak for themselves. 99/4a with 16-bit RAM in console: 500 16-bit MOVs: 8.5 ms. 1000 MOVBs: 15.5 ms. Stock 99/4a (emulated with Classic99), registers in scratchpad: 500 16-bit MOVs: 12.7 ms. 1000 MOVBs: 23.5 ms Stock 99/4a (emulated with Classic99) registers in 8-bit RAM: 500 16-bit MOVs: 16.5 ms (essentially 1/2 as fast as 16-bit RAM) 1000 MOVBs: 31.5 ms. Related, kinda: The January 1983 BYTE article reports the Z80 executing 10 iterations of the Sieve in assembly in 6.8 seconds. My 16-bit 99/4a does the same 6.4 seconds, a stock console in ~10 seconds (registers in scratchpad). The fastest Z80 running interpreted BASIC under CP/M executed 10 iterations of the Sieve in 1476 seconds. (In a later review the TRS Model II did so in 1440 seconds.) My 16-bit console running Cortex BASIC entirely out of 16-bit RAM executes the Sieve in 1313 seconds. Running out of the FinalGrom (with some of the interpreter therefore executing from 8-bit RAM) it executes in 1781 seconds. (I don't have numbers for a stock console). The fastest Z80 Forth execution of the Sieve is reported at 75.9 seconds, while FIG Forth executes in 84 seconds. Wycove Forth 3 (descended from FIG Forth) executes the Sieve in 92 seconds given 16-bit RAM. It would probably clock at about 130 seconds on a stock console.

It's understandable to feel retraumatized.

I wonder - since the early clock is set individually for each sprite, you could have a sprite with the appropriate early clock slide in from left, then, once it is fully visible, substitute an identical sprite at adjusted coordinates with it's early clock set for a smooth exit on the right and have it continue the journey.

Ti's original LINES running out of MiniMemory, My LINES running out of 8-bit SuperCart memory, and My LINES running in 16-bit RAM TI Lines.mov My lines out of SC.mov Fast Lines.mov

Interesting. To my eye it appears that the lines themselves are drawing more slowly. But overall there is less than a 10% difference between Cortex running from all 16-bit RAM and running partially out of cartridge ROM, with this particular program. Has anyone ever disassembled the TI/Minimem Lines program, or otherwise seen the source?

Here's another datapoint - Lines in Cortex BASIC running out of FinalGrom on a 16-bit console - so some of Cortex is running from cartridge space. Significantly slower than running purely out of 16-bit RAM, looking to me like the line drawing routine runs out of 8-bit cartridge space in this setup. Lines Cortext from FG.mov

More a jewel thief than a veteran. I borrowed from hither and yon. The Bresenham routine is a translation from the pseudocode in the Wikipedia article, combined with the E/A calculation for byte and bit offsets. I picked up the bit mask operation here somewhere. The RAND routine is purloined from TI's book, "16-Bit Microprocessor Systems" with, IIRC, a dash of Tursi wisdom, (the last few instructions, which constrain the output to the limit set in RNDLMT.) And, of course, the core routine is from senior_falcon's code in Cortex BASIC.

E/A source ("LINES4") and option3 executable ("LINES4O") attached. Program name "START." Hold option Quit to exit. I found an optimization, so this is a bit faster than posted above. LINES4 LINES4O

My assembly version of "Lines" (16-bit console, based on senior-falcon's Cortex BASIC version): Lines Assembly.mov

Chichen Itza, for example, which is in Yucatan:

This was Jaak Panksepp's work on "affective neuroscience" (the neuroscience of emotion, sociality, bonding, play, etc. in mammals, including ourselves). Rat laughter during play occurs at a frequency well above the limits of human hearing. I heard him present on his research at Akron University. He has since passed away.

BTW, your cover art pyramid most closely resembles a Mayan structure (southern Mexico, Central America), but Incan ruins characterize structures found in Peru (e.g. Machu Picchu). (Slips out the back dodging boos and thrown foodstuff)

It's written in FBForth, and running on real iron, so it's tricky to get a listing. As a workaround I've pasted the four screens of which the program is composed here - not sure what the result will be...

This discussion is making me think of Heathkit. Aw, now I'm getting all misty.

Circle Illusion.mov

It would be cool if just the floating point format and routines could be extracted and made available, to be called from an assembly program.

First the GPL call for "honk." Then E/A manual page 323.

The only practical way to do this is using the MiniMemory cartridge - which the FinalGrom can emulate - along with the very basic Line by Line Assembler (also available on the FinalGROM). This enables assembly programming with a pair of tweezers. You'd have approximately 4k of CPU RAM to work with and save and restore to cassette. The Mini Memory can also store files created by TI-BASIC, but (IIRC) it can't be configured simultaneously for file storage and assembly programming. Further, the file storage feature is only useful with the actual physical Mini Memory cartridge, which has a built in battery and can retain its contents when removed from the console. Fully equipped, the system supports three floppy drives. The TIPI provides (by far) the best drive emulation (and much more). Writing and reading to it seems to be about 3x faster than to/from floppy. Storage with the TIPI is almost unlimited, for all practical purposes (small TI files, gigabytes of SSD storage via raspberry PI). Groms are serial devices running on their own very slow clock and executing programs running on what amounts to a virtual machine (the GPL interpreter). The 16-bit thing is an historical shit-show all its own. RAM expansion is on the 8-bit bus with wait states for multiplexing. But there indeed are modifications that piggy back 32k of of 16-bit RAM onto the ROM chips, putting the expansion on the 16-bit bus, no wait states, and providing up to a 50% performance kick. Alternatively, there are cards (the SAMS being the most prominent) that provide paged RAM WAY beyond 32K. Can't have both, though.

My first post was way better than your first post.

Cortex BASIC does not feature named subprograms with local variables. (What other BASIC of that era did?). Indeed, Extended BASIC has many rich hardware features that Cortex BASIC lacks. Which makes sense, because CBASIC did not originate on the 99/4a. But what it does have should be evident here (keep in mind that this is on a 16-bit console): IMG_2943.MOV

Henry's Cortex LINES on 16-bit console. Lines T 480.mov

From the manual: So it's a binary format (right?)

This any better? Cortex FP format pdf.pdf