Willsy

A better version would be: : CALL ( -- ) ; IMMEDIATE This will take up precisely 0 bytes (and therefore 0 time) when you use it in your own words. Boot up TF from the normal disks, and load block 27 from the UTILS disk (the SEE decompiler). Then try this: : CALL ( -- ) ; IMMEDIATE; : TEST CALL 1 2 + ; SEE TEST As you can see, the word TEST has no reference to CALL at all. CALL is just syntactic sugar.

Electrolytics don't normally pose a problem... Until they do The problem is as they age, they turn into resistors. They can can still add capacitance (though they will be off spec) but they develop a (very low) resistance, the equivalent of placing a 0.5 or 1 ohm resistor across them. It wouldn't be so bad if the resistance was very high, but because the resistance is low, it causes the power supply to work much harder (and therefore get much hotter) than one would like. Eventually, something in the power supply will give up. You'll think it was a power supply problem, but in fact, the power supply failure would be a symptom, not a cause. I see this in old amplifiers all the time.

AFAIR, yes. Agree. In a game or something, it would be better to write to the screen timeout counter periodically in some other routine away from the main loop. The word JOYST in TF also sets >83d6, so if you're using joysticks it already taken care of. It actually writes the value 36, which appears to be the base CRU address for the joysticks. https://github.com/Mark-Wills/TurboForth/blob/main/bank1/1-02-Console.asm

I tried, but I couldn't get past the colours and the the 1997 design! But hey, it's good that someone is writing about the 9900. It's a very esoteric design, so I think we can forgive some factual errors.

Yeah - it's included in TF. I just checked its definition as I was worried it may have been somewhat nieve (thought it might be nesting, leading to a potential return stack overflow - but it isn't). I think it's okay, it's defined as: : THRU ( start-block end-block -- ) 1+ SWAP DO I LOAD LOOP ; See https://github.com/Mark-Wills/TurboForth/blob/main/bank0/0-18-Blocks.asm

Shhhirely it's missing an IMMEDIATE tag?

It's none of my business but I'm inclined to agree. If it ain't broke don't fix it! If you were starting out from scratch there might be an argument for using C, assuming the current crop of C compilers targeting the 9900 are good enough. From what I've read here on Atariage, I think there's sufficient grounds to argue they are too buggy at the moment.

That's neat. The old 9900 is so versatile.

Yes - change those electrolytics out if you're going to change anything.

Have you looked at MARKER? That might be what you're looking for. Nice to see someone playing with TF

The assembler commands are probably (speculating) a linked list. Might be relatively simple to view the assembler executable with a disk editor and follow the links to each command. I'm fairly sure it assembles a larger set of commands than the 9900 provides.

Agree 100%. I'm currently developing a serial comms driver for old RTUs (like a PLC) in C#. The object model I've come up with is simple, and reflects how the RTU works. A very simple class structure. I'm also writing an emulator for these RTUs as the hardware is obsolete. Again, C#, but running in Linux. Lots of fun. I've already been asked why I'm not using abstract classes and methods etc. The answer? I don't need them. At the company I consult for, the developers are young and VERY sharp. Really clever guys. They laugh at me because I tell them to STOP WRITING CODE! Try and spend an hour or so every day REMOVING CODE if you can! Do not add unnecessary layers of abstraction. This isn't a dick-measuring contest. Just stop it. Write what you need to get the job done ONLY. That's probably why I liked Forth so much. That's the entire ethos behind the language.

Talking of neat stuff, have you looked at OOP? I may have the authors name wrong, but if I remember correctly, Dick Pountain wrote a book on object oriented programming in Forth. IIRC it's based on Forth 83, and relies heavily on vocabulary manipulation to manage private class methods etc. I imagine it would be really fun to port it across to your Forth system - or, just use the book as a guide to learned how he modelled the design, and put something similar together from scratch. Just had a quick check. The author is indeed Dick Pountain. The title is Object Oriented Forth - Implementation of Data Structures. Object-oriented forth Implementation of data structures by Pountain, Dick (z-lib.org).pdf Source: https://archive.org/details/object-oriented-forth-implementation-of-data-structures-by-pountain-dick-z-lib.org The book is fetching ridiculous money online - around $50. I bought it probably ten years ago for a few quid! Not sure if you've seen this book before but I think you'll love it!

