Hacker News Reader

Comment by babypuncher | Hacker News Reader

This isn't even that new of a thing. The floppy disk drive sold for the Commodore 64 included it's own 6502 CPU, ROM, and RAM. This ran its own disk operating system[1]. Clever programmers would upload their own code to the disk drive to get faster read/writes, pack data more densely on the disk, and even copy protection schemes that could validate the authenticity of a floppy.

1: https://en.wikipedia.org/wiki/Commodore_DOS

View on HN

And all that engineering resulted in a floppy drive that was slower and more expensive than comparable units for other home computers. I'm not sure if there is a lesson there...

Probably not a fair comparison in some ways but this reminds me of that story of Woz making a disk drive controller with far fewer chips by being clever and thoughtful about it all. I’m probably misremembering this.

That's what pretty much what happened. The Integrated Woz Machine.

You’re talking about the Integrated Woz Machine. It was a custom disk controller that Wozniak created that was used in the Apple ][, /// and I believe on the original Macs. It was cheap, fast and worked.

And a later Mac, the IIfx, introduced I/O coprocessors to run the IWM, among other things. All part of the glorious wheel of reincarnation. [0]

[0] https://www.computer-dictionary-online.org/definitions-c/cyc...

Crazier yet: the IOPs on the IIfx were 6502-based microcontrollers.

The Integrated Woz Machine was the custom single-chip version of the Apple II floppy controller.

Well, it was slower due to a hardware problem. Basically, the hardware serial device had a bug which required a bit bang comms channel to the disk drive. Doing that amidst the sometimes aggressive video DMA is what caused all the slowdowns.

Back in the day I owned machines that did it both ways, but not a C64. My Atari computer also had a smart disk drive. Worked over something Atari called SIO, which is an early ancestor of modern USB. Back then, the Atari machine was device independent and that turned out to be great engineering!

Today we have Fuji Net devices that basically put Atari and other computers on the Internet, even to the point of being able to write BASIC programs that do meaningful things online.

The C64 approach was not much different, working via RS-232. But for a bug, it would have performed nicely.

Now, my other machine was an Apple ][, and that disk was all software. And it was fast! And being all software meant people did all sorts of crazy stuff on those disk drives ranging from more capacity to crazy copy protection.

But... That machine could do nothing else during disk access.

The Atari and C64 machines could do stuff and access their disks.

Today, that Fuji Net device works via the SIO on the Atari, with the Internet being the N: device! On the Apple, it works via the SmartPort, which worked with disk drives that contained? Wait for it!!

A CPU :)

Seriously, your point is valid. But, it's not really valid in the sense you intended.

No, VIC-20/1540 had hardware problem. C64 shipped with fixed chips. C64 cant even work with 1540. Commodore crippled it because of incompetence.

Too late for me to edit, but yes I did confuse the source of the bug. Please clarify the C64 drive scenario source of slowness. Was it VIC-20 backward compatibility, or?

In any case, I maintain the engineering wasn't at fault, having a CPU etc. Fastloaders showed it to be just poor software, and that's a point I did not make clear enough.

Commodore wanted new C64 drives to be backward compatible with VIC-20 and vice versa. They failed the second goal, and C64 sold ~10x the number of units VIC-20 did making whole exercise pointless.

All to sell more outdated garbage chips made by MOS instead of using proper FDC controller on CPU bus with cheap standard floppy.

Got it. Ty :)

The 1541 was slow because the c64’s serial bus was slow. Data was clocked over the bus 1 bit at a time. Various fastloaders sped up the data rate by reusing the clock line itself as a data line (2 bits at a time), later HW adapters adder parallel port or even usb to overcome the serial bus bottleneck.

Basically commodore was gonna use an ieee-488 bus for the drive and then decided it was too expensive late in the design and switched to this hacks serial bus that bottlenecked everything.

The 1541 was set to be a highly capable and performant machine, but an interface/design bug held it back and delivered dismal performance whenever connected to the C64. They tried to fix it but it couldn't be rescued, so speed freaks needed to wait for the 1570 series.

It was partially rescued by fastloaders and later JiffyDOS. Fastloaders tended to max out at 10-13x if the disk format was unchanged but if you could reformat or recode the files you could go anywhere from 25x speed to over 40x (transwarp) on stock hardware. DolphinDOS gave a 25x speed up by using the parallel port with 1541.

Epyx games used the Vorpal format which gave 15x load speedup.

The point is, the speed issues weren’t really the 1541’s fault although GCR coding could have benefited from a HW decoder.

There’s more to life and computation than cycles and read/write speed. A generation of engineers began their journey doing these “useless things”

The slowness was due to a hardware bug in the 6522 VIA chip. The shift register (FIFO) would lock up randomly. Since this couldn't be fixed before the floppy drive needed to be shipped, they had the 6502 CPU bit-bang the IEC protocol, which was slower. The hardware design for the 154x floppy drive was fine, and some clever software tricks allow stock hardware to stream data back to the C64 and decode the GCR at the full media rate.

https://www.linusakesson.net/programming/gcr-decoding/index....

Oh I know it’s been a thing forever. Hell, my NeXT Cube with its NeXTDimension display board was such. The NeXTDimension board ran its own entire stripped down OS. It used an Intel i860 and a Mach kernel…. It also was massively underutilized. If NeXT had did a bit more leg work and made the actual Display PS server run entirely on the board it would have been insane. But the 68K still did everything.

… I miss my NeXTs..

Yes, but ... Commodore did this because they had incompetent management. They shipped products (VIC-20, 1540) with hardware defect in one of the chips (6522), chip they manufactured themselves. The kicker is

- C64 shipped with 6526, a fixed version of 6522

- C64 is incompatible with 1540 anyway

They crippled C64 for no reason other than to sell more Commodore manufactured chips inside a pointless box. C128 was similar trick of stuffing C64 with garbage leftover from failed projects and selling computer with 2 CPUs and 2 graphic chips at twice the price. Before slow serial devices they were perfectly capable of making fast and cheaper to manufacture floppies for PET/CBM systems.

In the era of CP/M machines, the terminal likely had a similar CPU and RAM to the computer running the OS too. So you had one CPU managing the text framebuffer and CRT driver, connected to one managing another text framebuffer and application, connected to another one managing the floppy disk servos.

I guess I should have clarified more: I dislike everything running entirely separate OSes that you have no control over at all and are complete black boxes.

The fact they are running entire OSes themselves isn’t that big of a deal. I just hate having no control.

Oh God, the 1541 ran soooo hot, hotter than the C64 itself. I remember using a fan on the drive during marathon Ultima sessions. The 1571 was so much cooler and faster.

Reply on news.ycombinator.com