Great video Robin! And thank you for the shout-out! That clear screen trick is really neat :) I would love to make a follow-up video but it will be hard to make any better solution than yours. However, I modified your code a bit to make the ball flicker less and move faster :) (this is not a valid bounce ball program but it's fun!) 0dEfna(b)=aB(ti-int(ti/b)*b-b/2):g=z:z=1024+fna(48)*40+fna(78):pOg,32:pOz,81:gO
@@8_Bit If you look at my comment from yesterday, @caspianmaclean8122 and i found a way to make a one-liner without using FN() and with less flicker by drawing the new location first before deleting the old one. 0 x=1-x*(x
Instead of removing the ball first and then drawing it at the new location, you might want to switch it around and draw the ball at the new location first and then remove it. Instead of flickering it will then have a after image which is much more pleasant on the eyes.
Really cool! I don't think I've seen that trick before. Nice work, I'll keep that in mind next time I need looping numbers. For anyone wanting to try it, here's a version with a couple typos fixed: 0x=1-x*(x
The one issue with bouncing ball is if you use even numbers X and Y length of the field ball will go in same trajectory. I found out is best to limit like to 39 for example over X. Then ball will cover every position on the screen. You can test that with not clearing the old posiition.
It is not about evenness, strictly speaking. It happens because 40 and 25 have a common divisor, 5. 39 and 25 don't, indeed. 40 and 24 do as well, and so do 39 and 24, so nudging Y doesn't help.
Here's a version that's slightly shorter, and also clears the screen! The ball flickers a little bit more though. 0dEfna(b)=aB(t-int(t/b)*b-b/2):print"(cls)":pO1024+fna(48)*40+fna(78),81:t=t+1:gO While watching the video I was thinking of alternate approaches, such as having an index that starts at 0 and step variable that cycles between 41, 39, -41, and -39 as appropriate, but nothing was more compact than what you came up with.
Nice idea, but I find that inserting that code into the poke like you did (I tried it), results in more flicker where as if you leave it as it was, assigning it to Z and just adding the ?"{CLS}" before the pokez,81, it will almost be flicker free. The reason it flickers more is you clear the screen, than it does the calculations before it pokes which results in a delay that causes the ball to be gone longer before it is redrawn. I wonder if you did it your way, but put the CLS AFTER you poke the ball, which would probably reduce the flickering more as the ball would be on screen longer while your poke does the calculations (which is the slower part of this).
@@NeilRoy Sure, but code golf is about trying to fit as much as possible into one space, not about it necessarily producing the best results. :) Also I totally forgot that print can be abbreviated as ? which would have saved even more space.
You can get rid of the flicker by drawing the new position first before deleting the old one. You can do that in 2 lines, which also allows you to only call def() once. You could even add a clear screen to that. 0 DEFFNA(B)=ABS(T-INT(T/B)*B-B/2) 1 D=1024+FNA(48)*40+FNA(78):POKED,81:POKEC,32:C=D:T=T+1:GOTO1
@@caspianmaclean8122 Hmmm, it runs for one iteration and then i get a "syntax error" and it actually overwrites the program itself! I also believe you have two typos in your listing above, i think it should be x
I think i found the problem. Since you're starting at the end of the screen memory, you're writing into the basic program at 0x0800 because of the way you're accumulating the x,y location. Going to play with this a bit today.
Once again, you're bringing adult recreational thinking to our collective childhood programming experiences. :) It's like "here's your toy from childhood, and look, here's new ways to play with it!". I remember liking that program back in the day because it contained the variable DY, my initials (that's kinda vain, isn't it?). Didja ever submit an entry to the yearly 10-line basic programming competition? You're clearly optimized for such things.
Then you definitely shouldn't look into software development as a job, because that's all about creative problem solving 🥴 and this "trick" is really closer to the bottom of the pile of problems you'd need to solve 😄
I used to come up to people with an one liner, on the C64, that moved a ball erratically and replaced the old posistion with the reverse circle. Looked hilarious and I had to resort to two lines to make it also move diagonally. I called it the miner.
I used that Bounding Ball program and made it into a breakout game. I managed to get it to run very well considering it was all in basic. I later got it to run better and with redefined characters by using Simons' Basic cartridge and improved the overall programming. I was 13 at the time and it was 1984. Just wish I had the cassette it was saved on today.
Yeah, back in the day, some friends of mine wanted us to create a similar Breakout game that we called "Beat The Wall" (basically me telling them what to type in)... based on this bouncing ball program. On the first test run there was a bug in the bit that was supposed to detect the block and bounce it back so the ball just ripped through all the blocks. They all laughed, got bored and gave up, so we never got to fix it. To this day they are still making fun of me for my crappy "Beat The Wall" game!
Just got a pristine copy of the PRG after nearly 40 years. Looking forward to reacquainting myself with its contents. That’s a delightful solution to clearing the screen.
I think the early days of the C64 were the best. Those programs were just a nice way to get to know the computer. Although I I always sucked at programming.
0:26 My first programming experience was with the VIC-20 User's Guide. 14:16 The program didn't change the cursor color. By default, on newer C64s, it'd be light blue, which would probably be worse. 18:42 There'd be more variety to the bouncing pattern if the numbers of rows and columns were primes. 19:37 The relative flicker is also reduced by keeping the ball on the screen much longer than it's turned off. 28:26 Should start malfunctioning after T reaches 4.2-billion. 36:01 The abbreviations would be more clear if the character set were lowercase. 39:10 I get 2.10 seconds for T to increment 40 times, meaning it will take 7.1 years to overflow the integer range of floating-point numbers. Slowing the program down by re-executing the DEF FN helps to avoid this! It should never "overflow" the floating-point range since after passing the 32-bit mantissa range, T=T+1 will effectively round down to T=T+0.
That's very interesting about the width and height affecting the bouncing pattern; that's configurable on the VIC-20. Maybe a one-line VIC-20 version could also set the screen to 29x23 to make it more interesting. Or if 29 is too wide, 23 by 19 or something. Good point about T=T+1 rounding down to T=T+0! So I suppose the ball would just freeze once the 7+ years or whatever had passed. It would appear to have crashed, but it's really just adding (effectively) zero each step.
Well done, mind melting solution onto one line. This bouncing ball programme (well the vic 20 version) was one that never left my memory since i discovered it all those years ago.
Very clever techniques indeed, anyways, 35:18 for a second I thought why not we pass T as argument along with B and then we can goto 1 and eliminate the time needed to redefine the function, but then I realized that only one argument is supported. If I remember correctly MSX supports multiple arguments per function and one line of code can be 255 characters, it also has a LOCATE command to print at specific x,y coordinates, which gives you more room for one-liner programs (not so challenging for you, I know😎). anyways, commodore is more capable graphic wise I believe. Thanks Robin!
Love your investigations and experiments Robin! Thank you so much for taking the time for us :D (if you can guarantee that the ball won't be in the same place, drawing the new position then erasing the old position will look far less flickery (a ball will always be visible) and look smoother (as the moment where two balls are visible will act as an intermediate frame of animation))
I’m assuming this raises the issue of needing another variable to track the old position. Definitely good for a longer version. And even having a trail of a few balls (“snake”) would be cool.
@@andrewgillham1907 - If there's a smaller circular character, that could be written over the old position, and then blanked on the next frame - that would play into the 'ghosting' effect - although does mean an additional trailing-blanking write - so would be slower
@@andrewgillham1907 I could be wrong, but a new variable should not be required. Robin just needs to display then erase, rather than erase then display. I'm not entirely clear on what the pokes do, so I could very wrong. I just know that from my own experience of moving a dot in Atari BASIC, it was relatively smooth compared to this. Then again, I never it down to 1 line of code.
Alternate bouncing ball: 0D=-(X=0)+(X=39)+D:E=-(Y=0)+(Y=24)+E:X=X+D:Y=Y+E:POKEA,32:A=1024+Y*40+X:POKEA,81,GOTO Still 79 characters crunched. Once difference though, it takes two loops to reverse direction, because the D/E calculations only add or subtract 1. So D/E end up zero at the first boundary check, then will be +/-1 the next.
I think there are a few mistakes like; Y=Y+D => Y=Y+E 1024+Y*40 => 1024+Y*40+X Copy & paste ready version is below: 0d=-(x=0)+(x=39)+d:e=-(y=0)+(y=24)+e:x=x+d:y=y+e:pOa,32:a=1024+y*40+x:pOa,81:gO
I realized I can save 2 characters: 0d=d-(x=0)+(x=39):e=e-(y=0)+(y=24):x=x+d:y=y+e:pokea,32:a=1024+y*40+x:pokea,81:goto Or you can reduce the flicker by moving the *40: 0d=d-(x=0)+(x=39):e=e-(y=0)+(y=960):x=x+d:y=y+e*40:pokea,32:a=1024+y+x:pokea,81:goto
Three decades late, but I’m finally into a little CBM programming myself, and these videos helps me a lot. Thank you! I bought a second hand C64 manual. It’s printed in the UK and less fancy than the one you showed. The code examples are just plain text on paper, not with a black background. The horrible color green in the bouncing ball code is however replaced by blue. The music chapter is totally different than the US version. Strange. Perhaps you can spend a whole episode on the different versions C64 User Guide……
I had never noticed the screen colors of the 'bouncing ball' program. I went to pick up my 1986 manual and in fact... POKE 53280,7:POKE 53281,13 ... At the time I was using the C64 with a Mivar (Italian brand) 17 inches black and white 😁👍🏻
Nice work Robin. It is definitely fun to “re-experience” the joy you got as a kid going through the C64 User Guide. 😀 The bouncing ball is neat and cramming it into one line is impressive. I would say another feature people could try to add is some way to get more randomness as the ball is clearly only following a few paths over and over. With some randomness it should eventually clear the whole screen not just certain paths. Anyway keep up the good work. I’m amazed (& entertained) by how far “10 PRINT” and/or one-liners can go and still be fairly comprehensible. And look cool.
Yes, it would be more interesting if it somehow followed a more varied path. As csbruce noted, if the width and height of the screen were prime numbers, such as 41x23, then the same logic would allow it to cover the whole screen.
@@kernelramdisk3348 They don't have to be primes, just relatively prime (i.e. not sharing any common factors other than 1). It's because then the wavelengths wouldn't match up so frequently.
I altered it slightly. I removed the pokez,32 and put a ?"{CLS}" just before the pokez,81 so the screen is cleared, then the ball is drawn and the ball stays on screen most of the time during code execution and is only momentarily cleared before redrawn and this clears the screen of course. It's almost flicker free this way. I tried adding the Z calculation within the poke but I find it flickers much more that way because the ball is gone longer while it calculates the position before poking where as calculating that ahead of time means the ball is on screen during calculations and only moved once they are complete resulting in almost no flicker at all except to move it.
Robin, thanks for the screen clear idea. It's very counter intuitive way of thinking, because we have to add something to it to make it not be active, as opposed to doing something to it to make it active...or something like that. I just know that some vehicle braking systems require power to male them be released, rather than requiring power to make them work. It seems like there are more opportunities to use math to control things on the screen. By the way, I really appreciate the oscillator info. I watched portions several times, and learned a lot over the last 24 hrs. Thank you so much.
14:35 My first two thoughts as a developer immediately after I saw this code for the very first time: 1024+X+40*Y should be stored to a variable, so it doesn't have to be calculated twice and lines 60 and 70 should come after line 110, so the ball is constantly visible on screen during all the other code lines that also take time to execute, probably reducing the flickering a lot (and as the address is cached, it's okay to change X and Y, clearing is done via the cached address). So with zero C64 programming experience, I'd suggest the following optimization: 10 PRINT CHR$(147) 20 POKE 53280,7 : POKE 53281,13 30 X=1 : Y=1 40 DX=1 : DY=1 45 ADDR=1024+X+40*Y 50 POKE ADDR,81 80 X=X+DX 90 IF X=39 THEN DX=-DX 100 Y=Y+DY 110 IF Y=24 THEN DY=-DY 115 FOR T=1 TO 10 : NEXT 116 POKE ADDR,32 120 GOTO 45
@@BikeAreaBut would that make a performance difference? As if not, source code is written for human beings, computers (and also interpreters) would be fine with just hex digits (much easier to process, even for an interpreter).
This "all these lines into one line" thing never gets old. Seriously. It's always amazing to watch the process. I think by now, you might showcase "it can't be done" examples and let's see if your audience will participate in trying and presenting their results to you somehow. You're so good at what you do, but I'm curious if there are things you can't do?!
Commodore's sample code has lots of computation occurring between the time the ball is erased and once again redrawn. While certainly not compact, I think there is value in having some time delay leaving the ball visible versus hidden (call it the visible duty cycle, if you like). Here's one idea of how it might be coded... 10 poke53280,11:poke53281,0:poke646,7 20 dx=1:dy=1:printchr$(147); 30 a=1024+40*y+x:ifb=0thenb=a 40 pokeb,32:pokea,81:fort=1to10:next 50 b=a:x=x+dx:y=y+dy 60 ifx38thendx=-dx 70 ify23thendy=-dy 80 goto30
I'm so glad I finally watched this. I'm usually not a big fan of "code golf" and I thought 40m seemed long for "one line". But, wow, I have never seen anyone give such a lucid step-by-step process of transforming a program. Amazing job in story telling, giving the motivation before each change. For me, it was like clues so I could pause the video and try to guess what's coming next instead of being told the answer outright. (For example, when you showed how the numbers oscillate.) I also love that you explained everything at the perfect level, not skipping over things a C64 expert might forget to mention, like G shift+O is shorthand for GOTO. You didn't dwell on anything too long, either, or overexplain. In fact, I feel guilty now with this comment because I've clearly gone on far too long just to say "THUMBS UP! You've got a new subscriber."
Your 'bouncing ball' has elements of 'Breakout' about it. It is slowly removing the white text but it ends in a repeating loop following determined paths.
Fun video to watch. It brings back memories when I had to crunch code. Thanks for the video. I suppose the next step would be to execute this in machine language? But that is another video...!!! LOL!
Well done. I wonder how this could be adapted for the VIC-20. I think I preferred the 2-line version. You've optimized for space at the expense of efficiency. The division operations are expensive. Fun video. Thanks Robin
That was fun! I was wondering why, in your two line version before the final, why did you choose to GOTO 0 (where the function was defined) instead of GOTO 1? Very clever optimizations!
On the AMSTRAD CPC you could use the CRTC to synchronise to frame flyback so that the program could synchronise to each frame on the display with a single CALL instruction. This way you'd get rid of the flickering. Surely there is a poke on the C64 for this?
For anyone who doesn't know what a fortnight is that the program could run for ~55 of them... They are about equal to 6 7/8 stone or 4.9 decibushels. Total run time is a little over two years.and one month.
I would suggest starting an IOC64BCC but let's face it, it's hard not to write obfuscated C64 BASIC. Although, you might be able to compete in the IOCCC if you know C. I am curious if you could implement a real time flight sim on the C64, as that is definitely the most impressive entry I've seen. Check out Banks' entry in 1998, even shaped the source code to look like an airplane.
Fascinating use of the DEF FN there. I remember typing this in and making small changes - removing the space so you get a trail, starting at different points and getting rid of those awful colours!
Great ... Here the MM Basic Version for the Raspberry Pi Pico (PicoMite VGA) in MM-Basic ____ Do :D=12*A(78):E=8*A(158):Text E,D,"0":Inc T:Pause 20:Text E,D," ":Loop Function A(B):A=Abs(T-Int(T/B)*B-B/2):End Function ___ 🙂
I know that code! I made a rudimentary brickout game with it when I first got my C64!! Semirelated, but I recently tried porting Steve Wozniak's Little Brickout to C64 BASIC. The original version relies heavily on Integer BASIC draw commands so it's a really interesting challenge trying to get it working and playable on the C64. The only way I found it could be done was if I used print commands to draw the paddle instead of pokes to screen memory. Unfortunately that also meant having the game play lopsided, with the paddle moving horizontally at the top of the screen. I'm not a BASIC pro, though, so I'd be really interesting in seeing what techniques you might use to get it working!
my lazy bouncing ball in 79 standard character input. Amiga demo scene eat ur heart out lol: 2 pokes,46:s=1024+40*sin(t/40)^2+int(25*sin(t/25)^2)*40:pokes,81:t=t+1.5:goto 2
10 PRINT CHR$(147);:FOR I=.TO1STEP.:PRINT CHR$(205.5+RND(1));:NEXT also, fancy version (exactly 80 chars w/o abbreviations), 10 DEFFNA(X)=205.5+RND(1):PRINTCHR$(147);:FORI=.TO1STEP.:PRINTCHR$(FNA(.));:NEXT (Interestingly, I do not see much difference in speed, while the second version has to look up the FNA variable and to prepare the dummy argument. Notably, the FN-variable just points to the tokenized BASIC text in memory and there are no further optimizations for parsing and executing this. While this should run slower, it doesn't feel so. Anyways, no line look up in any of these version as we're relying on an infinite FOR-NEXT loop, which stores the entry point to the tokenized BASIC text on the stack, instead.)
On Applesoft FOR NEXT pushes/pops 7 bytes on the stack. C64 should as well since both BASICs are licensed from Microsoft. That should be faster then linearly searching through memory looking for line number 0 with GOTO.
@@MichaelPohoreski The surprise here is really that the version using DEF FN doesn't feel slower. A FN variable stores a pointer to the tokenized text, where it occurs in memory and to the body of the variable used for the argument. The tokenized text is still executed as normal till the next colon or end of line. However, the contents of the variable used for the argument is pushed to the stack, then we need to parse the argument, and eventually restore the variable contents from the stack. This and the variable look-up should cause a significant overhead, but it doesn't feel so. (Contrary to this, there is a felt difference using FOR-NExT versus GOTO.)
@@noland65 Thanks for the description. I hadn’t looked at the implementation of Define Function until just now but I see that DEF is at $E313 and FN is at $E354 on the Apple 2. Even though it pushes & pulls 7 bytes onto the stack it looks to be fast. Guess I should do some cycle counting for FOR, GOSUB, and FN so I have some hard timing data. The problem with GOSUB is that it does a slow linear search. :-/ I never realized AppleSoft has the same bug where you can omit zero from GOTO 0! :-)
@@MichaelPohoreski Heres's an example for how FN-variables are implemented in memory: 10 DEFFNR(X)=1+X*X 20 PRINT FNR(3) Tokenized BASIC text (Commodore PET, starting at $0401; C64 would be the same, but start at $0801) 0401 12 04 link: $0412 (pointer to next line) 0403 0A 00 line# 10 (binary integer) 0405 96 token DEF 0406 A5 token FN 0407 52 28 58 29 ascii «R(X)» 040B B2 token = 040C 31 ascii «1» 040D AA token + 040E 58 ascii «X» 040F AC token * 0410 58 ascii «X» 0411 00 -EOL- 0412 1E 04 link: $041E 0414 14 00 line# 20 0416 99 token PRINT 0417 20 ascii « » (space) 0418 A5 token FN 0419 52 28 33 29 ascii «R(3)» 041D 00 -EOL- 041E 00 00 -EOP- (link = null) Variables (at run-time) 0420 D2 00 Var. FNR() (ASCII «R» + $80, $00) 0422 0C 04 pointer to $040C 0424 29 04 pointer to $0429 0426 31 - ??? - (actually ASCII «1») 0427 58 00 Var. "X" 0429 00 00 00 00 00 float = 0 The first 2 bytes of the variable body of "FNR()" points to the variable body of var. "X" (5 bytes to hold a float: 1 byte exponent, 4 bytes mantissa), the second pair of bytes is a pointer to the tokenized function body in the main program, just after the token for"=". The 5th byte is just a leftover (actually the first token of the function body, here the ASCII code for "1", - simple variables in Commodore BASIC are always 7 bytes, 2 for the name/type and 5 for the variable body). FN-variables have the sign-bit set on the first name-byte, but not on the second one. On execution, the 5 bytes found at the first pointer (float body) are first saved on the stack and set to the value of the argument, then we execute the tokens found at the location of the second pointer, and finally restore the float variable from the stack. (Therefore, we can nest FN-calls and reuse a variable already in use elsewhere, while there are only global variables. The argument is effectively a local variable.) Notably, we have to parse and convert ASCII "R(3)" on each encounter and lookup the FN-variable (in a linear search). This is scarcely documented, the only (contemporary) book mentioning how FN-variables are stored, or even do exist, is "Programming the PET/CBM" by Raeto West. (So there are 4 basic variable types in Commodore BASIC: floats, integers, strings, and FN-variables. But there is no such thing as an array of FN-variables.) PS: May be intersting to see, if there are any major differences in how things are implemented in Applesoft BASIC. PPS: I've been wondering why this 5th byte is stored at all. Now, I've just the idea that this may be a simple check, if there is anything behind the "=" after the function definition, i.e. if there is a funtion body at all. (Maybe interesting to investigate, if there's any check at any point for this being not null, or, maybe, not a colon.)
@@noland65 Thanks for the awesome technical breakdown! I’ll take a look at the corresponding tokenized Applesoft BASIC in a day or two since my main machine is tied up processing simulations for the next day. Applesoft programs start at $801 as well so that is super convenient as that is one less thing to worry about. Now I’m curious how many of the tokens are the same across the 2 BASICs: Applesoft and C64? I would wager most of them since they came from the same source assembly file. Good to know that C64 floats are 5 bytes as well! You may already know this but Microsoft’s original source actually has an assembly-time define if floats should be 4 byte or 5 bytes. Kind of funny that our 8-bit computers have _more_ precision then C’s float type. Hehe. But I digress. Interesting that one can nest FN calls! This opens up some interesting possibilities. I see that Applesoft also sets the high bit on the first character of the DEF name. (Not sure if YT will preserve formatting.) E341- A9 C2 3780 FNC. LDA #TOKEN.FN MUST NOW SEE "FN" TOKEN E343- 20 C0 DE 3790 JSR SYNCHR OR ELSE SYNTAX ERROR E346- 09 80 3800 ORA #$80 SET SIGN BIT ON 1ST CHAR OF NAME, E348- 85 14 3810 STA SUBFLG MAKING $C0 < SUBFLG < $DB E34A- 20 EA DF 3820 JSR PTRGET3 WHICH TELLS PTRGET WHO CALLED E34D- 85 8A 3830 STA FNCNAM FOUND VALID FUNCTION NAME, SO E34F- 84 8B 3840 STY FNCNAM+1 SAVE ADDRESS E351- 4C 6A DD 3850 JMP CHKNUM MUST BE NUMERIC My mind is racing with possibilities. I want to document Applesoft’s stack usage now. Another GitHub repro to create and document this weekend. :-)
Hey, Robin, what are some of your favorite clever code snippets in C64 BASIC? For me, when I saw this particular one in a magazine listing once it stuck with me to this day for its simplicity and usefulness: A = 1 - A Very useful for alternating between 0 and 1 (or any two values with some slight modification). Another I like, which I believe only works on 8 bit Commodore computers, is for multi-loading: 10 If A = 0 Then A = 1: Load "part 1",8,1 20 If A = 1 Then A = 2: Load "part 2",8,1 etc. This was a mystery to me until I found out why it works.
in the 2 line bouncing ball, what if line 0 had the x and y drawing of a blank space happen before the coordinates being calculated with a line separator with the colon between the action to clear the coordinate and the coordinate calculation of line 0? is that possible in that method? If so, shouldn't most of the flicker of the drawing be negated?
Haha, I wondered about _that_ color combination too! Wouldn't exactly be even worse on a B/W TV or other monitor, since it seems to have low contrast? Wouldn't a grayscale screen make it even lower contrast? Yeah, I would definitely like to see this with a dark background and a light ball or vice versa.
Robin did an assembly-language version of the maze not that long ago. I recall it being about 100x faster than the BASIC implementation. That's a lot faster but not blindingly fast. It's still calling the BASIC functions to print and scroll. Further optimization could be done, but that would be an unfair comparison.
Re the colors from the manual, sometimes I have to ask, What does this look like on your display? Especially when I see a web site with dark gray text on a black background in a 6pt font.
It's called "Confounded to Corruption". A different mix of it is on my band's channel, but this particular version hasn't been released (yet). ua-cam.com/video/U1VKwqUWYa8/v-deo.html
I was wondering, what's the name of the "Island " demo Robin mentioned in some videos which he described as "has a lot of moving objects on the screen at once"? I can't seem to find, so let's see if someone can help. :)
Should have been called the useless guide. The part about sound was particularly disappointing. Loved that machine. It became the start of a new career.
Great video Robin! And thank you for the shout-out! That clear screen trick is really neat :)
I would love to make a follow-up video but it will be hard to make any better solution than yours.
However, I modified your code a bit to make the ball flicker less and move faster :)
(this is not a valid bounce ball program but it's fun!)
0dEfna(b)=aB(ti-int(ti/b)*b-b/2):g=z:z=1024+fna(48)*40+fna(78):pOg,32:pOz,81:gO
Nice work Josip, thanks for your interesting posts and videos!
@@8_Bit
If you look at my comment from yesterday, @caspianmaclean8122 and i found a way to make a one-liner without using FN() and with less flicker by drawing the new location first before deleting the old one.
0 x=1-x*(x
Nice one, Cyb! That's a really cool trick.
Both your channels are great, nice to see you both shouting each other out. :)
@@HAGSLAB Thank You :)
Instead of removing the ball first and then drawing it at the new location, you might want to switch it around and draw the ball at the new location first and then remove it. Instead of flickering it will then have a after image which is much more pleasant on the eyes.
If you check out the pinned post comments someone actually implemented exactly what you are saying.
Exactly what I was thinking.
YES!!! New 8-bit S&T Episode!!! Heck yes. Robin your channel seriously rocks.
heck. lol.
@@endoflevelboss didn't want my comment o get blocked :p
I found x=1-x*(x
Really cool! I don't think I've seen that trick before. Nice work, I'll keep that in mind next time I need looping numbers.
For anyone wanting to try it, here's a version with a couple typos fixed:
0x=1-x*(x
Had a blast with this one. Setup my "The C64" (no old hardware anymore. :( ) and typed along. I liked the seeing a good use of DEF FN.
The one issue with bouncing ball is if you use even numbers X and Y length of the field ball will go in same trajectory. I found out is best to limit like to 39 for example over X. Then ball will cover every position on the screen. You can test that with not clearing the old posiition.
It is not about evenness, strictly speaking. It happens because 40 and 25 have a common divisor, 5.
39 and 25 don't, indeed.
40 and 24 do as well, and so do 39 and 24, so nudging Y doesn't help.
Here's a version that's slightly shorter, and also clears the screen! The ball flickers a little bit more though.
0dEfna(b)=aB(t-int(t/b)*b-b/2):print"(cls)":pO1024+fna(48)*40+fna(78),81:t=t+1:gO
While watching the video I was thinking of alternate approaches, such as having an index that starts at 0 and step variable that cycles between 41, 39, -41, and -39 as appropriate, but nothing was more compact than what you came up with.
Nice idea, but I find that inserting that code into the poke like you did (I tried it), results in more flicker where as if you leave it as it was, assigning it to Z and just adding the ?"{CLS}" before the pokez,81, it will almost be flicker free. The reason it flickers more is you clear the screen, than it does the calculations before it pokes which results in a delay that causes the ball to be gone longer before it is redrawn.
I wonder if you did it your way, but put the CLS AFTER you poke the ball, which would probably reduce the flickering more as the ball would be on screen longer while your poke does the calculations (which is the slower part of this).
@@NeilRoy Sure, but code golf is about trying to fit as much as possible into one space, not about it necessarily producing the best results. :)
Also I totally forgot that print can be abbreviated as ? which would have saved even more space.
@@fluffycritter You still want it to run reasonably well, and having the delay while the screen is blank is not good. And it already fits on one line.
I'd like to challenge all you real experts to come up with a version of the CLS-inclusive 1-liner that takes inspiration from The Story of Mel.
You can get rid of the flicker by drawing the new position first before deleting the old one. You can do that in 2 lines, which also allows you to only call def() once. You could even add a clear screen to that.
0 DEFFNA(B)=ABS(T-INT(T/B)*B-B/2)
1 D=1024+FNA(48)*40+FNA(78):POKED,81:POKEC,32:C=D:T=T+1:GOTO1
I found enough space to draw before erase on one line:
0x=1-x*(y
@@caspianmaclean8122 Hmmm, it runs for one iteration and then i get a "syntax error" and it actually overwrites the program itself!
I also believe you have two typos in your listing above, i think it should be x
I think i found the problem. Since you're starting at the end of the screen memory, you're writing into the basic program at 0x0800 because of the way you're accumulating the x,y location. Going to play with this a bit today.
Yes!
0 x=1-x*(x
Saved another 2 chars:
0 x=1-x*(x
Never touched a C64, I'm more savvy in C, but I love watching your videos because they bring so much wisdom about the fundamentals of programming! ❤
Once again, you're bringing adult recreational thinking to our collective childhood programming experiences. :) It's like "here's your toy from childhood, and look, here's new ways to play with it!". I remember liking that program back in the day because it contained the variable DY, my initials (that's kinda vain, isn't it?).
Didja ever submit an entry to the yearly 10-line basic programming competition? You're clearly optimized for such things.
Thanks, I still haven't tried the 10-line compo. I really should sometime. That's funny about the DY! :)
Wow, Robin, that clear-screen-only-once trick is pretty clever! I don't think I would have ever thought of that on my own in my whole life!
Then you definitely shouldn't look into software development as a job, because that's all about creative problem solving 🥴 and this "trick" is really closer to the bottom of the pile of problems you'd need to solve 😄
I wonder if the color choice was because it most closely resembles a tennis court (when played on grass).
Or maybe a pool table.
I used to come up to people with an one liner, on the C64, that moved a ball erratically and replaced the old posistion with the reverse circle. Looked hilarious and I had to resort to two lines to make it also move diagonally. I called it the miner.
I used that Bounding Ball program and made it into a breakout game. I managed to get it to run very well considering it was all in basic. I later got it to run better and with redefined characters by using Simons' Basic cartridge and improved the overall programming. I was 13 at the time and it was 1984. Just wish I had the cassette it was saved on today.
Yeah, back in the day, some friends of mine wanted us to create a similar Breakout game that we called "Beat The Wall" (basically me telling them what to type in)... based on this bouncing ball program.
On the first test run there was a bug in the bit that was supposed to detect the block and bounce it back so the ball just ripped through all the blocks. They all laughed, got bored and gave up, so we never got to fix it. To this day they are still making fun of me for my crappy "Beat The Wall" game!
Just got a pristine copy of the PRG after nearly 40 years. Looking forward to reacquainting myself with its contents. That’s a delightful solution to clearing the screen.
I think the early days of the C64 were the best. Those programs were just a nice way to get to know the computer. Although I I always sucked at programming.
I remember writing my own version of Arkanoid on the C64 from scratch with multiple levels/patterns of blocks. Wish I still had it
0:26 My first programming experience was with the VIC-20 User's Guide.
14:16 The program didn't change the cursor color. By default, on newer C64s, it'd be light blue, which would probably be worse.
18:42 There'd be more variety to the bouncing pattern if the numbers of rows and columns were primes.
19:37 The relative flicker is also reduced by keeping the ball on the screen much longer than it's turned off.
28:26 Should start malfunctioning after T reaches 4.2-billion.
36:01 The abbreviations would be more clear if the character set were lowercase.
39:10 I get 2.10 seconds for T to increment 40 times, meaning it will take 7.1 years to overflow the integer range of floating-point numbers. Slowing the program down by re-executing the DEF FN helps to avoid this! It should never "overflow" the floating-point range since after passing the 32-bit mantissa range, T=T+1 will effectively round down to T=T+0.
That's very interesting about the width and height affecting the bouncing pattern; that's configurable on the VIC-20. Maybe a one-line VIC-20 version could also set the screen to 29x23 to make it more interesting. Or if 29 is too wide, 23 by 19 or something.
Good point about T=T+1 rounding down to T=T+0! So I suppose the ball would just freeze once the 7+ years or whatever had passed. It would appear to have crashed, but it's really just adding (effectively) zero each step.
Thanks Robin, you really have a gift of making programming fun and interesting. Another great video.
Well done, mind melting solution onto one line. This bouncing ball programme (well the vic 20 version) was one that never left my memory since i discovered it all those years ago.
Very clever techniques indeed,
anyways, 35:18 for a second I thought why not we pass T as argument along with B and then we can goto 1 and eliminate the time needed to redefine the function, but then I realized that only one argument is supported.
If I remember correctly MSX supports multiple arguments per function and one line of code can be 255 characters, it also has a LOCATE command to print at specific x,y coordinates, which gives you more room for one-liner programs (not so challenging for you, I know😎).
anyways, commodore is more capable graphic wise I believe.
Thanks Robin!
Love your investigations and experiments Robin! Thank you so much for taking the time for us :D (if you can guarantee that the ball won't be in the same place, drawing the new position then erasing the old position will look far less flickery (a ball will always be visible) and look smoother (as the moment where two balls are visible will act as an intermediate frame of animation))
I’m assuming this raises the issue of needing another variable to track the old position. Definitely good for a longer version. And even having a trail of a few balls (“snake”) would be cool.
@@andrewgillham1907 - If there's a smaller circular character, that could be written over the old position, and then blanked on the next frame - that would play into the 'ghosting' effect - although does mean an additional trailing-blanking write - so would be slower
@@andrewgillham1907 I could be wrong, but a new variable should not be required. Robin just needs to display then erase, rather than erase then display.
I'm not entirely clear on what the pokes do, so I could very wrong.
I just know that from my own experience of moving a dot in Atari BASIC, it was relatively smooth compared to this. Then again, I never it down to 1 line of code.
Alternate bouncing ball:
0D=-(X=0)+(X=39)+D:E=-(Y=0)+(Y=24)+E:X=X+D:Y=Y+E:POKEA,32:A=1024+Y*40+X:POKEA,81,GOTO
Still 79 characters crunched. Once difference though, it takes two loops to reverse direction, because the D/E calculations only add or subtract 1. So D/E end up zero at the first boundary check, then will be +/-1 the next.
I think there are a few mistakes like;
Y=Y+D => Y=Y+E
1024+Y*40 => 1024+Y*40+X
Copy & paste ready version is below:
0d=-(x=0)+(x=39)+d:e=-(y=0)+(y=24)+e:x=x+d:y=y+e:pOa,32:a=1024+y*40+x:pOa,81:gO
@@c64skate Thanks - I fixed typo in original.
I realized I can save 2 characters:
0d=d-(x=0)+(x=39):e=e-(y=0)+(y=24):x=x+d:y=y+e:pokea,32:a=1024+y*40+x:pokea,81:goto
Or you can reduce the flicker by moving the *40:
0d=d-(x=0)+(x=39):e=e-(y=0)+(y=960):x=x+d:y=y+e*40:pokea,32:a=1024+y+x:pokea,81:goto
Three decades late, but I’m finally into a little CBM programming myself, and these videos helps me a lot. Thank you!
I bought a second hand C64 manual. It’s printed in the UK and less fancy than the one you showed. The code examples are just plain text on paper, not with a black background. The horrible color green in the bouncing ball code is however replaced by blue.
The music chapter is totally different than the US version. Strange. Perhaps you can spend a whole episode on the different versions C64 User Guide……
I had never noticed the screen colors of the 'bouncing ball' program. I went to pick up my 1986 manual and in fact... POKE 53280,7:POKE 53281,13 ... At the time I was using the C64 with a Mivar (Italian brand) 17 inches black and white 😁👍🏻
If this one-liner were sent via time machine to an early 80s Commodore/computer magazine...
Nice work Robin. It is definitely fun to “re-experience” the joy you got as a kid going through the C64 User Guide. 😀
The bouncing ball is neat and cramming it into one line is impressive. I would say another feature people could try to add is some way to get more randomness as the ball is clearly only following a few paths over and over. With some randomness it should eventually clear the whole screen not just certain paths.
Anyway keep up the good work. I’m amazed (& entertained) by how far “10 PRINT” and/or one-liners can go and still be fairly comprehensible. And look cool.
Yes, it would be more interesting if it somehow followed a more varied path. As csbruce noted, if the width and height of the screen were prime numbers, such as 41x23, then the same logic would allow it to cover the whole screen.
First a "10 PRINT" to fill the screen and then a bouncing ball to clear it! A two line program :-P
Sorry for for being an idiot but can you explain why if the width and height were primes the trajectory of that ball would be more variable?
@@kernelramdisk3348 They don't have to be primes, just relatively prime (i.e. not sharing any common factors other than 1). It's because then the wavelengths wouldn't match up so frequently.
The ball seems to move in the same path all the time 🥺
That's because of the relationship between the X and Y values
Roll the clock back 45 years, I wish you would have been my computer science teacher! You have an amazing mind!
I altered it slightly. I removed the pokez,32 and put a ?"{CLS}" just before the pokez,81 so the screen is cleared, then the ball is drawn and the ball stays on screen most of the time during code execution and is only momentarily cleared before redrawn and this clears the screen of course. It's almost flicker free this way. I tried adding the Z calculation within the poke but I find it flickers much more that way because the ball is gone longer while it calculates the position before poking where as calculating that ahead of time means the ball is on screen during calculations and only moved once they are complete resulting in almost no flicker at all except to move it.
Robin, thanks for the screen clear idea. It's very counter intuitive way of thinking, because we have to add something to it to make it not be active, as opposed to doing something to it to make it active...or something like that. I just know that some vehicle braking systems require power to male them be released, rather than requiring power to make them work.
It seems like there are more opportunities to use math to control things on the screen.
By the way, I really appreciate the oscillator info.
I watched portions several times, and learned a lot over the last 24 hrs. Thank you so much.
I kind of started to miss you ;) thank you very much for that new video. I will enjoy it, for sure!
The Amstrad CPC 464 book was amazing. Would love to see an analysis
Soooo many memories back...thank you so much for your video and your passion. 🙂🙂🙂
Another great one. I think I will have a go at this. Also, my favourite song so far, at the end.
It’s always a highlight when Robin upload a new video.
14:35 My first two thoughts as a developer immediately after I saw this code for the very first time: 1024+X+40*Y should be stored to a variable, so it doesn't have to be calculated twice and lines 60 and 70 should come after line 110, so the ball is constantly visible on screen during all the other code lines that also take time to execute, probably reducing the flickering a lot (and as the address is cached, it's okay to change X and Y, clearing is done via the cached address). So with zero C64 programming experience, I'd suggest the following optimization:
10 PRINT CHR$(147)
20 POKE 53280,7 : POKE 53281,13
30 X=1 : Y=1
40 DX=1 : DY=1
45 ADDR=1024+X+40*Y
50 POKE ADDR,81
80 X=X+DX
90 IF X=39 THEN DX=-DX
100 Y=Y+DY
110 IF Y=24 THEN DY=-DY
115 FOR T=1 TO 10 : NEXT
116 POKE ADDR,32
120 GOTO 45
(Just a little note: C64-Basic only cares for the first two characters of a variable, so ADDR could be reduced to AD.)
@@BikeAreaBut would that make a performance difference? As if not, source code is written for human beings, computers (and also interpreters) would be fine with just hex digits (much easier to process, even for an interpreter).
This "all these lines into one line" thing never gets old. Seriously. It's always amazing to watch the process. I think by now, you might showcase "it can't be done" examples and let's see if your audience will participate in trying and presenting their results to you somehow.
You're so good at what you do, but I'm curious if there are things you can't do?!
So satisfying when the "ball" hits the corner perfectly. Reminds me of DVD players.
This is so damn clever. I love it!!
Code golfing on a C= 64, this video is the cutest.
Commodore's sample code has lots of computation occurring between the time the ball is erased and once again redrawn. While certainly not compact, I think there is value in having some time delay leaving the ball visible versus hidden (call it the visible duty cycle, if you like). Here's one idea of how it might be coded...
10 poke53280,11:poke53281,0:poke646,7
20 dx=1:dy=1:printchr$(147);
30 a=1024+40*y+x:ifb=0thenb=a
40 pokeb,32:pokea,81:fort=1to10:next
50 b=a:x=x+dx:y=y+dy
60 ifx38thendx=-dx
70 ify23thendy=-dy
80 goto30
19:15 you also notice that the bounce is very regular... it follows the same path
24:00 which you will take advantage of eventually.
“…does it work? Ship it!” Hahahahahaha. I laughed and laughed.
The bouncing ball was my first program I typed in on my c64.
I was 8 years old.
One can spare 1 char bei using 4↑5 instead of 1024
Nothing is slower in Basic than calculating the power function. 😉
I'm so glad I finally watched this. I'm usually not a big fan of "code golf" and I thought 40m seemed long for "one line". But, wow, I have never seen anyone give such a lucid step-by-step process of transforming a program. Amazing job in story telling, giving the motivation before each change. For me, it was like clues so I could pause the video and try to guess what's coming next instead of being told the answer outright. (For example, when you showed how the numbers oscillate.)
I also love that you explained everything at the perfect level, not skipping over things a C64 expert might forget to mention, like G shift+O is shorthand for GOTO. You didn't dwell on anything too long, either, or overexplain.
In fact, I feel guilty now with this comment because I've clearly gone on far too long just to say "THUMBS UP! You've got a new subscriber."
I have a suggestion for the bouncing ball. How about using SIN. Then you don't need that function. I suspect it would be a lot shorter as well.
I was thinking about using the trig functions but none of them are linear so the ball would look like it's speeding up and slowing down, probably?
@@8_Bit yeah it would look different possibly. But technically it would work
@@8_Bit Could you somehow use the Triangle waveform from the SID chip? I dunno, just spitballing
I was thinking that A mod B equals A AND (B-1) if B is a power of 2, so that might work for a 33x17 screen, but it doesn't really gain much.
2:28 i startet laughing so hard, i nearly lost consciousness
Miss this computer. Was so much fun with the overlay on the keyboard for gaming.
Fascinating. Nice to see C64 coding videos.
Your 'bouncing ball' has elements of 'Breakout' about it. It is slowly removing the white text but it ends in a repeating loop following determined paths.
Wow clever method. And really well explained by using the print statements!
Fun video to watch. It brings back memories when I had to crunch code. Thanks for the video. I suppose the next step would be to execute this in machine language? But that is another video...!!! LOL!
C64 was awsom for kids as you could program your own game , you got a book of games learned how it all worked and then create your own game.
So glad to see Josip mentioned!
Well done. I wonder how this could be adapted for the VIC-20.
I think I preferred the 2-line version. You've optimized for space at the expense of efficiency. The division operations are expensive.
Fun video. Thanks Robin
So that's just brilliant! Nice work!
That was fun! I was wondering why, in your two line version before the final, why did you choose to GOTO 0 (where the function was defined) instead of GOTO 1?
Very clever optimizations!
On the AMSTRAD CPC you could use the CRTC to synchronise to frame flyback so that the program could synchronise to each frame on the display with a single CALL instruction. This way you'd get rid of the flickering. Surely there is a poke on the C64 for this?
Yes, that could be done with a PEEK or WAIT command if there were room to fit it in the single line of code.
For anyone who doesn't know what a fortnight is that the program could run for ~55 of them... They are about equal to 6 7/8 stone or 4.9 decibushels.
Total run time is a little over two years.and one month.
So user-friendly. Completely understandable by someone who really didn't have a clue about computing .
I would suggest starting an IOC64BCC but let's face it, it's hard not to write obfuscated C64 BASIC. Although, you might be able to compete in the IOCCC if you know C. I am curious if you could implement a real time flight sim on the C64, as that is definitely the most impressive entry I've seen. Check out Banks' entry in 1998, even shaped the source code to look like an airplane.
Fascinating use of the DEF FN there. I remember typing this in and making small changes - removing the space so you get a trail, starting at different points and getting rid of those awful colours!
Great video Robin :) ... Josip does some great stuff :) ....
Great to have you back.
Great ...
Here the MM Basic Version for the Raspberry Pi Pico (PicoMite VGA) in MM-Basic
____
Do :D=12*A(78):E=8*A(158):Text E,D,"0":Inc T:Pause 20:Text E,D," ":Loop
Function A(B):A=Abs(T-Int(T/B)*B-B/2):End Function
___
🙂
I always look forward to the end credits music
I know that code! I made a rudimentary brickout game with it when I first got my C64!! Semirelated, but I recently tried porting Steve Wozniak's Little Brickout to C64 BASIC. The original version relies heavily on Integer BASIC draw commands so it's a really interesting challenge trying to get it working and playable on the C64. The only way I found it could be done was if I used print commands to draw the paddle instead of pokes to screen memory. Unfortunately that also meant having the game play lopsided, with the paddle moving horizontally at the top of the screen. I'm not a BASIC pro, though, so I'd be really interesting in seeing what techniques you might use to get it working!
Incredible, very nice :)
@7:00 Very clever!
my lazy bouncing ball in 79 standard character input. Amiga demo scene eat ur heart out lol:
2 pokes,46:s=1024+40*sin(t/40)^2+int(25*sin(t/25)^2)*40:pokes,81:t=t+1.5:goto 2
10 PRINT CHR$(147);:FOR I=.TO1STEP.:PRINT CHR$(205.5+RND(1));:NEXT
also, fancy version (exactly 80 chars w/o abbreviations),
10 DEFFNA(X)=205.5+RND(1):PRINTCHR$(147);:FORI=.TO1STEP.:PRINTCHR$(FNA(.));:NEXT
(Interestingly, I do not see much difference in speed, while the second version has to look up the FNA variable and to prepare the dummy argument. Notably, the FN-variable just points to the tokenized BASIC text in memory and there are no further optimizations for parsing and executing this. While this should run slower, it doesn't feel so. Anyways, no line look up in any of these version as we're relying on an infinite FOR-NEXT loop, which stores the entry point to the tokenized BASIC text on the stack, instead.)
On Applesoft FOR NEXT pushes/pops 7 bytes on the stack. C64 should as well since both BASICs are licensed from Microsoft. That should be faster then linearly searching through memory looking for line number 0 with GOTO.
@@MichaelPohoreski The surprise here is really that the version using DEF FN doesn't feel slower. A FN variable stores a pointer to the tokenized text, where it occurs in memory and to the body of the variable used for the argument. The tokenized text is still executed as normal till the next colon or end of line. However, the contents of the variable used for the argument is pushed to the stack, then we need to parse the argument, and eventually restore the variable contents from the stack. This and the variable look-up should cause a significant overhead, but it doesn't feel so. (Contrary to this, there is a felt difference using FOR-NExT versus GOTO.)
@@noland65 Thanks for the description. I hadn’t looked at the implementation of Define Function until just now but I see that DEF is at $E313 and FN is at $E354 on the Apple 2. Even though it pushes & pulls 7 bytes onto the stack it looks to be fast. Guess I should do some cycle counting for FOR, GOSUB, and FN so I have some hard timing data. The problem with GOSUB is that it does a slow linear search. :-/
I never realized AppleSoft has the same bug where you can omit zero from GOTO 0! :-)
@@MichaelPohoreski
Heres's an example for how FN-variables are implemented in memory:
10 DEFFNR(X)=1+X*X
20 PRINT FNR(3)
Tokenized BASIC text (Commodore PET, starting at $0401; C64 would be the same, but start at $0801)
0401 12 04 link: $0412 (pointer to next line)
0403 0A 00 line# 10 (binary integer)
0405 96 token DEF
0406 A5 token FN
0407 52 28 58 29 ascii «R(X)»
040B B2 token =
040C 31 ascii «1»
040D AA token +
040E 58 ascii «X»
040F AC token *
0410 58 ascii «X»
0411 00 -EOL-
0412 1E 04 link: $041E
0414 14 00 line# 20
0416 99 token PRINT
0417 20 ascii « » (space)
0418 A5 token FN
0419 52 28 33 29 ascii «R(3)»
041D 00 -EOL-
041E 00 00 -EOP- (link = null)
Variables (at run-time)
0420 D2 00 Var. FNR() (ASCII «R» + $80, $00)
0422 0C 04 pointer to $040C
0424 29 04 pointer to $0429
0426 31 - ??? - (actually ASCII «1»)
0427 58 00 Var. "X"
0429 00 00 00 00 00 float = 0
The first 2 bytes of the variable body of "FNR()" points to the variable body of var. "X" (5 bytes to hold a float: 1 byte exponent, 4 bytes mantissa), the second pair of bytes is a pointer to the tokenized function body in the main program, just after the token for"=".
The 5th byte is just a leftover (actually the first token of the function body, here the ASCII code for "1", - simple variables in Commodore BASIC are always 7 bytes, 2 for the name/type and 5 for the variable body).
FN-variables have the sign-bit set on the first name-byte, but not on the second one.
On execution, the 5 bytes found at the first pointer (float body) are first saved on the stack and set to the value of the argument, then we execute the tokens found at the location of the second pointer, and finally restore the float variable from the stack. (Therefore, we can nest FN-calls and reuse a variable already in use elsewhere, while there are only global variables. The argument is effectively a local variable.)
Notably, we have to parse and convert ASCII "R(3)" on each encounter and lookup the FN-variable (in a linear search).
This is scarcely documented, the only (contemporary) book mentioning how FN-variables are stored, or even do exist, is "Programming the PET/CBM" by Raeto West. (So there are 4 basic variable types in Commodore BASIC: floats, integers, strings, and FN-variables. But there is no such thing as an array of FN-variables.)
PS: May be intersting to see, if there are any major differences in how things are implemented in Applesoft BASIC.
PPS: I've been wondering why this 5th byte is stored at all. Now, I've just the idea that this may be a simple check, if there is anything behind the "=" after the function definition, i.e. if there is a funtion body at all. (Maybe interesting to investigate, if there's any check at any point for this being not null, or, maybe, not a colon.)
@@noland65 Thanks for the awesome technical breakdown! I’ll take a look at the corresponding tokenized Applesoft BASIC in a day or two since my main machine is tied up processing simulations for the next day.
Applesoft programs start at $801 as well so that is super convenient as that is one less thing to worry about.
Now I’m curious how many of the tokens are the same across the 2 BASICs: Applesoft and C64? I would wager most of them since they came from the same source assembly file.
Good to know that C64 floats are 5 bytes as well! You may already know this but Microsoft’s original source actually has an assembly-time define if floats should be 4 byte or 5 bytes. Kind of funny that our 8-bit computers have _more_ precision then C’s float type. Hehe. But I digress.
Interesting that one can nest FN calls! This opens up some interesting possibilities.
I see that Applesoft also sets the high bit on the first character of the DEF name. (Not sure if YT will preserve formatting.)
E341- A9 C2 3780 FNC. LDA #TOKEN.FN MUST NOW SEE "FN" TOKEN
E343- 20 C0 DE 3790 JSR SYNCHR OR ELSE SYNTAX ERROR
E346- 09 80 3800 ORA #$80 SET SIGN BIT ON 1ST CHAR OF NAME,
E348- 85 14 3810 STA SUBFLG MAKING $C0 < SUBFLG < $DB
E34A- 20 EA DF 3820 JSR PTRGET3 WHICH TELLS PTRGET WHO CALLED
E34D- 85 8A 3830 STA FNCNAM FOUND VALID FUNCTION NAME, SO
E34F- 84 8B 3840 STY FNCNAM+1 SAVE ADDRESS
E351- 4C 6A DD 3850 JMP CHKNUM MUST BE NUMERIC
My mind is racing with possibilities. I want to document Applesoft’s stack usage now. Another GitHub repro to create and document this weekend. :-)
One BASIC line is not the same as one screen line, so yes, your program is one BASIC line.
Hey, Robin, what are some of your favorite clever code snippets in C64 BASIC? For me, when I saw this particular one in a magazine listing once it stuck with me to this day for its simplicity and usefulness:
A = 1 - A
Very useful for alternating between 0 and 1 (or any two values with some slight modification). Another I like, which I believe only works on 8 bit Commodore computers, is for multi-loading:
10 If A = 0 Then A = 1: Load "part 1",8,1
20 If A = 1 Then A = 2: Load "part 2",8,1
etc.
This was a mystery to me until I found out why it works.
in the 2 line bouncing ball, what if line 0 had the x and y drawing of a blank space happen before the coordinates being calculated with a line separator with the colon between the action to clear the coordinate and the coordinate calculation of line 0? is that possible in that method? If so, shouldn't most of the flicker of the drawing be negated?
I like the non flickering version and it is only 5 characters too long... :)
Very interesting video! I'm guessing the program for the Patreon credits uses a similar oscillator function perhaps?
Haha, I wondered about _that_ color combination too! Wouldn't exactly be even worse on a B/W TV or other monitor, since it seems to have low contrast? Wouldn't a grayscale screen make it even lower contrast?
Yeah, I would definitely like to see this with a dark background and a light ball or vice versa.
Considering it emanated from the 80's, it makes perfect sense.
@@TheUtuber999: Not really. We were already well into color TV by then.
I thought it was supposed to represent a tennis court with grass.
I'd love to see something like this or the maze written in assembly on thr C64 to see how much faster it goes.
Robin did an assembly-language version of the maze not that long ago. I recall it being about 100x faster than the BASIC implementation.
That's a lot faster but not blindingly fast. It's still calling the BASIC functions to print and scroll. Further optimization could be done, but that would be an unfair comparison.
@@Starchface Nice- that's good to know :D
Really liked this episode!
Only way to improve the yellow/green screen colors would have been to keep the light-blue text color: All The Pastels FTW!
Would be great to see some sort of random bounce (but maybe 2 line)
Great video
Have you done 10 print in 6502 Assembly yet?
Yes he has: ua-cam.com/video/IPP-EMBQPhE/v-deo.html
Yes he did
Or they were colorblind?
i wish this video was available in 82
Re the colors from the manual, sometimes I have to ask, What does this look like on your display? Especially when I see a web site with dark gray text on a black background in a 6pt font.
Very nice channel. Robin, could you please share the name of the song at the end of your video?
I hated programming that, and that balloon 😬 it was the promise to learn coding that got me a c64 aged 8.. all downhill from there 😂
I see C64 BASIC does not have REPEAT/UNTIL, but will it let you use FOR A=0 TO 1 STEP 0 to create an infinite loop without GOTO?
Yes. That is an working loop.
what's the song at the end of the video? thanks
It's called "Confounded to Corruption". A different mix of it is on my band's channel, but this particular version hasn't been released (yet). ua-cam.com/video/U1VKwqUWYa8/v-deo.html
@@8_Bit ❤ loved it. thank you very much
We did this in elementary school how awesome!!
You made a one-line bouncing ball in elementary school?
clear:for i=1 to 2:do something:i=i-1:next i
Compact code is a lost art today. Bloatware rules.
I was wondering, what's the name of the "Island " demo Robin mentioned in some videos which he described as "has a lot of moving objects on the screen at once"? I can't seem to find, so let's see if someone can help. :)
Write it in machine code then 1 sys call in basic. Job done.
Yeah, I know it’s a bit of a cheat, but different route same outcome.
0 x=x+1+78*(x=39):y=y+1+48*(y=24):pOa,32:a=1024+aB(y)*40+aB(x):pOa,81
have you seen the c64 demos with wavy scrolling text ?.. can you do a basic version of the sin scrolling version so i can convert it to C# ?
Should have been called the useless guide. The part about sound was particularly disappointing. Loved that machine. It became the start of a new career.