JamesD

After some thought, this is probably what I will do. I'll divert the normal GOTO & GOSUB tokens to routines that turn the 16 bit line numbers into pointers, switch the code to alternate tokens, and then call the normal function. I don't have to worry about ON, I'll just keep converting until I get to a : or the end of the line, skipping commas if there are any. After that, the GOTO or GOSUB will just load the pointer as if it had already searched for the line number, and will continue normally from there. There's no startup delay, numbers only need converted when the GOTO or GOSUB is executed, and execution is always fast after that point. Converting back will have a delay, but that's not such a big deal as it only has to be done once before entering multiple new lines. Atari BASIC will probably need tokens just due to the ability to use variables instead of constants. I thought using tokens might allow me to add GOTO variable capability to MS BASIC, then I remembered that floating point doesn't represent all numbers exactly. Do I truncate? Round down? Round up? Want a reason to use BCD? This is a good one. If I can simply truncate numbers to represent the entire BASIC range, I may add this feature. Changing to 16 bit integers, and pointers does present a few challenges on MS BASIC. The code that scans through a line assumes ASCII, and isn't smart enough to skip these, so I *may* need to use tokens as well. Maybe use tokens $FE, and $FF so I can just test for > $FD or something like that. I'm not sure yet though, $FF was used on Extended COLOR BASIC for 2 byte tokens. Guess I could to the same with $FD. MS BASIC is (was) very dependent on searching for zero as an end of line marker. If it has to drop to the next line, it searches for the end of line marker even though the first thing on a line is the pointer to the next line. Yup, if there is an IF at the start of the line, and the line is 200 characters long, it has to skip over 190+ characters to find the next line. After I started keeping the pointer to the current line rather than the current line number, that went away, but it still has to skip constants searching for the next statement, and I'm sure for a few other things. If I want to convert ALL constants, not just line numbers, I'll have to use tokens to distinguish between INT, FLOAT, and variables. But regularly used constants can be defined at the top of the program to skip converting the type, so this isn't as big of a deal there. I do need to see if I can speed up searching the variable table, or eliminate the search completely. Sorry if I've hijacked the thread a bit, just thought some of this might be useful to further speed up Atari BASIC as well. We have some of the same issues to deal with.

For the discoloration... A friend suggested Xylene for removing the smoke from my machines that had smoke damage from a fire. Haven't tried it yet myself, so test in an area that isn't visible first. The stuff in nail polish remover (Acetone) will certainly do the job, but it will also melt the plastic. You can do a quick wipe, and rinse fast before it really starts melting (think model glue here), but think of it as a last resort. I used carb cleaner, which contains acetone. Just don't touch it for a few hours until whatever is left dries. That way if it does melt the plastic a little, you won't mess up the surface. Frankly, I would practice on something you don't care about first before trying it. But, it was the only thing I've tried that did remove the smoke, and it did it almost instantaneously.

I fixed my Apple III, got it to boot, then sold it. The OS, and some of the software was sort of advanced, but not enough to justify keeping the huge beast. Freakin heavy!!

Same thing happened with some smart TVs. I deleted the remaining apps from my "smart" TVs, and picked up a couple ROKUs for free with SlingTV.

Free https://freebies.indiegala.com/ceville/ https://store.steampowered.com/app/973000/Die_Young_Prologue/

Fanatical has Quantum Break for $9.99. It looks interesting, anyone here play it before? https://www.fanatical.com/en/game/quantum-break Never mind, it's that price on steam without going through Fanatical. Steam reviews are "Mostly Positive"

I am not taking the time to break that up this time, so... sorry in advance. (incoherent rambling may follow) I considered conversion during runtime, and to use tokens. Part of the reason I didn't want to do it during runtime, is that I didn't want to use additional tokens, it's just another byte to parse every single time, and not doing that leaves more room for code. If I convert the number when the line is tokenized, the slowest part is already done. If you could just search for the INT/POINTER tokens, this would be a no brainer, but you can't since embedded ints/pointers means some of those numbers could match the tokens. So you have to parse the line in an intelligent manner. This is probably the best excuse for making the change during runtime, tokens or not. Either way, you still have to scan every line converting pointers back to int line numbers before you enter/change new lines, or save the program. An alternative (just thought this up), would be to give GOTO and GOSUB alternate tokens. When you encounter the tokens that signify INTs follow at runtime, you convert the #s that follow, and update the tokens, then call the alternate routine for GOTO/GOSUB... or part of it anyway. It eliminates the delay at startup, and you don't have to constantly check whether numbers are ints or pointers. If you keep a table during conversion from line # to pointer, it would certainly speed up converting line #s to pointers. If you convert when you type RUN, the table could reside in variable space during conversion, and could be ditched once conversion is complete. That way it wouldn't take additional RAM. I wouldn't bother during runtime. The first use of a GOTO/GOSUB is only going to be a few clocks slower than before, and then it's faster after that. The speed penalty of searching for a line number on the 6803 & 6809 isn't so bad since the index register(s) are 16 bit, and you have a 16 bit accumulator to compare the line # when you are converting to pointers. You compare high and low bytes with a single instruction. And this is actually a small amount of what the interpreter is doing anyway. Converting back to ints is simple on the 6803/6809 since the pointer already points to the destination line location. In my case (off the top of my head), you do something like this once you find a pointer token: LDX CHRPTR ; point to current parse location (CHRPTR is direct page pointer to current parse location) LDAB #INTTOKEN ; get token for integer STAB ,X ; change token from pointer to int LDX 1,X ; load the line pointer (address of pointer token +1) LDD 2,X ; Get 16 bit int line # (lines start with pointer to next line, followed by line number as 16 bit int) LDX CHRPTR ; get current parse location pointer STD 1,X ; change pointer to line number INX INX INX STX CHRPTR ; update location to continue parsing from If you ditch the token, it's slightly smaller. This assumes the pointer is pointing to a GOTO or GOSUB token, or comma in the event of ON GOTO/GOSUB: LDX CHRPTR ; point to current parse location (CHRPTR is direct page pointer to current parse location) LDX 1,X ; load the line pointer LDD 2,X ; Get 16 bit int line # (lines start with pointer to next line, followed by line number as 16 bit int) LDX CHRPTR ; get current parse location pointer STD 1,X ; change pointer to line number INX INX INX STX CHRPTR ; continue parsing here That would need updated for alternate GOTO/GOSUB tokens. The 6809 could use LEAX 3,X instead of multiple INX instructions, or something like that.

