Fastest C64 10 PRINT (one-line) With New Benchmark BASIC? 

I love how these videos take me back to my teens to early 20s when programming in BASIC was my favourite hobby.

RND(x) where x>0 calculates a random number based on the last random number generated, stores the result for the next RND call and returns the result. In whatever way it does that, some calculations are performed and something is stored. If x=0, nothing is calculated or stored but the return value is directly constructed from the CIA 1 Timer and the Realtime Clock value of the CIA 6526. This results in a very bad random value as all randomness is based upon two time values but therefore you have no calculation or storage overhead. And for the sake of completeness, if x0, but the calculation is not based on the last random value generated but on the value of x itself, so RND(-x) will always return exactly the same value for the same value of x.

Your obsession with the 10? code is adorable. And the amount of stuff we learn about the innards of C64 Basic is astounding.

Benchmark BASIC is an interesting idea, but I love the optimisations. Magervalp's idea of using a REM statement to hold machine code is incredibly clever.

11:38 That's pretty clever. I often time things and never thought to soft patch the kernel to get a more accurate result. 27:00 Last time I had something make it to hacker news, the number of people who thought they could unroll better than anyone in the history of the world was staggering. I'm going on record and saying yours is excellent for educational purposes. 28:56 Your point here is so important. Learning, fun, and community over who is the best

I love these kind of videos. It'd be perfect if you ran that machine code so we would see how fast it draws compared to some other method.

Wow seeing the basic of the c64 drawing so fast is incredible, it s like seeing a total different computer, very nice!

Simply the best way to enjoy my morning coffee. Thanks for another great 10 PRINT video Robin.

Regarding "copy/paste" on the C64, I recall more then one terminal program featuring this in the mid-80s, they just called it a 'buffer' and you could activate the buffer with a command, type whatever, close the buffer, then paste it all you liked. I have no idea if any of these were written in BASIC or not, I was a 14 year old gaming geek and didn't care much about the underlying tools that made my hot rod run. ;-) Very cool to see all this optimization of what at the first time I saw it I thought was a cool effect and something to type into the store's display computers as a kid, but nothing beyond that.

Integer variable values are actually _stored_ as integers (though with the high byte first for some reason); they're just converted to floats for all arithmetic operations. That doesn't matter much for individual variables, but is very helpful for arrays, since an array of N integers only takes up 2N bytes instead of the 5N required for floats.

I was giggling all the way through this, at the amazing, ingenious improvements that you made. Clever stuff, and to me, it's a programming comedy.

I appreciate the joke thumbnail (even if unintentional) and that you used two exclamation marks instead of one or three. That makes it authentic. Just missing a red arrow pointing at something random. Somehow I never tire of your 10 PRINT antics. Making an Apple version drawn with pixels on the C64 would be interesting.

The speed savings are wild! Especially that assembler one, geesh.

From all the discussions in the comments, it looks like you've got a follow-up video on your hands 😉😄

Dang that MV guy had the same idea that immediately came to my mind about how to speed it up 🤣

Programming the C64, first in basic and then in Machine Code with this visceral direct connection to the hardware being able to modify registers and address spaces directly is something that is missing from today’s first computer experiences.

Very cool video. Love the benchmark basic. I also saw the thing you mention at 29:04. I was going to mention it before I saw you did. You can stack CHR$ in there as much as you like, not just one. Good stuff.

Wow, I really would have expected the integer variables to be faster. Thanks for the insight into the unoptimized integer implementation, that's an interesting find!

I was today years old when I learnt you can add a line number after run!

Wow, either I had totally forgotten about the "step" part of Commodore BASIC or never learned it!

I remember my computer studies teacher gave us a challenge to draw a circle full screen in the fastest time. It was a great lesson in optimisation and the tricks you need to do. Could still be a good interview question.

Some very cool optimizations there! Will have to give Benchmark Basic a try. Your lowercase crunched BASIC lines reminds me of obfuscated Perl lol

I love the concept of these videos. It's very similar to speedrunning video games. Who can get the same thing done fastest? It's awesome to see the ingenuity it takes.

This is a gem, this taught me some new things about Basic, 35 years after I ditched my C-16. But never too late they say right?

