That's very interesting, this would have been way over my head as a 12yr old when I got my C64. Of course if we had DevOps and clever build tools back then, even this assembly would be trivial to automate.
Next level is making a program packer winch takes the various files and plugs it into a program with a loader at the start. so when loaded it shows something like 10 SYS2061 - when run the ML at 2061 moves the upper memory ML in place moves down the basic code and then reset the start of variables locations then initates a RUN command. You might see that sometimes on cracked games, where first ran, the text screen fills with seeming garbage and you may see some rapid character changes, this is the unpacker ML put into screen memory running which moves the packed segments into the right memory locations (they use the screen because for 90% of games the screen isn't written to when unpacked) some of these packers also compress the data so the packed file is smaller for transfer/loading and will compress when unpacking. The upside of this is you can edit BASIC after unpacking downside is you have to use a separate utility to create the packed program.
I like the simplicity of BASIC and most non-game programs are fine in BASIC, but there are those times when you have a "need for speed" and BASIC+ML is a good solution.
Good video, thanks. One trick that can be used to easily ensure the program stays the same size while you are still finalizing the program is to create a buffer in lines 1-9 by adding REM statements to those lines and adding buffer characters (I just use a character repeatedly about 20 per line). This way you can modify your program while keeping it the same size by adding or removing characters from the REM lines accordingly. Obviously once you have the program performing like you want, you will want to remove those REM statements and make a final adjustment. In your case you could have just written 03539 instead to keep the same size.
Good idea using REM's. Wish I'd thought of it. I did the digit adjustment to make a point that all the addresses had to be exact for the process to work.
@@retrooldguy9880 I was going to point out this trick as it was popular with sound-effect routines in some games. Another trick along the same lines that you might find amusing is self-modifying basic. You structure your code as: 10 goto 40 20 30 return 40 ....rest of code goes here You could poke tokenised code directly over line 20 in memory and call as required. I wrote a simple graphing program back in the day using this (for microbee, but I'm assuming the same principle would work on c64) - user would enter eg sin(x), my code would do some rudimentary tokenisation (sin -> some hex code, - and no, I can't remember it :) and poke it in to line 20, then draw a graph of sin(x) using gosub 20 for evaluation.
I have tried putting ML code in a REM statement. The PLOT routine in my earlier video will work like this. But I've found that you can't use a zero in any instructions or addressing as BASIC will choke on it. You can load a zero from another address, but it's still too much trouble with anything large or complex. Locating it at the end of the BASIC code has no such restrictions. But I'll be happy to be proven wrong @TechTinkering did a video about this using a VIC20: ua-cam.com/video/PHJeQlGrTpQ/v-deo.html
Thanks, interesting video, and it makes me want to see more of these tricks that I've wondered about the all the decades since this great but sometimes mysterious computer came out!
What is much better: store the ML routines BELOW BASIC. For this, you can write a small BASIC stub at $0800 which changes the BASIC start to some address above and then RUNs the program above. There, you might wanna overwrite the BASIC stub (for example if you want a char set at $0800).
Using just a C64? Not that I'm aware of. I think it would be pretty difficult to assemble or move your ML code dynamically in memory while trying to merge and reset pointers A Windows based IDE like "C64 Studio" or "CBM Prg Studio" likely have that capability, and would be much more efficient.
Will you please make a video, or show me where you have already posted one, that explains the supposed need for the whole silly-looking math thing in the load command that's in a BASIC program? For 4 decades I've never understood the point of that!
In my previous video about moving the cursor, I have an explanation of how that LOAD works. This link will take you to that point in the video: ua-cam.com/video/QRDGabJXoOA/v-deo.html
Just because you can, doesn't mean you should. BASIC has very, very little to offer to any program written in assembly. No one with half a brain would ever want any BASIC code in their assembly program.
BASIC provides convenience for the programmer. If that were not the case, the C64 and the plethora of other competing computers for the era would have booted up to a monitor prompt. Having said that, some clever folks could have then created a cartridge with BASIC 7.0 or even other languages, together with fast load disk drive routines to extend functionality... albeit at the expense of base compatibility between systems. I think Commodore struck the best balance between convenience, functionality and price point (okay, maybe price point after a year or so on the market 😁) for the system they released in 1982. The late Jim Butterfield was a strong advocate of utilizing the convenience of BASIC where it makes sense, and tapping into the power of machine language where speed makes a significant difference. It doesn't have to be an either/or proposition.
@@TheUtuber999BASIC provides convenience for the user. In the case of the C64 It's designed to make it easy to load/run programs and not much else. Anyone who writes code in BASIC is not a programmer.
@@TheUtuber999 I'm a huge Commodore fan. Have been since the early 1980s. That doesn't change the fact that Commodore BASIC was absolutely useless for programming. Only an absolute novice would use anything but assembly on these computers.
@@bradallen8909 If that's what you believe then you are sadly misinformed. Check out the video entitled "The Computer Chronicles - Commodore 64 (1988)" to see several examples of successful businesses that benefited by using the Commodore 64 in their operations - most of which used programs written in BASIC 2.0.
That's very interesting, this would have been way over my head as a 12yr old when I got my C64.
Of course if we had DevOps and clever build tools back then, even this assembly would be trivial to automate.
Hey, I've seen a TON of machine code in REM statements in ZX Spectrum! REM at line 10 was the default place to put custom loaders back in the day...
Having never had or used a C64 (I was a ZX Spectrum kid) I'm fascinated by what these machines are actually capable of.
Very cool stuff. Thanks for sharing
Next level is making a program packer winch takes the various files and plugs it into a program with a loader at the start. so when loaded it shows something like 10 SYS2061 - when run the ML at 2061 moves the upper memory ML in place moves down the basic code and then reset the start of variables locations then initates a RUN command. You might see that sometimes on cracked games, where first ran, the text screen fills with seeming garbage and you may see some rapid character changes, this is the unpacker ML put into screen memory running which moves the packed segments into the right memory locations (they use the screen because for 90% of games the screen isn't written to when unpacked) some of these packers also compress the data so the packed file is smaller for transfer/loading and will compress when unpacking. The upside of this is you can edit BASIC after unpacking downside is you have to use a separate utility to create the packed program.
Thanks for this content. Wish I’d had a peer or teacher who was also interested in ML/ASM back in the early; I just couldn’t grok it.
I like the simplicity of BASIC and most non-game programs are fine in BASIC, but there are those times when you have a "need for speed" and BASIC+ML is a good solution.
Memories. 🙂
Interesting video. I might steal your 'load from disk' code for CBM prg studio!
Feel free. I saw it in either a book or magazine in the 80's
Good video, thanks. One trick that can be used to easily ensure the program stays the same size while you are still finalizing the program is to create a buffer in lines 1-9 by adding REM statements to those lines and adding buffer characters (I just use a character repeatedly about 20 per line). This way you can modify your program while keeping it the same size by adding or removing characters from the REM lines accordingly. Obviously once you have the program performing like you want, you will want to remove those REM statements and make a final adjustment. In your case you could have just written 03539 instead to keep the same size.
Good idea using REM's. Wish I'd thought of it. I did the digit adjustment to make a point that all the addresses had to be exact for the process to work.
@@retrooldguy9880 I was going to point out this trick as it was popular with sound-effect routines in some games. Another trick along the same lines that you might find amusing is self-modifying basic. You structure your code as:
10 goto 40
20
30 return
40 ....rest of code goes here
You could poke tokenised code directly over line 20 in memory and call as required. I wrote a simple graphing program back in the day using this (for microbee, but I'm assuming the same principle would work on c64) - user would enter eg sin(x), my code would do some rudimentary tokenisation (sin -> some hex code, - and no, I can't remember it :) and poke it in to line 20, then draw a graph of sin(x) using gosub 20 for evaluation.
I have tried putting ML code in a REM statement. The PLOT routine in my earlier video will work like this. But I've found that you can't use a zero in any instructions or addressing as BASIC will choke on it. You can load a zero from another address, but it's still too much trouble with anything large or complex. Locating it at the end of the BASIC code has no such restrictions. But I'll be happy to be proven wrong
@TechTinkering did a video about this using a VIC20: ua-cam.com/video/PHJeQlGrTpQ/v-deo.html
Thanks, interesting video, and it makes me want to see more of these tricks that I've wondered about the all the decades since this great but sometimes mysterious computer came out!
What is much better: store the ML routines BELOW BASIC. For this, you can write a small BASIC stub at $0800 which changes the BASIC start to some address above and then RUNs the program above. There, you might wanna overwrite the BASIC stub (for example if you want a char set at $0800).
Very cool!
is it possible to automate the build/merge/save process to avoid the manual pointer setting?
Using just a C64? Not that I'm aware of. I think it would be pretty difficult to assemble or move your ML code dynamically in memory while trying to merge and reset pointers
A Windows based IDE like "C64 Studio" or "CBM Prg Studio" likely have that capability, and would be much more efficient.
Interesting!
Will you please make a video, or show me where you have already posted one, that explains the supposed need for the whole silly-looking math thing in the load command that's in a BASIC program? For 4 decades I've never understood the point of that!
In my previous video about moving the cursor, I have an explanation of how that LOAD works. This link will take you to that point in the video: ua-cam.com/video/QRDGabJXoOA/v-deo.html
"Recombine... again"? Wait... doesn't "re-" _already mean_ "again"?
Whats meant by 'take care out there' ... where exactly?
It's a variation of the catchphrase "Let's be careful out there" from the 1980's police show called "Hill Street Blues"
@@retrooldguy9880 cool. Cheers dude
Just because you can, doesn't mean you should. BASIC has very, very little to offer to any program written in assembly. No one with half a brain would ever want any BASIC code in their assembly program.
BASIC provides convenience for the programmer. If that were not the case, the C64 and the plethora of other competing computers for the era would have booted up to a monitor prompt. Having said that, some clever folks could have then created a cartridge with BASIC 7.0 or even other languages, together with fast load disk drive routines to extend functionality... albeit at the expense of base compatibility between systems. I think Commodore struck the best balance between convenience, functionality and price point (okay, maybe price point after a year or so on the market 😁) for the system they released in 1982.
The late Jim Butterfield was a strong advocate of utilizing the convenience of BASIC where it makes sense, and tapping into the power of machine language where speed makes a significant difference. It doesn't have to be an either/or proposition.
@@TheUtuber999BASIC provides convenience for the user. In the case of the C64 It's designed to make it easy to load/run programs and not much else.
Anyone who writes code in BASIC is not a programmer.
@@bradallen8909 So what are you even doing here if you're not a Commodore fan?
@@TheUtuber999 I'm a huge Commodore fan. Have been since the early 1980s. That doesn't change the fact that Commodore BASIC was absolutely useless for programming. Only an absolute novice would use anything but assembly on these computers.
@@bradallen8909 If that's what you believe then you are sadly misinformed. Check out the video entitled "The Computer Chronicles - Commodore 64 (1988)" to see several examples of successful businesses that benefited by using the Commodore 64 in their operations - most of which used programs written in BASIC 2.0.