I was always using a variety of "fast loader" cartridges like Fast-Load, Ice-Pick, Snap-Shot, Datel's Action Replay, etc, all had a hot-key (usually two keys) which eliminated the need to type the long LOAD"*",8,1
Wow. I didn't think there would be much to learn in this video. But I learned a lot of things I did't know about! Thanks for making this. And also thanks for the unexpected sighting of Petscii Robots!
Thanks again for sending PETSCII Robots, the box and manual look fantastic and I'm looking forward to trying out that SNES adapter... on the PET? That seems crazy :)
I like to think my own stupid question posted in another video about TMP. I was loading TMP but didn't know about the ,1 at the end! I eventually figured it out and then updated my own comment with the solution. Or it's just coincidence and you never noticed ;)
Yeah, I honestly didn’t even know that * means “first file” only for the first time, and “last loaded file” thereafter. But it’s an edge case since in practical life who would load the same file twice...?
I thought I fully understood the load mechanics but clearly not! Thank you Robin for this super informative video - something to learn for even the most die hard C64 fans.
Well done! I saw the title, and a 30-minute length, and I was thinking that I couldn't possibly talk on ",8" vs ",8,1" for that long. But then, I'm not Robin. :) These are the details that make the C64 so engrossing. That Platoon loader is a little gem, and I only know about it because Robin leaves no 8-bit stone unturned. I still wonder how the ancient ones, with no web and poor documentation options, figured out such a variety of techniques on tight deadlines. All this 8-bit ingenuity unfolded over such a short period of time.
Before the internet there were many BBS/message boards, some for "warez", while others for programmers, so even back then people had means of sharing tips and tricks.
The C64 was very popular and Commodore's documentation was really good. The user manual that came with it was about half an inch thick and the programming manual was about 2 inches or so. Both were available everywhere along with assembly language guides to the registers and hardware. They were also pretty cheap!
This channel is so great, it's like the youtube version of the library books I used to read on the weekends while trying to learn how to use computers as a youngin
Doing LOAD"$", 8,1 doesn't produce gibberish, it is still a directory listing ju case switched. It was useful to see " hidden" files on the disk. Just hit commodore+shift to see the filenames. It lacks the fancy formatting but it defeats most(all?) tricks to hide files.
In the good old days, I used this to load the directory without erasing the BASIC program. Of course, this still killed the BASIC program if the directory was longer than four blocks.
Long-ish time viewer; first time commenter. Agree with The 8-Bit Guy's comment. There was incredible information presented about such a 'simple' command. Thanks for the great talk!
Very interesting in-depth description of the loading mechanisms and their differences, including the autorun trick; it always fascinated me how the C64 performed those special tricks, including weird directory listings with petscii art or "invisible" filenames as part of copy protection schemes (that in some cases go along with your dissection of Platoon payload disk)
Great, detailed, and accurate video (as always). Thank you so much for clearing this up! I have seen a lot of people get the details wrong (arbitrarily use ",1"), and I learned quite a bit myself.
Just so you know how you impact your fans: 1. I find when a new video appears, it immediately has my full interest and it brightens my day and I instantly forgive you for not having put out anything recently 2. If you don't keep[ putting things out, I begin to grumble increasingly as time passes.... Sounds like addiction... hrm.
ok i have just completed a BBC Micro MC/assembly book and learnt a lot i am in the process of converting the example programs into the C64C and encountered the first real difference, other than memory maps and routine call locations, between the 2 systems. That is the beeb has inline assembly, where you can go in and out of assembly and basic in one program, where as the c64 you do the assembly and save the mc code to a file then use a basic loader to load it all up. The problem i had was using load"file",8,1 in a basic program sent my sd2iec blink like mad. Thanks to this video we have now solved the problem using the L=L+1 counter before loading and it fixed it it then went on to print the result of an ADC with a basic print and peek Thanks very much Love your videos Steve in UK
My favorite space used to be $C000 to write assembly. But if I wanted an accompanying basic line to start it, (10 SYS 49152), I would waste all the space from $08xx to $BFFF on disk space, and would be big block files. But I have seen way smaller files that do this. Is there a trick to this?
I think I saw a video about this topic a couple of days ago and I think the trick was to type the 10 SYS... line with an approximate value then peeking the end of the BASIC program (PEEEK (45) + 256*PEEK(46)) then peeked again and updated the 10 SYS line with the proper value. Then he moved the whole ML program after the end of the BASIC program (I might be wrong because I just started to learn Assembly and Machine Language).
I never had to do anything other than "load" until I got my first emulator - as a kid we had tapes and a couple of cartridges. I didn't see a floppy disk in person until we got our Atari ST :)
the Atari 810 disk made a similar sound when it would seek a bad sector but it was more of a fart than a machine gun. One could create bad sectors intentionally by cranking the disk speed trimmer pot while writing to that sector.
Such a great video! I never had a C64, but I had plenty of friends who did. I started with a PET in school and then Apple IIs. At home I had a TI 99/4A and then an Apple IIGS. I knew how to load programs on the PET and C64, but never understood the specifics of that load command (or even that you could read a PET program into a C64) until today.
2:45 Neat, I've never played this game. 6:36 The first time I got that screen noise on the SS5 Monitor, I started checking power connections. It happens on every machine I have, so I wonder what causes it. It's not harmful, but now I'm curious. Still working on a full disassembly of the ROM so maybe it will reveal itself. 7:43 Interesting observation on it overriding the vector like a virus does. On a computer with no memory protection, folks do this all the time on purpose to get it to do things it wasn't necessarily intended to do (I'm thinking demo scene mostly). I've been teaching a couple younger people about how security works and now you've introduced the idea that I could use a 64 as a learning tool for this. 8:36 That's pretty clever, hadn't thought to do that before. 10:11 I should have this phrase in my office somewhere. Or maybe a tattoo. 12:45 I checked, October 1985 P 32 of Ahoy! archive.org/details/ahoy-magazine-22/page/n31/mode/2up 14:40 I wonder how many people scratched their heads for many minutes before that +1 at the end address became apparent 18:26 He spent a lot of time enhancing the graphics on this for the 64 version and I much prefer the PET and VIC20 graphics. This is a good use (educated guess) of reusing a lot of techniques from Planet X2 to make a similar but unique and really playable game without completely reinventing the wheel. I'm assuming he saved himself quite a bit of development time. 23:29 One of my favorite features of Action Replay (and derivatives like RetroReplay and Nordic) is that this start and load address is always printed, even when loading a BASIC program with the / wedge.
I would have shown more of Master of Magic but I found out during editing that my C64's sound output wasn't captured at all! And a silent Master of Magic is no fun at all. Well, the episode was plenty long enough without all that. re: noise in SS5 monitor, I believe it's the monitor rapidly switching to its extra RAM where the frozen program's stack and screen RAM are stashed to fetch the data that the user wants to see. That is, when you're disassembling or dumping memory in the monitor, do you want to see the frozen program's RAM, or do you want to see the monitor's RAM? The monitor has to share resources with the frozen program, but tries to be as transparent as possible. This is difficult to explain! re: Action Replay displaying the load address, I like that feature too. JiffyDOS derivative JaffyDOS also does that trick.
@@8_Bit That makes perfect sense. I'm flashing my snappy device this morning to do the TMP decimal fix and it's flashing the screen a lot while it's happening. Now I need to put the scope on it and watch :-) Bummer about the sound! I played that game during a conference call a little, it's pretty nifty
The more videos i watch of yours the more i appreciate how amazing the C64 was/is my Dad had an Amiga 500 in the early 90's hopefully one day i can get one
The fast hackem sector editor tutorial was awesome! I am a huge commodore fan but I don't play games. I am more interested in coding and your channel definitely keeps me interested. Great stuff. I remember being introduced to the sector editor at age 12 by an adult "cracker". He showed me how to change the text in infoquick by lew lasher so I could customize my bbs.
I like that feature too, though sometimes it kind of messes up certain programs by printing those load addresses while files are loading from under program control, potentially corrupting memory with those unexpected characters. It's not that common, but I've seen it happen. Super Snapshot shows the load addresses too, but only when loading is done from the machine language monitor.
Thanks for explaining that L=L+1 bit! I always wondered what that meant in many basic listings (why they didn't right away load the stuff but had that variable count up, mostly with A=A+1 :) Many interesting infos! Greetings from a C64 lover who played C64 games in 80s already and I also coded some Basic stuff and did lots stuff in Activision's Game Maker! :)
Something else this reminds me of (you can tell I never managed to afford, or get my parents to afford, a disk drive at the time)... I wrote a cassette directory/menu utility to the start of many of my home-made C64/128 tapes (all now sadly sent to landfill many years ago). The idea was, rather than scrawling the contents of my tape on the inlay and trying to keep it updated amidst loads of crossings-out and the new counter positions, my utility would present me with a list of programs/files and ask me which one I wanted to load. After making my selection, it would then instruct me to press FFWD on tape. It would then wait the requisite period of time to allow the tape to reach the correct counter position, at which point it would stop the tape motor and instruct me to press STOP. Then it would drop into the default LOAD command with PRESS PLAY ON TAPE. To add a new item to the directory/menu, it would input a filename/title from me, then ask me to locate it using FFWD and STOP. It would monitor how much time was spent fast-forwarding (i.e. the difference in TI between starting and stopping) and then by printing new data lines to the screen then using the C64's version of "SendKeys" (POKE131+...,[ASCII codes]:...) to auto-Enter those lines into the menu program, I could then resave the modified menu to the start of the tape. A bit long-winded in terms of getting the information in in the first place maybe, but a great timesaver once it was done.
Hi Robin! I can't believe that I have not discovered you channel sooner! Man, this is one of the best there is on C64s. I gladly subscribed and watched a ton of content already. Thanks for sharing your vast knowledge!
This reminds me of when I reverse engineered the cassette turbo-loading programme that Ocean Compiler came with, and used it for saving not just basic programs but font (character set) files, screenshots, sprite sets, or other random pieces of memory, and I remember finding out that there were two pairs of bytes that needed to be set to indicate the start and end address that would be saved. By using OPEN 1,1,1,"FILENAME" and then setting those addresses, I could then append any number of non-contiguous memory areas to one tape file. I can't remember whether triggering the save of each chunk was done with a PRINT#1 statement or an SYS command, but I could carry on saving multiple chunks until I used CLOSE 1 to finish.
10:30 It's fairly simple, the bulk of the stack is overwritten with $0202 so when kernal inevitably executes a RTS it "returns" to $0203 which is the games code.
Beautiful video. I didn't watch more than 2:38, but that explained everything I needed to know, and it made so much sense :) Regards from a commodore loading dude.
@@8_Bit Thanks! Your reply makes me happier than you could imagine. Atomic Shrimp would no doubt be both pleased and surprised that he has managed to propagate his newly chosen verbiage so far and fast, this being less than 24 hours from their first becoming publicly known.
The bit you mentioned about loading PET programs on the C64 etc. is actually the same reason that the directory has the $0401 load address. Since PETs *always* honor the load address, the disk drives had no choice but to send the directory program with the PET address for BASIC text in order to be compatible with those machines at all. To allow those same drives to work on the VIC, Commodore modified the behavior of LOAD to ignore the load address by default and just put the program wherever BASIC text was supposed to be unless the new optional ,1 parameter was specified. Though probably the main reason for the change was that he BASIC text address on the VIC moves around depending on expansion memory; if LOAD had still worked like it did on the PET, your old programs might suddenly stop loading after you got a memory expansion cartridge.
David and you both seem like really nice guys, I don't have a C64 but I spent a lot of time in basic on my Tandy 1000sx back in the day and in Qbasic on my Win 3.11 Packard Bell Machine. which is why I enjoy the stuff on both your channels, Some day if and when the world goes back to normal I would love to attend an event for this kind of stuff.
Wouldn't "*" just mean the first file encountered with a name that matches this pattern? Which is why something like "A*" will load the first file encountered that has the first letter "A".
I think the Commodore file system organizes files by the order in which the file was created. If you write Boot first, then, say, Adventure, Assets, Outro and Intro, in that order, Boot will be listed first for "*". For "A*", it would be Adventure, and for "*o" Outro.
@@alexandruianu8432 Most, if not all, disk systems do that: they store the next file in the first available space in the [current] directory, which if no files have been deleted is the next directory entry after the last one in the list. Sorting was not (usually) implemented, and if it was it would be implemented on listing, not storing.
OK, this makes sense now. I remember a crude "Action Replay Cart" that involved putting a paperclip between pins 1 and 3 on the cartridge port to jump back to the basic prompt to start entering poke commands for infinite lives. I imagine the ,1 was required to ensure the memory addresses were correct for each game when entering the poke address.
Bringing back the memories... of memory :) we got ours when I was 10. I remember making the kids at school jealous because I printed out my time tables homework.
It is nice that you like MoM as much, as I do. This brings back childhood memories. I think, this was the first game where I really "invested" systematic and serious gameplay to reach the end. Awesome game, really.
When I was a kid, I got my cousins old C64 and the only instructions he gave my was 'Use LOAD"*",8,1' It took me quite a while to get anything to run as I didn't know English at the time, knew nothing about computers and was like 6 years old :D
I knew the basics of this, but one thing I always wondered was how most programs in assembly seemed to have BOTH machine language and BASIC even if it's just a SYS command. I thought that it was loading the program into 2 separate locations. I didn't think it would be all together like that. Interesting video and nice to know. Definitely answers some questions. I suppose you could always have a separate BASIC loader that loads the ML program separately and then SYSes it afterwords. You could even do that with gravitron. It would still be smaller and faster than the POKE version even with 2 separate files.
I learned to code on my Dad's TRS-80 L-II as a freshman. I continued coding on the TI as my graduation gift at the beginning of my senior year before buying the C128 in '85 with my Kmart money. In retrospect I wish I had bought an Amiga instead but was scared to learn C at that time.
Working in IT I still jokingly say, "Have you tried Load "*",8,1?" when someone is having trouble booting a system up. It's a good age test, those over 45 laugh and nod and those under 45 just give a blank quizzical stare, I've even had a few of the younger IT folks actually take me seriously and try it, just assuming it's some special function.
Growing up my dad got an extra disk drive so I got used to using both ,8 and ,9 Never understood what ,1 indicated, just knew that sometimes you needed it and sometimes you didn’t.
When I was little, I had several hundred of floppy discs, and I had several games that after loading ,8,1 it would just return to READY. after it seemingly had loaded the game. Typing RUN did nothing and I never know why this happened. It does seem the game was loaded but didn't run.
I could probably make a more focused video about disk directory editing but the animated disk directory episode that Fit Fogey linked to gets into it. And I think I touched on locking files and maybe some other aspects in the Epyx Fast Load video too.
I remember doing a load”*”,8,1:RUN (or something like that) which was added to the end by hitting shift Ctrl/brk or something like that. I believe (gosh it’s been decades since I last touched a C64/C128) it was simply a shortcut to auto run after it was done loading.
I never understood the difference until now. I always used, 8,1. I remember my diskdrive wouldn't load anything for some reason and I thought the drive was dead until I had a friend over who typed ,8 and the drive starting to work again. Now I finally get it.
Omg what a flash of nostalgy this video gave. I loved my C64, those were so exciting times. I just wish information was more readily available back then,. Books were expensive as hell and 99% of time buggy and outdated.
When I was a beginner assembly language programmer on the CoCo2/3, there was a lot of encouragement to use position independent code (PIC). The compilers for OS-9 defaulted to op codes favoring relative addressing though absolute addressing was still available. While it's possible for PIC on the 6502, I'm not entirely sure how feasible it is to implement. I'm reminded of this as you're talking about changing where in memory a file gets loaded. I'm also thinking of raising that discussion in the Commander X16 forums though I fear development and standards are all but completely set. It's funny that Commander X16 is "not a Commodore clone" and yet they do too much commodore-like to avoid the notion.
Not only did 1541s come preconfigured as 8, but all other Commodore 8-bit drives, like the 4040-based series, the 1001, 1571, 1581, etc. And I don't think I've ever seen any other brand of drives made for this computer come preset to between 9-11, either.
I remember as a kid listing a loaded game loader and wondering at the "A = A + 1: IF A = 1 THEN A = 2, etc" and what it did. An article in Compute's Gazette explained this and now so have you!. Thanks for the memories. Can you explain how directory blocks can be faked? That is, sometimes when you list a directory from a game it will say that all 664 blocks are free, etc.
Great video as always Robin. Too funny about Fast Hack 'em. They couldn't possibly have expected people *not* to pirate probably the most widely used pirating program, lol.
LOAD... along with PRINT, the C64 most used commands ever ! 😎 What about tape loading ? In some tape games, the combination of keys works while the LOAD and then RUN command does not work. Thanks for these great memories!
FYI CBM basic programs exist in memory as as linked list: next line address (2 bytes), line number (2 bytes), and then the tokenized line. End of program is indicated by a next line address of $0000. When you load with ,8 BASIC actually steps through the list and rewrites the next line addresses until it hits a $0000, but it continues loading until EOF. I have seen some BASIC programs "protected" by a line that has been edited to link to itself. Trying to list (or load with ,8) will loop forever.
I never worked with a Commodore 64, because I had a TRS-80 Model I. It looks like the "8,1" option is for machine language programs. In TRS-80 DOS, you load machine language programs in DOS, and BASIC programs can only be loaded inside the BASIC interpreter. It looks like the Commodore 64 has one loader that works for everything by just loading code into BASIC by default, or somewhere else with the ",1" option for machine language programs. TRS-80 programs had extensions so that you could know whether a program was BASIC or machine language, much like MS-DOS or Windows.
Ah yes. Autoloading. Also autobooting. Something the C128 supports. Back in the days, I used to make autobootable C64 stuff. Would only work on the C128, though, as the C64 does not support autobooting from floppies. Basically... make a C128 autoboot program, which with a bit of magic, places a nice payload, then goes to C64 mode... with that magic payload, it then loads the targetted C64 program, that either is autostarting or not. I know there was some magic header on the floppy somewhere, that the C128 looked for during startup. Don't remember what exactly. That would cause the C128 to load a designated program, which if using the autostart tricks would automatically start. I also know there was a way to have a C128 program go into C64 mode, only to continue running there. I think it was done by preparing suitable locations in memory, probably just like an autostart program. Would work, as the memory wouldn't be cleared when going from C128 mode to C64 mode.
Another thing that's interesting about this is that in more modern computers since this, overlapping with Commodore's other 8-bit computers like the 128, though -- but basically all computers from all DOS-based and then 16-bit ones forward, have auto-run as the standard, and it doesn't seem weird to us at all. It only seemed weird to me on Commodores because when I started with Commodore I wasn't immediately presented with autorunners. I was used to manually running. But once my parents got our first Mac and I saw _every_ software autorun when you started to load it, that wasn't so odd on there. I wonder if DOS, Amiga, Atari ST, Mac, and Windows all use the same principle as the auto-run (what was then a "trick") on these 8-bit Commies.
That Ultima III disk was clearly written by some program which didn't understand too much of the standard 1541 sector layout. The files seem to have a sector interleave of 1, not the standard of 11. And the first file to load doesn't start on track 17 but track 1. You should make a video about sector interleave and the standard track order for writes on 1541, explaining how it is optimized for load time with a stock C64 and 1541. And how using a fast loader a smaller sector interleave would be beneficial.
i learned to type the ,8,1 as a young boy without ever knowing what it meant. It was just the magic command to get the games to run
Same here. I stayed away from ,8 like it was a rabid animal for some reason.
@@fitfogey you need that ,1 to keep that wild ,8 fenced in. My friend used to type ,8,8 like a madman.
Ditto. Also, we had a Mach 5 cartridge in our C64 at all times.
I only used ,8 when the loading instructions said so. Most of the time I ran into ,8 only however was if the game was written entirely in BASIC
I was always using a variety of "fast loader" cartridges like Fast-Load, Ice-Pick, Snap-Shot, Datel's Action Replay, etc, all had a hot-key (usually two keys) which eliminated the need to type the long LOAD"*",8,1
Wow. I didn't think there would be much to learn in this video. But I learned a lot of things I did't know about! Thanks for making this. And also thanks for the unexpected sighting of Petscii Robots!
Thanks again for sending PETSCII Robots, the box and manual look fantastic and I'm looking forward to trying out that SNES adapter... on the PET? That seems crazy :)
@@8_Bit would be good to see you code something up to demo the adapter? :)
@@RetroGameCoders ,,,llllll
I like to think my own stupid question posted in another video about TMP. I was loading TMP but didn't know about the ,1 at the end! I eventually figured it out and then updated my own comment with the solution. Or it's just coincidence and you never noticed ;)
Yeah, I honestly didn’t even know that * means “first file” only for the first time, and “last loaded file” thereafter. But it’s an edge case since in practical life who would load the same file twice...?
I knew about half of this. Who would've thought that 35 years later, I'd learn the other half. Thank you.
I was about to write the same thing!
same here and now kicking myself for not knowing as a kid
Lots of "old dogs" learning new tricks here. he-he
Another old dog here! Never to old to learn though! :-)
I thought I fully understood the load mechanics but clearly not! Thank you Robin for this super informative video - something to learn for even the most die hard C64 fans.
“We’ll look at the BASIC difference between them first” I see what you did there
Well done! I saw the title, and a 30-minute length, and I was thinking that I couldn't possibly talk on ",8" vs ",8,1" for that long. But then, I'm not Robin. :) These are the details that make the C64 so engrossing. That Platoon loader is a little gem, and I only know about it because Robin leaves no 8-bit stone unturned.
I still wonder how the ancient ones, with no web and poor documentation options, figured out such a variety of techniques on tight deadlines. All this 8-bit ingenuity unfolded over such a short period of time.
Before the internet there were many BBS/message boards, some for "warez", while others for programmers, so even back then people had means of sharing tips and tricks.
C64 magazines..
The C64 was very popular and Commodore's documentation was really good. The user manual that came with it was about half an inch thick and the programming manual was about 2 inches or so. Both were available everywhere along with assembly language guides to the registers and hardware. They were also pretty cheap!
This channel is so great, it's like the youtube version of the library books I used to read on the weekends while trying to learn how to use computers as a youngin
Oh dear, as you typed the load for the master of magic, the first sid tune started to play in my head..
Doing LOAD"$", 8,1 doesn't produce gibberish, it is still a directory listing ju case switched. It was useful to see " hidden" files on the disk. Just hit commodore+shift to see the filenames. It lacks the fancy formatting but it defeats most(all?) tricks to hide files.
can confirm, just tried it.
In the good old days, I used this to load the directory without erasing the BASIC program. Of course, this still killed the BASIC program if the directory was longer than four blocks.
Long-ish time viewer; first time commenter. Agree with The 8-Bit Guy's comment. There was incredible information presented about such a 'simple' command. Thanks for the great talk!
Very interesting in-depth description of the loading mechanisms and their differences, including the autorun trick; it always fascinated me how the C64 performed those special tricks, including weird directory listings with petscii art or "invisible" filenames as part of copy protection schemes (that in some cases go along with your dissection of Platoon payload disk)
All my favourite retro computer youtubers showing up on my favourite retro computing youtube channel...
Great, detailed, and accurate video (as always). Thank you so much for clearing this up! I have seen a lot of people get the details wrong (arbitrarily use ",1"), and I learned quite a bit myself.
I love your channel! I finally understand the stuff that was pure magic when I was just 8 years old.
Wow that's a true throwback. 😮. Unlocked all of my memories from that time in the 80s.
Funny, the "PLEASE SUBSCRIBE" title on that gravinauts floppy... 😎
They didn't have a "like" button in the early days ;)
@@anjinmiura6708 < LOL good one. ;D
Just so you know how you impact your fans:
1. I find when a new video appears, it immediately has my full interest and it brightens my day and I instantly forgive you for not having put out anything recently
2. If you don't keep[ putting things out, I begin to grumble increasingly as time passes....
Sounds like addiction... hrm.
In 1984-86, I was a GURU on the C64!! Still, there's a couple of things that I never knew about in this video. Thanks!!
Well I'm glad you have this video up because I come back to it from time to time. For some weird reason I can never remember this.
ok
i have just completed a BBC Micro MC/assembly book and learnt a lot
i am in the process of converting the example programs into the C64C and encountered the first real difference, other than memory maps and routine call locations, between the 2 systems.
That is the beeb has inline assembly, where you can go in and out of assembly and basic in one program, where as the c64 you do the assembly and save the mc code to a file then use a basic loader to load it all up.
The problem i had was using load"file",8,1 in a basic program sent my sd2iec blink like mad.
Thanks to this video we have now solved the problem using the L=L+1 counter before loading and it fixed it
it then went on to print the result of an ADC with a basic print and peek
Thanks very much
Love your videos
Steve in UK
My favorite space used to be $C000 to write assembly. But if I wanted an accompanying basic line to start it, (10 SYS 49152), I would waste all the space from $08xx to $BFFF on disk space, and would be big block files. But I have seen way smaller files that do this. Is there a trick to this?
I think I saw a video about this topic a couple of days ago and I think the trick was to type the 10 SYS... line with an approximate value then peeking the end of the BASIC program (PEEEK (45) + 256*PEEK(46)) then peeked again and updated the 10 SYS line with the proper value. Then he moved the whole ML program after the end of the BASIC program (I might be wrong because I just started to learn Assembly and Machine Language).
I never had to do anything other than "load" until I got my first emulator - as a kid we had tapes and a couple of cartridges. I didn't see a floppy disk in person until we got our Atari ST :)
FOUND TURBOTAPE
Fantastic nostalgia trip. Thanks for such a detailed and information filled video!
Wow... hearing that 1541 "machine gun" sound took me back about 30-35 years. Good times.
the Atari 810 disk made a similar sound when it would seek a bad sector but it was more of a fart than a machine gun. One could create bad sectors intentionally by cranking the disk speed trimmer pot while writing to that sector.
can verify this is a great explanation of the difference of ,8,1 and ,8.
I've been thinking about this for almost 36 years now. Thank you!
Such a great video! I never had a C64, but I had plenty of friends who did. I started with a PET in school and then Apple IIs. At home I had a TI 99/4A and then an Apple IIGS. I knew how to load programs on the PET and C64, but never understood the specifics of that load command (or even that you could read a PET program into a C64) until today.
Amazing detail Robin. Like a lot of the comments here I “knew” this stuff but didn’t actually know most of it. Well done 👏
Thank you for finally clarifying something I've occasionally wondered about in the past 30 years or so, having been a C1541 user as a kid!
2:45 Neat, I've never played this game.
6:36 The first time I got that screen noise on the SS5 Monitor, I started checking power connections. It happens on every machine I have, so I wonder what causes it. It's not harmful, but now I'm curious. Still working on a full disassembly of the ROM so maybe it will reveal itself.
7:43 Interesting observation on it overriding the vector like a virus does. On a computer with no memory protection, folks do this all the time on purpose to get it to do things it wasn't necessarily intended to do (I'm thinking demo scene mostly). I've been teaching a couple younger people about how security works and now you've introduced the idea that I could use a 64 as a learning tool for this.
8:36 That's pretty clever, hadn't thought to do that before.
10:11 I should have this phrase in my office somewhere. Or maybe a tattoo.
12:45 I checked, October 1985 P 32 of Ahoy! archive.org/details/ahoy-magazine-22/page/n31/mode/2up
14:40 I wonder how many people scratched their heads for many minutes before that +1 at the end address became apparent
18:26 He spent a lot of time enhancing the graphics on this for the 64 version and I much prefer the PET and VIC20 graphics. This is a good use (educated guess) of reusing a lot of techniques from Planet X2 to make a similar but unique and really playable game without completely reinventing the wheel. I'm assuming he saved himself quite a bit of development time.
23:29 One of my favorite features of Action Replay (and derivatives like RetroReplay and Nordic) is that this start and load address is always printed, even when loading a BASIC program with the / wedge.
I would have shown more of Master of Magic but I found out during editing that my C64's sound output wasn't captured at all! And a silent Master of Magic is no fun at all. Well, the episode was plenty long enough without all that.
re: noise in SS5 monitor, I believe it's the monitor rapidly switching to its extra RAM where the frozen program's stack and screen RAM are stashed to fetch the data that the user wants to see. That is, when you're disassembling or dumping memory in the monitor, do you want to see the frozen program's RAM, or do you want to see the monitor's RAM? The monitor has to share resources with the frozen program, but tries to be as transparent as possible. This is difficult to explain!
re: Action Replay displaying the load address, I like that feature too. JiffyDOS derivative JaffyDOS also does that trick.
@@8_Bit That makes perfect sense. I'm flashing my snappy device this morning to do the TMP decimal fix and it's flashing the screen a lot while it's happening. Now I need to put the scope on it and watch :-)
Bummer about the sound! I played that game during a conference call a little, it's pretty nifty
Great info! Thank you
I was thinking about Fast Hack 'em minutes before you brought it out.
The new thing that I learned was the ":*". Thanks for teaching me something new.
Excellent video for all of us to learn and remember
The more videos i watch of yours the more i appreciate how amazing the C64 was/is my Dad had an Amiga 500 in the early 90's hopefully one day i can get one
As a lot of you would agree, getting that disk drive was a huge step up from cassette drive. I had my disk box and all my games.... Great times.
The fast hackem sector editor tutorial was awesome! I am a huge commodore fan but I don't play games. I am more interested in coding and your channel definitely keeps me interested. Great stuff. I remember being introduced to the sector editor at age 12 by an adult "cracker". He showed me how to change the text in infoquick by lew lasher so I could customize my bbs.
I love The Final Cartridge and Action Replay. They show the load address from and to when loading is completed.
I like that feature too, though sometimes it kind of messes up certain programs by printing those load addresses while files are loading from under program control, potentially corrupting memory with those unexpected characters. It's not that common, but I've seen it happen. Super Snapshot shows the load addresses too, but only when loading is done from the machine language monitor.
Thanks for explaining that L=L+1 bit! I always wondered what that meant in many basic listings (why they didn't right away load the stuff but had that variable count up, mostly with A=A+1 :) Many interesting infos! Greetings from a C64 lover who played C64 games in 80s already and I also coded some Basic stuff and did lots stuff in Activision's Game Maker! :)
Something else this reminds me of (you can tell I never managed to afford, or get my parents to afford, a disk drive at the time)...
I wrote a cassette directory/menu utility to the start of many of my home-made C64/128 tapes (all now sadly sent to landfill many years ago).
The idea was, rather than scrawling the contents of my tape on the inlay and trying to keep it updated amidst loads of crossings-out and the new counter positions, my utility would present me with a list of programs/files and ask me which one I wanted to load. After making my selection, it would then instruct me to press FFWD on tape. It would then wait the requisite period of time to allow the tape to reach the correct counter position, at which point it would stop the tape motor and instruct me to press STOP. Then it would drop into the default LOAD command with PRESS PLAY ON TAPE.
To add a new item to the directory/menu, it would input a filename/title from me, then ask me to locate it using FFWD and STOP. It would monitor how much time was spent fast-forwarding (i.e. the difference in TI between starting and stopping) and then by printing new data lines to the screen then using the C64's version of "SendKeys" (POKE131+...,[ASCII codes]:...) to auto-Enter those lines into the menu program, I could then resave the modified menu to the start of the tape.
A bit long-winded in terms of getting the information in in the first place maybe, but a great timesaver once it was done.
Robin I promise you I was just tinkering on the C64 today and wondered what the difference between ,8 and ,8,1 was. Crazy. Thanks so much man!
I've noticed it's still a common question on Facebook and elsewhere, so I thought I'd take a crack at it. Thanks for watching :)
Hi Robin! I can't believe that I have not discovered you channel sooner! Man, this is one of the best there is on C64s. I gladly subscribed and watched a ton of content already. Thanks for sharing your vast knowledge!
This reminds me of when I reverse engineered the cassette turbo-loading programme that Ocean Compiler came with, and used it for saving not just basic programs but font (character set) files, screenshots, sprite sets, or other random pieces of memory, and I remember finding out that there were two pairs of bytes that needed to be set to indicate the start and end address that would be saved. By using OPEN 1,1,1,"FILENAME" and then setting those addresses, I could then append any number of non-contiguous memory areas to one tape file. I can't remember whether triggering the save of each chunk was done with a PRINT#1 statement or an SYS command, but I could carry on saving multiple chunks until I used CLOSE 1 to finish.
10:30 It's fairly simple, the bulk of the stack is overwritten with $0202 so when kernal inevitably executes a RTS it "returns" to $0203 which is the games code.
back when a stack smash was just how you got things done.
Beautiful video. I didn't watch more than 2:38, but that explained everything I needed to know, and it made so much sense :) Regards from a commodore loading dude.
This is the most glarded video I've seen all day - thanks!
You're weclome, anytime I take inoppolity to clode.
@@8_Bit Thanks! Your reply makes me happier than you could imagine.
Atomic Shrimp would no doubt be both pleased and surprised that he has managed to propagate his newly chosen verbiage so far and fast, this being less than 24 hours from their first becoming publicly known.
Thank you!!! Great video! As always I am looking forward to your next great video! Have a nice Weekend!
The bit you mentioned about loading PET programs on the C64 etc. is actually the same reason that the directory has the $0401 load address. Since PETs *always* honor the load address, the disk drives had no choice but to send the directory program with the PET address for BASIC text in order to be compatible with those machines at all. To allow those same drives to work on the VIC, Commodore modified the behavior of LOAD to ignore the load address by default and just put the program wherever BASIC text was supposed to be unless the new optional ,1 parameter was specified. Though probably the main reason for the change was that he BASIC text address on the VIC moves around depending on expansion memory; if LOAD had still worked like it did on the PET, your old programs might suddenly stop loading after you got a memory expansion cartridge.
David and you both seem like really nice guys, I don't have a C64 but I spent a lot of time in basic on my Tandy 1000sx back in the day and in Qbasic on my Win 3.11 Packard Bell Machine. which is why I enjoy the stuff on both your channels, Some day if and when the world goes back to normal I would love to attend an event for this kind of stuff.
Wouldn't "*" just mean the first file encountered with a name that matches this pattern? Which is why something like "A*" will load the first file encountered that has the first letter "A".
I think the Commodore file system organizes files by the order in which the file was created. If you write Boot first, then, say, Adventure, Assets, Outro and Intro, in that order, Boot will be listed first for "*". For "A*", it would be Adventure, and for "*o" Outro.
@@alexandruianu8432
Most, if not all, disk systems do that: they store the next file in the first available space in the [current] directory, which if no files have been deleted is the next directory entry after the last one in the list.
Sorting was not (usually) implemented, and if it was it would be implemented on listing, not storing.
@@cigmorfil4101 I know how it works physically, but what I meant was the directory listing wasn't sorted on Commodore machines.
Thank you for that fantastic explanation !
1SYSxxxx: That brought back memories! That's how I started all my ML programs.
SYS 49152 for simple fare; SYS 64738, and you knew you were in for a real treat.
Finally, after 33 years!
OK, this makes sense now. I remember a crude "Action Replay Cart" that involved putting a paperclip between pins 1 and 3 on the cartridge port to jump back to the basic prompt to start entering poke commands for infinite lives. I imagine the ,1 was required to ensure the memory addresses were correct for each game when entering the poke address.
Bringing back the memories... of memory :) we got ours when I was 10. I remember making the kids at school jealous because I printed out my time tables homework.
Well explained.
It is nice that you like MoM as much, as I do. This brings back childhood memories. I think, this was the first game where I really "invested" systematic and serious gameplay to reach the end. Awesome game, really.
Man, I even love how you handle the DIskdrive with your hand. Your videos are just pure attention-to-detail gold. :)
this brings back memories i started on c64 father the vic 20
Very useful info. I always used ,8,1 unless the game had explicit instructions to do otherwise, often on the floppy label itself.
When I was a kid, I got my cousins old C64 and the only instructions he gave my was 'Use LOAD"*",8,1'
It took me quite a while to get anything to run as I didn't know English at the time, knew nothing about computers and was like 6 years old :D
Autoduel would be one reason I'd like a working C64 for. Was such a fun game.
12:28 oh, so THAT’S why LOAD “$”,8,1 messes up the screen!
After 35 years I finally understand what I used to practice all the time.
I knew the basics of this, but one thing I always wondered was how most programs in assembly seemed to have BOTH machine language and BASIC even if it's just a SYS command. I thought that it was loading the program into 2 separate locations. I didn't think it would be all together like that. Interesting video and nice to know. Definitely answers some questions. I suppose you could always have a separate BASIC loader that loads the ML program separately and then SYSes it afterwords. You could even do that with gravitron. It would still be smaller and faster than the POKE version even with 2 separate files.
I have used this a lot when I was a teenager without knowing why I had to used those numbers :)
This is the most niche video I've seen in 2021.
There's a simple explanation why Ultima loads from the last file: Because "Ultima" means "last" in spanish!!! 🤣
Maybe they just overlooked the file position or it was pure laziness of Lord British. ;D
The seven people who disliked video this are clearly TI-99/4A users.
I learned to code on my Dad's TRS-80 L-II as a freshman. I continued coding on the TI as my graduation gift at the beginning of my senior year before buying the C128 in '85 with my Kmart money. In retrospect I wish I had bought an Amiga instead but was scared to learn C at that time.
Awesome, I always wondered how it was that machine language programs could auto load it was like voodoo magic back in the day!
Same here man! Magic is cool lol.
Working in IT I still jokingly say, "Have you tried Load "*",8,1?" when someone is having trouble booting a system up. It's a good age test, those over 45 laugh and nod and those under 45 just give a blank quizzical stare, I've even had a few of the younger IT folks actually take me seriously and try it, just assuming it's some special function.
Mind blown! Awesome video. Thank you.
Growing up my dad got an extra disk drive so I got used to using both ,8 and ,9
Never understood what ,1 indicated, just knew that sometimes you needed it and sometimes you didn’t.
FINALLY! Been wondering about that since 1990!
Imagine being the programmer that 8008ed with that 0800 address error... a 30 year old mistake and ppl find out about it, because plague!
I have never known, nor experienced the "last file you loaded" thing.
When I was little, I had several hundred of floppy discs, and I had several games that after loading ,8,1 it would just return to READY. after it seemingly had loaded the game. Typing RUN did nothing and I never know why this happened. It does seem the game was loaded but didn't run.
Ahh... the sound of the guitar at the end of the video (before vocals) flashed me back to Goddo's Sweet thing!!
I do hear a similarity in the guitar tone!
Have you ever done a video on editing the disk directory? Undeleting, change a file to locked, animation in the filenames, etc?
He’s done an animation directory video before I don’t know the link off hand but you can find it if you search for it.
Here you go. m.ua-cam.com/video/HVMjLUhOX90/v-deo.html
I could probably make a more focused video about disk directory editing but the animated disk directory episode that Fit Fogey linked to gets into it. And I think I touched on locking files and maybe some other aspects in the Epyx Fast Load video too.
Another great video imo.
Now I can try some of my discs (that I thought were corrupted) again.
I remember doing a load”*”,8,1:RUN (or something like that) which was added to the end by hitting shift Ctrl/brk or something like that. I believe (gosh it’s been decades since I last touched a C64/C128) it was simply a shortcut to auto run after it was done loading.
As someone who has never touched a C64, this is still invaluable computer history content. Your videos are better than any college lecture I've had!
Yeah, he did all this without telling you it is OK to be a non-binary fluid spirit.
@@billkeithchannel which is a positive
Thanks, it was interesting.
Love your clips. You are awesome
Thank You! 👍😊
I never understood the difference until now. I always used, 8,1. I remember my diskdrive wouldn't load anything for some reason and I thought the drive was dead until I had a friend over who typed ,8 and the drive starting to work again. Now I finally get it.
Omg what a flash of nostalgy this video gave. I loved my C64, those were so exciting times. I just wish information was more readily available back then,. Books were expensive as hell and 99% of time buggy and outdated.
Great video. Very informative. Thank you very much.
When I was a beginner assembly language programmer on the CoCo2/3, there was a lot of encouragement to use position independent code (PIC). The compilers for OS-9 defaulted to op codes favoring relative addressing though absolute addressing was still available. While it's possible for PIC on the 6502, I'm not entirely sure how feasible it is to implement. I'm reminded of this as you're talking about changing where in memory a file gets loaded. I'm also thinking of raising that discussion in the Commander X16 forums though I fear development and standards are all but completely set. It's funny that Commander X16 is "not a Commodore clone" and yet they do too much commodore-like to avoid the notion.
Not only did 1541s come preconfigured as 8, but all other Commodore 8-bit drives, like the 4040-based series, the 1001, 1571, 1581, etc. And I don't think I've ever seen any other brand of drives made for this computer come preset to between 9-11, either.
I had no idea I didn't know so much about this.
Might it be interesting to make a video about viruses on the C64? I never got one back in the days but I heard that there have been some.
I remember as a kid listing a loaded game loader and wondering at the "A = A + 1: IF A = 1 THEN A = 2, etc" and what it did. An article in Compute's Gazette explained this and now so have you!. Thanks for the memories. Can you explain how directory blocks can be faked? That is, sometimes when you list a directory from a game it will say that all 664 blocks are free, etc.
"what are you wearing?"
"nothing but my clothes."
Great video as always Robin. Too funny about Fast Hack 'em. They couldn't possibly have expected people *not* to pirate probably the most widely used pirating program, lol.
Greta video!. I vaguely remember the use of the "&" sign in loading or used some how in dish commands. Are you familiar with it's use? thanks again.
LOAD... along with PRINT, the C64 most used commands ever ! 😎
What about tape loading ? In some tape games, the combination of keys works while the LOAD and then RUN command does not work. Thanks for these great memories!
FYI CBM basic programs exist in memory as as linked list:
next line address (2 bytes), line number (2 bytes), and then the tokenized line.
End of program is indicated by a next line address of $0000.
When you load with ,8 BASIC actually steps through the list and rewrites the next line addresses until it hits a $0000, but it continues loading until EOF.
I have seen some BASIC programs "protected" by a line that has been edited to link to itself. Trying to list (or load with ,8) will loop forever.
I never worked with a Commodore 64, because I had a TRS-80 Model I. It looks like the "8,1" option is for machine language programs. In TRS-80 DOS, you load machine language programs in DOS, and BASIC programs can only be loaded inside the BASIC interpreter. It looks like the Commodore 64 has one loader that works for everything by just loading code into BASIC by default, or somewhere else with the ",1" option for machine language programs. TRS-80 programs had extensions so that you could know whether a program was BASIC or machine language, much like MS-DOS or Windows.
i was actually looking for the answer to this a month or so ago
Ah yes. Autoloading. Also autobooting. Something the C128 supports. Back in the days, I used to make autobootable C64 stuff. Would only work on the C128, though, as the C64 does not support autobooting from floppies.
Basically... make a C128 autoboot program, which with a bit of magic, places a nice payload, then goes to C64 mode... with that magic payload, it then loads the targetted C64 program, that either is autostarting or not.
I know there was some magic header on the floppy somewhere, that the C128 looked for during startup. Don't remember what exactly. That would cause the C128 to load a designated program, which if using the autostart tricks would automatically start.
I also know there was a way to have a C128 program go into C64 mode, only to continue running there. I think it was done by preparing suitable locations in memory, probably just like an autostart program. Would work, as the memory wouldn't be cleared when going from C128 mode to C64 mode.
Another thing that's interesting about this is that in more modern computers since this, overlapping with Commodore's other 8-bit computers like the 128, though -- but basically all computers from all DOS-based and then 16-bit ones forward, have auto-run as the standard, and it doesn't seem weird to us at all. It only seemed weird to me on Commodores because when I started with Commodore I wasn't immediately presented with autorunners. I was used to manually running. But once my parents got our first Mac and I saw _every_ software autorun when you started to load it, that wasn't so odd on there. I wonder if DOS, Amiga, Atari ST, Mac, and Windows all use the same principle as the auto-run (what was then a "trick") on these 8-bit Commies.
That Ultima III disk was clearly written by some program which didn't understand too much of the standard 1541 sector layout. The files seem to have a sector interleave of 1, not the standard of 11. And the first file to load doesn't start on track 17 but track 1.
You should make a video about sector interleave and the standard track order for writes on 1541, explaining how it is optimized for load time with a stock C64 and 1541. And how using a fast loader a smaller sector interleave would be beneficial.