Great video again Robin! I haven't had the chance to read all the comments yet so maybe my contribution is redundant. I used C64 VICE in NTSC mode to compare the different versions. The original for/next version was measured as: J:246 S: 4.1 Here are my one liner versions for even less jiffies spent: (Best being 239 jiffies) What works for the program version: instead of using chr$(a+rnd(.)) I swapped the two operands of the addition. The idea behind this was that in some cases multiplications, divisions etc can take more or less iterations depending on the number of bits on the left and right side. Without knowing exactly how the C64 FP arithmetic internals work I still had this assumption. So the chr$(rnd(.)+a) version ended up with overall 1-2 jiffies less than chr$(a+rnd(.)). J:245 S:4.083 What only works in immediate mode: Two more areas where we can speed up this program: 1) Doing less FP arithmetic 2) Unrolling more iterations somehow For 1): I looked for a solution which can branch without doing arithmetic operations. NEXT does FP addition and comparsion against STEP and TO which takes time. From all the branching instructions I found only a few which are not based on line numbers (so works for the one liner versions): END - Not usable as branches into input mode STOP - Same as END RETURN - Requires a GOSUB and heavy trickery on the stack CONT - Hm.. we have a winner What CONT does is that it simply restores the basic program counter and line numbers to where a STOP or BREAK occured. So I just needed to force it to somehow break before the ? so that CONT jumps back. Obviously breaking is not an option. But the way BASIC works is that it stores the address of the current basic instruction in the (61,62) zero page locations before it executes it. CONT uses this saved address to resume the program. Sadly it is not usable in a stored program because BASIC automatically updates this for every instruction, so a simple CONT in the program would jump back to the same CONT. However in immediate mode you can not CONT, so basic does not modify (61,62) location. So all you need to do is store the address of the first statement of the loop in (61,62) then any CONT can jump back to that location. The immediate mode maze generator using CONT is: a=205.5:pO61,20:pO62,2:?cH(rN(.)+a)cH(rN(.)+a)cH(rN(.)+a)cH(rN(.)+a);:cO J:240 S:4 Sadly this is one less iteration unrolled than the original version, but still faster. For 2): To add more statements into the same line these must be crunched even more. The idea here was to enter the already tokenized basic code somehow because the functions and statements take 1 byte instead of 2 or 3. At the end of your video there was a version which contained a machine code after the REM. Using the similar tech but for basic we can write the following immediate mode maze generator: (If you see a that means you need to press Commodore key with the key after it) a=205.5:pO61,24:pO62,2:cO:":#6G(#f(.)#na)G(#f(.)#na)G(#f(.)#na)G(#f(.)#na)G(#f(.)#na);:#7 J:239 S:3.983 Explanation: 61,62 is set to the location of the first : after the ". The first CONT jumps to that location so the " is skipped this way. The one and only quote mark here is needed to store the special token codes. Basic directly stores the string without altering it. No need to close the string. Sadly there is no way to enter the token code of NEXT (130, 0x81) in the string so the for/next version can't be used this way. P.S.: I had to make a patch for your BBASIC to measure immediate basic lines too.

I used to own the C128 back in mid 1988, but I stared out on an Atari 1300 home computer system back in the summer of 1986. I just loved that C128. I played around with its 6502 Assembler Language, after understanding peeking and poking, via invoking into machine code, but it still wasn't as fast as full 6502 machine code. Peeking and poking were from advanced basic near the back of the thick white book. They don't make computers like that anymore. Educational machines at one point in time. I was lucky enough to get into it back then. I was 21 years very young when I started.

This basic had a PI constant, and it was the actual character? Wow. I'm beyond impressed. (the float vs. int thing is a bummer, but as someone who took their first walking steps with AmigaBASIC, this is something I can still appreciate, as I had seen my brother do these weird "BASIC" things when I could still barely write) The "crunch" by removing whitespace thing is absolutely barbaric, but it explains how the parser works in 8k.

and yes I was totally thinking the same thing about embedding assembly. hats off

Suggestion for improvement: Create two internal variables, a line number L as a breakpoint, and a number N as repetitions. When the program hits line L for the Nth time, stop and print the jiffies. That'll allow you to benchmark non-halting programs that never scroll. (Like, updating a number at the top left corner of the screen.) You could combine this with your "array of time points" suggestion setting a third variable, NE (number of external repetitions).

