I assume this is an allusion to the fact that the standard Commodore 64 disk drive had an identical CPU, lol. A legitimate computer all to itself. You could even expand the default 2KB of RAM up to 48KB. [1]
The 1571 floppy (successor to the 1541) used a 2Mhz 6502, versus the 1Mhz 6502 in the C64. So, fairly common to have a disk drive that had a better CPU than your PC.
Through the serial port. It turns out that if you really dig into the 1541 docs, it’s possibly to push assembly code into RAM using existing 1541 commands over the serial port. And the 1541 has a command buffer. So I pushed assembly to perform parallel calculations to it, and then pushed two commands into the buffer, one to execute the code and the next one to resume normal serial ops after it ret’urned. The data from the calculations was placed into the data buffer prior to returning, and the 1541 just sent it out the port as a regular data packet, just as if it had been read off a floppy. Or so I recall; this was in 1986. My memory’s a little fuzzy.
It worked with N drives, too, although the C64 sort of had to act as the bus master to avoid serial packet conflicts.
That was a long time ago and I’ve certainly forgotten many of the details. But it won me a trip to the International Science Fair (this was before Intel started sponsoring it).
It might add to the understanding, for those who are familiar with some other legacy stuff, to note that the cbm serial data port was a reimplementation of ieee488/gpib in a shift register style to cut down on the cabling cost. It was synchronus but some fastloader software reimplemented it in an async fashion (thanks to being able to upload code to the drive) along with changing the clk wire to be another data wire.
That's a fascinating technique. Did the commodore operating system itself push 6502 code to the floppy drives to move the heads, initiate data transfer, etc?
No, the basic floppy control software resided in ROM on the 1541. But as mentioned below, you could (and people did) essentially reprogram much of that stuff to enable copy protection, increase serial throughput speeds, etc.
That's the joke basically... they took the Amiga approach at simplicity. Amazingly, Amiga's UI primitives were nothing but that. Maybe have programmers get a general idea about what the UI needs to feel like and what events are being handled. The simplicity of it is what makes it useful, and these concepts, if you put them into C directly translate to modern systems.
The variables never moved in 30 years. Stop adding visual effects if all you aim for is operational swiftness.
I was just thinking about DOS apps, specifically how nice it was when keyboard shortcuts pertinent to your current mode were helpfully displayed at the bottom of the screen.
Contiki is an RTOS and ipv6/lowpan library, intended for modern rf-capable microcontrollers with no UI.
This OS on the other hand is a desktop OS for an ancient 8-bit processor (far less capable than modern microcontrollers) and oriented around the user interface.
So... not much to compare really, they're completely different beasts.
There is (or at least was, not sure if it is still maintained) a version of Contiki for the C64, for which as far as I know also a GUI toolkit existed.
I had a 300 baud modem and text wouldn't even download close to reading speed. I need to see if this will work on my old C64 machine. Would be fun to go through a few BBS that are still around.
Even in the 90s BBS experience on a C64 was pretty dismal. Everybody was running 80x24 screens and the operators had to assume it was safe.
Shame too, because ANSI artists could have done some even more impressive works with the PETSCII character set but the world had already moved on by that point.
The BBS scene is still alive. These days, people "dial in" via telnet via WiFi modems (among other ways) using their old 8-bit and 16/32-bit hardware (e.g. Amiga). And, as long as you set your stuff to 9600 baud, it's absolutely fast enough.
Worth mentioning that GEOS itself has been completely reverse engineered and the fully commented 6502 assembler source is up on github: https://github.com/mist64/geos
In theory quite portable to other 'new' 6502/816 systems.
Oh, wow, GEOS is a name I haven't heard in a long time!
I never got the chance to use it on a real C64, but I played with it a lot under CCS64 ( http://ccs64.com/ ). I had a very slow computer at the time, too slow to run many modern games and applications, so I found a lot of interesting things to do under various emulated environments.
Edit: since we're mentioning (possibly) obscure operating systems, WingsOS ( http://wingsos.org/ ) also deserves a note :-).
I did use GEOS on a real C64 back in the day, and what I remember was that every click of the joystick button led to a disk seek to find the graphics for the next screen. If you knew the commands to display a directory, etc, GEOS made things maddeningly slow. I remember similar sentiments being expressed back in the DOS to early Windows days.
GEOS felt kind of pointless to me, like early Windows but worse. It ate so much of the limited resources on the machine that you wouldn't be able to do much while it was still in memory.
The built in word processor had a lot of cool text effects. 13 year old me thought it was much more impressive than my mom's Paperclip. It has been very many years since I used it, but I recall multiple drives improved the experience, and these days I see it is popular to run GEOS with a ram expander.
I used GEOS, and later GEOS 128, to do a lot of my homework in high school. GeoWrite was much better than an other word processor I'd used in the 64 or 128, and it used proportional fonts rather than the printer's built-in monospaced font. Printing took forever, though.
https://www.youtube.com/watch?v=T14dL9MeMHE
Speed-wise this appear to me to be about the same speed 8MHz 68000 Mac SE did run it's graphics.