JamesD

Skipping the scan to find the array size by just setting N=891 instead, and using my new method of calculating the gap. Emulator, hand timed, full run time, not just the sort. MC-10 5:34 = 334 seconds MC-10 New ROM 4:55 = 295 seconds Apple II Plus 5:57 = 357 seconds Emulator, machine timed, full run time Plus/4 7:16 = 436 seconds Plus/4 (high speed sort) 5:10 = 310 seconds (309.9166...) I was not expecting that much of an improvement. *edit* Not sure if the timer interrupt is running in high speed mode Changes for Plus/4 0 TI$="000000":I=0:G=I:N=I:C=I:D=I:E=I:NW=I:H=I:T=I:O=1:Z=0:GOTO20 20 SCNCLR:PRINT"READ, SORT, AND LIST MOST POPULAR SIR NAMES" 34 PRINT:PRINT"DONE";TI 'To use high speed mode for the sort only 30 POKE 65286,0:GOSUB1:POKE65286,27

I don't know how much BBC BASIC borrowed from it, but the Atom version is really weird. It's a little easier to be fast if you don't worry about being compatible with existing BASICs.

Epic games freebies https://www.epicgames.com/store/en-US/product/for-honor/home https://www.epicgames.com/store/en-US/product/alan-wake/home

Seems to me, even the original author said this was pretty primitive.

This isn't a video, but I think it was worth sharing here. https://archive.org/details/pacman_transcode_v1.01

Yeah, seems to me the story went that the fast RAM was so new, and difficult to get, that it was hand delivered for the prototype.

If you have a program that takes a long time to complete a task without prompting the user, you might want to give the user the option of whether or not to disable the display. Leaving a program to run overnight... as long as you know the program works, it might not matter if the display is on. You would probably turn off the monitor anyway. But it would also be nice to know if the program is stuck in an endless loop, or if it has died. I see no reason why you couldn't test with, and without this. The Plus/4 could also turn off the display to run a program faster. If they hadn't slowed the BASIC down so bad to support RAM under ROM, it would have been a fast machine.

If you don't like the conversation, you don't have to participate

I suggested an all BASIC solution simply because the subject is about BASIC string handling, and switching to assembly means you aren't benchmarking BASIC any more. If there is a faster way of implement string handling in Atari BASIC, do it! It makes no sense not to use a better approach if there is one. At the very least, you could ditch the end pointer array in favor of putting the length as a character in front of the string, or you could calculate the end of a string with the next string pointer-1 (implying you need to make the pointer index larger by 1). Using an array of constant length strings, and calculating the string start would also be okay, but as I pointed out, it wouldn't handle the full list of names, which just might not be possible no matter what. If it's a limitation, it's a limitation. As long as every machine uses the same number of names, in the same order, you are doing the same work (sorting an index to the array of names with a comb sort), you get an idea of how they compare speed wise. There are clearly some trade offs in how you implement the code, and finding the fastest way, or most names you could load and sort would certainly be interesting. If you want to benchmark against machines that were available when the Atari came out, you need to at least include times for the original Atari BASIC, but there's no reason not to include faster BASICs that didn't exist back in the day as well.

Commodore BASIC is Microsoft BASIC. You can PRINT variables, and modify variables, but you can't modify the code if you want to CONTinue.

I tried a couple different variations of the sort. They are very similar except for one small detail... instead of a divide, one only uses a multiply. The idea was to use multiply because they are faster than divide. Speed is very dependent on what constant you use for F.

As has been previously pointed out, the MC-10 came out years after the Atari. The Apple II Plus would be more of what the Atari was up against, and here is it completing the sort of the larger list of names. And here is the Plus/4. Another 1.77MHz machine, though the interpreter is really slow due to the extended memory support. I made a test patch for the Plus/4, and got a 5% speedup on the first try, so with a little work, it *should* offer pretty competitive times... just not with the standard BASIC. It would be at the cost of available program, and variable storage space though.

I'll disagree on better and say different. The pointer is faster. The hash function lets you keep existing BASIC functionality. It depends on what is most important to the person using it.

FWIW, I think you can get away with using 1.33 instead of 1.3 for the value of F, but there may be cases where that sort code doesn't completely sort the data if the number is too large. This version is a little better, and matches the comb sort examples closer. Using larger values for F won't fail, but you'll have more passes on a gap of 1 if F is too large. *edit* This will fail if any pass has no swaps. (?)