2032: Humanity is ready for the PC and C64 finally runs Crysis

"It's able to do this with BASICally no overhead at all." Haha, nice pun!

Thanks, Robin & Alex!

Ah, so that's the basis of the "backrooms" portal field generator. LOL :) Kidding! I remember this simple little code, back when I had the C-64. Was always cool to watch that random maze generation. Thanks for sharing.

Yeah, that ending SYS example _is_ a cool idea, even though it is technically a cheat according to the spirit of BASIC. So what does that system call to memory location 2016 (decimal) do: read whatever's in the REM statement and take it in as ML bytes? And what does SYSing that without the REM statement do?

You've made it fast, now try and make the the slowest 10print

As soon as I saw "an addendum" I knew it was about print :) I actually fired up vice while you were talking and tried it myself :D

Back in the day, one of the TRS80 magazines ran a one line game challenge, where you had to write a game in 251 characters. All the concepts you talk about here were used to get the best performing game 😄

In some languages a print statement itself is very slow. In those cases it helps to add characters to a string var and print that. Dunnu if that would work here.

Wow, how cool that we can compact the typing of one BASIC line into what's still "80" logical characters, or originally 2 screen lines, but then it uncompacts into what ends up being most of 3 screen lines! OK, your new challenge: Write a C64/128 mode (but still 40-column) noticeably working BASIC program with the longest unfurled logically "80"-character line! IOW, use the longest BASIC commands and operands, etc. with the shortest abbreviations that you can assemble to do something that's noticeably functional.

Another boost: 0 a=4:a$="...MNMNNNNMMMMNNMNMMNM":forb=16to.step.:printmid$(a$,a+b*rnd(.),a);next The M is the graphic backslash, N the graphic slash (shifted M, N on the keyboard). The sequence gives all 16 possible variations (2^4) of 2 symbols on 4 places by indexing from 4 to 19 (16 + 3 symbols). This index is randomized, selecting one of the 16 different 4 character sequences. The dots are a filler to be able to use variable A (primarily needed as string length) also as some offset, because MID$ needs something > 0. A is defined earlier for faster access, because it is referenced twice, A$ and B only once. This takes on my PAL C64 171 jiffies or 2,85 seconds. This seems the maximum possible if keyed in via screen editor (with abbreviations). If we dismiss the line limit of the screen editor this game could played further as far as we keep A$ limited to the maximum of 255 characters (the line length is unlimited, but a re-chaining of the program must not happen). If an appropriate A$ can be composed, the a possible for A and B would be 7 and 128, giving a length of 140 for A$. This task is left to the readers (or Robin), to push it to the extremes ... ;)

Awesome stuff, brings back memories of the '80s! Such a shame that young programmers these days have no insight of the inner workings of the machines the write programs for. Thanks for making these videos!

"A whole nother video..." * "A whole _other_ video" or _"another whole_ video." ("Nother" isn't a word.)

I grew up with a C64, but i was just beginning to code. The lessons of space and logic optimizations paid off when i got a HP 48GX calculator for college and began coding lots of helper functions for math and science classes.

Great job man

Quite interesting! However the main question is: is it jiffies or giffies?

Great video! It would have been nice to have a scoreboard in the upper-right corner, as my short-term memory isn't what it used to be (and it never was much, to begin with).

Great video, Robin :) I totally agree with You, even if it's not the fastest solution, one-line is totally sexier :) Thank You for Benchmark BASIC, it will be a very handy tool to have. Cheers!

I'd love to see a video digging into that REM statement with the machine language in it.

HI Robin. Thanks for these videos. You can further optimize by changing A+RND(.) to RND(.)+A. Using the unrolled version at 28 minutes, I was able to save an additional jiffy. It's not much, but it does make me wonder what the interpreter is doing to make that even the slightest bit faster.

that was a very interessting video, i like it

Oh! I either never learned or had forgotten that the "ready" prompt could be replaced!

Nice one \o/

Awesome video, thank you 😊 What band is in the end credits? 🎉

Awesome!

Not sure if this counts since it doesn't use print or CHROUT, but it fills the screen in about 6 seconds: 10 a=77.5:fori=1024to2024:pokei,(a+rnd(0)):next

x 2 is the first thing after having decided to watch those overlength videos. 😊

That was fun!