For me, it would be BBC BASIC. It offered full access to all the machine's features. It even had a built in assembler. You could write assembler *in-line* with your BASIC code, and it would just work. The language could be esoteric though. *FX commands, anyone? VDU commands? All a bit weird, and probably arose out squeezing as much into the ROM as possible. A very good machine for its time. It had named functions (DEF PROC!), integer variables etc. Excellent.

Are you seeing simple 'tearing' - adjusting the sprites when they are actually being drawn? One way to get around that would be to try and do it in the vertical blank period. That would depend on when the VDP interrupt fires I guess - beginning or end of frame etc.

^^^^ what he said

Me too. I was going to give a shit today, but then on reflection I determined that I didn't give a shit about giving a shit, so I just left it

Domain Specific Language is the term, I believe. Of course, Forth is a general language, but with its ability to call a word anything, and the fact that the language itself can be extended, its very open to use for production of DSLs.

So impressed with what you're doing. This would have been a killer app back in the day. I'm not joking when I say if you'd written this for the Apple II, C64 and early PCs you would be a millionaire today. It's similar to a program for the PC called Ability+. Ability+ was a word processor, spreadsheet, and database all in one application. For example, you could enter data into a database, and that data could be queried to populate a spreadsheet - change the data in the data in the database, and the spreadsheet changes. You could then include that spreadsheet in a document, and again, if you change the data in the database, the spreadsheets updates itself, and so does the document. It was an early form of object embedding I suppose. Worked a treat. Ran on a 640K PC IIRC!

Just an observation that line ORI R0,>E0A5 - that might want a comment to explain what the 'magic number' EA05 is

Yes. Or rather, I'm suggesting that such an approach would be low-hanging fruit in the design on a new BASIC interpreter. Your point about bounds checking at run-time is a good point. Personally, I'd have a switch allowing bounds checking to be turned on and off, allowing a well-running program to benefit from further performance gains. One reason for Forth's speed is its lack of bounds checking, or indeed any other sanity checking. You're completely free to screw your program (and the system) up in any way you desire. This is possibly a step too far for BASIC systems.

I'd say of all the issues with a BASIC interpreter to be solved, the threading model and address lookup/execution model are one of the less contentious issues. One of the main issues is the syntax validation and error checking that takes place at runtime, rather than when a line of BASIC code is crunched/tokenised. A case in point: 10 CALL HCHAR(1,2) This line is completely invalid in TI BASIC/XB and results in an INCORRECT STATEMENT error. However, there's no reason why that particular error (missing argument) could not be caught at compile/tokenisation time. However, the interpreter writers chose to do it (and most BASIC interpreters do this, to be fair) at run time, presenting a further runtime penalty. This is a long-winded way of saying "Yes, you're probably right!" - but I did pre-qualify my ill-considered statement by saying it was based on no research at all - and it was! Read at your own risk It's an interesting point though isn't it? There is a lot of syntax validation that occurs at runtime that should be caught at compile time. E.g, missing operands, un-balanced parenthesis etc, which would all contribute to faster run times, even for interpreted code.

It's a neat idea, but, without wishing to derail the topic from improving TI BASIC performance, I think at that point, you might as well invest the time in learning something like Forth, or assembler, or, of course, compiling the BASIC code which already works superbly well. My preference would be to junk the internal ROMS & GROMS and just replace them entirely with something completely new and not related to the TI system in any way. A blank sheet. Not an easy feat of course, because the cards in the PEB (e.g. disk controller) have certain expectations and dependencies. But it would be a great way to develop a basic interpreter on the console that is not shackled by the GPL interpreter. It should be possible (based on no calculations whatsoever ) to produce a BASIC interpreter that runs at, say, half the speed of a Forth system. I say that because a BASIC system is always interpreting the tokenised code, whereas a typical Forth system isn't normally doing that - it's executing a bunch of subroutines one way or another. But if you replace the internal ROMS is it still a TI? I was keen on replacing the internal ROMS in the TI with TurboForth (since it fits in 16K) - it would be running on the native 16-bit bus so would be faaaaast - but.... Is it a TI? And... there would be a lot of stuff to redevelop - the DSR system (DSRLNK), XMLLNK etc which would probably be required for interfacing with the PEB cards. Not an easy job. TI/Microsoft really did a remarkable job back in the day with what they had.

What Lee said! Post a snippet of the code in question!

Yes, that's a major improvement - nice job, Rich.