Maury Markowitz

Which BASIC is this on the Atari? That's not stock I don't think?

Why would PAL be faster, less memory contention? BTW, how did TURBO fix that problem, did it build a list of GOTO targets using linenum/address?

OMG, nice work! Any chance of running under stock TURBO? Or did you do that and I missed it?

A couple of weeks ago I came across a 1970s BASIC benchmark suite I had not heard of - it was mentioned here in the forums. So I wrote this: https://en.wikipedia.org/wiki/Rugg/Feldman_benchmarks Is anyone willing to run these through on a NTSC machine in Atari BASIC and TURBO? Others would be nice too, but I'm especially curious about TURBO on the 8th test. It's interesting that I did not hear of these tests at the time - they are much more useful than either Ahl or Sieve, and pre-date either.

Given that there were already a number of publicly available FP libraries using 32 and 40-bit binary representations, why the heck did SMI/OSS write their own using BCD? For instance, Woz had already published a complete FP package in 1976 in Dr. Dobbs, and Atari had already licenced MS 8k basic with their 32-bit code (I'm assuming it wasn't the 40-bit code in the 8k version). They suggest they did this to avoid rounding and presentation problems, but those are minor advantages at best. It seems like they went to a lot of effort to make a system that offered very little in upside and a whole lot of downside in both time-to-complete-the-contract and the performance. However... * has anyone compared the binary size of the original Atari code to Woz's or MS 8k? I would suspect the BCD version would be larger due to the other two being written for extremely memory-constrained systems * given the performance of TURBO-BASIC XL's math package, is BCD FP code *inherently* slower on the 6502? IIRC, turbo blew by Apple by well over 2x that the clock speed might suggest on sieve and Ahl's.

Let us not forget BASIC09 as well: https://en.wikipedia.org/wiki/BASIC09

Fair enough. But posts above lead to a second question: am I correct in thinking the 7800 did not play 8-bit games? I was under the impression the machines were *very* similar, no?

Does anyone have pointers, especially online, of circa 1979/1980 reviews of the 8-bitters? The Wiki article currently has only Infoworld (good) and Kilobaud (meh). Byte, Creative Computing and others surely reviewed them, but I can't find anything on archive.org. (they really need indexes!)

This came up in another forum as well: the MS code is barely optimized for any processor other than the 8080. The Z80 (early?) versions, for instance, do not take advantage of the many features of the Z80 that could improve performance. In the case of the 6502 versions, the strings should have been re-written to work in a different way, but they just used the original code. There's likely a LOT of low-hanging fruit in all of the MS versions.

I'm not sure there is a real answer to this, but maybe someone know: The 7800 appears to be a great advance in graphics over the 8-bit line, especially due to its improved sprite handling. So why, then, did the XEGS ever become a product? They already had the 7800 on the market for a very low cost.

I'm wondering if anyone is aware of an article benchmarking the various drive options on the Atari, starting with the "base 810"? I've been googling, but unfortunately almost every article with "atari" has "disk drive" so you get the Byte benchmark, etc.

Yes, and I recall that BASIC XL's FAST command did the same thing basically. But this uses a little more memory and retains the forward-only search, albeit improved. So if you're not on the 256 boundary, especially if you're the 254th item, the searching is slower than a back-link. Still much better than Atari BASIC, but this can be improved, especially in the close-match case. If your code is repeatedly looping from line 110 to 100, a tiny cache of the last 8 or 16 line numbers is going to kick. As to the labels, yes this is very good, but they should have used the @ symbol. It more closely represents what it means "goto the line at...". I'm too used to using # for hex and addresses! Of course, one could say the same for $... Yes, but it still has to search for that variable during the tokenization, I think that's where this was used. FB examines the entire formula and then decides to build one or the other, right? What if you assume both are possible, build both sets of code, and then drop one or the other as soon as the condition fails? For instance... PRINT 10 + 20 would fail immediately because the 10 is not an integer variable. So this immediately goes to FP. Whereas... PRINT A% + 1 would continue testing both possibilities until it gets to the end. All you need is a flag that any FP-only op turns off. You have to test the constants for decimals, but that doesn't seem like a big deal? This would mean the user would have to understand that using the integers in this manner requires them to write the code in a certain way. But of course, that's exactly what you are doing when you use integer variables. Yeah, but that's a compiler like FastBasic from you, not a crappy interpreter from someone at MS :-) Someone is attempting to decompile the BASIC-PLUS version to see if there is an advantage or not. I'm still not convinced one way or the other.