Now I want to see more assembler source sticking 75 (?) bytes of machine code at a time in REM statements. 😀 (Ok I actually checked and you can get 75 bytes after 1REM” I guess for a line that can actually be typed in.)

The outro song is really cool. Are you on Spotify by any chance, can we find it there?

Strangely exiting 👍

Hat's off to the MID$ with a de Bruijn sequence, that's really clever! My SYS to a REM statement was always cheating, and I typed it in using the monitor. It's possible to tweak it so it works when typed in though. Not sure how to share the listing, but a hex dump looks like this: >C:0801 26 08 00 00 9e 32 30 36 31 3a 8f 22 a0 df c8 8c >C:0811 15 08 20 be a0 a2 cd 8a a4 8b 30 02 49 03 20 d2 >C:0821 ff 4c 13 08 00 00 00

OMG i love those LOW% speedruns! :D

Astounding, something like A$(0)=CHR$(205):A$(1)=CHR$(206):FORA=.5TO-STEP.:PRINTA$(A+RND(.));:NEXT is roughly 20 % slower ,,, Ok, it's fairly plausible that an array access seems to be more complex than the CHR$ function ... ;)

Unrelated to this video in particular, I've been curious whether the colors your Commodore 64s and 128s produce in these videos are what your capture device spits out by default or if you've had to do some fine tuning to make it match what you've come to expect it to look like on a vintage TV or monitor. I ask because-while I haven't had the pleasure of seeing a Commodore 64 screen in person in quite some time-it feels more accurate to my own memories than anything VICE has been able to produce, both before and after the multiple tweaks that have been made recently to its color handling.

Are you familiar with "Waterloo Structured Basic"? Back in the day it was available on the PET computer. My Mom and Sister learned about and worked with it at the University of Waterloo. I heard rumours that it was available on both VIC 20 and C-64. Have you heard of it on the VIC 20 or C 64?

when i was young i wrote a programm for someone. I wonder how much faster it could have been with those tricks you showed here which i had no idea about. One trick i used was ... since it was a C128 (i used the C64 mode for my programm dont know why anymore) i Poked the speed up to the C128 Clock. While the calculation was done you could not "see" anything on screen but once it ends i Poked the speed back to the C64 clcock and the videooutput was ok again :)

Hehe, "RUN 1." Yeah, it makes sense, it's just a bit funny though.

Aproved? That’s not even a word!

I LOVE C64 ❤❤❤

Real C64 nerds should go even further: Next step is to write an Assembly version of this (which was done in a previous video, if I recall correctly), then arguing how using SID's voice 3 as a random number generator is for "noobs", so not good enough for Assembly 10PRINT. And then arguing once again what is the best sophisticated RNG to use, and how can we squeeze ONE more jiffy by tweaking the Assembly code again and again for an eternity. 😁

Title suggestion: You Won't Believe How FAST This 10 PRINT is!!!

Robin, you had demonstrated that integer math was slower on the Commodore BASIC, but has anyone ever optimized BASIC to make integer basic the faster solution?

Great video! Would it be faster to poke to screen memory rather than using print?

Thanks!

Was there ever a BASIC compiler for the C64? That was one of the reasons that I loved QBasic 4.5 because it could compile a binary and was so much faster that way, but I'd imagine that the memory constraints of the C64 would make that a significant challenge. For instance, how much memory would the program listing take up versus the binary and could you actually store both without eating all your memory too quickly. Which I guess naturally leads to a second question. How many instructions could you usefully store in memory and still get work done?

14:01 Are the 17 consecutive forward slashes 7 lines above the Benchmark results bound to happen whatever the seed for RND() or just with the pi seed?

Cool credits music! What is the song?

I believe you can use shortened 'shift' commands and, as long as you don't list the program first, it will run fractionally faster since the commands are shorter. If you list the program it's destructively expanded back into memory, so you lose the benefits. That may be a VIC 20 quirk, though, as it was a way to get a little more out of your 4K. In that case, if you listed, you'd get an out of memory error as it ran out of room expanding.

Would poke to frame buffer be less overhead over print. Also with poke you write 8-bit value which maybe could be bitwise done. I don't know if c64 basic supports this. Also maybe random value could read from ROM with AND 0X01

I wonder if a peek to the SID's voice 3 oscillator and an AND to grab the lowest bit might work in place of RND, and might be faster.