In this case, you still need one index array for the staring pointer in order to sort the data, but that is a big improvement. If you are using the array for packed strings to print, you *should* be able to set the negative bit for the last character in the string, and then just subtract 128 to print that character. Works well from assembly, but BASIC... IDK

I based the comment on drpstr's code. Lot's of changes needed for Atari BASIC so I didn't bother testing... just assumed he knew what he was doing. But then he doesn't care about wasting 6% of the CPU time, which is over half the amount I've managed to speed up the MC-10. :/ Getting it running on the Apple II required changing CLS to HOME, and the Plus/4 required changing CLS to SCNCLR. Pretty trivial changes really. Assuming the emulators are accurate... the II Plus takes about 6:30, and the Plus/4 takes about 8 minutes. The extended RAM support in the Plus/4 has quite a price. But, it would be able to handle the entire list of 1000 names if I tried it. The MC-10 came in a few seconds under 6 minutes for regular BASIC, and around 5:20 for the new version. The C64 emulator I downloaded, VCC (CoCo), and Blue MSX don't have an option for typing in text so I didn't test them.

A slightly fixed, and optimized MS BASIC version of the comb sort with prettier output. The Atari had line length issues with some of the previous code I posted, doesn't like NEXT without a variable, and seems to require THEN GOTO instead of just THEN line#. This should be closer to working from the start.

CURLIN is line number, TXTPTR is current position *edit* In this case TXTPTR is the end of the FOR statement, which is where to continue after the NEXT

MS BASIC pushes the line # as well. I don't think you can continue on it if you add, delete, or edit a line of code anyway.

One of my area libraries has a 3D printer you can use. You have to take a training session, and for something like this you might need your own roll of plastic compatible with their printer for the right color. Check libraries in your area.

The 2nd two, depend on fixed length strings, rather than packed strings. You could scan through the names in the data to find the longest name, then use that for the size of the field, but you are looking at reserving at least 11 characters from a glance at the data. The program becomes a little simpler since you don't have to store start & end info for the strings, just multiply the index * the max length to calculate the start, and add the max length to get the end. Given the size of the space reserved for the start & end numbers, it should be able to hold a lot more strings, thought I'm not sure it will do much for speed since you are multiplying.

I tried to implement the sort to encourage someone more familiar with Atari BASIC to finish the code. I figured the Atari could do it based on the comments, but I wanted to see how difficult it was, and how fast it would run. Congrats, you fell victim to my evil plan! Mu ha ha haaaaa! Well done on implementing it btw. Any reviewer that knocked Atari BASIC for string handling had some justification because it's not as easy. But when they just said it didn't support string arrays... well... technically it's true, but they didn't tell you there were ways to implement it. Atari BASIC may have been the biggest reason the Atari didn't sell better, and the saddest part of that... it was on a freakin cart! How do you mess that up??

This worked great, thanks!

Ditch the busy thing, it just steals too much CPU time on this much data. Neither interpreter has integer support, but I think difference on the first version comes down to the extra pointer overhead, and it being easier to convert between FLOAT and INT, than BCD and INT. If the data were written to a disk file instead of being read from data statements, you might be able to load the entire list using this approach. The 2nd approach just has too much overhead. If you needed to use that kind of approach, a machine language sort that converts everything to ints/pointers on entry, does the sort, and then converts everything back on exit would probably be needed. The MC-10 completes the full list in around 5:17, more with standard MS BASIC... maybe another minute or more. This does show some criticism of string handling with Atari BASIC is deserved, but it's certainly capable of doing the job. If you had an Atari, had to deal with this much data, didn't know assembly language, and didn't have access to existing tools, you could definitely roll your own software to do the job. It would still be infinitely faster than having to alphabetize a list of names by hand. One of my duties at a job when I was in college, was having the computer sort, and print their mailing list for bulk mailings. The research group I worked for had printed it unsorted once, and the university mail office said never again. Doing it by hand took days if I remember right. If you started a similar program, and left it running, it could probably sort and print such a list in a couple hours.

Nice to see an alternative to CC65. UNIONS are dropped by a lot of versions, so no big deal there. Recursion isn't something I see being real efficient on the 6502, so not a problem there either.