Neat, I actually didn't know about half of those!

I just love this channel. There is so much low quality content on KZfaq. It's so refreshing to have really interesting videos on here.

BASIC V2: DEF FN... Everybody: no one is ever going to use that! Python: Hold my lambda

This was nice to see but I do remember seeing these being used in long BASIC listings in various computer magazines. (The German 64'er and the Sonderheft particularly). The multiple parameter INPUT was very often used with the disk drives, so INPUT#15,A,B$,C,D (IIRC!) would be used to check the disk error. Menus would use the ON A GOSUB for the various submenus, etc. Kinda makes me miss typing in long BASIC listings as a result. So thanks for this trip down memory lane :)

26:15 I was glad to see you instinctively cushioned the release of the play button when pressing stop on the tape player!

The random seed value has always been a great way to create the same levels (procedural) over and over again with just one number. I remember the game Modem Wars using this. You entered a sequence of characters, this way you could make a word, name etc... and use that to generate the level. The game could then simply convert the letters to the ASCII values and use that as the seed for the random number generator. Minecraft still uses this technique to this day, you enter a number to generate the same world. Great stuff anyhow.

There's a potential issue with RND(0) depending on how you use it - if it's called at regular intervals, it will produce a limited subset of random numbers. I remember doing experiments like 10 POKE 1024+(RND(0)*1000),160:GOTO 10 and seeing that it never actually filled the whole screen with inverse-space characters. Instead, what I recall various books (or BASIC programs in REM statements? It's been a while) recommending is to use a single X = RND(-TI) statement to seed the pseudorandom number generator with the number of jiffies since the power was turned on, which is highly unpredictable, followed by RND(1).

As a matter of curiosity: You can LIST all the individual basic lines you want, except for line 0! 'LIST 0' gives the same result as a simple 'LIST' command. :-) Great video as usually!

Thanks for the tip at 23:49! I never met this handbook, I downloaded this in PDF, very very useful, although I still have my old guide books. This was a perfect video, waked up joyfully my sleeping memories, I haven't used C64 professionally almost three decades.

Back in the early days of Amazon you could enter quantities up to 10E300. Adding 2 different items to the cart and setting quantities of each to 10E300 would crash the system. Now it appears to be limited to 999.

Member when you used to stay up late at night coding on the C64? I member.

By the way in BASIC 7.0 (C128) the SYS command was extended to pass parameters to (unfortunately not back from) an assembly program. Parameter 2,3,4,5 are A, X, Y, status in this order, if specified.

"WAIT" in most program languages is an evolutionary hold over from a time when computers mainly controlled mechanical devices and output to teletype for display. It's specific purpose was to halt all processing at a particular place in the program ("wait" = "freeze the program counter") until a specific condition was met, either in a manufacturing process or to wait for a user input. This is why it is effected only by hard-wired, electrical changes like pushing a button. Most manuals for the various languages that use the command will WARN you to avoid using it (except in specific applications) because it essentially stops the computer from doing anything else other than interrupt driven functions. In some really early (1950s and 60s) CPUs the waiting for an electrical change was all it could do and is the reason most CPUs were later designed with "maskable" and "non-maskable" interrupts with WAIT being put into the maskable category. "SLEEP" is similar, not part of C-64 BASIC, in that the CPU freezes all function for a specified number of clock cycles.

I thought I might pass along that using DEF FN you can do IF/THEN, but you have to use boolean math. Boolean operators return 0 or -1 for false and true, respectively. Also, you can use variables defined in the program, not just the passed parameter, in your function. So, let's define S as a "switch" to control the value in DEF FN FOO(X)= X*2 *-(S10). Using a bit of addition and multiplication identity math we can get one side of the equation to zero out by the boolean returning 0 or -1. If S is 10 or less, it returns X times 2; otherwise, it returns X times 3. You can make this a bit simpler if your controlling variables are a 0 or 1. Instead of testing with a boolean operator, use AND. AND returns 0 if the two numbers don't match or the number if they do, so you don't have do the negation.

I used most of those commands when I got my Commodore VIC-20/64 by reading its BASIC user manual... those were the good old days.. though I didnt learn much with machine language, since it wasn't built in.

A fair amount of those commands I've used running a BBS back in the day. Love your channel!

RND(-1) or other negative values can be used in games to program pseudo preprogrammed surroundings. I once made a side scroller using BASIC together with assembler routines, the user could chose 4 different ways he wanted to go, they where generated with RND(-1), RND(-2), RND(-3) and RND(-4).

Appendix A of the C64 Programmers Reference Guide has derived trig functions that can be implemented with DEF FN.

Great tips! To make the USR function more useful, you could call the subroutine located in BASIC ROM that turns the floating point number into a 16-bit value. I believe that routine is called FACINX and is located at $b1aa. The 16-bit number is returned in the A and Y registers, hi and lo byte, respectively. I used it to fill the color RAM with a 4-bit value, in ML code, of course, and called from BASIC with the USR function.

Thanks, I needed some help with subroutines it's been years since working with c64 basic.

Great Commodore BASIC video Robin! As always.

Great video, Robin. Always wondered about these commands, particularly USR().

I wish I had KZfaq when I was a kid. I'd have been so thrilled! OK, well, I still am thrilled. I need a new 64. 🙂

I started programming on TRS-80 Basic, and during my younger years messed about with Apple 2 Basic, ZX80 Basic and plenty of others that in my middle age I just can't remember anymore. At some point I have used all of these commands in some way, especially the ON..GOSUB (a very useful thing indeed). Its been very interesting watching this video and realizing how many of these functions were available in Commodore Basic. Many thanks for the insight 👍

I think I used all of these commands at some point while programming my C64/C128. I remember using the WAIT command as a "security verification" if you didn't press the correct key they program wouldn't continue to execute. I was a teenager that would rather write weird programs than play games.

I knew all this stuff, except the 9999 example. However, it's so relaxing to listen to your calming voice. Thx for being on KZfaq.

I had a Commodore 64 in 1987 during college and a dot matrix printer. To print I basically had to write code....it was not easy as pushing a button or giving a voice command...although I did talk (or scream) at the C64 often....

Great video! You are clear and concise when showing instructions. Keep up the great work!

I'll admit I had no idea how USR and WAIT worked before this.. Good walkthrough

@15:1- That's a bug in the stack PC, if I ever saw one. Obviously BASIC is setting a PC limit to a line number if the number is > the current limit, but it isn't cleared. I don't ever recall running into that in the era, but it's an interesting observation. I would expect it to do this if you execute a programme that terminates prior to its max PC value, and I may have seen that happen, long ago.

Just want to add a bit on USR(). USR is not limited on numeric values. The interpreter calls the expression evaluation which may result in a string or numeric value. It depends on the calling context what is expected (otherwise a TYPE MISMATCH may occure). One may take a look on the examples of the german variant from c64-wiki.com (I have to take over the examples to the english site some time in future): www.c64-wiki.de/wiki/USR#Beispiele. Because the interpreter passes the control after the expression evaluation but before checking for the closing parenthesis to the USR code, you may add the interpretation of additional parameters in your function. You have only to ensure that the interpreters parser stays in front of the closing parenthesis and you are fine.

I watch each video of yours and I have to admit that your way of presenting all those things is so good. I would even say that your videos are quite good for beginners to start with real IT. I mean that you explain everything as to the people who doesn't know the basics while doing a showcase of what you talk about. I think about that stuff like memory addressing., how CPU works, all basic concepts in programming etc. It is soo goood and your approach is so much quality to me.

Your videos are amazing... I love the c64 so much and you show such unknown skill it’s mind blowing!!! Much support from the uk!

Absolutely beyond awed! Truly impressed! Thanks for this real world example of some commodore basic (I only ever had BBC basic, but still relevant)

The fact that RND(1) gives the same sequence every time after a reset is not solved by using RND(0) instead (because RND(0) is not really random). Instead, just add A=RND(-TI) as your first command to give it a random seed.

Awesome run-down of those old commands. I had forgotten most of them even existed in the C=64 BASIC!

Thank you so much! This will definitely come in useful for some software I am programming. I can’t believe I hadn’t figured out that you can input multiple variables!

Another quirk of RND() - try these two lines: 10 PRINT [clear/home] ; 20 POKE 1024 + RND(1)*1024, 81 : GOTO 20 Run this then change it to ... RND(0)*1024 ... and run it again. You find the '0' argument RANdom formula skips numbers in patterns, depending on the size of the multiplier. Although RND(0) generates different sequences, depending on the range of numbers you are trying to generate, you will never see certain numbers. The BEST method: 10 X = RND(0) : PRINT[clear/home] ; 20 POKE 1024 + RND(1)*1024, 81:GOTO 20 By using the RND(0) in a throw away call to the RND function, C-64 seeds the random generator with a value read from the "time of day" clock on the CIA chip. IBM's BASICA or QBASIC equivalent is RANDOMIZE(timer). The odds of reading the exact same number in two different runs of the program are astronomically huge against it. Then using RND(1) for the rest of the program it does not skip numbers. I'm not 100% certain why RND(0) times a number greater than 256 produces this skip, but it is consistent, and the skipped numbers are always the same depending on the value of the multiplier. This: RND(0)*257 will never return the number 128; RND(0)*259 skips 86 and 172, RND(0)*512 skips every other number, meaning all the odd numbers ... and so on ...

Last (well almost last I think) I did to my C64 was to transfer some of my BASIC programs to my Amiga 500, I made a userport connector that connected to my Amiga parallel port and did a basic program to read bytes from the floppy and send them to my Amiga 500. On my Amiga I did Pascal (Kickpascal I remember correctly) program to receive and store on floppy. I think I was about 14-15 at the time... It was an amazing experience. Lots of trial and errors haha... I think my final version was transfer 7 bits and use 1 bit for a sync "clock" and that worked the best... It was fun to program the C64 again and with a specific purpose, the Amiga I was quite comfortable with when I did it. I think I did a peek/poke though but some of it could been used by the wait routine... Can remember the actual purpose of it though but I think I did it because I just got an early C64 emulator and wanted to see how it worked without retyping everything again or I was just testing and seeing if I could get my C64 work together with my Amiga. Some of what you been demonstrating I do remember and I think I used, but some was news to me aswell! Great video!

"ON SGN(I)+2 GOTO ln1, ln2, ln3" makes also a great replacement for FORTRAN's original arithmetic-if statement ("IF (I) label1, label2, label3"), in case you need it. ("I" can be any arithmetic expression, as well, in both cases.)

Commodore Forever! My basement is filled with Commodore machines.

wow, this takes me back 33 years and some knowledge I forgot I had in me came back up. I used to type programs from magazines and recognize most of these , except the CONT

Another quirky thing about C64 basic - if you put a line in your code with a remark and a shift L, (10 rem L), it will cause a syntax error on that line. you can put a ": rem L" at the end of each line to make your code REALLY annoying to attempt to read. It's not a useful/functional thing... but it was used as crappy copy protection - Artworx's Strip Poker used it to hide their basic code. There were a lot of fun things hidden in the C64. :)

