I recently bought Vision BASIC (@visionbasic) for the C64 which has highly optimized commands for drawing lines. It was able to do this sort in under 10 seconds!. Here's a link if you'd like to check it out: visionbasic.net/
@@visionbasic Thanks for all the hard work in making it. Would've loved to have this in the 80's. Don't know if you saw my 1541 Navigator program & videos, but I'm tinkering with adding the ability for it to parse VB programs just like it does with BASIC, and popular BASIC extensions like SIMON's and SuperExpander.
I would think the vast majority of the time is spent inside BASIC's graphical line drawing routine so any speed up of the actual sort is going to have marginal returns. These kinds of compilers basically speed up calls into and out of the built in BASIC routines, they don't rewrite or optimize them.
I'd say the graphical version may spend most of the time actually drawing the screen :) With the way C64/128 organise their bitmap screen, drawing vertical lines is the worst-case scenario. You need hundreds of read-mask-update-write operations per single line being drawn/erased. In fact, reorganising the screen so that the lines are horizontal could help a little, but I have no idea if the built-in line draw operation is optimised for that. And this is also the reason why C64/128 games don't employ the bitmap mode. You could still manage to write a game in BASIC and compile it, but you'd have to stick with the custom charset text mode and sprites for that.
Most line-drawing routines are "all purpose". A vertical line COULD be drawn faster because the values for masking and such are already known for the first dot. You only need to update the position for each successive bit that need to be drawn. But a separate drawing routine would need to be created for this. A horizontal line-drawing routine would ideally be the fastest if programmed correctly.
@@visionbasic Thanks for watching. I've had Vision BASIC for a little over a month now and really like it. I ported this sort program into it, using the VLINE instead of DRAW and the line sort ran in just over 9 seconds! (which is what I was hoping for when compiling on the 128). Toying with the idea of a video to show the Vision BASIC quicksort version as a "new school" compiler as opposed to the "old school" compilers I used in these videos.
@@retrooldguy9880 Compilers that borrow the ROM routines can't speed up things like line drawing unless they provide their own routines (and those routines would have to be faster anyhow). Compilers like Blitz! pretty much just pre-interpret the code, and that's how they speed things up, really. I'll keep watch for such a video if you make it! :)
If I remember correctly, BASIC 7.0 had to be a little bit slower to deal with two-byte tokens so they could have more commands. Technically you could have put a FAST at the start and a SLOW at the end if you wanted to test machine speed, but for BAIC interpreter speed testing, sadly, my old 128 wasn't going to win races.
Just found your channel because of the C64 sorting video. Great content! I’m curious if the hex values on the sides have any particular significance. 🤔
I was wondering if anyone would be curious about that. The answer is both yes and no. I thought the blank sides looked kind of dull, so I did a hex dump of a source code file from my 1541 Navigator program. I wasn't trying to plant an easter egg or anything, the file was already open in the editor and was the first file I saw when I came up with the idea to fill in the sides of the video.
Very surprising to see BASIC 7.0 is only 2/3 the speed of CBM BASIC 2.0 on the bubblesort. Very interesting C128 BASIC Compiler, I never heard about this one bitd. I suspect when it is compiling the graphics commands it is just calling the ROM routines so there is not as much performance increase.
Have you been able to find a .D64 file of either of these that operate on the VICE or other C64 emulators? I've never been able to get it to work in emulation. Thanks.
I still have my original Abacus disks and made my own D64 images, so I don't know where you can download them from. They do work in VICE. The 128 video was done in VICE on my Windows laptop and the C64 video on my iMac Pro. However they DON'T work on the 64mini or TheC64. I'm running VICE using an NTSC model with no REU expansion or ROM files (such as JiffyDos). The only thing I can suggest is start with a bare-bones emulation and go from there. Good luck.
@@retrooldguy9880 Thanks for the swift response, i'll try using your configuration. In another post I mentioned having bought the C64 version (later the 128 too). When I tried this before (2002 ish) it was with 64Commander ripping tool and CCS64 emulator. Its great seeing these products remembered. This 'need for speed' and my experience with the 3-D surface plotting lead me to ultimately a PC with 8087 fp co-processor and Borland's Turbo Basic.
Nice video. To speed up your BASIC program you shouldn't use numbers in a formula. Replace it with a variable. And the last sort routine doesn't work right. 😉 Look at 06:26. The second line is shorter than the first.
True, using a variable in the calculations did result in a slight (3/10 of a second) speed increase when using the BASIC interpreter. Oddly, the compiled version was the opposite, it actually SLOWED it by almost a full second!. Either way, for this small a data set the time saved is insignificant. The C128 is spending a big chunk of time drawing the lines. Good catch on the Shell sort demo, I didn't notice that when editing. It was a simple matter of increasing the item count by 1 in the algorithm.
@@retrooldguy9880 The benefit of using variables for speed in regular uncompiled BASIC doesn't typically apply to compiled programs. In compiled programs, numbers could be stored in a format that is faster to fetch than variables. Also, in compiled programs, the numbers are already converted from ASCII characters over to actual values.
@@retrooldguy9880 I did ask it to create a machine language program for the C64 to sort and the system spit a bubble sort program that looked reasonable to my knowledge. I didn’t test it though…
![Lp. Сердце Вселенной #1 НАЧАЛО ПУТЕШЕСТВИЯ [Новый сезон] • Майнкрафт](http://i.ytimg.com/vi/380Q7gLWGvk/mqdefault.jpg)
I recently bought Vision BASIC (@visionbasic) for the C64 which has highly optimized commands for drawing lines. It was able to do this sort in under 10 seconds!. Here's a link if you'd like to check it out: visionbasic.net/
Thanks for the endorsement! :) Actually, I wouldn't have known about it if I had not scrolled down to see the comments.
@@visionbasic Thanks for all the hard work in making it. Would've loved to have this in the 80's. Don't know if you saw my 1541 Navigator program & videos, but I'm tinkering with adding the ability for it to parse VB programs just like it does with BASIC, and popular BASIC extensions like SIMON's and SuperExpander.
Nice work! I wonder how this comparison would turn out in 80 columns mode, given the 2 MHz clock there.
I would think the vast majority of the time is spent inside BASIC's graphical line drawing routine so any speed up of the actual sort is going to have marginal returns. These kinds of compilers basically speed up calls into and out of the built in BASIC routines, they don't rewrite or optimize them.
I'd say the graphical version may spend most of the time actually drawing the screen :)
With the way C64/128 organise their bitmap screen, drawing vertical lines is the worst-case scenario. You need hundreds of read-mask-update-write operations per single line being drawn/erased. In fact, reorganising the screen so that the lines are horizontal could help a little, but I have no idea if the built-in line draw operation is optimised for that.
And this is also the reason why C64/128 games don't employ the bitmap mode. You could still manage to write a game in BASIC and compile it, but you'd have to stick with the custom charset text mode and sprites for that.
I tried horizontal lines, but it still took about 90 seconds in BASIC. No significant difference.
Most line-drawing routines are "all purpose". A vertical line COULD be drawn faster because the values for masking and such are already known for the first dot. You only need to update the position for each successive bit that need to be drawn. But a separate drawing routine would need to be created for this. A horizontal line-drawing routine would ideally be the fastest if programmed correctly.
@@visionbasic Thanks for watching. I've had Vision BASIC for a little over a month now and really like it. I ported this sort program into it, using the VLINE instead of DRAW and the line sort ran in just over 9 seconds! (which is what I was hoping for when compiling on the 128). Toying with the idea of a video to show the Vision BASIC quicksort version as a "new school" compiler as opposed to the "old school" compilers I used in these videos.
@@retrooldguy9880 Compilers that borrow the ROM routines can't speed up things like line drawing unless they provide their own routines (and those routines would have to be faster anyhow). Compilers like Blitz! pretty much just pre-interpret the code, and that's how they speed things up, really. I'll keep watch for such a video if you make it! :)
If I remember correctly, BASIC 7.0 had to be a little bit slower to deal with two-byte tokens so they could have more commands. Technically you could have put a FAST at the start and a SLOW at the end if you wanted to test machine speed, but for BAIC interpreter speed testing, sadly, my old 128 wasn't going to win races.
True. FAST mode will speed it up 2x, but, it turns off the 40 col/bitmap screen. So you don't get to see it working.
Great comparison
I‘d be interested to see how Blitz128 is performing
It's actually about 7 seconds slower
Just found your channel because of the C64 sorting video. Great content!
I’m curious if the hex values on the sides have any particular significance. 🤔
I was wondering if anyone would be curious about that. The answer is both yes and no. I thought the blank sides looked kind of dull, so I did a hex dump of a source code file from my 1541 Navigator program. I wasn't trying to plant an easter egg or anything, the file was already open in the editor and was the first file I saw when I came up with the idea to fill in the sides of the video.
Very surprising to see BASIC 7.0 is only 2/3 the speed of CBM BASIC 2.0 on the bubblesort. Very interesting C128 BASIC Compiler, I never heard about this one bitd. I suspect when it is compiling the graphics commands it is just calling the ROM routines so there is not as much performance increase.
Have you been able to find a .D64 file of either of these that operate on the VICE or other C64 emulators? I've never been able to get it to work in emulation. Thanks.
I still have my original Abacus disks and made my own D64 images, so I don't know where you can download them from. They do work in VICE. The 128 video was done in VICE on my Windows laptop and the C64 video on my iMac Pro. However they DON'T work on the 64mini or TheC64. I'm running VICE using an NTSC model with no REU expansion or ROM files (such as JiffyDos). The only thing I can suggest is start with a bare-bones emulation and go from there. Good luck.
@@retrooldguy9880 Thanks for the swift response, i'll try using your configuration. In another post I mentioned having bought the C64 version (later the 128 too). When I tried this before (2002 ish) it was with 64Commander ripping tool and CCS64 emulator. Its great seeing these products remembered. This 'need for speed' and my experience with the 3-D surface plotting lead me to ultimately a PC with 8087 fp co-processor and Borland's Turbo Basic.
Nice video. To speed up your BASIC program you shouldn't use numbers in a formula. Replace it with a variable. And the last sort routine doesn't work right. 😉 Look at 06:26. The second line is shorter than the first.
True, using a variable in the calculations did result in a slight (3/10 of a second) speed increase when using the BASIC interpreter. Oddly, the compiled version was the opposite, it actually SLOWED it by almost a full second!. Either way, for this small a data set the time saved is insignificant. The C128 is spending a big chunk of time drawing the lines. Good catch on the Shell sort demo, I didn't notice that when editing. It was a simple matter of increasing the item count by 1 in the algorithm.
@@retrooldguy9880 The benefit of using variables for speed in regular uncompiled BASIC doesn't typically apply to compiled programs. In compiled programs, numbers could be stored in a format that is faster to fetch than variables. Also, in compiled programs, the numbers are already converted from ASCII characters over to actual values.
Would ChatGPT compile this and create faster code? Who knows…
I'll leave that to you..or somebody else to find out.
@@retrooldguy9880 I did ask it to create a machine language program for the C64 to sort and the system spit a bubble sort program that looked reasonable to my knowledge. I didn’t test it though…