There is another drawback. If you haven't finished typing all the code, and some line that hasn't been entered yet is referred to with a GOTO or GOSUB, you would necessarily get an error when you type RUN.

I wish I knew! At least we used to be able to edit the formatting. There was an OR there. Several Microsoft BASICs fit in 8K, but they don't support extended BASIC graphics or sound commands. Integer BASIC on the Apple had a few extended BASIC type things. I can't remember how large it is though. I don't know what Atari BASIC does, but MS BASIC does not convert line numbers in GOTO or GOSUB statement to 16 bit integers during tokenization. It does use 16 bit integers to represent the line number in the structure before each line of code. Every time it executes a GOTO or GOSUB, it has to parse the number from ASCII to a 16 bit int, then it searches through the linked list of lines looking for the 16 bit integer of the line you are jumping to. I wanted to convert the ASCII to INTs when the line is entered (which by itself would be a big improvement), then convert those to pointers when you type RUN, so all the lookups take place before the code executes, and just directly jump to the line without any kind of search after that. Not even a table lookup. The drawback, is that you have to enter a non-runtime mode before you can actually add more lines, change lines, or save the program. Would it be faster? Yes! But the mode switching, even though it could be automatic, would create a few delays as the interpreter performs the conversions.

Free https://freebies.indiegala.com/space-pilgrim-episode-i-alpha-centauri/

The only 8K BASIC interpreters I'm aware of either don't have floating point math or any extended BASIC commands. The MS BASIC floating point libraries I've looked at take up around 2K. That doesn't leave a lot of room for for speed optimizations. @Maury Markowitz, I was looking at using tokens to identify what type of value followed to speed up the BASIC on the MC-10, and to do the conversions at tokenization time as you suggest. To store floating point numbers, I planned on using pointer to a location in a table with the FP value, and the original string. Numbers don't convert exactly when using floating point, so the original string needs preserved somehow. Plus, Microsoft BASIC has to copy the floating point number to a virtual floating point register, and the function that does that requires a pointer anyway. I also considered converting line numbers to pointers, and the original ASCII line number can be generated from the line the pointer refers to. This makes the interpreter faster, and listing the file or editing a line easy, but saving the program in a compatible format is a little more difficult on a machine with only cassette tape with no on/off control. 🙄

My apologies. I did not intend to misrepresent his original statement, just to point out that the idea of replaceable drivers for devices predates the Atari. Microsoft BASIC clearly is not a full OS (a fact I previously admitted). CP/M and FLEX (which I already mentioned) are operating systems and I/O is handled through device drivers which could be added/changed, and you could add additional commands to both operating systems. FLEX pretty much duplicates (though not quite exactly) the calls used by CP/M, but has entirely different commands. CP/M 86 is a re-implementation of CP/M for the 8086, and it's pretty much what MS-DOS was based on. If MS-DOS doesn't measure up to AtariOS, they I guess neither of those would as they work very much like MS-DOS, and that would mean I haven't refuted that point, and I apologize for upsetting everyone.

Huge difference between hyperbole and a straw man argument Here is what I replied to: Note that in the same post you claim is a straw man, I actually refute his original claim, not some made up position that was not his to begin with. Hence, it is not a straw man argument. Go back to your high school debate teacher and ask them.

Hyperbole noun Rhetoric. obvious and intentional exaggeration. an extravagant statement or figure of speech not intended to be taken literally, as “to wait an eternity.”

It's a combination of BASIC and I/O functions. Not everything used the built in I/O calls, but any program that used the documented ROM calls for I/O would make use of any custom drivers. Was it as complete as on the Atari? No, largely because the DOS was separate, but then the first personal computers released didn't even have disk drives yet. Atari benefited from being released later. CP/M, and FLEX had their own driver system as well. CP/M was released in 1974, FLEX in 1976. Did they work like Atari? No, but trying to say Atari was some super advanced micro vs everything else before it is an exaggeration.

Not really, device IDs and handlers were in Microsoft BASIC from the start. You can replace the default drivers by intercepting one or more of the 14 or so extension hooks BASIC calls, which includes console in, and console out.

https://freebies.indiegala.com/the-deed/

Hmmm... it's almost like the Atari has a 1.7 x advantage in clock speed. 🙄

Other hardware resources: https://boysontech.com/ http://www.go4retro.com/

There are several other resources you could check out. There is a discord server dedicated to the CoCo, facebook pages, the Color Computer Mailing List, CoCoTalk weekly live talk show, the CoCo Crew Podcast, etc...

I suggest you start here: http://www.colorcomputerarchive.com/

Free https://freebies.indiegala.com/gateways/

Still showing up for me. It's a facebook video, maybe Bruce blocked you on facebook.