Good stuff. Thanks for keeping the C64 BASIC alive. Good memories.....

I once made a video game as a kid where the computer controlled grasshopper character flew around the screen controlled by a RND(1) generated number, thinking it would move around at random, as you tried to shoot it. After playing the game several times I realized it was doing the exact same pattern over and over again! Oops!

I used to use the LIST command with a range frequently. When your program would get so long that you couldn’t easily stop it and make corrections, i would list it with control and remember the range. It worked well for my 10 year old brain 😂

Hi, I learned a lot from this video, thank you very much! I wrote a BASIC game that I can improve now with the new knowledge of this video: First, I will exchange the RND(1) to RND(0) just to get ALWAYS a new random series of numbers each time the commodore powers up. Second, I will use the on-gosub command for the joystick query. And third, the wait command is very useful, each time I wait for the fire button of the joystick. It’s way better than doing it with if-then-loop. That’s very helpful, thank you very much and keep up your good work👍👍👍

I remember I actually did use the scientific notation feature at one point, for some math self-study thing I did. The LIST range and selective RUN start wasn't that obscure though I think. I used it all the time to edit my larger basic programs and it was invaluable.

The limitations of the C64's DEF/FN really make me realise how I was spoiled by BBC BASIC.

The WAIT command basically is waiting for an interrupt signal. That's why the Eject button doesn't caUse WAIT to end. It only opens the door of the casette player, it doesn't send an interrupt to signal it's ready to send or receive data.

