The line of the day, "It's still fairly useless." I love it. After all, retro computing is for the nostalgia, not the productivity. That's what makes it fun.
If we modified the RUN command in V.2.0 BASIC (C64, etc.) to behave like it does on the C128, it would be quite useful, actually. That meant, of course, making a custom ROM with resident code for the improved RUN command to load programs from disk. BTW, I had no idea of the improved RUN of the C128 (BASIC V.7.0), at all. So, thank you, Robin!
They all had their own personalities, on ROM (usually). I remember being so excited to try a new machine and learn its idiosyncrasies back in the day that my hands were shaking. If that ever happens again it will be if I've got Parkinson's!
Inspired. Nice video... Was flicking through the Loadstar disks last night and found an article by you about game development. Then here you are this morning!
Neat. Works in Applesoft too, at least in the initial example's case. It occurred to me that it would work because the input buffer is in the same memory location, even!
I am kinda confused why people don't find this useful? For something simple and small, obviously, but that's not the point here. If you make any programs that are much bigger and more complex, it's just so much easier and more intuitive, when you also want to troubleshoot things for example. Especially for those who go back from years of DOS/Linux commands to these things. Great video! :)
I could see games written to read level codes so it could jump to the level associated with the code. Many MSDOS programmers use this trick to pull multiple command line options from the command line. You could use a control character to terminate strings so that multiple options could be separated by spaces.
Great first video of the year Robin! In c128 mode there's no need of any wedge software to use sd2iec. Just enter built-in monitor and type: @,cddirname to change current dir, @cd
I remember your video on the monitor of plus4... Very interesting! also for c128 users like me. But there are little differences. Probably you could do a video ad-hoc, mentioning sd2iec and other related stuff! ;)
I like your BASIC stub since it's easier to understand and modify, say if you need to point SYS to a different memory location in a program. The stub that CBM Prg Studio generates is smaller (if I'm remembering correctly) but a little trickier to decipher in order to modify it. #HappyCommodoreNewYear
I think this is my "latest generation" of BASIC stub and yeah, the aim was to make it easier to modify within the limits of Turbo Macro Pro's pseudo-ops. I think some fancier cross-assemblers have the potential to make it even more clear what each byte does.
Oh I really enjoyed this Robin, great video. This feels like it could be useful to me at least. I find I often write little BASIC utilities to automate stuff I do regularly on my C64. I'll keep this video in mind for the next time I need to scratch an itch. Thanks Robin 👍
In your last ML example, since you use the BASIC expression parser to get your parameter, I think you can potentially use arithmetic and variables in the parameter itself. So you could write something like, RUN:3+a*8 and it would potentially work (haven't tested it though).
I didn't really know how to write a BASIC stub back in the day, so I'd write the first line in BASIC, then go into the MC monitor and write code after the program in memory and change the SYS code to where it should go later.
Despite its bad reputation, the TRS-80 had one big advantage which was that the BASIC interpreter already had "hooks" in memory which were designed to allow the language to be expanded (intended for disk BASIC commands) and so anyone with some knowledge of machine code and what each "hook" did could add their own commands to the language.
Enjoyable episode as always, Robin! Have you played with the VIC-2 Kawari or Commander X16 or have any interest in doing so? I did a cursory search of your chan but didn't find anything.
Thanks very much! Both are interesting, as well as the Mega65, but I've got a lot of time and money already invested in many other 8-bit things (systems, software, accessories, etc.) that I'm equally interested in and already plan to make videos about without spending more money :) So yes, I'm interested, but they're a fairly low priority mostly due to limits of time and money.
Great video, I enjoyed that. I was thinking in the basic border colour program about allowing abbreviations and just find first match so RUN:"O" would pick orange, and "LT B" would be light blue
Wow, this is pretty interesting. But of course in 128 mode you'd save that feature for something more complicated, since changing the border color in direct mode is simply just a matter of using the color command.
Each DATA statement with the valid colour parameters could be doubled, so that 2 values are read per loop the first being the parameter in text and the second being the tokenised value - or blank if the same as the first. So that tokenised text would be recognized!
If you type GOTO 100 in immediate mode it's interesting, it adds a 0 every time. If you put a STOP on the next line, and copy the same routine to the following lines, you can also pass a parameter to the CONT command. You can also GOSUB from immediate mode but it adds zeroes to the start of the parameter.
Yeah, the whole line is tokenized, no matter how many commands (and colons) are on it. The two things that prevent tokenization are a REM statement, or quote mode.
@@8_Bit I picked up on the REM/Quote thing. What I'm curious about is executing code that is after the colon. If it is BASIC code it would be difficult as the BASIC pointers would need to be changed (and changed back). I'm not sure that it could be run as immediate mode code either, perhaps it can but I missed that part. If you encode ML code in the REM statement your BASIC program could SYS it. I don't know why you would want to do this, but it would be interesting.
Hello! Can't you test for the tokenised "orange" string and make it work? Like double the DATA entries with even numbers being string and odd tokenised. Or something.
I'm curious about something else too: Wouldn't "lineesque" form as a real word just by the rule that standard suffixes can be added to just about anything? Like if I said "computerish," and even though not every conceivable word formation based on every conceivable prefix or suffix is in the dictionary (because that would make a physical one huge), it's still a real word because of the way those suffixes work and according to the word-formation rules concerning them? So why not still use the hyphen, but just move it between "command" and "linesque" to form the compound word "command-lineesque"? What made you rationalize that the hyphen needed to be there because you needed "line-esque" instead of just having the whole term with "command-" as "command-lineesque"?
On a C64/128 note, but unrelated to the current video topic, perhaps something for a future video though, can the 1541/71/81 drives be used as co-processors for game or application performance gains? Each floppy drive has its own 6502 and you could add some memory. The 1571/81 drives run their 6502s at 2mhz. If you have 4 drives attached, you have the possibility of 5 6502s at your disposal.
It's an interesting topic that I've thought about, but haven't come up with a good way of demonstrating it. The short answer is yes this will work in high computation, low-bandwidth cases. The problem is that it's very slow, relatively, for the CPUs to communicate with each other over the IEC bus. So there has to be the right balance for a net gain from the extra CPU computation, once you remove the CPU cycles burned in communication.
@@8_Bit - There's a demo "freespin" that runs entirely on a 1541 - sound and video too :O (it doesn't address the bandwidth issue no - but an extra music channel if nothing else)
I used to have 2 disk drives and a printer….i made a program that would program one disk drive to send the home work file to the printer while I used the 64 and other drive to play games…
I just had an idea for a video. I was watching gameplay of Caverns of Khafka and I remember playing it years ago as it was in the Cosmi top 20 collection. I was never a big fan of it though. This game has some of the glitchiest sounds I've ever heard on the 64 and I wanted to see if you could disassemble it to figure out why it sounds the way it does. For instance, the music gets interrupted by other sounds and sometimes makes a garbled noise which sounds the same every time. The elevator sound makes a few beeping noises after it stops moving and there's a green bug which changes pitch after it dies and your character moves around and many more. Just a video showcasing why it does all that would be neat, but if you could write some code to fix some of the issues that would be interesting as well.
I've always hated the CLI and I will never be convinced that it's a good way to interact with a computer - Especially one that can easily display graphics or more comprehensive text.
I found the Amiga's CLI very restrictive after being used to the C64's free-form screen editor approach, but I now appreciate the CLI approach for certain tasks that can be broken into precise steps, which often happens while doing software development.
9:56 BASIC does seem to get rid of any spaces before the RUN command. Similarly, you can't indent BASIC lines without a leading ":". 14:57 Seems more like a brown than an orange. 15:26 You could add "┌ANGE" as an alias. You might want that for the British "GREY" spellings as well. 16:59 This is more like it - giving command-line arguments on the command that loads and runs the program. Various C64 wedges also have a loan-and-run command. 17:32 I assume this fails if the filename has a colon in it. 19:01 Cool - the C64 automatically changes «LIST» to «L╮»! 20:32 But it's 2024! 26:00 Yeah, you manually hacked my name to not break your credits program! I suppose «Craig'; DROP TABLE Students;» won't work here, either.
Fun (useless) fact - orange and brown are one and the same. It's the brightness of the orange and the contrast between it and any surrounding colours that determine if your eyes perceive it as orange or brown (assuming one isn't colour blind).
amazing how a value can be carried on P and also use a P$ can hold a string, a lot of programming languages dont allow that in basic i think6 anymore??
Yes, and in fact P% is also available as a signed 16-bit integer, and then all 3 of those types can also be made into arrays with the same variable name. So we could have P, P%, P$, P(), P%(), and P$() all being valid independent variables :)
@@8_Bit i found the article, but i can't paste the link. search the web for "The Case of the Missing 4th Commodore BASIC Variable (and the 5th Byte)" by masswerk
Hi Robin! Sorry for asking, but in my country there are to few people who is pograming for Commodore. Are there any forums or groups or channels or something where can I publish my game (and development process).
OK grew up with an Apple ][+, then PC, then Mac SE, then PCs again, so no Commodore experience, and definitely no Commodore hate, but I gotta admit this not leaving a space after LOAD or RUN or other commands really irks my OCD
Hi Robin! I'm soo please to meet you. I'm San K. Rianna came a few times, very nice girl. Lately, I want my old computers (A500 and A3000) stand on their feet again. Both of them still running but A3000 HD death.
Hello San! Thanks for subscribing, and for having Rianna as a guest. That's really cool you're into Amiga! My friend @10MARC is very knowledgeable about Amiga, I suggest watching his videos in particular. I like Amiga very much but have not got a lot of experience with repairing them.
20:00 This probably hasn't been important for several decades, but "STA $FA" corrupts the RS-232 output buffer pointer.
And now I have no idea why I used $FA/$FB instead of $FB/$FC !! Weird mistake for me to make. Good catch.
The line of the day, "It's still fairly useless." I love it. After all, retro computing is for the nostalgia, not the productivity. That's what makes it fun.
If we modified the RUN command in V.2.0 BASIC (C64, etc.) to behave like it does on the C128, it would be quite useful, actually. That meant, of course, making a custom ROM with resident code for the improved RUN command to load programs from disk.
BTW, I had no idea of the improved RUN of the C128 (BASIC V.7.0), at all. So, thank you, Robin!
I don't think it's useless! This opens up a lot of options, it's just way too late!
Absolutely. Computers of today may be much faster, but they're also a lot more boring. No personality.
@@Starchface Agreed. 8 and 16 bit computers had character.
They all had their own personalities, on ROM (usually). I remember being so excited to try a new machine and learn its idiosyncrasies back in the day that my hands were shaking. If that ever happens again it will be if I've got Parkinson's!
Inspired. Nice video... Was flicking through the Loadstar disks last night and found an article by you about game development. Then here you are this morning!
4:57 Wow, I did not know this can be done this way. Thank you for sharing.
Tricks like this must be why the C64 was so loved
Neat. Works in Applesoft too, at least in the initial example's case. It occurred to me that it would work because the input buffer is in the same memory location, even!
I was just about to try that!
On the CoCo it is at address 732 (the input buffer actually starts at 733, but is tokenized starting at 732 overwriting the untokenized string).
A perfect way to kick off New Year's morning, thanks!
That was yesterday.
@@SellamAbrahamit was but so was the comment
Weird. This video was just posted 15 minutes ago for me.
Happy new year.
@@SellamAbraham Those that support the channel on patreon get videos just a little bit earlier (and without ads).
Happy New Year! Thanks in advance for another year of great videos.
I love it that you had a pic of Arnie when you mentioned the Terminator.
It's doubly appropriate as the Terminator runs 6502 code
I'm not sure he runs that code, seems more like he's daydreaming about it...
GREP. Now that's a name I have not heard in a long time, a long time.
I am kinda confused why people don't find this useful?
For something simple and small, obviously, but that's not the point here.
If you make any programs that are much bigger and more complex, it's just so much easier and more intuitive, when you also want to troubleshoot things for example.
Especially for those who go back from years of DOS/Linux commands to these things.
Great video! :)
I could see games written to read level codes so it could jump to the level associated with the code. Many MSDOS programmers use this trick to pull multiple command line options from the command line. You could use a control character to terminate strings so that multiple options could be separated by spaces.
I worked with the c64 for lots of years, and the 128 some. I NEVER knew you could load and run with RUN "program name"
like that on the 128! Wow.
Really enjoyed that :) happy new year!
Great first video of the year Robin! In c128 mode there's no need of any wedge software to use sd2iec. Just enter built-in monitor and type: @,cddirname to change current dir, @cd
Aha, I didn't realize the C128 monitor allows @ commands. That's great, thanks. I should see if that also works in the Plus/4 monitor.
I remember your video on the monitor of plus4... Very interesting! also for c128 users like me. But there are little differences. Probably you could do a video ad-hoc, mentioning sd2iec and other related stuff! ;)
I wish that I had the Super Snapshot Cartridge and the Epyx Fast Load Cartridge when I was kid and had my C-64. I love these videos of yours!
I like your BASIC stub since it's easier to understand and modify, say if you need to point SYS to a different memory location in a program. The stub that CBM Prg Studio generates is smaller (if I'm remembering correctly) but a little trickier to decipher in order to modify it. #HappyCommodoreNewYear
I think this is my "latest generation" of BASIC stub and yeah, the aim was to make it easier to modify within the limits of Turbo Macro Pro's pseudo-ops. I think some fancier cross-assemblers have the potential to make it even more clear what each byte does.
At the end of the program, I think you could also poke characters into the keyboard buffer to print "RUN:" again.
Oh I really enjoyed this Robin, great video. This feels like it could be useful to me at least. I find I often write little BASIC utilities to automate stuff I do regularly on my C64. I'll keep this video in mind for the next time I need to scratch an itch. Thanks Robin 👍
In the late 80's I created fake command input written in Basic to emulate MSDOS! It was to prank a work mate!
I had never heard of this feature but it is very interesting and might be useful.
In your last ML example, since you use the BASIC expression parser to get your parameter, I think you can potentially use arithmetic and variables in the parameter itself. So you could write something like, RUN:3+a*8 and it would potentially work (haven't tested it though).
Never knew this, so thanks to you an the Channel creator.
Obvs in Linux / Unix things are case sensitive.
I didn't really know how to write a BASIC stub back in the day, so I'd write the first line in BASIC, then go into the MC monitor and write code after the program in memory and change the SYS code to where it should go later.
Despite its bad reputation, the TRS-80 had one big advantage which was that the BASIC interpreter already had "hooks" in memory which were designed to allow the language to be expanded (intended for disk BASIC commands) and so anyone with some knowledge of machine code and what each "hook" did could add their own commands to the language.
Enjoyable episode as always, Robin! Have you played with the VIC-2 Kawari or Commander X16 or have any interest in doing so? I did a cursory search of your chan but didn't find anything.
Thanks very much! Both are interesting, as well as the Mega65, but I've got a lot of time and money already invested in many other 8-bit things (systems, software, accessories, etc.) that I'm equally interested in and already plan to make videos about without spending more money :) So yes, I'm interested, but they're a fairly low priority mostly due to limits of time and money.
Great video, I enjoyed that. I was thinking in the basic border colour program about allowing abbreviations and just find first match so RUN:"O" would pick orange, and "LT B" would be light blue
Wow, this is pretty interesting. But of course in 128 mode you'd save that feature for something more complicated, since changing the border color in direct mode is simply just a matter of using the color command.
Good stuff Robin. Had no idea this was possible.
There must be a kernal location to expand tokens to text (used for list)
Interesting C64 interpreter specialty. Love it!
Each DATA statement with the valid colour parameters could be doubled, so that 2 values are read per loop the first being the parameter in text and the second being the tokenised value - or blank if the same as the first. So that tokenised text would be recognized!
Happy New Year Robin i like much all videos
Fascinating stuff. Happy New Year to you and yours. Thanks.
If you type GOTO 100 in immediate mode it's interesting, it adds a 0 every time.
If you put a STOP on the next line, and copy the same routine to the following lines, you can also pass a parameter to the CONT command.
You can also GOSUB from immediate mode but it adds zeroes to the start of the parameter.
don't gosub and goto have two-byte tokens? Maybe that's the issue with the "added zeroes" you mention?
Thats just fun :) 'Heres something neat! Lets play! lol' Cool share. All sorts of neat things we never knew.
Could you implement a special case for your BASIC border color-changing program to account for that tokenized "OR"?
Interesting that it tokenizes after the :
Makes me wonder about having the 'parameter' be a ML program encoded in a REM statement.
Yeah, the whole line is tokenized, no matter how many commands (and colons) are on it. The two things that prevent tokenization are a REM statement, or quote mode.
@@8_Bit I picked up on the REM/Quote thing. What I'm curious about is executing code that is after the colon. If it is BASIC code it would be difficult as the BASIC pointers would need to be changed (and changed back). I'm not sure that it could be run as immediate mode code either, perhaps it can but I missed that part.
If you encode ML code in the REM statement your BASIC program could SYS it. I don't know why you would want to do this, but it would be interesting.
Hello! Can't you test for the tokenised "orange" string and make it work? Like double the DATA entries with even numbers being string and odd tokenised. Or something.
Yes, that's likely a good work-around, or perhaps the BASIC ROM routines could be leveraged to de-tokenise before the comparison is done.
Really cool!
It's not 2022 anymore, Robin. Or 2023, for that matter. Your BASIC stub has missed a whole year! (Happy new year!) :)
I think this video got stuck in a buffer for a couple years or something!
I used to flash the border red if you entered an incorrect response.
Neat, Neat, Neat
Can we simply add up arrows for histoey? Type the first two characters of a Basic command and right arrow to autocomplete? More like linux
I'm curious about something else too: Wouldn't "lineesque" form as a real word just by the rule that standard suffixes can be added to just about anything? Like if I said "computerish," and even though not every conceivable word formation based on every conceivable prefix or suffix is in the dictionary (because that would make a physical one huge), it's still a real word because of the way those suffixes work and according to the word-formation rules concerning them? So why not still use the hyphen, but just move it between "command" and "linesque" to form the compound word "command-lineesque"? What made you rationalize that the hyphen needed to be there because you needed "line-esque" instead of just having the whole term with "command-" as "command-lineesque"?
On a C64/128 note, but unrelated to the current video topic, perhaps something for a future video though, can the 1541/71/81 drives be used as co-processors for game or application performance gains? Each floppy drive has its own 6502 and you could add some memory. The 1571/81 drives run their 6502s at 2mhz. If you have 4 drives attached, you have the possibility of 5 6502s at your disposal.
It's an interesting topic that I've thought about, but haven't come up with a good way of demonstrating it. The short answer is yes this will work in high computation, low-bandwidth cases. The problem is that it's very slow, relatively, for the CPUs to communicate with each other over the IEC bus. So there has to be the right balance for a net gain from the extra CPU computation, once you remove the CPU cycles burned in communication.
@@8_Bit - There's a demo "freespin" that runs entirely on a 1541 - sound and video too :O (it doesn't address the bandwidth issue no - but an extra music channel if nothing else)
I used to have 2 disk drives and a printer….i made a program that would program one disk drive to send the home work file to the printer while I used the 64 and other drive to play games…
Couldn't you copy the kernal in to ram, and change the tokenization code?
I just had an idea for a video. I was watching gameplay of Caverns of Khafka and I remember playing it years ago as it was in the Cosmi top 20 collection. I was never a big fan of it though. This game has some of the glitchiest sounds I've ever heard on the 64 and I wanted to see if you could disassemble it to figure out why it sounds the way it does. For instance, the music gets interrupted by other sounds and sometimes makes a garbled noise which sounds the same every time. The elevator sound makes a few beeping noises after it stops moving and there's a green bug which changes pitch after it dies and your character moves around and many more. Just a video showcasing why it does all that would be neat, but if you could write some code to fix some of the issues that would be interesting as well.
Couldn't have accounted for the token for OR in your error checking?
Just add a lookup table for when the character read from peek is outside of the ASCII range. Will make the code a lot larger though
Love to see some simons basic stuff in here. Also, do you plan on going back to the IDE-DOS cartridge?
I've always hated the CLI and I will never be convinced that it's a good way to interact with a computer - Especially one that can easily display graphics or more comprehensive text.
I found the Amiga's CLI very restrictive after being used to the C64's free-form screen editor approach, but I now appreciate the CLI approach for certain tasks that can be broken into precise steps, which often happens while doing software development.
For someone using an emulator, the easiest way is going to be overwriting part of the disk image with command line data before every invocation.
9:56 BASIC does seem to get rid of any spaces before the RUN command. Similarly, you can't indent BASIC lines without a leading ":".
14:57 Seems more like a brown than an orange.
15:26 You could add "┌ANGE" as an alias. You might want that for the British "GREY" spellings as well.
16:59 This is more like it - giving command-line arguments on the command that loads and runs the program. Various C64 wedges also have a loan-and-run command.
17:32 I assume this fails if the filename has a colon in it.
19:01 Cool - the C64 automatically changes «LIST» to «L╮»!
20:32 But it's 2024!
26:00 Yeah, you manually hacked my name to not break your credits program! I suppose «Craig'; DROP TABLE Students;» won't work here, either.
Fun (useless) fact - orange and brown are one and the same. It's the brightness of the orange and the contrast between it and any surrounding colours that determine if your eyes perceive it as orange or brown (assuming one isn't colour blind).
Yes, brown is dark orange, just like pink is light red.
amazing how a value can be carried on P and also use a P$ can hold a string, a lot of programming languages dont allow that in basic i think6 anymore??
Yes, and in fact P% is also available as a signed 16-bit integer, and then all 3 of those types can also be made into arrays with the same variable name. So we could have P, P%, P$, P(), P%(), and P$() all being valid independent variables :)
@@8_Biti think DEF FN P, too
@@gabrielsroka Yes, true, even if it's a function and not a variable, it's still stored like one. FNP() or FN P() in that case.
@@8_Bit i found the article, but i can't paste the link. search the web for "The Case of the Missing 4th Commodore BASIC Variable (and the 5th Byte)" by masswerk
Hi Robin! Sorry for asking, but in my country there are to few people who is pograming for Commodore.
Are there any forums or groups or channels or something where can I publish my game (and development process).
The website itch io seems to be a leading place for C64 developers to publish their game. Search there for Commodore 64 and you'll see quite a few.
Hi Robin!
OK grew up with an Apple ][+, then PC, then Mac SE, then PCs again, so no Commodore experience, and definitely no Commodore hate, but I gotta admit this not leaving a space after LOAD or RUN or other commands really irks my OCD
Just retrain your OCD to focus on optimizing away unnecessary whitespace. Works for me, anyway!
OR... if you named the colour "dark yellow" maybe "LT BROWN" it would all work
You know you could make RUN:ORANGE work without the rem or "...
Great video, but using lower and upper case like "rU:TEST" it doesn't work. 😂 And what about GOTO? Like "GOTO:MENU"? If line zero is there.
Hi Robin! I'm soo please to meet you. I'm San K. Rianna came a few times, very nice girl. Lately, I want my old computers (A500 and A3000) stand on their feet again. Both of them still running but A3000 HD death.
Hello San! Thanks for subscribing, and for having Rianna as a guest. That's really cool you're into Amiga! My friend @10MARC is very knowledgeable about Amiga, I suggest watching his videos in particular. I like Amiga very much but have not got a lot of experience with repairing them.
Try his channel here: youtube.com/@10MARC/