Here is a mid$ version that calculates the "lookup table" s$ with overlapping strings of length l (here 7 chars). 10 s=0:l=7:n=2^l:dima(n-1) 11 fori=1tol:s$=s$+"M":next 12 : 13 fori=1ton:a(s)=1:s=s*2+1:s=s-n*int(s/n):s$=s$+chr$(206-a(s)):s=s-a(s):next 14 : 15 fori=.ton-1:k=k+a(i):next 16 ifknthenprint"checksum error":stop 17 : 18 fori=nto.step.:printmid$(s$,rnd(.)*n+1,l);:next The precalculation takes a while but you can print s$ and write a new program that uses its value directly.

The machine language in rem at 30:34 doesn't work as typed. Mine matches exactly in lowercase AND uppercase but doesn't do anything when you run it. Is there something else required that is over my head or does it just not work? Regardless of all that this is a great video and project. Thank you!

Great! Is it possible to give goto a rnd(2) adress? How fast would a print be with the complete screen hardcoded in it (1000 c) ?

I typed in the program with the REM line, but it doesn't seem to work. For example the SHIFT+I character is always interpreted as $C9 and hence CMP, but it should be interpreted as $69 which stands for the mnemonic ADC. Or is there a way to fix that?

As far as I can tell, the machine code version in this video does not work if typed in from BASIC. Any opcode or data in the ranges of $60-$7F and $E0-$FE cannot be used because in PETSCII, they are copies of codes at $C0-$DF and $A0-$BE respectively, so if you type the correct character in it changes the opcode. In the case of this code, ADC and BNE cannot be used because ADC gets changed to CMP and the BNE relative jump back changes from F3 to B3. I made another version that has assembly that utilizes ASL, BCC, and INY to switch between 205 and 206. This can be typed in from BASIC. Here is the assembly of just the executable machine code. 080d ldx #$ff 080f stx $d40e 0812 stx $d40f 0815 ldx #$80 0817 stx $d412 081a ldy #$cd //load y with 205 081c lda $d41b //load a with random # from noise waveform 3 081f clc 0820 asl a //shift hi bit of random number to carry 0821 bcc $0824 //skip increment of y if carry is clear 0823 iny //if carry is set then increment y to 206 0824 tya //transfer y to a for printing to screen 0825 jsr $ffd2 //print to screen 0828 jmp $081a //loop back

30:15 : I guess this is an early example of a code injection attack, albeit not in Java.

You Kobayashi Maru'ued 10 print!

I'd love to know the name of the song that played at the end, their voice is interesting and I'm curious to see what else exists for them.

Could you convert 205.5 to hex? Might parse faster. Not as fast as the variable version of course.

Thanks

Would a machine code version of the 1 line program make it any faster.

WHAT IS THAT SONG AT THE END??? I must play it on the radio!

I'm waiting for this program to be ported to a Cray-2 supercomputer.

Pretty cool video, thanks! Too bad this benchmarking tool or one like it didn't come out about 4 decades ago (when you were likely way too young to know how to write it; but then someone else could have). I wonder how handy it would've come for so many coders who, for whatever reason, just wanted to stick with BASIC but still be able to speed things up a good bit.

First I don’t know the c64 can you not store the A value (int 205) in memory along with the RND val (1) before you read the with poke in an unused part of ram then in your line peek it out as it will already have been phrased so 10 print chr$(peek(stored add)) + rnd(peek (stored other add)). Of course assuming c64 has poke and peek. The other way would be to look through ram for a value of 205 and 1 then use those addresses Bob

is that a C64C or is it a 128 in C64 mode?

How about trying run instead of goto?

I had a flashback to the Calgary Olympics while watching this video😂

I wonder how fast you could get it if you ditched the requirement that it has to be a single line, and then unrolled it to be 1000 lines of basic, one for each character printed (40 cols x 25 rows). Preferably by cheating and creating it on your regular computer and then loading it into the C64. (But if you're up for it, it might be entertaining to hear you descend into madness as you produce the 1000 lines on the C64. You know, for science. :D)

…Huh. I guess I was spoiled by Atari 8K BASIC. It tokenized everything, including constants, at the time of line input. So this using-a-variable trick wouldn't help, the number already having been parsed.