Interesting. I am just getting back into basic after 40 years

I remember, back in the day, starting programs with 10 A=RND(-TI) to get the C64 to randomize. All that time I could've just RND(0)'d instead. In my defence, I was 7 and a dumb 7 at that.

Another fascinating video I've been looking forward too. Thanks man. :-) Can't you do an Assembly programming in Turbo Macro Pro series for the beginner? Your previous vids 'bout Assembly helped me out a lot. But I think that you could be a very good teacher for a "complete" assembly course from the ground up. I'm reading Jim Butterfields' excellent, brilliant, book on machine language but it's a bit too much about, erm..., machine language in a Machine Language Monitor and less about programming in "full blown" Assembler.

This video has suddenly pushed me to learn C64 Assembly, and yesterday I've completed my first hello world 😁 I had a C64 as a kid but i was too young and I never really used it for coding. I started coding with C on a 386. Always skipped Assembly for some reason until now!

I noticed the Mapping the 64 book was written by Sheldon Leemon. I have not thought of him in years! I think he used to write a lot of articles in Compute! Back in the day.

These tricks are so neat, I truly appreciate all your retrocational vids! C=

It is possible to have an IF in a DEF FN -- by using what could be called an "implied if" that utilizes the (typically) numerical value returned by boolean expressions. The trouble of course is that the "true" and "false" representations was largely implementation-dependent: 1. some BASICs would return 0 for false and -1 for true (e.g. TRS-80 BASIC on model I/III/4, IBM-PC BASIC), whereas some would return 0 for false and 1 for true (e.g. AppleSoft BASIC). 2. the boolean operators of NOT, AND and OR would introduce yet another wrinkle. In some implementations the return value would perform a bitwise operation (e.g. TRS-80 BASIC on model I/III/4, IBM-PC BASIC) on the (implied) integer operands, and others would only affect the least significant bit (e.g. Applesoft BASIC). Aside from the highly non-portable aspect, use of this "implied if" is generally *slower* than having an actual IF-THEN-ELSE statement, since this "implied if" involves using a multiplication for each of the conditions.

