JamesD

Even though the Atari clock speed is higher, plus your version doesn't scan the data to find out how large the array is, and after I removed the busy indicator... standard MS BASIC on the MC-10 beats it. I ran the test on Altirra 3.1, with Altirra BASIC. Loading the array was pretty fast, but the sort... not so much. Oh, and pasting the text into the Altirra emulator is excruciatingly slow. It takes about 15 seconds to load the original program on VMC-10. I might be able to make coffee with the Atari. Is there a faster way to enter the program? Here's how it compares as written. Keep in mind that the Atari code is unoptimized, and even dropping the busy indicator makes a noticeable difference, so don't worry too much about this version being slower. Standard MS BASIC is also closer to the speed of the Atari. I guess I should worry about how the output of mine looks... it's kinda ugly in comparison. In my defense, it was a quick n dirty test.

Other Atari BASIC changes for the MS BASIC program I posted. Not sure if they are correct, but I think it's how it should work.

I think this is the correct code, I left the previous code intact in case I forgot something. 19 FOR I=1 TO NW : S1=B(I) : S2=B(I+G) : IF NA$(P1(S1), P2(S1)) > NA$(P1(S2), P2(S2)) THEN B(I)=S2 : B(I+G)=S1 VS MS BASIC 19 FOR I=1 TO NW : IF A$(B(I)) > A$(B(I+G)) THEN T=B(I) : B(I)=B(I+G) : B(I+G)=T

That might simplify the string compare code in the interpreter. At least it makes the sort code smaller. Given the CPU speed, I can't see it being slower than MS BASIC on a 1MHz or less machine. Here is the updated code. The MS BASIC code wouldn't require a huge number of changes to get the program working on the Atari. Yeah, I figured they did. Can't use it here due to the sort, but for printed strings it would be nice. I've toyed with the idea of adding some sort of data decompression to BASIC, LZ4 maybe, but I decided that was best left to the realm of compilers.

The drawback to the packed strings I used is clearly speed, and as you indicate, it's for data that doesn't change. You could mix the two string array approaches in the same program for different uses. While my approach works, I really wonder about the speed hit on the index sort. It requires extracting the strings from the data, and then comparing them rather than comparing strings in place. The faster clock speed of the Atari should help a lot vs 1MHz machines but that's a lot of string copies. I think the 891 names I'm using (the most that will fit in MC-10 memory) requires 26 passes through the data. Algorithm choice might also be critical. Comb sort is relatively easy to implement, works well in BASIC, and it's one of the faster sorts, but if another sort required fewer comparisons, it might make a bid difference in speed due to the string copies. A bubble sort would take all day. A machine language subroutine that compares strings in place would probably make the most difference.

A couple Fallout titles are on the sale list as well.

Well, I *thought* he wrote it, but he's only credited for Zaxxon in 1983, where the Sega game is 82 So he just wrote the CoCo version and the unofficial Z-89 CoCo 3 version. https://www.mobygames.com/developer/sheet/view/developerId,196778/

If you are interested in Zaxxon, you'll want to talk to Steve Bjork. He programmed the arcade game, the CoCo version, several other Datasoft titles, and a lot of other games. He's a regular on the CoCo Discord server, and makes appearances on CoCoTalk! (live CoCo oriented talk show).

Prey Deluxe $8 https://www.humblebundle.com/store/prey-deluxe

After looking at your code comments, you'd probably want to keep arrays with string locations, and length of the strings to pack the data in as small of space as possible. It's not as easy as indexed arrays, but doable. Something like this (logically) would be needed to extract the strings, not claiming it's optimal. It's worse than an array of strings but not a logical nightmare by any means... though I might lie down till the headache passes. Atari BASIC isn't the only one without INSTR$. I have to add it to the MC-10. The adventure game comment was about Fast BASIC, which is different than Atari BASIC. It's a question of whether or not it can load the data even then, so it would be program specific.

I don't think it's a memory efficiency issue with Atari BASIC, it was more about functions, and maybe how easy it is to do something. LEFT$, RIGHT$, MID$, INSTR$ are the typical BASIC string functions that were mentioned to compare string handling features. Even if the parser is slow on the Atari, those should be pretty fast. I know Atari BASIC strings are an array of characters, but what about an array of strings? Fast BASIC may not be efficient memory wise with strings, but it's efficient speed wise. It limits what you can do with it, but I'm not sure anyone is writing business software for the Atari these days. It's probably more of an issue of whether you could use it for a BASIC adventure game or something like that. Here is the quick n dirty data/string/sort test I use. This is really easy in MS BASIC, but how do you do it in Atari BASIC?

Based on the video, and the pricing discrepancy... if you were a big company someone thought they would make a lot of money, you'd get it cheap, or possibly even free. If you were a small company they never heard of, you'd pay through the nose for one, or have to buy from a reseller that is buying in quantity. My estimate is probably correct for a reseller... if you can't find someone that carries it you are paying $185-$200. Motorola didn't even try to market it until 1979 according to one article, even though it was in the Cadillac Seville starting in 1977, so you probably wont find anyone selling them until 79 as it supposedly wasn't in their sales literature before that. Unless the sales person can be smooth talked with promises of 20,000 units, my estimate is off by $150 for the prototype, but probably close for production... if they will sell you the chips. I still can't see it taking 2 years to get a part. Let's face it, there were probably less than 15,000 of those Cadilacs sold, and the digital trip meter that used the 6801 was a $920 option. Surely the chips could be produced faster than demand for that. But then two years works out to about when the 6805 came out... which was a cheaper design, and it was very popular with auto makers. Coincidence? But then, that's also when they switched from NMOS to CMOS and the die yield went up. Those prices is crazy. You can buy a full keyboard for $33, but a keyboard encoder chip costs another $15. A 6800 kit was $145, which is cheaper than the KIM 1, but the KIM 1 is assembled, and might have included more stuff. A computerized Backgammon game is $130 $2345 for a 48K Apple II, with integer BASIC. Any wonder why Atari thought they could make money selling computers? Anyway, this hijack of the thread has run it's course. Back to Atari and string handling... I hope.

