"Quad density" was an informal name, so-called because it stored at least four times as much as most early 5¼-inch disk formats (720K or higher vs. 180K or lower). In reality it was still only double-density, but used twice as many tracks per inch (96 tpi vs. 48) and both sides of the disk. You were supposed to use special disks rated at 96 tpi, but eventually floppy disk media became good enough that you could reliably store it on disks only rated for 48 tpi (such as the IBM PC 360K format).
Yeah, I never had a problem using DS/DD disks in my SFD-1001 back in the day. Of course, I didn't get my SFD-1001 until 1985 -- by then, as you said, floppy-disk quality had improved to the point where a DS/DD disk was good enough.
The 8050 disk mechanisms, for those who are wondering, are Micropolis. They designed a 100 tracks-per-inch standard, which was very short lived, and was ultimately supplanted by a 96tpi (because disk drive manufacturers could easily re-tool between 48tpi and 96tpi mechanisms, with a minimal change to the stepper motor). Both Micropolis and Tandon made 100tpi mechanisms (Tandon suffixed their 100tpi drives as M, so TM100-4 was 96tpi Shugart, versus TM100-4M which was the Micropolis 100tpi variant). The 4040 used fairly standard Shugart SA-400 mechanisms (Shugart actually labeled these as SA-390, which lacked the analog board, Commodore supplied their own.)
I cover a lot of stuff in this episode, so here's an index. Also, a correction: Apparently drive 0 *is* on the right in the dual drives from the factory! So someone just swapped the labels/face plates, not the drive mechs. Also, I totally forgot that in BASIC 4.0 you can just PRINT DS$ to get the disk status, rather than typing in that 4 line program. D'oh! 0:00 Family Photo: all my C= Floppy Disk Drives 1:10 The two interfaces: Parallel IEEE-488 and Serial IEC - as seen on the MSD SD-2 3:45 Commodore's IEEE-488 cables 4:48 PET 4032, and opening a new box of DSDD 5.25" disks 5:56 Formatting a disk in the CBM Model 4040 disk drive 7:41 Reading the command channel - Everything's OK 9:05 CBM DOS V2 - the DOS is in the drive, not in the PET 9:44 Labelling a disk! 10:20 CBM Model 8050 - 520K per disk side, NOT high-density! 13:09 Formatting with the HEADER command 14:12 CATALOG and how the 1541 was a regression due to $$ 15:01 Inside the 4040 - two processors including a 6504! 16:48 Inside the 8050 - DUAL 6502s 17:47 The SFD 1001 20:13 4133 blocks free: Successfully formatting a SFD 1001 disk 21:48 Commodore 2031 and 2031LP 22:43 Stacking Drives: The TPUG Locker 23:14 4040 to 2031LP to 1541 lineage 24:25 Thank you to my patrons: patreon.com/8BitShowAndTell 24:45 I'll cover the IEC (serial) drives such as the 1541 in another episode
I worked for KAO in Arnprior, Ontario were those floppy disks were no doubt manufactured. Good times. It’s pronounced more like “cow” and means face in Japanese.
The irony of the C64 moving from the 6522 to the 6526 was that they wanted to keep compatibility with the 1540 drive of the VIC-20, but a new problem crept in with the VIC-II chip requiring an additional slowdown of the data transfer from the drive to the computer. This made the 1540 incompatible with the C64 unless you sent a command to the disk drive to slow the data transfer down. EPYX, (among others), solved the throughput problem with their FAST-LOAD cartridge, but it wasn't 100 percent compatible with all the copy-protected game software that was available at the time. In the end, the C64 using the 6526 and 1541 transfer data more slowly between themselves than the VIC-20 using the 6522 and the 1540. While there are mods that work around the data transfer rate issue, not everyone uses them.
None of the drives besides the original 1541 and the 2031lp are brown, they are very light beige. Of course the plastic yellows over time if exposed to direct sunlight.
@@csbruce no, all they knew was that it didn't work. You can get a version of the chip that was fixed about 25 years ago by Western Design Center. www.westerndesigncenter.com/wdc/w65c22-chip.cfm
Lol, in high school I used to change the drive ID of one the 4040/8050 units so I had exclusive access in a IEEE network of PETs. Loved those behemoths. Thanks for the look inside and all the technical details!
I absolutly love this channel. I was born in 1991 and my parents had a C128D. My older brothers were more into Gaming when i grew up. Some day i discovered the manual with a full documentation of both Basic versions. So i started coding all by myself and the manual. Must be at the age of 9 or 10. Now working as PHP Developer/it admin. Greetings from Germany
Never head about the 8050 able to store about 512kB on a SD floppy, by using 80 tracks instead of 40. In the late 80's I had a program named "VGA COPY" for the PC, able to make special formats. One on the was 1.72 MB on a standard 1.44 MB, this special format was used by Microsoft when then distributed the first version of Win95. The one I liked to use was formatting SD floppies (360kB under MS-DOS) with 80 tracks and 720kB (the same as single density 3-1/2 floppies). This was convenient and very reliable. I can see my idea was used years before by Commodore and I didn't even know it.
It wasn't just Commodore - QD was a thing in general, but I guess IBM was a bit worried about reliability in '81 and went with 40 track. QD drives were quite popular in the eastern block for Z-80 based computers in the late 80s - early 90s.
Wow! A COMSPEC relic made its way to Thunder Bay! Comspec was a Commodore computer store in Toronto, ON. For most of my friends, getting there was always an adventure: 45-60 minute subway ride to Wilson station, followed up by a 20-30 minute bus ride! They had some great stuff in stock: bought my 1351 mouse from them as well as a Pascal and C compiler for the C64. I think I still have a mouse pad from Compsec!
@@8_Bit: There were two locations, the one on Wilson being the main software/hardware sales store. I found a photo of my Compsec mousepad I took a few years ago: imgur.com/a/A4r86b6. I think my parents still use it as their mouse pad today.
It turns out Comspec is a lot more popular than I thought! I currently live in Washington state USA and met a person from the local C= user group with a bunch of Compsec-branded Amiga hardware. It is really strange to see that logo outside of Toronto, but understandable given the collector market.
I went from using the cassette tape to the MSD2, which I bought in Toronto in the early 80s, most likely at Paperclip, on Queen St. I used it with an IEEE488 parallel card on my C64, and it worked great for everything, except for copying some protected disks. I was a member of TPUG, and regret, never being in town on a day where I could attend a meeting.
I didn't realize most of those disk commands were built-in. I never figured out how to format a disk on my C64 until I got a copy of the 1541's owners manual (that's all long gone now), but in the appendix there was a program for initializing disks. Like it had for loops that zeroed out blocks and everything and even wrote out the header (byte for byte IIRC) and you could take any random 5.25" disk and turn it into a Commodore disk! (obviously the initialization and header commands you showed today are much faster but I didn't know them). I ended up saving that program to the first disk I formatted with it. (making sure never to load it and run it on that disk by accident). It's also how I found out about the "$" program (never learned catalog). Wish I had access to this channel back in the 90s! 🙂
We used these pets for cad design at college in the late 80s, at the start of each lesson we would have to open up the hood of the disk drives and clean the heads. I cannot remember what the cad program was called, but there was no mouse, you had to key in commands to generate the drawings. If you keyed in a command that was out of range the program jumped back to the basic Ready prompt and you lost everything!
@ungratefulmetalpansy I do remember that if you poked memory at around 32768 and above you got to write over the screen memory and it was a bitmap not character based like the C64 1k screen ram. or did I dream that!? Nope I a sure I am correct.
@ungratefulmetalpansy Yes I just had a look on the web and you re right, umm I can only guess that they had some sort of add on board for bitmap mode and I never realised.
There were a surprising number of add-on graphics boards for the Commodore PET, so it's quite possible that's what the college had for the CAD course. They probably invested a lot of money in those systems in the early 1980s and didn't have the budget to upgrade that decade. Here's a great page about those add-ons by Steve Gray, the same guy I mention in this episode: www.6502.org/users/sjgray/computer/petgraphics/index.html
@@8_Bit Gosh there are hundreds of themon that site! no idea which we had, I am sure it was running from boot up as I remember poke(ing) around and I found I could overwrite the screen ram like a bitmap. I did it from basic after the machine had been switched on and I clearly remember writing over the boot up text (basic bytes free text) but like i was going over it in bitmap mode not character mode. So the card must have remaped the PETs char mode into the bitmap mode on startup, if you see what I mean. Thanks for the interesting Videos (from Nottingham UK.)
Heh, I've also stuck to using 15 in drive commands. Probably because I saw it in a manual somewhere and kept using it out of habit. And the lazy typist in me loves the shortcuts for disk commands, but also I've noticed that not a lot of people remember that CBM DOS has the asterisk wildcard character... if you wanted to load KOALA.PRG from your disk, you just type LOAD "K*",8 and you're in business.
You are the master. I kneel before you almighty one. Thank you for sharing your in-depth knowledge on these old but still loved machines. I love the way you present , you are easy to follow. Even though I used Pets at school, had a Vic 20 and a C64, you have forgotten more than I ever knew about the systems. I still have my C64 and would love a Pet, those clear green screens bring back such fond memories and I can almost smell the machines when I see that font. keep up the good work. Thumbs up.
@ungratefulmetalpansy Completely agree. 1551 had such a complex communication, it made it very slow. They could just realize IEEE protocol on same 8 bit paralellel bits. But nope, they created a new one... In fact 151 only 2.4x faster on a 8 bit wider data line. Epic! :-D The idea of implementing Dolphin DOS never came up in my mind, just the C128's and 1571's Fast mode, just created 1.5 years later... In fact I could not find a single bit of information how much faster was the C128's Fast protocol VS normal IEC. (also not about burst mode, or a benchmark JiffyDOS VS Fast protocol or Burst mode). Strange. Maybe they could not sell JiffyDOS, if it would turn out that the C128 is faster by default? Just thinking.
I noticed that immediately as my first generation NEC Multisync monitor has that same sticker on the back. Can you imagine these days being a manufacturer or importer and having to get electronics you want to sell approved by the provincial / state electricity company?
Fun fact: the Commodore implementation of the IEEE-488 bus was so slow it was reliable over a long distance. I recall someone getting it to work through a 50 foot ribbon cable.
In high school I worked at a computer store in Ottawa that sold KAO Didak disks by the truck load. Somehow we were invited to visit the plant. I and a few coworkers went.
Yeah, KAO's history is interesting. Before the 1980s, they primarily made cosmetics, and branched out in the 1980s to do floppy disks, they actually were very good.
tschak909 KAO disks were very high quality. I have some that are over 30 years old and still work with programs I wrote in the 80s. Many of my old disks are bad but none are KAO.
Damn, those are some cool drives. I wish the IEC serial was faster by default, but oh well. If I had way too much money I'd buy a PET, or UK/IE equivalent. I'd almost need to redo my whole bedroom to fit it though.
21:05 The keyboard was really *easy* to get used to for people who started out on the original PET with the chiclet keyboard. The keyboard shown here has full-size keys, which is of course an improvement over the small chiclet keys, but the weird arrangement meant that all the graphics characters were in the same positions as on the original machine, which made them easy to find. I loved this layout back in the day!
I can assure you that the behavior of your SFD is totally normal for single sided disks. It's the same as with the 8250(lp). The first access tries reading the disk as double sided, results in an error and the drive switches to single-sided mode. Then the next access will succeed. Also, the older low capacity drives like the 2040 don't automatically detect disk changes, you had to reinitialize the drive manually. And yes, the plastic case drives are pretty susceptible to EMF. I guess one of the reasons why today you shouldn't stack them is because the plasticizer might leech out of the rubber feet and deform and imprint the top of the bottom drive. Back then, I guess, it was mainly heat and EMF.
Nice. I have not seem a pair of pets in the wild for over 25 years and never the large size full height floppy boxes. I do love how they use a flat card edge connector that should have just been a standard 488. But then again I assume since it is part of the board design that it was cheaper. I also leave vintage stuff on items. Shows the history. I also collect records / Laser Discs and leave period correct labels on them including if they came from a rental store.
5:38 I remember distinctly that the 8050 drive at my school in 1980 also had drive 0 on the right so I think that was the way they came out of the factory. Notice that the 8050 (and the 8250 double-sided version) also had almost 3 times the capacity per diskette of the IBM PC: about a megabyte per disk, on the same type of diskette! When my school got an IBM PC I was pretty disappointed about that. Not to mention the stupid PC keyboard on which you had to use the Shift key to type all the important BASIC symbols such as " and $.
The 8050 used 77 tracks instead of the PC's 40, and Commodore used variable bitrates with GCR encoding (8 data bits = 10 disk bits) to cram every possible bit onto each track, while the PCs used a fixed number of sectors per track, limited by the innermost track with the shortest linear length, and used MFM encoding (8 data bits = 16 disk bits).
Thanks, I've now done the research I should have done beforehand, and yes, drive 0 is on the right from the factory. So I should swap those faceplates around now, that should be simpler than swapping the drive mechs :)
@@8_Bit I think the face plates are attached to the mechs, not the case. So you probably have to take the mechs out to swap the face plates. Either way, you could just leave it like it is, just like you did with all the other modified hardware and stickers and stuff.
Had a Vic-20 but never managed to get a disk drive. That would have been pretty incredible. Could have stored every single little game and song I ever programmed onto a single disk. But had to make do with a tape drive (to which I lost at least 25% of everything I recorded, due to bad tapes) and a mini-printer that printed on receipt-like paper. Still have several printouts of Basic games from that.
A nice demonstration to show that these drives are actually independent computers in their own right would be to use a later version of Fast Hack'em disk copying software from Basement Boys Software. It loads into two 1541 drives chained together and turns them into a disk duplication system which no longer requires being connected to the computer to work. So long as they don't get power cycled, you can just keep feeding it disks to copy and hook another drive back onto the computer.
Great video Robin. Had no idea there was so many variations of commodore drives, and it's pretty impressive how much data could be stored on those DD disks. Cheers
I ran a C64 BBS back in the 80's. I had the MSD2, 1541, SFD1001, CPM8050 and a CPM D9060 (Hard Drive). the SFD's ran hot and I used some 3rd party exhaust fans to keep them cool. I used the MSD2 as a personal copy machine with my portable C64 think it was called a SX64.
Great video as usual, Robin. I grew up with a C64 and 1541. Thanks for the PET drives education. I had no idea the PET drives were faster and had a higher capacity than the C64 drives. That kind of stinks for us C64 guys. Also, I knew they added the "CATALOG" command for the C128, but had no idea the PET had it as well. I wonder why they left it out of the C64. Looking forward to part two.
PET BASIC 4.0 with disk commands took twice the ROM space, I believe, which would have increased production cost.The C64 was much more a mass-market machine where every dollar counted, while some later PETs (the CBM 8000 series that high-density drives like the 8050 were meant for) were moderately high-end microcomputers for their day, intended for business use with 80-column video, etc. and quite expensive. Time pressure during development must have been a factor also - C64's BASIC ROM was nearly a direct copy of the VIC-20's, where disk drives were rarely used, and its custom chips (VIC-II, SID) were first introduced in the Commodore Max Machine (Ultimax), basically a game console with only a few K of internal RAM, no internal BASIC (had to use a cartridge) and an awful membrane keyboard. That was only sold in Japan, and didn't last long.
@@8_Bit Yup, the one that was located in Dresden. Drive is up and running now after exhanging the EPROMs and 2 SRAMs. Tested on my friends CBM610 and C64 with IEEE Interface.
Haa! I own a MDS SD-1 you do not have! :-) Seriously: a very nice collection! My SFD-1001 just died few month ago, and really hard to get someone to repairt it.
I used it on a few old keyboards and it didn't get yellow in the last 2 years and the plastic also did not get brittle- but keyboards mostly have a very thick plastic to begin with and may be more resilient.
I still have lightly used SFD-1001 from running a BBS back in the 80's, with an Skyles Works Quicksilver-128 IEEE adapter/cable. I was shocked to see an SFD-1001 on E*bay asking for over $1,000usd with an original Commodore IEEE adapter/cable. While it's rare, don't think it worth that much.
Great video. Very interesting. I'd read that leaving the slow drive interface on the C64 was to do with time constraints, and they wanted to release it quickly. I love that scrolling credits program.
Did I ever say that i love this channel, I do ... :-) - And regarding floppy drives, if anyone ever needs an VIC-Switch I have one in the attic you can have :-)
Three cheers for CMD JiffyDOS and the included wedge! I HATED slow drive throughputs, and hated even more having to load disk directories into memory like a program.
It wouild be an interesting hack to turn a Commdore drive into a full blown computer that you plug a video terminal into, or by using a terminal emulator in a Commodore computer.
Look up the freespin demo. They made the 1541 drive composite video out through the serial cable and make music with the drive stepper motor. It's seriously impressive
Something I would’ve liked to see is a VIC 20 using one of these PET drives via a VIC-1112 IEEE 488 interface cartridge. I’m sure it’s nothing special but just seeing it in action would’ve been great.
I had the SFD1001 with an IEEE-488 adapter with my Commodore 64. Unfortunately, I was involved with a music band that I left suddenly - never wanting to return. The SFD1001 probably sat on the floor of his spare shed, near the beach... So, I suspect that it rusted to dust...
@@8_Bit It's a chubby boy for sure with that full height Shugart mech with the garage door latch. It's quite an odd mechanism, it uses a cam follower to move the head instead of the usual metal belt on a pulley. I did know about the 2031LP but I didn't know C= also made one with the VIC-1540-style nameplate. I think the chunky 2031s are rare now.
@@8BitNaptime Yes, it might be the most rare of the three drives, but they're all pretty rare now: 1540, 2031LP, and original (chunky metal) 2031. 1540 seems to turn up most often on eBay, but it goes for pretty big money when it does.
@8-Bit Show And Tell I am very surprised no one has found a Mini Chief drive for the C64. It was a drive/kit that converted a 1571 to have a 20 or 40MB Mini-Scribe drive in it. The 1571 as a floppy still worked too. I knew a old friend when I lived in Ottawa, ON who had one back in the day, it was amazing. It could create x number of 644 byte drives (can't remember how many) or be set to use all 20MB (in his case) as one drive. I am guessing the Mini-Scribes died and people probably just tossed them.
I've heard of that drive but have never seen one in person. There were a number of interesting early hard drive solutions that are extremely rare nowadays as presumably very few units were sold. The only one I have is the CMD HD which was relatively common.
0:10 I've had most of those drives, but what the heck is that weird dual-drive thing on the top right? 2:17 Apparently, the bug in the VIA's shift register is pretty easy to fix with an extra logic gate or two. I don't know if they knew this at the time. 2:28 While the CIA's shift register didn't have this bug, the VIA used in the 1541 still did, so they couldn't fix the problem without overcoming the VIA's bug. Also, the C64 with its BASIC 2.0 and carbon copy of the VIC-20's ROMs seems like it was mostly slapped together by taking a VIC-20 and sticking some new I/O chips in it. Upgrading the serial bus with backward compatibility like they did with the C128 would have been a big job. 3:23 It seems a bit wasteful that it has so many wires with a bunch of twisted-pair grounds for the control signals. Was noise on these lines really a big problem? I don't even see a special ground for the data lines. 5:12 I'm more of a Victorinox guy, myself. 6:06 I normally use Logical File Number 1 since my first storage device was a cassette drive. 8:00 PRINT DS$ 8:14 They waste a space at the front of each line when listing on a 40-column screen. Did they believe that the indentation made it easier to read when lines wrapped? 13:52 They also accept the DIRECTORY command, abbreviated "diR". 14:39 There was also an 8250 drive which was double-sided and could store over 1 MB per disk. 21:06 That is so weird that the 4032 didn't have numbers on its top row of keys. Every other keyboard had that, including the 8032. 23:03 It's not the stacking that damages the drives; it's the overheating from the lack of ventilation when they're turned on.
That weird drive in the top right corner is a Dual CMD FD-2000. As far as I know, only three were made. This one was used for Loadstar's (monthly disk magazine) 3.5" duplication needs from the mid-late '90s until the early 2000s, I believe. Ugh, I can't believe I forgot about DS$!
@@8_Bit: I was hoping that your early-access Patreon videos got promoted to public viewing since that would give me a crack at FRIST POST!!!1!, but sadly, this appears to be a separately-posted video.
@@csbruce Sometimes I do change the early-access video from unlisted to public, but other times I find extra things to tweak in the final video render that goes public. Thanks for your support, and if you keep trying I'm sure you'll get FRIST POST!!!1! eventually :)
I have a Commodore 1702 monitor with the same "COMSPEC" label on it. I think I picked it up near Toronto. I infer that this was a chain of computer stores in southern Ontario in the 1980s but haven't been able to find any more information on them.
I regret giving away a bunch of my Commodore stuff in the late 90s, when I needed to make space when I moved. Given how cheap all this stuff was in thrift stores at the time I figured I'd be able to replace it easily enough. Oh, how mistaken was I. More than the hardware, though, I really regret also including all of my floppies in that; most of it was pirated games but I had a bunch of stuff I'd made, including music and my earliest games. That stuff's irreplaceable.
I would also like to have seen an HD, DS dual 5.25" drive, like if the 1572 had come to light, or even if they had made a "1592" (3.5") or something like that. I also didn't know, or at least remember, that the 1001 is DS, until now!
You are using a lot of post-production digital zoom. No problem with that, but have you considered a 4K camera? Those zoomed parts would look much nicer with it. I'm actually watching this on a 17" CRT monitor, though :-) , so 4K is redundant for me at this moment, but the zoomed parts still look blurry and noisy on my current setup. (edit: typo corrections)
Thanks, I did shoot in 4K for this video (usually I don't) but just on my phone which is all I have currently. I'll look into a proper camera especially if I keep making videos like this one, with more need for close-ups.
I 'inherited' a perfectly cared for, working 8050 in the late 80's, along with an Interpod adapter to make it work with a C64. Yea, I tore it apart in the 90's. :( Incidentally, the hardware inside the 8050 is as robust as any 3D printer today. The mechanism isn't really much different.
Just got my 4016 up and running, had to replace the video ram. have the old style 2031 disk drive in the metal box, and the external cassette player. there is something wrong with the cassette which is not surprising as it has spent the last 20 years in the garage loft. but i can't find my PET 488 lead so have not been able to try the disk drive out. looking at making a SD2pet unit as something to do during lockdown if i can get the parts.
i absolutely loved this video! thanks so much! i wish you had explained the syntax of the commands a bit more. for example, when you said the first number was 15 but could be anything, what is that number for in the first place? thanks! btw, i think the drives look perfectly fine without retrobrighting, but then i wouldn't mind either way! :) oh... i was wondering... why do you have to put the disk in to see the DOS version that's stored on the disk /drive/? i thought the dos version is in the drive rom whether or not the disk is present? thank you!!
The problem is it would take another video just to explain it. The very short explanation is: OPEN file#, device#, channel# *file#* = any number from 1 to 127. and allows the program/user to have several files open at once - random access data base ("relative files") usually opened multiple files at one time. This was called a "logical file number" and was basically how C=64 "remembered" which file was which. *device#* : 0 = Keyboard;1 = Tape; 2 = RS-232; 3 = Screen; 4 = Printer; 5 = (alt)Printer; 6 = Plotter; 7 = (?reserved?); 8 = Disk Drive; 9,10,11 = (alt) Disk Drive (10 and 11 usually had to be implemented through DIP switches on the drive's PC board or through commands sent to the drive's OS) *channel#* = varied from one device to the next, but in the disk drive channel 0 and 1 are used internally to address the directory, although ch 1 can be used to "read only" a sequential file. Channel 2 through 14 are used to send and read data to open files. Channel 15 is strictly used to send commands to the DOS and read status flags from the DOS. (not exactly true, but data sent on channel 15 is for advanced DOS programming) In the format of OPEN 15,8,15,"xxxx" the file number (first number) was simply a programmers way to separate/remember this was the command channel. It could be any number but could get confusing with several open files especially if you were working in direct mode. Technically speaking the second and third numbers are an "Attention, address" header bytes sent on the serial bus.
@@3DPDK wrote «varied from one device to the next, but in the disk drive channel 0 and 1 are used internally to address the directory». I thought 0 and 1 were used for special LOAD and SAVE access.
@@csbruce I think what you are thinking is "LOAD "filename",8,1 The '8' of course indicates the disk drive. If '1' is included in the command it flags the C=64 to load the program to the memory address indicated by the first two bytes in the file on the disk or tape. An ML program that resides at (say) 49152 has the first two bytes of the file set to $C000, or #00 - #192.(lo byte-hi byte) Without the '1' the C=64 automatically ignores the first two bytes and loads the program beginning at 2048 or BASIC program memory. SAVE "filename",8,1 is the opposite. Without the '1' C=64 automatically writes the 2048 load start location. SAVE"filename",8,1 will wright the address indicated by the value held at memory locations 172 - 173 which usually point to 2048. By temporarily setting this to another memory location and setting a few other pointers, this command format can be used to save screens, ML programs in upper memory or anywhere, basically a memory "snap-shot". SAVE or LOAD "filename",8,0 is the same as LOAD "filename",8 (no second number) - the second number is simply a flag and is either a zero or non zero value - LOAD"filename",8,2 does exactly the same as LOAD"filename",8,1 However, none of this has anything to do with the communication channel set in the OPEN command between the computer and the external device.
@@3DPDK: A quick look at the ROM listings shows that the secondary "number" given for a LOAD operation and the secondary address sent over the serial bus are distinct. A secondary "number" of 0 is a relocating load and 1, a non-relocating load. There are a number of different ROM listings online (and each is broken in a different way!). The one at github.com/mist64/c64rom/blob/master/kernal/load.s shows on line 43, "lda #$60 ;special load command", meaning that secondary address sent to the serial device for a load is always $60, regardless of the secondary "number" taken from the user. The upper nybble identifies the serial-bus command (accept the secondary address) and the lower nybble identifies the disk-controller channel, with 0 indicating the special LOAD channel. Technically, you're correct in that the directory is retrieved using a LOAD operation, but so is every program. Similarly, the "save.s" file shows "lda #$61 : sta sa", which accesses disk-controller channel "1", which is dedicated to the special SAVE operation.
It is so strange that these diskdrives get into trouble when placed to close to other antiques. Remarkable how easily they get confused, it can't be the speed or the pressure of having to do the work accurately. Working with sign flags is almost as quick.
I'm wondering if Commodore used single-density disks out of spec with so many tracks (and sectors per track)? If so, did they rely on the disks being better than specified? At least the manual you've shown only demands single-density disks for the 8050 having 77 tracks. Or did the DOS include some kind of low-density backwards-compatible format for the use of single-density disks?
Someone asked me about redirecting the PRINT command to memory to print sound effects or sprites etc. I forget where they asked so I'll post more of what I found out here. I done more digging and found my old notes, combined with some information on the C64 registers and memory maps. Here's how you do it and why... Lets say you wish to set the SID chip to play a sound. The SID chip is at location $D400/54272. The low byte for that address is 0, the high byte for that is 212 ($D4 hex). So you POKE 209 with the low byte (POKE 209,0) and you POKE 210 with the high byte (POKE 210,212). 209 and 210 are pointer to current line in screen memory and you can set that to any address at all. But you also have to set the current column the cursor is on to zero so it starts at the beginning of that memory location. That is set with POKE 211,0. Once you do all these POKEs, the next PRINT/? command will print to that memory location whatever you wish. So if you just wanted to clear the SID chip, you would print 25 @'s (@ equals zero on the C64) and it would be clear, like this: POKE209,0:POKE210,212:POKE211,0:?"@@@@@@@@@@@@@@@@@@@@@@@@@"; (I'm not sure if the semicolon was important here or not) This would clear the SID chip. The first @ is at location 54272 (hex D400), the start of the SID chip. You can change each @ to whatever number you wish to place in that memory location and you can literally PRINT a sound effect. I used to have a fun C64 BASIC program where you had a menu and selected a sound effect and it would play it. When you looked at the source code the above line is ALL you seen for each sound effect (just the @'s were changed for the values of course). Same deal with sprites. Point it to sprite memory and print a sprite out. Or moving ANY DATA you wish! This can eliminate loops that read and poke data completely! Just point to the memory and print it all there in one shot. Very powerful trick.
Hey, did you ever consider doing a "Introduction to Assembly Language". Use a simple CPU like the 6502, or 6008? Heck, if you sold them as videos on a thumb drive, I'd buy the set.
Huh! I didn't even know that the 1541 is single-density and that the quads were already out before it until I heard of the SFD-1001 8 years after we got a '41! (And even then, the friend showing it to me didn't make it clear that that was still for the PET.) It's unfortunate that the first 15-series drive was so crippled in the name of CR that it was just SD even though there were already DD and QD drives out there, but Commodore didn't think enough people would want to buy those for the 64. I wish the 1001 through the user port had been the standard, and it's interesting that the 64 will even recognize a device 8 through that port. That's dumb; I hate back-sliding with newer stuff, like what they did to BASIC before going back to a higher version with the 128. But then the question might have been, "Yeah, but then could your parents have afforded it?" Maybe by the time the 128 came out it was easier to afford better things and keep a low price for the consumers. But overall it seems dumb and counterintuitive to put the weaker peripherals with the generally stronger computers (in the sense of memory size, etc.).
Why does the PET have BASIC V4.0? This is even a newer version of BASIC than on the C16/116 which has V3.5 and came out much later. Is this some kind of homebrew witchcraft?
Commodore's BASIC numbering scheme is really weird. I think the PETs (in different models, and with various ROM upgrades) got V1, V2, and V4. V3.5 seems to be more advanced than V4. I don't know what happened to 3.0, and why the C128 jumped up to V7. Could be an interesting video, but I will need to do a LOT of research for that one :)
2052 blocks on that 5 1/4" disk. It makes me wish the 1581 was HD instead of just SD (haha, those sound like video terms, but they stood for "-density" before they stood for "-definition") because then it could have had around 7320 blocks instead of just 3160 (even though 3160 wasn't bad for then). Dumb to make the 1581 SD when the SFD-1001, etc. were already QD, with the 4133 blocks instead of the '81's.
Neat, I learned a few things.
Hello dave :)
The man, the myth, the legend
@@EpicTyphlosionTV The overrated.
haters gonna hate ;)
@@dovic2293 Fanbois gonna fanboi.
"Quad density" was an informal name, so-called because it stored at least four times as much as most early 5¼-inch disk formats (720K or higher vs. 180K or lower). In reality it was still only double-density, but used twice as many tracks per inch (96 tpi vs. 48) and both sides of the disk. You were supposed to use special disks rated at 96 tpi, but eventually floppy disk media became good enough that you could reliably store it on disks only rated for 48 tpi (such as the IBM PC 360K format).
Yeah, I never had a problem using DS/DD disks in my SFD-1001 back in the day. Of course, I didn't get my SFD-1001 until 1985 -- by then, as you said, floppy-disk quality had improved to the point where a DS/DD disk was good enough.
That's like with the BBC Micro and 40 vs 80 track drives.
The 8050 disk mechanisms, for those who are wondering, are Micropolis. They designed a 100 tracks-per-inch standard, which was very short lived, and was ultimately supplanted by a 96tpi (because disk drive manufacturers could easily re-tool between 48tpi and 96tpi mechanisms, with a minimal change to the stepper motor). Both Micropolis and Tandon made 100tpi mechanisms (Tandon suffixed their 100tpi drives as M, so TM100-4 was 96tpi Shugart, versus TM100-4M which was the Micropolis 100tpi variant).
The 4040 used fairly standard Shugart SA-400 mechanisms (Shugart actually labeled these as SA-390, which lacked the analog board, Commodore supplied their own.)
I cover a lot of stuff in this episode, so here's an index. Also, a correction: Apparently drive 0 *is* on the right in the dual drives from the factory! So someone just swapped the labels/face plates, not the drive mechs. Also, I totally forgot that in BASIC 4.0 you can just PRINT DS$ to get the disk status, rather than typing in that 4 line program. D'oh!
0:00 Family Photo: all my C= Floppy Disk Drives
1:10 The two interfaces: Parallel IEEE-488 and Serial IEC - as seen on the MSD SD-2
3:45 Commodore's IEEE-488 cables
4:48 PET 4032, and opening a new box of DSDD 5.25" disks
5:56 Formatting a disk in the CBM Model 4040 disk drive
7:41 Reading the command channel - Everything's OK
9:05 CBM DOS V2 - the DOS is in the drive, not in the PET
9:44 Labelling a disk!
10:20 CBM Model 8050 - 520K per disk side, NOT high-density!
13:09 Formatting with the HEADER command
14:12 CATALOG and how the 1541 was a regression due to $$
15:01 Inside the 4040 - two processors including a 6504!
16:48 Inside the 8050 - DUAL 6502s
17:47 The SFD 1001
20:13 4133 blocks free: Successfully formatting a SFD 1001 disk
21:48 Commodore 2031 and 2031LP
22:43 Stacking Drives: The TPUG Locker
23:14 4040 to 2031LP to 1541 lineage
24:25 Thank you to my patrons: patreon.com/8BitShowAndTell
24:45 I'll cover the IEC (serial) drives such as the 1541 in another episode
at 25:07 all AvE fans are thinking "Thanks for watching, keep your disk in the drive...."
wow i forgot how loud those keyboards were.
Yes, I thought that drive 0 was on the right too.
I worked for KAO in Arnprior, Ontario were those floppy disks were no doubt manufactured. Good times. It’s pronounced more like “cow” and means face in Japanese.
The irony of the C64 moving from the 6522 to the 6526 was that they wanted to keep compatibility with the 1540 drive of the VIC-20, but a new problem crept in with the VIC-II chip requiring an additional slowdown of the data transfer from the drive to the computer. This made the 1540 incompatible with the C64 unless you sent a command to the disk drive to slow the data transfer down. EPYX, (among others), solved the throughput problem with their FAST-LOAD cartridge, but it wasn't 100 percent compatible with all the copy-protected game software that was available at the time.
In the end, the C64 using the 6526 and 1541 transfer data more slowly between themselves than the VIC-20 using the 6522 and the 1540. While there are mods that work around the data transfer rate issue, not everyone uses them.
Wow did not know that there were such a variety of brown drives just knew the 1541
None of the drives besides the original 1541 and the 2031lp are brown, they are very light beige. Of course the plastic yellows over time if exposed to direct sunlight.
ok I just wanted to say i never knew that 2031 or sfd drives existed, but that video enlightend me...
To fix the famous 6522 bug, all they needed to to was sync up the data line with the CPU clock by using an and gate.
Did they know this at the time?
@@csbruce no, all they knew was that it didn't work. You can get a version of the chip that was fixed about 25 years ago by Western Design Center.
www.westerndesigncenter.com/wdc/w65c22-chip.cfm
Really enjoy your commodore stuff it's what i grew up with in australia
Please make a Jiffydos special sometime, it's so ingenious.
Ah, device vs. drive numbers. The cause of the scary "save with replace" bug that terrorized Commodore owners for years. Great stuff!
Lol, in high school I used to change the drive ID of one the 4040/8050 units so I had exclusive access in a IEEE network of PETs. Loved those behemoths. Thanks for the look inside and all the technical details!
Off topic, but I had forgotten how nice that PET keyboard sounds. Super relaxing video, really takes me back. Thanx!
I absolutly love this channel. I was born in 1991 and my parents had a C128D. My older brothers were more into Gaming when i grew up. Some day i discovered the manual with a full documentation of both Basic versions. So i started coding all by myself and the manual. Must be at the age of 9 or 10.
Now working as PHP Developer/it admin.
Greetings from Germany
At 16:57 looks like two Micropolis drives! Seem to be model 1006-2. Thanks for preserving this old hardware!.
Never head about the 8050 able to store about 512kB on a SD floppy, by using 80 tracks instead of 40. In the late 80's I had a program named "VGA COPY" for the PC, able to make special formats. One on the was 1.72 MB on a standard 1.44 MB, this special format was used by Microsoft when then distributed the first version of Win95. The one I liked to use was formatting SD floppies (360kB under MS-DOS) with 80 tracks and 720kB (the same as single density 3-1/2 floppies). This was convenient and very reliable. I can see my idea was used years before by Commodore and I didn't even know it.
It wasn't just Commodore - QD was a thing in general, but I guess IBM was a bit worried about reliability in '81 and went with 40 track. QD drives were quite popular in the eastern block for Z-80 based computers in the late 80s - early 90s.
Ahhhh. The talking hands, again.. My evening wouldn't be complete without it. 😊
Thank you for showing PET related stuff! Pre-C64 is very interesting
Wow! A COMSPEC relic made its way to Thunder Bay! Comspec was a Commodore computer store in Toronto, ON. For most of my friends, getting there was always an adventure: 45-60 minute subway ride to Wilson station, followed up by a 20-30 minute bus ride! They had some great stuff in stock: bought my 1351 mouse from them as well as a Pascal and C compiler for the C64. I think I still have a mouse pad from Compsec!
I meant to try looking up Comspec but hadn't got around to it yet, thanks for the info! Did they just have a single location?
@@8_Bit: There were two locations, the one on Wilson being the main software/hardware sales store. I found a photo of my Compsec mousepad I took a few years ago: imgur.com/a/A4r86b6. I think my parents still use it as their mouse pad today.
It turns out Comspec is a lot more popular than I thought! I currently live in Washington state USA and met a person from the local C= user group with a bunch of Compsec-branded Amiga hardware. It is really strange to see that logo outside of Toronto, but understandable given the collector market.
I went from using the cassette tape to the MSD2, which I bought in Toronto in the early 80s, most likely at Paperclip, on Queen St. I used it with an IEEE488 parallel card on my C64, and it worked great for everything, except for copying some protected disks. I was a member of TPUG, and regret, never being in town on a day where I could attend a meeting.
I am blown away!!! i had no clue commodore hat so many disk drive models and even high capacity ones :O amazing computer history!!! thanks
I didn't realize most of those disk commands were built-in. I never figured out how to format a disk on my C64 until I got a copy of the 1541's owners manual (that's all long gone now), but in the appendix there was a program for initializing disks. Like it had for loops that zeroed out blocks and everything and even wrote out the header (byte for byte IIRC) and you could take any random 5.25" disk and turn it into a Commodore disk! (obviously the initialization and header commands you showed today are much faster but I didn't know them). I ended up saving that program to the first disk I formatted with it. (making sure never to load it and run it on that disk by accident). It's also how I found out about the "$" program (never learned catalog). Wish I had access to this channel back in the 90s! 🙂
Having a nostalgia attack
We used these pets for cad design at college in the late 80s, at the start of each lesson we would have to open up the hood of the disk drives and clean the heads. I cannot remember what the cad program was called, but there was no mouse, you had to key in commands to generate the drawings. If you keyed in a command that was out of range the program jumped back to the basic Ready prompt and you lost everything!
@ungratefulmetalpansy I do remember that if you poked memory at around 32768 and above you got to write over the screen memory and it was a bitmap not character based like the C64 1k screen ram. or did I dream that!? Nope I a sure I am correct.
@ungratefulmetalpansy Yes I just had a look on the web and you re right, umm I can only guess that they had some sort of add on board for bitmap mode and I never realised.
There were a surprising number of add-on graphics boards for the Commodore PET, so it's quite possible that's what the college had for the CAD course. They probably invested a lot of money in those systems in the early 1980s and didn't have the budget to upgrade that decade. Here's a great page about those add-ons by Steve Gray, the same guy I mention in this episode: www.6502.org/users/sjgray/computer/petgraphics/index.html
@@8_Bit Gosh there are hundreds of themon that site! no idea which we had, I am sure it was running from boot up as I remember poke(ing) around and I found I could overwrite the screen ram like a bitmap. I did it from basic after the machine had been switched on and I clearly remember writing over the boot up text (basic bytes free text) but like i was going over it in bitmap mode not character mode. So the card must have remaped the PETs char mode into the bitmap mode on startup, if you see what I mean. Thanks for the interesting Videos (from Nottingham UK.)
I owned 1541s, 1571s and a 1581 which I used to run my BBS off of for years.
Heh, I've also stuck to using 15 in drive commands. Probably because I saw it in a manual somewhere and kept using it out of habit. And the lazy typist in me loves the shortcuts for disk commands, but also I've noticed that not a lot of people remember that CBM DOS has the asterisk wildcard character... if you wanted to load KOALA.PRG from your disk, you just type LOAD "K*",8 and you're in business.
It's the 1541 User's Guide that had file # 15 in all the examples, so that's how we got the habit :)
Excellent video as always Robin, thanks. Love these old floppy drives and learned lots of new stuff 👍
You are the master. I kneel before you almighty one. Thank you for sharing your in-depth knowledge on these old but still loved machines. I love the way you present , you are easy to follow. Even though I used Pets at school, had a Vic 20 and a C64, you have forgotten more than I ever knew about the systems. I still have my C64 and would love a Pet, those clear green screens bring back such fond memories and I can almost smell the machines when I see that font. keep up the good work. Thumbs up.
They fixed the slowness before the C128, on the Plus/4 which has its own interface.
@ungratefulmetalpansy Completely agree.
1551 had such a complex communication, it made it very slow. They could just realize IEEE protocol on same 8 bit paralellel bits.
But nope, they created a new one... In fact 151 only 2.4x faster on a 8 bit wider data line. Epic! :-D
The idea of implementing Dolphin DOS never came up in my mind, just the C128's and 1571's Fast mode, just created 1.5 years later...
In fact I could not find a single bit of information how much faster was the C128's Fast protocol VS normal IEC. (also not about burst mode, or a benchmark JiffyDOS VS Fast protocol or Burst mode). Strange.
Maybe they could not sell JiffyDOS, if it would turn out that the C128 is faster by default? Just thinking.
Gloriously nerdy! Love these videos, thanks for making them.
Excellent video.
As a once long ago BBS runner using Cnet, I can confirm that SFD drives worked best side by side.
great ! wonderful collection !! thanks !
2:00 Approved by Ontario Hydro! Awesome! :)
I noticed that immediately as my first generation NEC Multisync monitor has that same sticker on the back. Can you imagine these days being a manufacturer or importer and having to get electronics you want to sell approved by the provincial / state electricity company?
Mmmmmm... I love the smell of fresh disks in the morning. Awesome overview!
Really cool. Thanks
Fun fact: the Commodore implementation of the IEEE-488 bus was so slow it was reliable over a long distance. I recall someone getting it to work through a 50 foot ribbon cable.
KAO disks are pronounced “cow”. I toured the plant in Arnprior once.
That's really cool, how did that come about, may I ask?
In high school I worked at a computer store in Ottawa that sold KAO Didak disks by the truck load. Somehow we were invited to visit the plant. I and a few coworkers went.
@@curiousottman nice!
Yeah, KAO's history is interesting. Before the 1980s, they primarily made cosmetics, and branched out in the 1980s to do floppy disks, they actually were very good.
tschak909 KAO disks were very high quality. I have some that are over 30 years old and still work with programs I wrote in the 80s. Many of my old disks are bad but none are KAO.
I love working with discs.
Damn, those are some cool drives. I wish the IEC serial was faster by default, but oh well. If I had way too much money I'd buy a PET, or UK/IE equivalent. I'd almost need to redo my whole bedroom to fit it though.
21:05 The keyboard was really *easy* to get used to for people who started out on the original PET with the chiclet keyboard. The keyboard shown here has full-size keys, which is of course an improvement over the small chiclet keys, but the weird arrangement meant that all the graphics characters were in the same positions as on the original machine, which made them easy to find. I loved this layout back in the day!
I can assure you that the behavior of your SFD is totally normal for single sided disks. It's the same as with the 8250(lp). The first access tries reading the disk as double sided, results in an error and the drive switches to single-sided mode. Then the next access will succeed.
Also, the older low capacity drives like the 2040 don't automatically detect disk changes, you had to reinitialize the drive manually.
And yes, the plastic case drives are pretty susceptible to EMF.
I guess one of the reasons why today you shouldn't stack them is because the plasticizer might leech out of the rubber feet and deform and imprint the top of the bottom drive. Back then, I guess, it was mainly heat and EMF.
Nice. I have not seem a pair of pets in the wild for over 25 years and never the large size full height floppy boxes. I do love how they use a flat card edge connector that should have just been a standard 488. But then again I assume since it is part of the board design that it was cheaper. I also leave vintage stuff on items. Shows the history. I also collect records / Laser Discs and leave period correct labels on them including if they came from a rental store.
5:38 I remember distinctly that the 8050 drive at my school in 1980 also had drive 0 on the right so I think that was the way they came out of the factory.
Notice that the 8050 (and the 8250 double-sided version) also had almost 3 times the capacity per diskette of the IBM PC: about a megabyte per disk, on the same type of diskette! When my school got an IBM PC I was pretty disappointed about that. Not to mention the stupid PC keyboard on which you had to use the Shift key to type all the important BASIC symbols such as " and $.
The 8050 used 77 tracks instead of the PC's 40, and Commodore used variable bitrates with GCR encoding (8 data bits = 10 disk bits) to cram every possible bit onto each track, while the PCs used a fixed number of sectors per track, limited by the innermost track with the shortest linear length, and used MFM encoding (8 data bits = 16 disk bits).
Thanks, I've now done the research I should have done beforehand, and yes, drive 0 is on the right from the factory. So I should swap those faceplates around now, that should be simpler than swapping the drive mechs :)
@@8_Bit I think the face plates are attached to the mechs, not the case. So you probably have to take the mechs out to swap the face plates.
Either way, you could just leave it like it is, just like you did with all the other modified hardware and stickers and stuff.
Had a Vic-20 but never managed to get a disk drive. That would have been pretty incredible. Could have stored every single little game and song I ever programmed onto a single disk. But had to make do with a tape drive (to which I lost at least 25% of everything I recorded, due to bad tapes) and a mini-printer that printed on receipt-like paper. Still have several printouts of Basic games from that.
A nice demonstration to show that these drives are actually independent computers in their own right would be to use a later version of Fast Hack'em disk copying software from Basement Boys Software. It loads into two 1541 drives chained together and turns them into a disk duplication system which no longer requires being connected to the computer to work. So long as they don't get power cycled, you can just keep feeding it disks to copy and hook another drive back onto the computer.
Great video Robin. Had no idea there was so many variations of commodore drives, and it's pretty impressive how much data could be stored on those DD disks. Cheers
I ran a C64 BBS back in the 80's. I had the MSD2, 1541, SFD1001, CPM8050 and a CPM D9060 (Hard Drive). the SFD's ran hot and I used some 3rd party exhaust fans to keep them cool. I used the MSD2 as a personal copy machine with my portable C64 think it was called a SX64.
WONDERFUL, informative video! Where's part 2 as stated at 23:39?
Great collection
Got led here by the 8-Bit Guy, and I love how similar this is to channels like VWestlife! Keep up the good videos!
VWestlife is a big inspiration for me, thanks!
Excellent episode as always!
Great video as usual, Robin. I grew up with a C64 and 1541. Thanks for the PET drives education. I had no idea the PET drives were faster and had a higher capacity than the C64 drives. That kind of stinks for us C64 guys. Also, I knew they added the "CATALOG" command for the C128, but had no idea the PET had it as well. I wonder why they left it out of the C64. Looking forward to part two.
PET BASIC 4.0 with disk commands took twice the ROM space, I believe, which would have increased production cost.The C64 was much more a mass-market machine where every dollar counted, while some later PETs (the CBM 8000 series that high-density drives like the 8050 were meant for) were moderately high-end microcomputers for their day, intended for business use with 80-column video, etc. and quite expensive. Time pressure during development must have been a factor also - C64's BASIC ROM was nearly a direct copy of the VIC-20's, where disk drives were rarely used, and its custom chips (VIC-II, SID) were first introduced in the Commodore Max Machine (Ultimax), basically a game console with only a few K of internal RAM, no internal BASIC (had to use a cartridge) and an awful membrane keyboard. That was only sold in Japan, and didn't last long.
Your serial number on the first drive is 6809! Bonus points for 8 bit cpu references.
Friend of mine recently bought a CBM8280 ... one behemoth of a drive.
Is that the one that was on eBay very recently? I am totally envious :)
@@8_Bit Yup, the one that was located in Dresden. Drive is up and running now after exhanging the EPROMs and 2 SRAMs. Tested on my friends CBM610 and C64 with IEEE Interface.
Great video! I like how in depth it is and I'd love to see more such videos.
Haa! I own a MDS SD-1 you do not have! :-)
Seriously: a very nice collection! My SFD-1001 just died few month ago, and really hard to get someone to repairt it.
The SD-1 has a great look, wish I had one of those too! Sorry to hear about your 1001.
I've heard retrobrite is sometimes only a temporary fix and it can make the plastic brittle. I don't blame you for not trying...
I used it on a few old keyboards and it didn't get yellow in the last 2 years and the plastic also did not get brittle- but keyboards mostly have a very thick plastic to begin with and may be more resilient.
Very nice collection and very cool to see them in action.
This is absolutely fascinating, boggling to see all of these cool things.
I still have lightly used SFD-1001 from running a BBS back in the 80's, with an Skyles Works Quicksilver-128 IEEE adapter/cable. I was shocked to see an SFD-1001 on E*bay asking for over
$1,000usd with an original Commodore IEEE adapter/cable. While it's rare, don't think it worth that much.
Great video. Very interesting. I'd read that leaving the slow drive interface on the C64 was to do with time constraints, and they wanted to release it quickly. I love that scrolling credits program.
Did I ever say that i love this channel, I do ... :-) - And regarding floppy drives, if anyone ever needs an VIC-Switch I have one in the attic you can have :-)
Three cheers for CMD JiffyDOS and the included wedge! I HATED slow drive throughputs, and hated even more having to load disk directories into memory like a program.
Yes the Commodore way of dealing with drives was quite ... interesting.
It wouild be an interesting hack to turn a Commdore drive into a full blown computer that you plug a video terminal into, or by using a terminal emulator in a Commodore computer.
Look up the freespin demo. They made the 1541 drive composite video out through the serial cable and make music with the drive stepper motor. It's seriously impressive
Something I would’ve liked to see is a VIC 20 using one of these PET drives via a VIC-1112 IEEE 488 interface cartridge. I’m sure it’s nothing special but just seeing it in action would’ve been great.
Wow 8050 same year and month model as me in the manual... no wonder why they were thrown out already ;)
These old drives (the 4040 and 8050 dual floppy drive units by Commodore) might have multi-threaded versions of CBM DOS.
Wonderfilled!
Please do a video on those clone drives in the upper right sometime!
I had the SFD1001 with an IEEE-488 adapter with my Commodore 64. Unfortunately, I was involved with a music band that I left suddenly - never wanting to return. The SFD1001 probably sat on the floor of his spare shed, near the beach... So, I suspect that it rusted to dust...
I only have a 2031 in the metal case. You have quite the collection.
The metal case 2031 is one I'd love to get. So chunky!
@@8_Bit It's a chubby boy for sure with that full height Shugart mech with the garage door latch. It's quite an odd mechanism, it uses a cam follower to move the head instead of the usual metal belt on a pulley.
I did know about the 2031LP but I didn't know C= also made one with the VIC-1540-style nameplate.
I think the chunky 2031s are rare now.
@@8BitNaptime Yes, it might be the most rare of the three drives, but they're all pretty rare now: 1540, 2031LP, and original (chunky metal) 2031. 1540 seems to turn up most often on eBay, but it goes for pretty big money when it does.
@@8_Bit I need a 1570 and 1551 to complete my hoard. 1551s are crazy on eBay and I've never seen a 1570 there.
...and of course today I found a 1570 on eBay but it's part of a lot. Oh well.
@8-Bit Show And Tell I am very surprised no one has found a Mini Chief drive for the C64. It was a drive/kit that converted a 1571 to have a 20 or 40MB Mini-Scribe drive in it. The 1571 as a floppy still worked too. I knew a old friend when I lived in Ottawa, ON who had one back in the day, it was amazing. It could create x number of 644 byte drives (can't remember how many) or be set to use all 20MB (in his case) as one drive. I am guessing the Mini-Scribes died and people probably just tossed them.
I've heard of that drive but have never seen one in person. There were a number of interesting early hard drive solutions that are extremely rare nowadays as presumably very few units were sold. The only one I have is the CMD HD which was relatively common.
@@8_Bit Just found this, its a flyer for the Mini Chief. archive.org/details/Mini_Chief_Hard_Disk_System_1987_In_Control
0:10 I've had most of those drives, but what the heck is that weird dual-drive thing on the top right?
2:17 Apparently, the bug in the VIA's shift register is pretty easy to fix with an extra logic gate or two. I don't know if they knew this at the time.
2:28 While the CIA's shift register didn't have this bug, the VIA used in the 1541 still did, so they couldn't fix the problem without overcoming the VIA's bug. Also, the C64 with its BASIC 2.0 and carbon copy of the VIC-20's ROMs seems like it was mostly slapped together by taking a VIC-20 and sticking some new I/O chips in it. Upgrading the serial bus with backward compatibility like they did with the C128 would have been a big job.
3:23 It seems a bit wasteful that it has so many wires with a bunch of twisted-pair grounds for the control signals. Was noise on these lines really a big problem? I don't even see a special ground for the data lines.
5:12 I'm more of a Victorinox guy, myself.
6:06 I normally use Logical File Number 1 since my first storage device was a cassette drive.
8:00 PRINT DS$
8:14 They waste a space at the front of each line when listing on a 40-column screen. Did they believe that the indentation made it easier to read when lines wrapped?
13:52 They also accept the DIRECTORY command, abbreviated "diR".
14:39 There was also an 8250 drive which was double-sided and could store over 1 MB per disk.
21:06 That is so weird that the 4032 didn't have numbers on its top row of keys. Every other keyboard had that, including the 8032.
23:03 It's not the stacking that damages the drives; it's the overheating from the lack of ventilation when they're turned on.
That weird drive in the top right corner is a Dual CMD FD-2000. As far as I know, only three were made. This one was used for Loadstar's (monthly disk magazine) 3.5" duplication needs from the mid-late '90s until the early 2000s, I believe.
Ugh, I can't believe I forgot about DS$!
@@8_Bit: I was hoping that your early-access Patreon videos got promoted to public viewing since that would give me a crack at FRIST POST!!!1!, but sadly, this appears to be a separately-posted video.
@@csbruce Sometimes I do change the early-access video from unlisted to public, but other times I find extra things to tweak in the final video render that goes public. Thanks for your support, and if you keep trying I'm sure you'll get FRIST POST!!!1! eventually :)
I have a Commodore 1702 monitor with the same "COMSPEC" label on it. I think I picked it up near Toronto. I infer that this was a chain of computer stores in southern Ontario in the 1980s but haven't been able to find any more information on them.
I think the concern about stacking 1541 style drives (the 1001 on through 1541) was more about heat dispensation not physical weight.
I regret giving away a bunch of my Commodore stuff in the late 90s, when I needed to make space when I moved. Given how cheap all this stuff was in thrift stores at the time I figured I'd be able to replace it easily enough. Oh, how mistaken was I.
More than the hardware, though, I really regret also including all of my floppies in that; most of it was pirated games but I had a bunch of stuff I'd made, including music and my earliest games. That stuff's irreplaceable.
I would also like to have seen an HD, DS dual 5.25" drive, like if the 1572 had come to light, or even if they had made a "1592" (3.5") or something like that. I also didn't know, or at least remember, that the 1001 is DS, until now!
I love movies of this kind ...
You are using a lot of post-production digital zoom. No problem with that, but have you considered a 4K camera? Those zoomed parts would look much nicer with it. I'm actually watching this on a 17" CRT monitor, though :-) , so 4K is redundant for me at this moment, but the zoomed parts still look blurry and noisy on my current setup. (edit: typo corrections)
Thanks, I did shoot in 4K for this video (usually I don't) but just on my phone which is all I have currently. I'll look into a proper camera especially if I keep making videos like this one, with more need for close-ups.
First! (to point out the paradox of saving the disk status program on disk, the retrieval of which obliterates the status one was trying to state.)
lol my oscilloscope has the same Ontario hydro electrical approval sticker on it.
Did that 4040 have a TV modulator on the motherboard?
I 'inherited' a perfectly cared for, working 8050 in the late 80's, along with an Interpod adapter to make it work with a C64. Yea, I tore it apart in the 90's. :( Incidentally, the hardware inside the 8050 is as robust as any 3D printer today. The mechanism isn't really much different.
Just got my 4016 up and running, had to replace the video ram. have the old style 2031 disk drive in the metal box, and the external cassette player. there is something wrong with the cassette which is not surprising as it has spent the last 20 years in the garage loft.
but i can't find my PET 488 lead so have not been able to try the disk drive out. looking at making a SD2pet unit as something to do during lockdown if i can get the parts.
Yes, Commodore also made filing cabinets, hence the 18ga steel probably 😂
i absolutely loved this video! thanks so much! i wish you had explained the syntax of the commands a bit more. for example, when you said the first number was 15 but could be anything, what is that number for in the first place? thanks!
btw, i think the drives look perfectly fine without retrobrighting, but then i wouldn't mind either way! :)
oh... i was wondering... why do you have to put the disk in to see the DOS version that's stored on the disk /drive/? i thought the dos version is in the drive rom whether or not the disk is present? thank you!!
The problem is it would take another video just to explain it. The very short explanation is:
OPEN file#, device#, channel#
*file#* = any number from 1 to 127. and allows the program/user to have several files open at once - random access data base ("relative files") usually opened multiple files at one time. This was called a "logical file number" and was basically how C=64 "remembered" which file was which.
*device#* : 0 = Keyboard;1 = Tape; 2 = RS-232; 3 = Screen; 4 = Printer; 5 = (alt)Printer; 6 = Plotter; 7 = (?reserved?); 8 = Disk Drive; 9,10,11 = (alt) Disk Drive (10 and 11 usually had to be implemented through DIP switches on the drive's PC board or through commands sent to the drive's OS)
*channel#* = varied from one device to the next, but in the disk drive channel 0 and 1 are used internally to address the directory, although ch 1 can be used to "read only" a sequential file. Channel 2 through 14 are used to send and read data to open files. Channel 15 is strictly used to send commands to the DOS and read status flags from the DOS. (not exactly true, but data sent on channel 15 is for advanced DOS programming)
In the format of OPEN 15,8,15,"xxxx" the file number (first number) was simply a programmers way to separate/remember this was the command channel. It could be any number but could get confusing with several open files especially if you were working in direct mode. Technically speaking the second and third numbers are an "Attention, address" header bytes sent on the serial bus.
@@3DPDK wrote «varied from one device to the next, but in the disk drive channel 0 and 1 are used internally to address the directory». I thought 0 and 1 were used for special LOAD and SAVE access.
@@3DPDK great explanation, thanks! another video? not a problem at all!! :D
@@csbruce I think what you are thinking is "LOAD "filename",8,1 The '8' of course indicates the disk drive. If '1' is included in the command it flags the C=64 to load the program to the memory address indicated by the first two bytes in the file on the disk or tape. An ML program that resides at (say) 49152 has the first two bytes of the file set to $C000, or #00 - #192.(lo byte-hi byte) Without the '1' the C=64 automatically ignores the first two bytes and loads the program beginning at 2048 or BASIC program memory. SAVE "filename",8,1 is the opposite. Without the '1' C=64 automatically writes the 2048 load start location. SAVE"filename",8,1 will wright the address indicated by the value held at memory locations 172 - 173 which usually point to 2048. By temporarily setting this to another memory location and setting a few other pointers, this command format can be used to save screens, ML programs in upper memory or anywhere, basically a memory "snap-shot". SAVE or LOAD "filename",8,0 is the same as LOAD "filename",8 (no second number) - the second number is simply a flag and is either a zero or non zero value - LOAD"filename",8,2 does exactly the same as LOAD"filename",8,1 However, none of this has anything to do with the communication channel set in the OPEN command between the computer and the external device.
@@3DPDK: A quick look at the ROM listings shows that the secondary "number" given for a LOAD operation and the secondary address sent over the serial bus are distinct. A secondary "number" of 0 is a relocating load and 1, a non-relocating load. There are a number of different ROM listings online (and each is broken in a different way!). The one at github.com/mist64/c64rom/blob/master/kernal/load.s shows on line 43, "lda #$60 ;special load command", meaning that secondary address sent to the serial device for a load is always $60, regardless of the secondary "number" taken from the user. The upper nybble identifies the serial-bus command (accept the secondary address) and the lower nybble identifies the disk-controller channel, with 0 indicating the special LOAD channel. Technically, you're correct in that the directory is retrieved using a LOAD operation, but so is every program.
Similarly, the "save.s" file shows "lda #$61 : sta sa", which accesses disk-controller channel "1", which is dedicated to the special SAVE operation.
What happened to the 2nd part? Did you decide not to make it?
It is so strange that these diskdrives get into trouble when placed to close to other antiques. Remarkable how easily they get confused, it can't be the speed or the pressure of having to do the work accurately. Working with sign flags is almost as quick.
I'm wondering if Commodore used single-density disks out of spec with so many tracks (and sectors per track)? If so, did they rely on the disks being better than specified? At least the manual you've shown only demands single-density disks for the 8050 having 77 tracks. Or did the DOS include some kind of low-density backwards-compatible format for the use of single-density disks?
Someone asked me about redirecting the PRINT command to memory to print sound effects or sprites etc. I forget where they asked so I'll post more of what I found out here. I done more digging and found my old notes, combined with some information on the C64 registers and memory maps. Here's how you do it and why...
Lets say you wish to set the SID chip to play a sound. The SID chip is at location $D400/54272. The low byte for that address is 0, the high byte for that is 212 ($D4 hex). So you POKE 209 with the low byte (POKE 209,0) and you POKE 210 with the high byte (POKE 210,212). 209 and 210 are pointer to current line in screen memory and you can set that to any address at all. But you also have to set the current column the cursor is on to zero so it starts at the beginning of that memory location. That is set with POKE 211,0. Once you do all these POKEs, the next PRINT/? command will print to that memory location whatever you wish. So if you just wanted to clear the SID chip, you would print 25 @'s (@ equals zero on the C64) and it would be clear, like this:
POKE209,0:POKE210,212:POKE211,0:?"@@@@@@@@@@@@@@@@@@@@@@@@@"; (I'm not sure if the semicolon was important here or not)
This would clear the SID chip. The first @ is at location 54272 (hex D400), the start of the SID chip. You can change each @ to whatever number you wish to place in that memory location and you can literally PRINT a sound effect. I used to have a fun C64 BASIC program where you had a menu and selected a sound effect and it would play it. When you looked at the source code the above line is ALL you seen for each sound effect (just the @'s were changed for the values of course). Same deal with sprites. Point it to sprite memory and print a sprite out. Or moving ANY DATA you wish! This can eliminate loops that read and poke data completely! Just point to the memory and print it all there in one shot. Very powerful trick.
Is part 2 of this video ever going to happen?
Hey, did you ever consider doing a "Introduction to Assembly Language". Use a simple CPU like the 6502, or 6008? Heck, if you sold them as videos on a thumb drive, I'd buy the set.
Question: Is "fast serial" on the Commodore 128 the exact same thing as "Burst Mode?"
Huh! I didn't even know that the 1541 is single-density and that the quads were already out before it until I heard of the SFD-1001 8 years after we got a '41! (And even then, the friend showing it to me didn't make it clear that that was still for the PET.)
It's unfortunate that the first 15-series drive was so crippled in the name of CR that it was just SD even though there were already DD and QD drives out there, but Commodore didn't think enough people would want to buy those for the 64. I wish the 1001 through the user port had been the standard, and it's interesting that the 64 will even recognize a device 8 through that port.
That's dumb; I hate back-sliding with newer stuff, like what they did to BASIC before going back to a higher version with the 128. But then the question might have been, "Yeah, but then could your parents have afforded it?" Maybe by the time the 128 came out it was easier to afford better things and keep a low price for the consumers. But overall it seems dumb and counterintuitive to put the weaker peripherals with the generally stronger computers (in the sense of memory size, etc.).
It seems like that there is a FPGA COMMODORE C64 which implements the whole PC in FPGA and it seems you can get a COMMODORE PET in a FPGA.
Why does the PET have BASIC V4.0? This is even a newer version of BASIC than on the C16/116 which has V3.5 and came out much later. Is this some kind of homebrew witchcraft?
Commodore's BASIC numbering scheme is really weird. I think the PETs (in different models, and with various ROM upgrades) got V1, V2, and V4. V3.5 seems to be more advanced than V4. I don't know what happened to 3.0, and why the C128 jumped up to V7. Could be an interesting video, but I will need to do a LOT of research for that one :)
Great video, Robin. I am always learning more and more from you. #FancyZoom 😂
DUDE!! I am seriously jealous of that! My wife would kill me if I had that many in my basement
We had a House of Computers in Timmins for a while. Hmmm.....
2052 blocks on that 5 1/4" disk. It makes me wish the 1581 was HD instead of just SD (haha, those sound like video terms, but they stood for "-density" before they stood for "-definition") because then it could have had around 7320 blocks instead of just 3160 (even though 3160 wasn't bad for then). Dumb to make the 1581 SD when the SFD-1001, etc. were already QD, with the 4133 blocks instead of the '81's.