I really like your assembly videos !

The C64 has the same version of Commodore BASIC as the VIC20 before it. So strictly speaking this video should have been called "10 Rarely Used Commodore BASIC V2 Features"! 😁

One of the videos about disk drives made me connect my usb floppy drive to android phone via USB OTG and write some files to a blue 3.5" floppy disk. It's actually safer than writing to a Pendrive these days, I mean who would be able to read that, they only know the "Save" button icon...

Awesome! really well explained.👍

Fire those QA people if they can't understand scientific notation of numbers.

Re: USR vs SYS: you can call line reading routines from within a machine code program following an SYS command. I can't remember specifics but I remember writing commands back when I had a C64 as my main computer in the form of SYS49152,.

Great stuff. Very interesting.

Alright, I give up. I finally subscribed. Thanks for the awesome content!

I am a big fan of in my programs: poke 198,0 : wait 198,1 : get a$

Man, used to use the list 30- method when writing text adventures on the TI 99/4A...

I kind of blasted over BASIC into assembler once I hit its limits trying to build a dictionary. The text was space delimited and contained commas so INPUT# wouldn't work and GET# chewed through memory creating too much garbage - "h", "he", "hel", "hell", "hello" etc. USR only worked with numbers so straight to SYS to read the next word and write it to the screen and then push a Home and CR onto the input queue. 26 hours shrunk to 8. Full blown assembler processed all 6 disks (not just the one) in 20 minutes so at that point, BASIC just became a toy.

