Here's a video of a classic Mac OS style UI running on 1.79MHz Atari 8-bit computers. I find this to be a very very impressive feat.

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.

I've been searching high and low for a Linux port of GEM.

Related: Old computers did it better!

https://www.youtube.com/watch?v=0wDtxYeJdzg (8-Bit Guy)

At which point have you just replaced so much hardware that you've just got a modern PC on your desk?

Especially when you start adding modern peripheral hardware that contains more general-purpose processing power than the C64's CPU itself.

Nothing special, this game already started when you replaced your datasette with the floppy drive back in the days.

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]

[1] https://en.wikipedia.org/wiki/Commodore_1541#Hardware

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.

You could also use it as a home-brew multiprocessor. I did that as a science fair project.

That's kind of amazing. How did you communicate between the onboard CPU and the CPU in the floppy drive(s)?

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.

Computer of Theseus.

I could ask Amiga X5000 owners the same. :D

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.

It’s going to take a bit more than some storage and a network widget to get to that stage...

Interesting to read about pull-down menus being useful as I suffer from their removal on current GTK apps.

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.

You can get that in Emacs with the which-key: https://github.com/justbur/emacs-which-key

Remember the cardboard cutouts that sat over the F-keys and listed what each did? Used by ex. Wordperfect.

Yes, unfortunately. "Reveal Codes" FTW :)

alt-f3 is burned into my brain forever.

I'd like to see a comparison of this against Contiki.

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.

Contiki used to run on the Commodore 64 and have a desktop UI. Someone even used it to make a Twitter client for the C64, called Breadbox64.

http://www.c-64.org/pics/os/contiki1.html

https://commons.wikimedia.org/wiki/File:Contiki-C64.png

https://www.c64-wiki.com/wiki/Contiki

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.

Reminds me of KnightOS, a project in a similar vein. https://github.com/KnightOS/KnightOS

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.

It was fine, in the 80's, for me, because I didn't have anything better to compare it to.

So... like GEOS. But, with more awesome?

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.

Can it run some programming language like turbo pascal?

I still have my C-64 pascal compiler from Abacus software. Apparently it can now be downloaded online.