I'm trying to flesh out the articles related to BASIC on the Wiki and on AtariWIki. As part of this I've been delving into historical BASICs and others that I was not familiar with. And here's some ideas for everyone to chew on: 1) line searching Atari BASIC infamously had to search the entire program to look for a GOTO/GOSUB target, while MS-derived BASICs used a simple trick of starting at the top only if the line number was smaller than the one you were reading. Now I would say that in most programs, most GOTOs tend to be short, maybe a dozen lines in either direction. So in the case of a forward jump, moving forward from your current position is likely to be efficient, but jumping backward from it is not, it has to start at the top. Why? Because the original Altair BASIC, on which everything is patterned, had a forward pointer only, so there was no way they could scan backward. So you could only start from where you were, or the top. Now one solution would be to cache all the line numbers you encounter in a GOTO/GOSUB, but that requires lots of memory even if they are never called at runtime. Another solution would be to put a backpointer on every line as well, but that would use even more memory, and do so for every line instead of just the interesting ones. So what about a trailing XXX lines cache? That is, as you roll through the code you keep track of the last, say, 16 lines, as back pointers. Now on a backward jump, you can scan that list first, and if you don't find it there, start at the top. This is likely almost as fast as full caching, because if you're not jumping back a little, you're likely jumping back a LOT, so a start-from-top would be the right one anyway. This would require much less memory than the other solutions, yet likely offer almost all the same speed. 2) variable lookup I'm not exactly sure what Atari BASIC does here, but I assume its the same as Altair/MS in that there is a list of variable names and their memory locations that it scans when it encounters a variable name in code. One of the really fast BASICs is BBC BASIC and I was curious why and got some great answers. One of the reasons is that instead of one big list of variable names, it has a bunch of smaller ones, I think one for each possible starting letter. I think a great improvement on that would be a shorter hash table, say with 16 entries. This can be hand-shuffled - there's a whole lot of I, J, K and X, Y, Z's in most programs, so maybe they get their own list each, and then sort out the rest into four groups of five letters each, ABCDE, FGHLM, etc. Now you have 10 lists, you can easily figure out which one to start in, and it should be really much faster. BBC BASIC also had a completely separate list with fixed entries for every possible integer variable. This makes sense if you think about it - you use these for speed 3) integer math package One of the great mysteries to me is why the later MS BASICs had integer variables but did not have a separate math library for working with them. Looking into this, it seems the only interest here was saving memory - they did not see people actually doing math on these, but if you used them for indexes and such it could save you enough memory to make up for the slightly larger interpreter size needed to parse them. Of course, this seems odd in retrospect. After all, if you use them as intended, you're likely going to do a LOT of math on them, specifically a +1 in FOR loops. Ok, so we wouldn't put SIN() in the library, but increment, decrement, +, - and maybe even * and / seem like no brainers. And of course a trunk that just does a NOOP would likely be useful too, and perhaps a RND%(), and I'm sure you can all think of others. Now FastBasic does this naturally, but for the other Atari BASICs out there do not appear to have these. Given the savings in code size (or at least memory use) it would seem such a package could be implemented within the 8k limits, a statement I base on the fact that MS's size increased about 1000 bytes with the addition of both 9-byte FP and ints. Aside from pure-int BASICs, like FBI, is there a A%-capable BASIC on the Atari? Did the MS BASICs have this? 4) cool control structures This is a little more esoteric, but cool nonetheless. DEC's line of BASICs derived from Dartmouth BASIC, which is pretty similar to MS. But they then added a feature that did not make it into MS, and I think it's worth mentioning. In BASIC-PLUS, most commands could be followed by a logical operator. So for instance: 10 FOR I=1 TO 10: A=A+A: NEXT I could be written this way: 10 A=A+A FOR I=1 TO 10 Now what's the difference? At first I thought nothing, but then some of the smarter people convinced me this might offer a great advantage in terms of constructing the loop in the resulting interpreted code. For instance, there can only possibly be one operation in the loop, which makes the construction much simpler. Whether this offsets the increase in complexity of the parser I cannot guess. But there were other variations... A=A+10 WHILE I<100 A=A+10 UNTIL I>=100 These are basically different variations on the FOR, but simpler to read. The second one... I'm not sure this really clarifies anything compared to the WHILE.? There's also the one-time versions of the same: A=A+10 IF A<>100 A=A+10 UNLESS A=100 Again, I question the need for the UNLESS version. I still haven't decided if these are a good idea or a distributed cost. Any comments?