I remember not understanding DEF FN in ZX Basic, but using BLITZ now it is super useful. I think in 8 bit basic the DEF FN was as you said just a mathematical equation. In NBASIC the List - list 100-200 etc was essential.

WAIT was one I never remember knowing back then. Sure it is "WAIT 174" that waits for the Vblank

So I definitely read those when I read the manual (which was like an IT bible for me when I was 9), but didn't remember some of them. 1. Remember and have used. 2. Definitely remember and have used. 3. Don't remember, definitely haven't used. Possibly because when I was 9 I didn't even know what was that (and there was no Google to look for it). 4. Don't remember but possible used it. 5. Don't remember but most probably used it because I typed some LONG BASIC programs back then (to the point of getting OUT OF MEMORY errors). 6. Remember and have definitely used. 7. Remember, don't remember if I have used it or even if I understood it. 8. I remember I tried several tricks with random and pseudorandom. 9. I probably didn't understand its use. 10. I remember but did not remember such use. I might confuse it with some other machine/OS wait command. Thanks!

You can also command RUN and line number to run the program skip that STOP or END line.

i use all of theose frequently because i bothered to read the manual

Wow, idk the wait command did all of that!

Beautiful!

ON GOTO, USR and RND(.) were new to me, mind blown 🤯✌🏼

Another very cool and useful video from the Famous Dancing Hand. :) I did a quick check to answer an earlier question.A user-defined function can call another user-defined one no problem. No reason it shouldn't be allowed, as long as the function being called is defined first. 10 DEF FN A(X) = X + 1 20 DEF FN B(X) = FN A(X) + 1 30 PRINT FN B(1) Run it and it prints "3". Good on touching on the USR function. Sometime I intend to study up on how floating point is implemented by the BASIC interpreter. (It hasn't been a priority.) I have a seriously hard time believing it's some extraordinarily difficult and untouchable thing like the computing masses have repeatedly been led to believe. As for WAIT, it doesn't help when the user manual and even the programmer's reference manual confront readers with shit talk like "for most programmers, this command should never be used." I didn't realize you had to be a certain kind of programmer to use a command. The important things to understand about WAIT are the concept of bitwise operations (AND and Exclusive OR in this case, and these concepts and that of 16-bit twos-complement signed numbers are useful when taking advantage of the relational, AND, OR and especially NOT operators) and it has to be something outside of your program that changes the contents at the memory address being WAITed on. In practice this will be one of two things: a control register (e.g. the raster interrupt bit on the VIC chip interrupt status register: bit 0 of 53273), or a memory address being written to by the routine running in the background every 1/60-second, such as the examples given in this video which involve the keyboard and Datasette.

Hi sire, the STOP command is not like breakpoint. STOP IS breakpoint. When your program finishes or executes END, the BASIC is supposed to do some housekeeping on variables. And it should clean the internal execution stack. Contrary the STOP/CONTinue, when reaching STOP, the BASIC suspend execution and waits for your interaction with system. The variables and internal execution stack are not affected. So when you finish your debugging where you interrogate variables, you command CONT to resume the execution of the program from exactly the point it was stopped. During the STOP you can also change the values in variables. So the original purpose of STOP/CONT is to help programmer debug its program. Have a great day, -- Radek

In BASIC logics, STOP should preserve runtime variables and their values, but END could deallocate those variables, so you could get error, then trying to peek variables after END.

very nice video ,thanks.

You have an excellent presentation and speaking voice

I wasn't a "professional" programmer but I used all of these regularly in small and large programs. Odd. Why do you think they weren't used much??? These are all useful and common commands.

Anyone know how I can start the CCSMON cartridge in vice after attaching it? I can start the 64mon cartridge fine (using SYS 32820 from BASIC) but CCS mon (from lemon) doesn't seem to start.

This channel is awesome 😍