Wiki? The wiki doesn't have the price of the 6801 any of it's variations. That's the 6800 price. This video goes into details on 6800 pricing among other things: https://archive.org/details/VCFE7_SWTP Here is where you can find a 6800 MPU for under $25 in 1977 on the top right page, and you can find that ad in issue after issue. The 6800L is $35 in a later issue, and that's the ceramic version with gold pins. https://archive.org/details/Kilobaud197711/page/n131 FWIW, I used the price of the 6800L in my estimate just in case. *edit* I didn't see your change about 6803 pricing until after I posted this. If the wiki says the 6800 is $175 but the magazine has it for $25, what does that tell you about the $185 6803 pricing?

What did you google? I can't find any old price sheets.

By 1977/78, electronics distributors had magazine ads listing the 6800 at $25 for one. I looked it up in an issue of Kilobaud magazine. Quantity from Motorola would obviously be less. The problem is, you won't find the 6803 or 6847 at electronics distributors at that time, you'd have to go to Motorola to even know they existed. Based on the prices I've found, in 1977 you should have been able to build a one-of prototype MC-10 ish system using parts ordered from magazine ads, along with sample 6803, and 6847s, (no quantity discount) for under $400. Most of that is the RAM, and EPROMs. The magazine price for a 1K EPROM was $45! You could probably build a production model for half that.

The MC-10 is pretty much 1977 technology with newer SRAMs and ROM.

String handling is one of the things that may have hurt Atari 8 bit sales. There seemed to be a perception in magazines that Atari BASIC was more suited for games than business. While BCD math was cited as being better suited for business programs, that's about where the pros of Atari BASIC seemed to end. The slow speed was the most often cited problem with Atari BASIC, but string handling is definitely something that was brought up in magazines. PRINT USING was the other thing that was commonly referred to as a business oriented feature, and that takes up a lot of ROM real estate. I'm not sure PRINT USING even made an appearance on a 6502 BASIC until Atari MS BASIC came out, so it's not as big of a deal. If you wanted those features, you bought a TRS-80, but you sacrificed other things by doing that. When you try to squeeze a lot of stuff in a small ROM, something has to give. String functions, and PRINT USING seems to have been what was left out. A couple of the modifications I made to the MC-10 ROM, were changing from 8 bit, to 16 bit memory copies, and string compare functions. Using a lot of 1 byte strings might be slightly slower, but that's more than made up for by the faster speed of the rest of the interpreter. The change is very noticeable when manipulating, or comparing long strings. Sadly, you can't make those optimizations on the 6502, and the penalty for mode switching on the 65816 would probably mean string compares would be slower on strings under 4, or more, bytes in length. The memory moves should be faster on the 65816 due to the memory move instructions, but not by a large amount due to the setup time, and number of clock cycles required per byte moved. As for how MS BASIC stores strings vs Fast BASIC... it may not be the fastest approach, but MS BASIC was designed to run with as little as 4K of RAM. When you start allocating 256 bytes for every string, you are going to run out of RAM in a hurry in certain cases. My test program to compare string, and memory move changes, reads 891 of the most popular sir names, and related info from DATA statements, then arranges them in alphabetical order. Unless I misunderstood what Fast BASIC does, that would require 228,096 bytes, or almost 223K of RAM just for the string variable portion of the data. As long as you aren't dealing with a lot of strings, the Fast BASIC approach may be superior, but it sounds like it's a memory hog. For strings that will ALWAYS be a shorter length, and are rarely if ever manipulated, some form of packed or compact string might be in order. Or did I miss something?

No need to store both, this is all it takes to get the current line number on the 6803, the line number isn't needed as often so it's faster than storing line number, and I'm out of space on the direct page with the stock amount of RAM. If I had a couple more index registers, I might dedicate one to the current parse location, and the other to the current line pointer. LDX CURLIN ;get current line pointer LDD 2,X ;get current line number

Boy did you picked a rare machine to play with, and one of the few personal computers to use the 8080! I ran across a site supporting the Interact that might still be around, but I don't have a link. The design was sold to a French company that continued development of the machine. Changes included a real keyboard, and later models even switched to a 5MHz Z80. You might try looking for a site that support the French version. Try searching for Victor Lambda, and Hector computers.

This is a really good talk on the early history of micro-computers, CPUs, etc... There is some info I hadn't heard anywhere else.

Yeah, start with new posts there, then move popular posts for existing hardware from the last few months, and let forum members find the others to move.

I really don't see people missing new hardware because it's in a subforum. Sure, you might not see it on day one, but if people even check it once a week they are more likely to find it than in the main forum after only a few days.

I really don't see people missing new hardware because it's in a subforum. Sure, you might not see it on day one, but if people even check it once a week they are more likely to find it than in the main forum after only a few days.

The syntax looks the same as Extended Color Basic on the TRS-80 COLOR COMPUTER. LINE, CIRCLE, PAINT, DRAW, SCREEN, etc...