Using the changes posted by @visionbasic, the sort took 6.13 seconds! Three seconds faster than shown in the video. If anyone wants to experiment, here is the complete data set that was used (it was pointed out that I didn't display all of it in the video): 500 data 51,107,26,3,61,135,99 501 data 36,116,68,82,32,0,65 502 data 72,97,19,148,83,126,89 503 data 141,22,31,120,154,63,40 504 data 114,143,42,157,130,27,112 505 data 129,2,44,149,74,85,123 506 data 70,33,79,12,71,73,75 507 data 5,119,95,55,98,80,156 508 data 23,49,136,84,8,150,100 509 data 113,93,111,105,66,41,110 510 data 94,21,125,24,109,37,58 511 data 128,7,30,4,16,118,153 512 data 159,151,46,64,115,103,145 513 data 29,39,140,56,91,9,45 514 data 60,11,102,138,88,134,52 515 data 25,38,76,106,158,121,50 516 data 62,155,20,139,18,132,92 517 data 90,69,35,81,6,117,87 518 data 142,131,10,53,78,13,127 519 data 34,108,1,77,144,43,14 520 data 15,137,86,146,48,124,28 521 data 122,47,57,17,147,101,67 522 data 104,96,59,133,54,152
It looks like the above data set contains 160 bytes, which would be exactly four lines of data on the 40-column screen. However, at 2:04 the unsorted data set takes up nearly 6½ lines on the screen (6*40+16=256 bytes). So I think some of the data statements must have been omitted.
You're correct, the graphical line sort only uses 160 items (0-159) as that was what could comfortably fit on screen, and the PETSCII sort used 256 items (0-255).
Here are my results: Reverse order 3.6 bubble 2.8 insert 1.2 select 0.1 shell 0.7 quick Already sorted 0.7 bubble 0.0 insert (no measurable time, not even 1 jiffy, it would be in the 1000ths of a second) 1.1 select 0.1 shell 0.05 quick Two items swapped (100 and 200) 0.7 bubble 0.01 insert 1.1 select 0.1 shell 0.05 quick Of course this is a small data set (of integers, not strings) we're working with. You should try it with a larger set. Check out this site for sorting algorithms: www.geeksforgeeks.org/sorting-algorithms/#
@@retrooldguy9880 Interesting, thank you for doing that. I do remember the sort algos, we had quite a few lessons on how they work and why they work in programming class. Long time ago, but it was extremely fascinating.
2:24 I'm getting an execution time of 1.2 seconds for the ML Bubble Sort, so I'm not sure what's different about my code, except that I'm decrementing the length of the search data by one byte for each cycle, since it can be assumed that the list gets sorted from the end to the beginning. Here is the code for reference... 10 forx=0to10:readn:printchr$(n);:next 20 forx=0to64:readn:poke828+x,n:next 30 forx=0to255:readn:poke1024+x,n:next 40 print"Press a key to sort..."chr$(17) 50 getk$:ifk$=""then50 60 t=ti:sys828:print"Time:"int((ti-t)/6)/10"seconds", 70 print"Swaps:"peek(831)+peek(832)*256 100 data 5,147,17,17,17,17,17,17,17,17,14 200 data 76,66,3,0,0,0,169,0,141,63,3,141,64,3,169,255,141,65,3,162,0,160,0,185 210 data 1,4,217,0,4,176,20,72,185,0,4,153,1,4,104,153,0,4,232,238,63,3,208,3 220 data 238,64,3,200,204,65,3,208,222,206,65,3,224,0,208,211,96 500 data 106,20,107,230,80,33,205,88 501 data 36,84,194,165,243,7,1,56 502 data 130,22,214,144,89,45,93,131 503 data 207,16,104,117,147,48,85,163 504 data 210,92,196,69,157,96,30,115 505 data 209,99,119,100,63,77,187,121 506 data 244,103,123,215,42,116,211,250 507 data 87,110,128,32,43,178,162,19 508 data 248,49,135,61,79,76,52,139 509 data 25,27,5,150,91,132,12,225 510 data 155,112,113,167,125,26,177,62 511 data 148,75,189,82,51,95,169,102 512 data 108,246,29,40,4,193,204,54 513 data 98,126,146,58,159,114,228,201 514 data 57,66,72,186,188,240,236,245 515 data 35,143,226,145,74,47,251,120 516 data 129,140,153,237,235,154,255,50 517 data 223,9,229,232,160,10,168,97 518 data 175,21,171,78,233,124,241,253 519 data 138,185,18,105,55,73,71,170 520 data 249,242,28,218,6,219,195,202 521 data 247,231,252,11,83,164,212,64 522 data 137,44,70,8,213,53,0,222 523 data 176,2,174,183,152,59,238,224 524 data 31,197,14,199,13,161,38,166 525 data 217,15,221,158,101,234,65,90 526 data 227,122,37,208,156,23,206,149 527 data 60,94,198,172,182,111,118,192 528 data 41,190,203,136,239,200,141,127 529 data 68,254,180,191,17,133,142,34 530 data 216,151,109,134,81,86,24,220 531 data 67,46,3,39,173,179,181,184
Cool! Your code is more optimized than mine, plus I have a IRQ running for the clock which takes a few cycles. but the biggest savings in yours is counting the swaps. I have the traditional ADC #$01...etc. which all of the sort routines JSR to, so I am also saving the registers before the JSR (when needed), that also takes a few extra cycles, especially with an algorithm that has a lot of swaps. If I comment out the JSR, It takes less than a second on some randomized data sets Thanks for the comment. Sorting algorithms are fascinating to me. I'm always looking for a faster algorithm or faster code.
@@retrooldguy9880 Thanks for the feedback! I also noticed a pretty big variation when updating external variables. I also found a bug in my previous revision that only presented itself when the original data set is sorted in reverse order. It is fixed now with the following source code... _Assembly routine:_ *=$33c ; sys 828 start: lda #$ff sta eod -- ldx #$00 ldy #$00 - lda $0401,y cmp $0400,y bcs + pha lda $0400,y sta $0401,y pla sta $0400,y inx + iny cpy eod bne - dec eod beq start cpx #$00 bne -- rts eod: !byte $ff _BASIC code:_ 10 forx=0to45:readn:poke828+x,n:next 20 forx=0to9:readn:printchr$(n);:next 30 forx=0to255:readn:poke1024+x,n:next 40 print"press a key to sort..."chr$(17) 50 getk$:ifk$=""then50 60 t=ti:sys828:print"time:"(ti-t)/60"seconds" 100 data169,255,141,105,3,162,0,160,0,185,1,4,217,0,4,176,12,72,185,0,4,153,1,4 110 data104,153,0,4,232,200,204,105,3,208,230,206,105,3,240,216,224,0,208,217 120 data96,255 200 data5,147,17,17,17,17,17,17,17,17 {lines 500 onward appear as in the previous listing...}
@@retrooldguy9880 Surprisingly, the Insertion Sort takes up fewer bytes than the Bubble Sort in my test, but the sort takes only 0.67 seconds to complete with your data set, and only 1.4 seconds for the worst-case scenario of all data elements in reverse order. Source code follows... _Assembly routine:_ *=$33c ; sys 828 start: ldy #$00 -- tya tax - lda $0401,x cmp $0400,x bcs + pha lda $0400,x sta $0401,x pla sta $0400,x cpx #$00 beq + dex jmp - + iny cpy #$ff bne -- rts _BASIC code:_ 10 forx=0to36:readn:poke828+x,n:next 20 forx=0to9:readn:printchr$(n);:next 30 forx=0to255:readn:poke1024+x,n:next 40 print"press a key to sort..."chr$(17) 50 getk$:ifk$=""then50 60 t=ti:sys828:print"time:"(ti-t)/60"seconds" 100 data160,0,152,170,189,1,4,221,0,4,17 6,19,72,189,0,4,157,1,4,104,157,0,4,224 110 data0,240,4,202,76,64,3,200,192,255 120 data208,222,96 200 data5,147,17,17,17,17,17,17,17,17 {lines 500 onward are as in the previous listing...}
@@retrooldguy9880 Hello again. At 3:26 it is showing a sort time of 0.1 seconds for the ML Quick Sort. I was wondering if the calculated execution time is rounded or truncated? The reason I ask is because I was able to write an ML Merge Sort routine which takes 0.15 seconds to sort your data set, and the same amount of time to sort data that is initially in reverse order. I decided to try this algorithm because I read that both the Quick Sort and Merge Sort algorithms have roughly the same performance characteristics, but the latter seemed a bit more straightforward to implement in ML.
The clock in the video is using the Time Of Day clock located at $DC08-$DC0B and is in BCD format. It's lowest measurement is in 10ths of a second. So, I switched to jiffies and tried. It took 8 jiffies or 0.13 seconds (8/60=0.13 NTSC). And I did use the quick sort algorithm.
I've seen BASIC commands added to the 64's RAM before, like "SAY" that came with SayIt from the S.A.M. package, but I don't understand how it works. How does someone program the computer to make new BASIC-based commands that it would otherwise return with "?SYNTAX ERROR" for? And will you please give more detail than something like, "Uhh, well that's just another ML thing"?
BASIC is stored into C64's RAM when you start the computer. Then you can directly change how individual commands work or add new ones by modifying the content of BASIC RAM. For example, using a simple POKE command, you can change a character in any BASIC text.
It's actually a routine I read about back in '84 from Compute!s Gazette. I tweak it as necessary when I want a real-time clock. Here's the link: archive.org/details/1984-12-computegazette/page/158/mode/2up
How is it that I saw some C64 text that's a bit yellow-white but it's neither the same yellow or white that we'd normally see on that computer, and I can tell that especially when it's right next to the plain-white text and somewhat close to the stronger yellow text that's on at the same time?
That just some editing magic in order to make the text stand out. A screenshot with the selected text changed to yellow (but not commodore's yellow) overlaid on the video, which wasn't changing or moving at that time.
@@retrooldguy9880: You're talking about the _other_ yellow than what I'm talking about, right? So the "OK"s and the yellowish text at the beginning and end were C64/128-based yellow (I say it like that because Commodore had machines with more colors than that)? Because if so, then that's interesting, because that makes me think my PC monitor was detuned a little, because while my 64 and 128 haven't been set up for a long time, I remember that yellow being a little more vivid than it looked here -- at least for me. Yeah, maybe I'll have to look at this again and try tweaking my PC monitor and see if I can get a better match based on my memory, heh. Thanks for your response.
If I am understanding you correctly, yes, you are right. The prompts of "OK" and "Break" is the true Commodore yellow (as rendered in VICE on my Dell monitor). The yellow and green in the lines of code are colors I added in a separate editor. The overlay only covers affected text, not the whole screen so you ARE seeing two different shades of yellow in the same screen. I hope I answered your question.
@@retrooldguy9880: Yep, you got it, that's the highly trivial item I was curious about! I even turned up the color saturation on my monitor a bit and replayed your intro, and the yellow still seems washed out as compared to my memory and what I've seen in other C64/128 videos recently. So maybe those people were showing the real deal but the VICE is a little off. I don't know; it's not important, but my curiosity was just nagging me a little. Thanks for your time, it was fun to chat!
I copied what you had onscreen and tried to recreate the program, but I had to fill in the missing details. I had to create my own set of data statements as well (because not all of them are listed). Anyhow try these changes: 120 L=S(P):DEC P:F=S(P):DEC P:LET I=F 130 LET J=L 132 ADD X=F+L:HALF X:D=A(X) 140 IF A(I)D THEN DEC J:GOTO150 160 IF I>J THEN190 162 AI=A(I):AJ=A(J):A(I)=AJ:A(J)=AI 164 LET XI=I:DUBL XI:SUB YI=160-AI 166 LET XJ=J:DUBL XJ:SUB YJ=160-AJ 168 SUB A=AI-AJ 170 VLINE XI,YI,A,0 171 VLINE XI,YJ,AJ,1 172 VLINE XJ,YI,AI,1 180 INC I:DEC J 190 IF I
Tried the changes: Total time 6.13! That's a little over 3 seconds faster than shown in the video and faster than 2 of the the non-graphical PETSCII sorts using the ABACUS computer (shown in a previous video). I'll post the complete data set at the top, if you (or anyone else) wants to experiment with it.
@@retrooldguy9880 Wow... 6.13 seconds, that's incredible! I don't suppose we'll see a follow-up video on this huge speed improvement, would we? Maybe even just a TH-cam Short (60 seconds or less and in vertical mode)?
@@retrooldguy9880 I sincerely appreciate the exposure! I have no expectations, so if people like the software, I appreciate videos such as these. I did make a few more changes to speed things up a little more. This time I made the COMPARE conversions. The only other thing that could be done is to access the array contents with machine language instructions (and that would make it more of a machine language program as a result). There is a ceiling that one would hit when considering that the bitmap stuff eats up a lot of the cycles. Anyhow, here are my changes in addition to what I posted before: 160 compj,i:[bcc190] 172 vline xj,yi,ai 190 comp j,i:[bcs140] 200 comp f,j:[bcs210] 205 incp:s(p)=f:incp:s(p)=j 210 let f=i:comp f,l:[bcc130] 220 comp p,0:[bne120] In line 172, I just dropped the final parameter because it isn't needed. The effect isn't huge, though.
@@visionbasic Very cool. Thanks I'll give them a try. You are correct, my original concept for the video(s) was to use all BASIC, plus any extended BASIC commands available, and see how much faster it can be by using a compiler. Vision BASIC came to my attention via comment in the first video, and I soon became a customer.
There's an easier way to say years like 2017. Remember when we'd say 1975 as "NINETEEN-seventy-five" because it's shorter than the alternative way, which makes it easier? Yeah, well guess what: That still works for most years in this century too! So try saying "TWENTY-seventeen" (and "TWENTY-ten," etc.) today!
![[Full] 4 ต่อ 4 Celebrity EP.922 | 10 พ.ย. 67 | one31](http://i.ytimg.com/vi/zmV5HRIxIBI/mqdefault.jpg)
Using the changes posted by @visionbasic, the sort took 6.13 seconds! Three seconds faster than shown in the video. If anyone wants to experiment, here is the complete data set that was used (it was pointed out that I didn't display all of it in the video):
500 data 51,107,26,3,61,135,99
501 data 36,116,68,82,32,0,65
502 data 72,97,19,148,83,126,89
503 data 141,22,31,120,154,63,40
504 data 114,143,42,157,130,27,112
505 data 129,2,44,149,74,85,123
506 data 70,33,79,12,71,73,75
507 data 5,119,95,55,98,80,156
508 data 23,49,136,84,8,150,100
509 data 113,93,111,105,66,41,110
510 data 94,21,125,24,109,37,58
511 data 128,7,30,4,16,118,153
512 data 159,151,46,64,115,103,145
513 data 29,39,140,56,91,9,45
514 data 60,11,102,138,88,134,52
515 data 25,38,76,106,158,121,50
516 data 62,155,20,139,18,132,92
517 data 90,69,35,81,6,117,87
518 data 142,131,10,53,78,13,127
519 data 34,108,1,77,144,43,14
520 data 15,137,86,146,48,124,28
521 data 122,47,57,17,147,101,67
522 data 104,96,59,133,54,152
It looks like the above data set contains 160 bytes, which would be exactly four lines of data on the 40-column screen. However, at 2:04 the unsorted data set takes up nearly 6½ lines on the screen (6*40+16=256 bytes). So I think some of the data statements must have been omitted.
You're correct, the graphical line sort only uses 160 items (0-159) as that was what could comfortably fit on screen, and the PETSCII sort used 256 items (0-255).
Nothing beats the machine code :) But Vision BASIC is pretty impressive! Very nice video :) Cheers!
I love your content! Keep it coming!
It'd be interesting to see what happens if you throw the worst-case initial dataset at the sort algorithms, rather than the same random set.
Here are my results:
Reverse order
3.6 bubble
2.8 insert
1.2 select
0.1 shell
0.7 quick
Already sorted
0.7 bubble
0.0 insert (no measurable time, not even 1 jiffy, it would be in the 1000ths of a second)
1.1 select
0.1 shell
0.05 quick
Two items swapped (100 and 200)
0.7 bubble
0.01 insert
1.1 select
0.1 shell
0.05 quick
Of course this is a small data set (of integers, not strings) we're working with. You should try it with a larger set. Check out this site for sorting algorithms: www.geeksforgeeks.org/sorting-algorithms/#
@@retrooldguy9880 Interesting, thank you for doing that. I do remember the sort algos, we had quite a few lessons on how they work and why they work in programming class. Long time ago, but it was extremely fascinating.
2:24 I'm getting an execution time of 1.2 seconds for the ML Bubble Sort, so I'm not sure what's different about my code, except that I'm decrementing the length of the search data by one byte for each cycle, since it can be assumed that the list gets sorted from the end to the beginning. Here is the code for reference...
10 forx=0to10:readn:printchr$(n);:next
20 forx=0to64:readn:poke828+x,n:next
30 forx=0to255:readn:poke1024+x,n:next
40 print"Press a key to sort..."chr$(17)
50 getk$:ifk$=""then50
60 t=ti:sys828:print"Time:"int((ti-t)/6)/10"seconds",
70 print"Swaps:"peek(831)+peek(832)*256
100 data 5,147,17,17,17,17,17,17,17,17,14
200 data 76,66,3,0,0,0,169,0,141,63,3,141,64,3,169,255,141,65,3,162,0,160,0,185
210 data 1,4,217,0,4,176,20,72,185,0,4,153,1,4,104,153,0,4,232,238,63,3,208,3
220 data 238,64,3,200,204,65,3,208,222,206,65,3,224,0,208,211,96
500 data 106,20,107,230,80,33,205,88
501 data 36,84,194,165,243,7,1,56
502 data 130,22,214,144,89,45,93,131
503 data 207,16,104,117,147,48,85,163
504 data 210,92,196,69,157,96,30,115
505 data 209,99,119,100,63,77,187,121
506 data 244,103,123,215,42,116,211,250
507 data 87,110,128,32,43,178,162,19
508 data 248,49,135,61,79,76,52,139
509 data 25,27,5,150,91,132,12,225
510 data 155,112,113,167,125,26,177,62
511 data 148,75,189,82,51,95,169,102
512 data 108,246,29,40,4,193,204,54
513 data 98,126,146,58,159,114,228,201
514 data 57,66,72,186,188,240,236,245
515 data 35,143,226,145,74,47,251,120
516 data 129,140,153,237,235,154,255,50
517 data 223,9,229,232,160,10,168,97
518 data 175,21,171,78,233,124,241,253
519 data 138,185,18,105,55,73,71,170
520 data 249,242,28,218,6,219,195,202
521 data 247,231,252,11,83,164,212,64
522 data 137,44,70,8,213,53,0,222
523 data 176,2,174,183,152,59,238,224
524 data 31,197,14,199,13,161,38,166
525 data 217,15,221,158,101,234,65,90
526 data 227,122,37,208,156,23,206,149
527 data 60,94,198,172,182,111,118,192
528 data 41,190,203,136,239,200,141,127
529 data 68,254,180,191,17,133,142,34
530 data 216,151,109,134,81,86,24,220
531 data 67,46,3,39,173,179,181,184
Cool! Your code is more optimized than mine, plus I have a IRQ running for the clock which takes a few cycles. but the biggest savings in yours is counting the swaps. I have the traditional ADC #$01...etc. which all of the sort routines JSR to, so I am also saving the registers before the JSR (when needed), that also takes a few extra cycles, especially with an algorithm that has a lot of swaps. If I comment out the JSR, It takes less than a second on some randomized data sets
Thanks for the comment. Sorting algorithms are fascinating to me. I'm always looking for a faster algorithm or faster code.
@@retrooldguy9880 Thanks for the feedback! I also noticed a pretty big variation when updating external variables. I also found a bug in my previous revision that only presented itself when the original data set is sorted in reverse order. It is fixed now with the following source code...
_Assembly routine:_
*=$33c ; sys 828
start:
lda #$ff
sta eod
--
ldx #$00
ldy #$00
-
lda $0401,y
cmp $0400,y
bcs +
pha
lda $0400,y
sta $0401,y
pla
sta $0400,y
inx
+
iny
cpy eod
bne -
dec eod
beq start
cpx #$00
bne --
rts
eod: !byte $ff
_BASIC code:_
10 forx=0to45:readn:poke828+x,n:next
20 forx=0to9:readn:printchr$(n);:next
30 forx=0to255:readn:poke1024+x,n:next
40 print"press a key to sort..."chr$(17)
50 getk$:ifk$=""then50
60 t=ti:sys828:print"time:"(ti-t)/60"seconds"
100 data169,255,141,105,3,162,0,160,0,185,1,4,217,0,4,176,12,72,185,0,4,153,1,4
110 data104,153,0,4,232,200,204,105,3,208,230,206,105,3,240,216,224,0,208,217
120 data96,255
200 data5,147,17,17,17,17,17,17,17,17
{lines 500 onward appear as in the previous listing...}
@@retrooldguy9880 Surprisingly, the Insertion Sort takes up fewer bytes than the Bubble Sort in my test, but the sort takes only 0.67 seconds to complete with your data set, and only 1.4 seconds for the worst-case scenario of all data elements in reverse order. Source code follows...
_Assembly routine:_
*=$33c ; sys 828
start:
ldy #$00
--
tya
tax
-
lda $0401,x
cmp $0400,x
bcs +
pha
lda $0400,x
sta $0401,x
pla
sta $0400,x
cpx #$00
beq +
dex
jmp -
+
iny
cpy #$ff
bne --
rts
_BASIC code:_
10 forx=0to36:readn:poke828+x,n:next
20 forx=0to9:readn:printchr$(n);:next
30 forx=0to255:readn:poke1024+x,n:next
40 print"press a key to sort..."chr$(17)
50 getk$:ifk$=""then50
60 t=ti:sys828:print"time:"(ti-t)/60"seconds"
100 data160,0,152,170,189,1,4,221,0,4,17
6,19,72,189,0,4,157,1,4,104,157,0,4,224
110 data0,240,4,202,76,64,3,200,192,255
120 data208,222,96
200 data5,147,17,17,17,17,17,17,17,17
{lines 500 onward are as in the previous listing...}
@@retrooldguy9880 Hello again. At 3:26 it is showing a sort time of 0.1 seconds for the ML Quick Sort. I was wondering if the calculated execution time is rounded or truncated? The reason I ask is because I was able to write an ML Merge Sort routine which takes 0.15 seconds to sort your data set, and the same amount of time to sort data that is initially in reverse order. I decided to try this algorithm because I read that both the Quick Sort and Merge Sort algorithms have roughly the same performance characteristics, but the latter seemed a bit more straightforward to implement in ML.
The clock in the video is using the Time Of Day clock located at $DC08-$DC0B and is in BCD format. It's lowest measurement is in 10ths of a second. So, I switched to jiffies and tried. It took 8 jiffies or 0.13 seconds (8/60=0.13 NTSC). And I did use the quick sort algorithm.
VISION Basic Rules!
I've seen BASIC commands added to the 64's RAM before, like "SAY" that came with SayIt from the S.A.M. package, but I don't understand how it works. How does someone program the computer to make new BASIC-based commands that it would otherwise return with "?SYNTAX ERROR" for? And will you please give more detail than something like, "Uhh, well that's just another ML thing"?
BASIC is stored into C64's RAM when you start the computer. Then you can directly change how individual commands work or add new ones by modifying the content of BASIC RAM. For example, using a simple POKE command, you can change a character in any BASIC text.
@@jakubkrcmadont quit your day job.😮
Do you have any videos or source code regarding your interrupt timing routines?
It's actually a routine I read about back in '84 from Compute!s Gazette. I tweak it as necessary when I want a real-time clock. Here's the link:
archive.org/details/1984-12-computegazette/page/158/mode/2up
divide and conquer version of radix sort, largest digit first
How is it that I saw some C64 text that's a bit yellow-white but it's neither the same yellow or white that we'd normally see on that computer, and I can tell that especially when it's right next to the plain-white text and somewhat close to the stronger yellow text that's on at the same time?
That just some editing magic in order to make the text stand out. A screenshot with the selected text changed to yellow (but not commodore's yellow) overlaid on the video, which wasn't changing or moving at that time.
@@retrooldguy9880: You're talking about the _other_ yellow than what I'm talking about, right? So the "OK"s and the yellowish text at the beginning and end were C64/128-based yellow (I say it like that because Commodore had machines with more colors than that)?
Because if so, then that's interesting, because that makes me think my PC monitor was detuned a little, because while my 64 and 128 haven't been set up for a long time, I remember that yellow being a little more vivid than it looked here -- at least for me.
Yeah, maybe I'll have to look at this again and try tweaking my PC monitor and see if I can get a better match based on my memory, heh.
Thanks for your response.
If I am understanding you correctly, yes, you are right. The prompts of "OK" and "Break" is the true Commodore yellow (as rendered in VICE on my Dell monitor). The yellow and green in the lines of code are colors I added in a separate editor. The overlay only covers affected text, not the whole screen so you ARE seeing two different shades of yellow in the same screen. I hope I answered your question.
@@retrooldguy9880: Yep, you got it, that's the highly trivial item I was curious about! I even turned up the color saturation on my monitor a bit and replayed your intro, and the yellow still seems washed out as compared to my memory and what I've seen in other C64/128 videos recently. So maybe those people were showing the real deal but the VICE is a little off. I don't know; it's not important, but my curiosity was just nagging me a little.
Thanks for your time, it was fun to chat!
I copied what you had onscreen and tried to recreate the program, but I had to fill in the missing details. I had to create my own set of data statements as well (because not all of them are listed). Anyhow try these changes:
120 L=S(P):DEC P:F=S(P):DEC P:LET I=F
130 LET J=L
132 ADD X=F+L:HALF X:D=A(X)
140 IF A(I)D THEN DEC J:GOTO150
160 IF I>J THEN190
162 AI=A(I):AJ=A(J):A(I)=AJ:A(J)=AI
164 LET XI=I:DUBL XI:SUB YI=160-AI
166 LET XJ=J:DUBL XJ:SUB YJ=160-AJ
168 SUB A=AI-AJ
170 VLINE XI,YI,A,0
171 VLINE XI,YJ,AJ,1
172 VLINE XJ,YI,AI,1
180 INC I:DEC J
190 IF I
Tried the changes: Total time 6.13! That's a little over 3 seconds faster than shown in the video and faster than 2 of the the non-graphical PETSCII sorts using the ABACUS computer (shown in a previous video). I'll post the complete data set at the top, if you (or anyone else) wants to experiment with it.
@@retrooldguy9880 Wow... 6.13 seconds, that's incredible! I don't suppose we'll see a follow-up video on this huge speed improvement, would we? Maybe even just a TH-cam Short (60 seconds or less and in vertical mode)?
Thanks, but I think I've done enough videos with sorting. I might use Vision BASIC in some future video though.
@@retrooldguy9880 I sincerely appreciate the exposure! I have no expectations, so if people like the software, I appreciate videos such as these.
I did make a few more changes to speed things up a little more. This time I made the COMPARE conversions. The only other thing that could be done is to access the array contents with machine language instructions (and that would make it more of a machine language program as a result). There is a ceiling that one would hit when considering that the bitmap stuff eats up a lot of the cycles.
Anyhow, here are my changes in addition to what I posted before:
160 compj,i:[bcc190]
172 vline xj,yi,ai
190 comp j,i:[bcs140]
200 comp f,j:[bcs210]
205 incp:s(p)=f:incp:s(p)=j
210 let f=i:comp f,l:[bcc130]
220 comp p,0:[bne120]
In line 172, I just dropped the final parameter because it isn't needed. The effect isn't huge, though.
@@visionbasic Very cool. Thanks I'll give them a try. You are correct, my original concept for the video(s) was to use all BASIC, plus any extended BASIC commands available, and see how much faster it can be by using a compiler. Vision BASIC came to my attention via comment in the first video, and I soon became a customer.
"You'll remember..."
Well... _maybe._
"9.26 seconds."
* 9.27
"BASIC and... BASIC"? Umm...?
Wouldn't "interpreted and compiled BASIC" actually make sense?
There's an easier way to say years like 2017. Remember when we'd say 1975 as "NINETEEN-seventy-five" because it's shorter than the alternative way, which makes it easier? Yeah, well guess what: That still works for most years in this century too! So try saying "TWENTY-seventeen" (and "TWENTY-ten," etc.) today!