Thanks! I didn't find that one.

I'm working on the Turbo-Basic article on the Wikipedia. It currently mentions something called "Ken's Super BASIC", but Google turns up nothing for this. Does anyone know of this?

For those of you who are interested in a quick intro, I've updated the en.wiki and AtariWiki entries for this language. It is the strangest language I have seen, a weird blend of PILOT, Lisp, and psychedelics. https://en.wikipedia.org/wiki/WSFN_(programming_language) https://atariwiki.org/wiki/Wiki.jsp?page=WSFN Apparently it is VERY fast at doing what it does.

This is turning into a fascinating thread! So it sounds to me like the Turbo math package would be too large to use as an outright replacement for the one in the original ROMs - I assume that based on loop unrolling, which would normally increase the size more than any offsetting code cleanup might accomplish. But what about the AltirraOS and OS++ versions? Would these be suitable for drop-in replacements if someone wanted to burn a new ROM for an 800? Are the entry points the same? The E: accelerator also sounds like something that could be drop-in replaced. Are there others I'm forgetting? It's interesting that there's all this low-hanging speedup fruit in the OS, and Atari didn't change one bit of it for the 1200XL.

An interesting thread has started over on the retrocomputing SO board: https://retrocomputing.stackexchange.com/questions/2998/what-implementations-of-basic-had-a-robust-flood-fill-operator Is anyone willing to try this on their Atari? The second post, for the Amstrad, should port fairly directly.

Ok, so it seems I was imagining the LINETO... but that brings me to another question. Am I correct in thinking that there were several replacement math ROMs? I seem to recall reading somewhere that the ones in FastChip were not all that fast compared to the ones in turbo basic. But then perhaps there were two things called FastChip? Can anyone add a little color here?

Any pointers to this project? I have some suggestions for Action! that i would love to play with if someone is working on this.

I have a terrible feeling I'm repeating myself here, but if I did ask this before, I can't find it in Google. I recall that one of the many OS upgrades, I want to say Fastchip, included a new line-drawing routine that sped up LINETO. Does this ring any bells? More generally, of all the various speedups that have appeared over the years, is there a list of their features and perhaps a performance comparison? It might be nice to collect all of that in a single place so the emulator guys can put in a switch to select all of the best.

So... 1) I saw there are different versions for integer and FB, but looking in the source on github I could not find a separate non-FP library. Is there someone I should look to understand what FB is doing here? 2) So does Advan require things like "A% = 10%"? Or is it "A% = 10". If the later, that is the "standard" all the way from BASIC-PLUS on the PDP-11 (ahhh, the PDP). If it is the former, I agree it's less than ideal, but I'm not sure why it is needed - wouldn't the parser normally work left-to-right?

You poor, poor man. Well, periodically I have to do some APL, so there's that...

That IS the standard for integers, however. It stated in the DEC basics on the PDP line, moved to MS when they basically copied DEC, and then became pretty common on other platforms. Unfortunately, MS didn't add it until the 1.6 version or so. Even then, the only place it was treated as a 16-bit int was when you were in an array index or for loop. In every case where you ran a math function, like A% = B% + 1, it converted them to the 9-byte FP/BCD format and then called the original FP math functions. I always found this odd. I emailed the original author of the 6502 version of MS BASIC, but the feature was added after he left microsoft (or that project anyway) so he didn't know. I think they did it because their primary concern was memory, and these took 2 bytes instead of 9, so that's a pretty big savings.But why not add an int library while you're at it? When I think about it, it seems there is a "half way" solution that was not attempted. Since these variables are really intended for loops and arrays, something like 99% of the functions called on them would be plus, minus and compare. It would seem one could have a very small addition to the original code with just these three functions in it, and still gain a significant performance increase.

Jumping in the middle here... The "slicing" commands in Atari BASIC were functional, and in some ways more in common with modern systems that generally only have a single substring command. The real problem with them is the off-by-one lengths. LEFT$(10) is not the same as [1,10]! This makes it very easy to introduce errors that can be very difficult to see. I asked Bill Wilkinson about this some time ago, and he was of the opinion there was enough room left on the ROM to include "cover methods" for these commands. That would allow you to use the MS BASIC string commands without changing the entire string system. String arrays are certainly useful too, but I suspect for 90% of the uses, simply having those commands would be enough.