Can you use functions within functions? can LO(X) be =X-FUN HI(X)*256? ( I know I can just fire up an emulator and check but I thought others might like to know too. EDIT: I see that is does work and that you answered this below in one of the other comments. Neat!

I knew about the list, end, stop and cont commands, but they weren't used too often.

Oh, BTW: If you ever need to do some modulo operation to get binary values, use binary functions instead: For example don't use DEF FN LO(X) = X-INT(X/256)*256) use DEF FN LO(X) = X AND 255 Try thinking binary as often as possible, dividing values is a costly operation on all CPUs and functions like modulo are always performing a divide procedure internally. There is just one tiny nuisance be careful with negative values.

Awesome, sir. Instead of loading a game from tape or disk, why don't I just flip open that awesome manual and play with this BASIC stuff on my TV! Spent some hours reading the example code. Just as cool as pressing the fire bottom. :-)

You have convinced me. I hated BASIC in the good old days when I built my first computer. Right now I have a small computer on the breadboard. Just six ICs, but it's already talking to a Terminal and runs at blistering 6 MHz without even getting warm. I will take the time and write some mor assembly code to test it and not simply install a BASIC interpreter. C never was a thing for 8 bit processors, but FORTH may be a good candidate.

You can exploit dynamic variable scope to make some surprisingly useful stuff in DEF FN, though you may run afoul of FORMULA TOO COMPLEX or OUT OF MEMORY errors if you get too deep. This is typical of my date-processing BASIC programs: 1 DEF FNM(N) = Y - N * INT(Y/N):REM MODULUS, ASSUMES DIVIDEND IS Y 2 DEF FND(N) = FNM(N) = 0:REM DIVISIBLE? 3 DEF FNL(Y) = FND(4) AND ((NOT FND(100)) OR FND(400)):REM LEAP? Since FNL calls its parameter Y, FNM and therefore FND operate on it no matter what the global variable Y is set to, and FNL correctly returns whether or not its argument is a leap year. I have a further extension that actually returns the number of days in a month using a function without an array, with logic like 30-((m=1)or(m=3)...)+(2+fnl(y))*(m=2), but while you can barely fit it on a line with single-digit line number, the D▔ abbreviation for DEF, a single-letter function name, and no spaces, most Commodore BASICs blow up on that number of nested function calls.

Hello I would like to control 2 outputs via 2 5Volts input signals. Can you help me?

if you put your own usr(1) in does it replace the illegal error like a trap command ?

Using functions actually can speed up basic executing of that bit of logic. Reading joystick port addresses in a game is actually a lot faster when doing it this way as you don't have to include the logic in the main basic loop. Using functions you can actually speed up a basic game quite a lot by using FN for a lot of the game logic and keep the basic game loop small.

But "cont" is a BASIC statement whether it's in a program or run directly. OK, Robin, now... as a request for my birthday today (Feb. 23), will you please make a video showing us what happens if you make a program with "cont" that you've run right after turning the computer on?

You could use the pokes as part of your basic usr(1) call you have more usr(1) calls

ON GOTO has the advantage over IF GOTO that it may fall through and continue in the same line. To replace IF A > 0 GOTO 99 : REM DEAD END you may write ON -(A > 0) GOTO 99 : REM HERE WE CONTINUE If one is looking for a possibility the squeeze the program further ...

15:22 can you add a direct link to the wiki sub-page you mentioned on basic commands? I get the impression you had a specific sub page in mind - maybe one that notes the oddities and quirks of some commands?

I remember on ZX Spectrum there was a randomize usr command that would give side audio bars and "saving" sounds as if the computer was saving some random stuff. I recall there was something similar on the C64 where you could either enter a SYS command or a USR[] and it would suddenly start outputting data to the cassette. So 1) Is my memory correct that there is a command on the C64 to do that and 2) What the hell was it saving??

Great Video, as always. Could you make a video about the "ext in" pin of the SID chip? I am really curious how to access the data that comed into the SID, and what possible applications are possible.

At 3:15 on line 20, could you have used the first DEF FN in defining the next one? Something like: 20 DEF FN LO(X)= X-(FN HI(X))*256 Would that work? It's been 35+ years since I used DEF FN so at the very least I may have a syntax error there.