I've been waiting for one of these to connect to my C64 Pi based emulator. Now, how long will it be before there's a 4 pen plotter? Used to love messing with that.
A near perfect emulation of the 1541 floppy drive has been released, and you need only a Raspberry Pi and a soldering iron to rock the 1980s once again. Thankfully, the emulator does not recreate the 1541's unfortunate habit of dying early and often. Retro enthusiast Steve White ruined the weekend of many a computer-widow or …
Wow--you just brought back a memory from my childhood that I'd completely forgotten about!
We had one of those KoalaPads for an old Atari 800, which I recall being pretty disappointed with by the time my Dad finally got it up and working (I must have been 6 or 7 at the time). My childhood imagination was far too much hype for that primitive little gizmo to live up to!
I can't recall if we ever had the printer hooked up to it or not, but I don't think you missed much--even if you were amazing with that thing, those 8-bit systems weren't capable of rendering very much detail back then, and most dot matrix printers were even worse!
Back in the day I was a VIC-20 user (bought before the C64, and when it eventually came time to go for something bigger, I went down the Speccy route).
I remember buying the 1540 drive which stopped working properly after a couple of months. The shop eventually replaced it with a 1541 which got used very heavily for long time, and rarely skipped a beat. I guess I must have been one of the luckier ones.
I must have been one of the lucky ones as well.
I started with a Vic20, a datasette drive, & a 300baud acoustic coupler modem connected via the joystick port. From there it was a C64, a 1541, & a 1200baud modem of the same ilk. Then I added a 2nd 1541, then a 1581, & a 2nd 1581 so I could do lots of disk copy jobs. I eventually ended up with a C128D, 1750 REU with a SwiftCart & an external 56K Hayes modem with a purple case, the REU maxed out with all the RAM it could stomach, and it pretty much gave The Finger to everyone else at the time as far as computational grunt was concerned.
I used it to write reports, create artwork, fool around on CompuServe & Qlink, and play games like the AD&D GoldBox series of Pool of Radiance.
In all those years I only ever had to replace a single 1541 & that was definitely my fault: they don't tend to work well if you accidently set it on fire. *Sheepish grin*
Ahhhhh... those were the days.
"Nostalgia ain't what it used to be." =-D
I never had any acoustic couplers. but all the rest of the kit was the same. I jumped from C64 to A500, though. Used to love making up kits from Maplin, then modifying them. Midi controllers, speech synthesisers, expansion port expanders etc.
I did network the 20 to the 64, using RS-432!
30+ years later I still can't purge the music from a cartridge game called Radar Rat Race out of my memory. Found a Vic 20 emulator and the game cartridge turned in to a 6k rom....everything gets emulated these days.
The Action replay cartridge for the Amiga was also emulated, so I assume they did the same for the C64.
@Anonymous South African Coward
Why emulate? I have a Microdrive that's virtually unused still. I say virtually because I received the Spectrum as a Christmas gift one year and there was no way to attach it so it was either lost or was bought without knowledge of what it was. There's even a small disk inside its plastic case and I have no idea what, if anything, is on it.
I have to say that this stuff does please me greatly. The Pi has a lot to answer for here.
I was reading about the various 6502 Second Processor modules for BBC micros that are still being run off. Initially using faster 6502 variants, then FPGAs, and some fella blew them all out the water by hooking a Raspberry Pi to the Tube...
Sheds all round!
Now there is an ironic circle.
The ARM instruction set was originally modelled on an Econet of BBC micros, and then the first ARM 1 development board was a Tube second processor!
Acorn really did have some exceptional engineers, and the BEEB was an exceptional system for it's time.
Incidentally, there were 80x86 (I think it was an 80286) second processors, as well as Z80 and even a NS32016 (originally intended to run Xenix) available as second processors. These were even packaged as business oriented machines as the ABC (Acorn Business Computer) range.
Only for certain values of reliable...
In the mid 1980s I had an early plastic C128D and the internal 1571 suffered from data corruption when side 2 of a disk was used. Using relative file access was also beset with problems, causing programs to crash out with "?device not present" errors (which, for some reason, couldn't ever be trapped). Commodore initially denied there were problems (in an attempt to avoid replacing the drives) but they eventually fixed most of the bugs with updated ROMs.
Yeah... about the reliability.... There was the top read/write head that had to be levered up and down to get the disk in and out. It was directly connected to the lever on the front. It's "hinge" was the cable bundle to make it work as a read/write head. This cable bundle tended to rip after a few months, whisking the head first out of alignment, and then stopped to work altogether. Happened on both my 1571. I think the second one is still around somewhere...
I also had two 1541s. Ran the second one mostly without top cover for cooling, since it's main problem was the hot power supply in the back.
Taking over two minutes to load a 64 kilobyte into memory was maddening. As Russell told Bagnall: "I wasted millions of people's hours I was later told."
Horrible by today's standards but at a time when the majority of C64 punters owned tape drives it was nonetheless a welcome improvement. Thankfully there were a lot of peripheral solutions that vastly improved loading times. Even the software companies had custom fast loading routines included in their products towards the end of the C64's life that reduced loading time to seconds.
Kudos to those still making available (emphasis on available) hardware and software not just for the C64 but for all retro computing and gaming gear. I do not include crowd-funded vapor-ware in that category.
"Horrible by today's standards but at a time when the majority of C64 punters owned tape drives [...]"
In 1970 our IBM-compatible mainframe was running a TP system. It had a then massive 600MB fixed hard disk. There was much celebration when some inspired use of self-modifying command chains reduced the overnight back-up to magnetic tape - to only 8 hours.
"Horrible by today's standards but at a time when the majority of C64 punters owned tape drives it was nonetheless a welcome improvement."
Having started with a TRS-80, the Commodore floppies felt like a backward step. I could never quite figure out why they went for a serial data link that required so much processing power in the drive unit. But then I can't get my head around why SATA should be faster than PATA :-)
"Having started with a TRS-80, the Commodore floppies felt like a backward step. I could never quite figure out why they went for a serial data link that required so much processing power in the drive unit."
Since it was an end-user-targeted computer, I would think simplicity of interface and price played a factor. The interface they used was a lot easier to daisy-chain (so only one link to the computer; drives, printers, etc. connected to each other), and they modified the specs to use ubiquitous DIN connectors, reducing costs.
There was a bug in the serial hardware on the C64 that required them to seriously drop the transfer speed. The slowness was a result of having to deal with that bug.
SATA on the other hand uses 2 differential pairs (One Send, One Receive, simultaneously) which you can drive a lot faster with more noise immunity than a single-directional bundle of parallel wires with only a high or low signal that is extremely susceptible to electrical noise.
To put it in an ELI5 fashion..
With a PATA drive you have 16 pairs of people having a single slow back-and-forward conversation in a crowded room of other people talking.
With a SATA drive you have 2 pairs of people having entirely separate conversations where one person is listening while the other talks extremely quickly in an empty room that is almost completely silent.
That's what I could do with an emulator for. A cable that plugs into a Raspberry Pi at one end and a standard PC floppy drive at the other and reads stuff off Amiga formatted disks. I have some old projects on floppies in the cupboard and it would nice to be able to salvage them.
"That's what I could do with an emulator for. A cable that plugs into a Raspberry Pi at one end and a standard PC floppy drive at the other and reads stuff off Amiga formatted disks. I have some old projects on floppies in the cupboard and it would nice to be able to salvage them."
I used to have a Catweasel PCI card for my PC that would read standard Amiga formatted disks under Windows, as well as let you plug in real Amiga mice and joysticks. I sold it a years ago as I no longer had any use for it but they are still available if you need one, try Amibay or Amigakit.
I agree though that a cheap device that would let you connect up a PC floppy to modern hardware and read disks would be good especially if it supports reading games disks with none standard formatting which the Catweasel card could not do.
You could perhaps pick up a cheap second hand Amiga and use a null modem cable to copy the data off that way or if the data isn't sensitive ask around on some Amiga forums I am sure someone with a networked Amiga would do it for you if you posted the disks to them.
The main reason the heads became misaligned was because many commercial disks were deliberately formatted in a way that caused the drive to read a bad block - something to do with an anti-piracy mechanism. However this caused the drive to smash its heads against the end stop (often several times in very quick succession). No surprise it caused the failure rate to rocket.
Yep it was an old trick, the track header contained the track number & block
by setting the track header to a different one than expected, caused the drive to error.
Basically the drive went to track XYZ but when it got there , the header was a different number and so it threw an error, validating the disk.
There was also a byte in each sector header that was 0x09 or was it 0x21.. if i remember correctly..
my system produced a disk that only the directory track (trk18) could be read, the rest of the disk was unreadable.
Commodore GCR-format floppies used 256-byte sectors and variable-length tracks (long towards the rim, shorter towards the hub; IINM, the disc was formatted from the outside in), but the first two bytes were reserved as a "next sector" link (track for the first byte starting with 1, sector for the second; if the first number was 0--no next track--you've hit the last sector of the file, the second byte instead described how much of the last sector is used). Track 18 (in the middle) was the directory track.
interesting. That might explain why my 1541's lasted quite a while, even though on one of them [the first one I bought] I had to cut open the case a bit and place a cooling fan on top because it overheated early in its life. I noticed that Commodore went with external power supplies for later models, which prevents the overheating.
ahhh the good old bad block anti-piracy.....
Not to hard to get around, not that I ever would do something like that.
Making multiple copies of something was nice and easy with those drives. Start a copy from device a to b with a bit of code running on A then you could just unplug the 64 and let them keep o making multiple copies.
I also had a head realignment program... loosen of the screw a tiny bit... run the program (very noisy head crashes), tighten the crew and then paint it with nail polish. Fixed a few drives like that :)
can guarantee it wont emulate correctly.
I was a specialist in writing protection for the 1541 disk drive, and i don't mean adding "IBG" or extra sync marks to the sync headers....
and for some of my stuff he would need to have programmed the head travel time between tracks
I'm the author of an ordinary software-in-your-computer 1541 emulator — the concept is nothing new, the chips are very well understood. Regardless of the article's comments about the 6522, doing it as a proper real-time process compatible with the original signalling is the interesting bit.
That being declared, I disagree with the reasoning for your guarantee. Emulating proper physical timing is pretty trivial, especially if you've a whole Ghz-level ARM at play.
To my mind the main obstacle is more likely to be the Commodore file formats: the most advanced one, G64, is a "raw bit stream" that permits multiple speed zones per track and atypical track lengths, with half-track positioning but all data within a speed zone is implicitly perfectly clocked and of perfect amplitude. So amongst other things, weak bits and fuzzy bits are not conveyed by G64.
Some of us have a full pretend PLL in our emulations; I'll wager that was omitted.
Only one of these is actually a processor.
The 6522 is a 'versatile interface adaptor' - it could be configured in various ways with 16 bits of I/O configured as input or output on a bit-by-bit basis, it could input and outpt serial bit-streams and had programmable repeating or single-shot timers - and probably a load of other stuff I've forgotten now as I haven't used one in about 30 years! But it was never a processor.
" But it was never a processor."
well, there was a documented way of sending code to the on-board 6502 for things like "fast disk". but since the RAM was limited, you couldn't load very much. Seriously, though, it was doing what microcontrollers often do, in this case moving the diskette drive heads and whatnot. The ROM was decoded and documented in various books and whatnot. I don't have any of those any more [gave them all away along with the hardware, long ago] and I'm pretty sure that whoever ultimately ended up with it all probably didn't appreciate the geek factor of it...
In any case, it was possible to use the on-board 6502 as an actual 'processor'. It was just somewhat difficult and impractical for anything NOT disk related.
It shouldn't have taken that long. According to "Commodore - A Company on the Edge", Robert Russel considered the disk access on the VIC-20's serial bus to be too slow. So for the C64, they replaced the 6522 VIA (with its broken shift register) with a 6526 CIA and added some high speed lines to the serial port. Same deal with the 1541. It would have been 20 to 30 times faster than the VIC-20.
Problem was, during the period when prototype boards were being reworked into their final production layout, somebody removed the high speed lines. The decision to reuse VIC-20 cases for the C64 imposed some serious space challenges. Some engineer mistakenly thought they weren't being used, so they were omitted to save space on the board. Since the Kernal's serial routines hadn't yet been updated to utilize the new burst mode, nobody realized the mistake until several hundred thousand motherboards had been manufactured. By then, it was too late.
When marketing said that the 1541 also had to be backwards compatible with the VIC-20, that limited how the serial routines could be written even further. There was also a looming deadline. So Bob Russell wrote the routines over a weekend to stay on schedule. They worked, but they sucked. Programs such as Epyx Fastload and CMD JiffyDOS worked by replacing the serial routines with optimized versions.
Anyone who has used a 1571 or 1581 on a C128 knows how much faster they are. That's what the 1541 on the C64 was supposed to be like. But due to a few bad decisions, the 1541 ended up dirt slow.
To add to that, the 1541 is also actually slower than the 1540 it replaces. They're physically the same device with a ROM swap, but both ended up oriented around bit-bashing the serial port at a rate that they could expect a busy-polling 6502 to be able to read. The C64 obtains the memory bandwidth necessary to double the Vic-20's output resolution by excluding the 6502 from the bus for one pixel line out of eight and buffering the tile map. So whereas the 6502 in the Vic-20 goes at a constant speed, the 6502 in the C64 suffers a line-length pause reasonably frequently. Therefore the data transmission rate had to be slowed to make sure the C64 wouldn't miss anything.
It's not a big difference but Vic-20 owners with a 1541 can obtain a mild speed-up by switching the drive into Vic-20 mode. In classic Commodore fashion, it's an arcane command that repurposes file transfer, a lot like $ being the file you load to get a BASIC listing that contains the disk catalogue.
Still nowhere near as fast as a turbo loader though; it's still one 6502 bit-bashing the two signals on the serial bus at a rate it knows isn't too fast for a listening 6502 to deal with but while maintaining the proper serial bus protocol in case the other end is ever upgraded with a race-condition-free incoming shift register.
Ahh the old EA games copy protection... a single change of BNE to BEQ, and the game was cracked!
Now as far as copy protection and fast loaders go... the most epic fast load of all was GUNSHIP.
that rewrote the DOS and used epic timing tricks to get around 21 times fast load from a standard loader.
Our crack of gunship ended up with a built in 5x fastloader, but resulted in a game that could be copied with single file copy!!
what an epic game that was too!
...compatible with the ageing Vic 20 computer...
Incidentally, the VIC-20 was only a year old at the time and still making truck loads of cash for Commodore. Ageing? Perhaps. But not quite irrelevant. The fault remains with the broken 6522 serial shift register and the dunderheads that cut the fast data lines off the C64 motherboard.
..as I started even earlier with a PET and an 8050 dual floppy drive. A drive which incidentally I still have, and which still seems to work as well as the day it was made. I will also say the drive is durable enough that I recall using it once as a step stool to reach something on a high shelf of a closet.
Aside from all that, 500K/side of a 5 1/4 floppy in 1980? And a drive intelligent enough to tell it to copy from one drive to another, shut off the computer and go make a sandwich while it finishes the job? Commodore was really ahead of everyone. (at least for a while)
Biting the hand that feeds IT © 1998–2019