Hacker News Reader

1) Turn on computer.

2) 500ms go by

3) Computer prints "READY" and shows a blinking cursor.

At this point you can start typing code.

That is what I miss about 80s computing.

4) Spend 10 minutes saving your carefully written code to tape.

5) Scream at the tape the next day because it stretched a bit and the computer now won't read it back, or your little sister recorded the spice girls over it :P

I did love that time too though! But it did have its drawbacks.

But really, this experience is not far away if you're looking for it. A raspberry pi kinda offers that. Maybe not the 500ms, but it boots in seconds to a CLI and it's cheap enough to just leave running. Windows 10 is also really fast at booting (basically because it secretly just hibernates its kernel but it's a smart and useful trick).

You had tape? I had to retype all my programs any time I power cycled my computer :-)

Well in effect that same thing happened to me.. Atari's tape drives were horribly unreliable. It was a tense time listening to the screeching during read operations. You could usually hear it go wrong, and some error would appear, having to start all over again (and the position counters were cheap and unreliable too).

My 1010 tape drive also had really really thin plastic stems under the buttons, which pressed on quite heavy mechanical tape controls.. Obviously they didn't last much longer than the warranty period :X I removed the front panel and pushed the metal parts by hand for a while until the whole thing just gave out.

The new-style XE tape drive I got after that was better but still had the poor reliability.

There was also a disk drive option but it cost more than the computer itself (and in fact it was almost another computer as it was powered by a similar CPU, just with less RAM). So being a schoolboy I never owned one.

You had a keyboard? I had to reenter the sequences of toggle switches every time I turned on my MIPS.

3) Prepare to load yesterday's work from the tape

4) Tape does not load for some reason, retry.

5) Tape still does not load, retry.

6) You remember your friends brought some games yesterday and you had to tweak tape player's head position. Where is your screwdriver again?

7) Spend 20 minutes trying to re-align the heads so you can load the tape.

...

If you want "turn on and start coding" experience, then programmable calculators are your friend. Really, give them a try -- they have the same BASIC, support your familiar "PLOT 10,0" commands, but at the same time do not lose all your data when you turn then off, and do not require tapes.

That is essentially possible with any laptop today, regardless of OS.

Just fullscreen a terminal and start your favorite repl. You can even have basic if you want.

It's possible, but it's just not the same thing. There are orders of magnitude more layers of abstraction in play. "Fullscreen a terminal" implies graphics - so X, toolkits, window managers, on top of kernel and userland etc. It would take you decades to wrap your head around all that; a little 6502 computer you can grok in a month.

Quick, what stovepipe of software would let you type "PLOT 10, 10: DRAW 20, 20" to draw a line :)

Any system with Python (so any Linux system)? Here is a real-example, just tested on my Ubuntu PC:

    $ python3
    Python 3.6.9 (default, Oct  8 2020, 12:12:24)
    [GCC 8.4.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from turtle import *
    >>> penup()
    >>> setposition(10, 10)
    >>> pendown()
    >>> setposition(100, 100)

Not quite the same commands, but pretty close. And you have more modern things like "bgpic", "onclick" and entire Python library.

https://docs.python.org/3/library/turtle.html

Yeah, but you're missing the point the parent is making. On a C64, you boot into bare basic and can immediately start playing with sprites and lines and stuff. With a modern computer you have BIOS, 80 bazillion lines of Windows or Linux, your Python installation and about 90 layers in between. It's simply not possible to fully understand a modern computer. Just take a look at all the lines of code in Windows and Python that lets you play with turtle graphics (forget about the other million lines of other code I don't even know about). Then, compare that sum with the amount of code in the C64. See the difference? Sure a modern computer does a lot more, but it's also a black-hole/ accretion disk of bad design glued together.

Well, what is your goal?

If you want to play with sprites and lines and stuff, use modern PC. It does the things that poor C64 never dreamed of, and if you want constraints, there are always things like "1k demos" which let one express their creativity while keeping the minimal amount of code around.

if you want to understand stuff down to the metal, there is a whole embedded world out there. From the simple 8051 with a half-dozen registers to 32 bit ARMs where you can learn how to set up DMA transfers. (My favorite one is 8-bit AVR: the datasheet is small enough you can read it end to end, there are plenty of peripherals, but at the same time it is slow enough you have to occasionally solve "how to code this quickly" puzzle)

I see no reason to mix those two, except because of nostalgia. Yes, in the past you had to be blacksmith and woodworker -- but those are gone. You can still mix those two, and the very first rasp you made still feels very special, but let's not pretend it was somehow better than the modern store-bought one.

I'm not sure if there is a goal here, just pointing out how times have changed. I shift between we should throw out the whole modern desktop and completely redesign it from the ground up to resigning myself to the understanding that the complexity is unavoidable in a fashion if you want networking, USB, web browser, GPU...etc.

The desktop itself doesn’t really seem very ‘modern’. It’s really not very different from what was available in the 80’s and 90’s, just with better graphics on some systems.

Most of the complexity in those things you mention comes from asynchrony.

> On a C64, you boot into bare basic

Come on. I think you're remembering the past with rose colored glasses. I loved my C64 in the 80s but it was not user friendly, compared to say an iPad running playgrounds.

This is what is was like when things worked. https://dfarq.homeip.net/load-commodore-64-games/

When things didn't work...

True, Python is good for this, it also comes by default on mac!

Probably just an emulator if you want that to actually work.

Yes, it does take decades to wrap one’s head around all that stuff, but you don’t have to in order to have a straightforward programming experience.

Take this for example: https://docs.racket-lang.org/quick/

Almost as simple, vastly better to learn.

And it’s not like we understood how graphics worked, or how the basic interpreter was built in order to type those commands anyway. Even if some of us do now, most people who used those machines never understood them.

I do agree with you in essence - I want that simplicity back, but I don’t miss actually using those machines. I wrote some quite complex software in BASIC, and have no desire to return to that.

I want something with the immediacy and programmability of that era, but with modern capabilities and programming concepts.

Yeah, I basically want a machine with a fast CPU and lots of RAM that boots into something like LISP or Forth with a very minimal OS (SD card navigation, text editor, image and audio file player, simple graphics).

We have a group that has been playing with that concept, songseed.org/dinghy, including the notion of a ‘forth workstation’.

Through this, I have found networking to be a significant design pressure on the rest of the system, inviting complexity. The comparison of retrobsd and litebsd in the pic32 paper talks about this.

Another conclusion - if you want the platform to be relevant on high end hardware, you must use Windows or Linux as part of your foundation due to the gpu driver situation.

It sounds like you've thought this through pretty well. Once you add in networking and a web browser, it might not be possible to avoid all that complexity.

I feel like I have only scratched the surface :) If you take interest in this, we hang out in #dinghy on freenode. We have bursts of activity, and then long periods of silence.

But I do feel like the world is ripe for a revolution in a few directions here.

-- Browser

To your point that a conventional browser creates unavoidable complexity: I agree.

It may be possible to disrupt that stack entirely, by creating something that developers would prefer to develop for.

The new conversational interaction between whatsapp users and corporate chatbots (e.g. airline rebooking over whatsapp) shows developer and user appetite for non-HTTP internet activity. As does Slack, somewhat.

This gopher-like 'Gemini' thing that has been popping up recently is interesting.

On the Dinghy website, there is a proposal for an engine, /Limit/. It would be a Forth VM that would maintain an async connection back to a webserver-like server. Instead of having HTTP+HTML+CSS+Javascript, you would deliver sites as forth bytecode. This could be tighter yet more flexible than a web browser. An Everything-Is-A-X based overthrow of the current web browser model.

/Limit/ could be simulated in a browser (using javascript and websockets) so that people who only had a browser could browse a Limit server without adding new software.

Hypothesis: /Limit/ would have common purpose with alt-OS communities that do not have first-class browsers: Haiku, Plan9, Amiga, Suckless, people who run old SGIs for fun. Imagine if you could just recompile a C codebase, and change some headers, and get a full-featured browser-like thing running on these systems.

-- Networking

I am confident that there is a non-complex path through this problem.

Hypothesis: interaction with the systems API should be purely asynchronous, and TCP interaction will look nothing like the Berkeley sockets API.

Tanenbaum warns of the dangers of an async systems API (http://songseed.org/dinghy/tanenbaum.html).

But there is an occam-based OS, RMoX, that looks to be a demonstration of the async OS concept. I hit obstacles trying to evaluate/verify this.

On the Dinghy website, there is a paper for "Drift". This proposes an async OS for the amd64 architecture. I noticed drafting problems in this paper earlier, will revise soon.

The addition of io_uring to Linux may allow another approach: create an async API mezzanine on io_uring; regard this as your Bedrock, rather than the hardware itself.

Once io_uring is mature, it may be possible to fork Linux in order to discard /all/ syscalls except io_uring. This kernel would have ongoing Linux driver support, but with a much smaller kernel surface area.

-- Your requirements

Regarding your stated requirements, 'SD card navigation, text editor, image and audio file player, simple graphics', you could build this on top of the Maximite architecture. But it would lack networking.

Whereas the Dinghy concept goes beyond your stated requirements.

Sounds like I'd love to play with the system y'all are hoping to build. I'd also be ok with something like a web browser, but just Forth scripts being shared like you said. As long as I have text and images and a way to view them, I don't think anything else matters.

It sounds like y'all are trying to build the original internet OS (iOS, but years before Apple took the term) that Carl Sassenrath of Amiga and Rebol fame was trying to build. Rebol is a lot like both lisp and forth, and is very powerful. Carl thought users would just share Rebol scripts over the network. To give some context, a fully graphical tetris is like 3/4 a page of Rebol code. If only he had open sourced it sooner.

Thanks for your note. I have had a several bursts of play with Red, but it keeps slipping my mind. I suspect it would be an easier starting point than building up Forth from nothing.

There may be a challenge bootstrapping that ecosystem on obscure platforms. If I remember correctly, you need an existing Red or Rebol in order to build the latest Red.

I will update the Limit page with a reference to this.

No problem. Rebol is built on C I think and is an interpreted language that I would guess is similar to Ruby in speed (as in fairly slow). Red should be a lot faster, but I wonder if they'll ever get there with the project being so ambitious. I do think you currently need Rebol to build the Red binary, but it'll eventually be fully self hosted and under 5 MB in size. A Red OS would be pretty neat as in you could use the high level words in interpreted mode and throw in some Red-System level code for performance if you need it. I'm a little concerned though that some of the high performance libraries will be commercial. I don't mind paying, but licensing always gets cloudy in those cases.

https://bbcmic.ro/

Is pretty close:

https://bbcmic.ro/#%7B%22v%22%3A1%2C%22program%22%3A%22MODE%...

That's absolutely true. It was much simpler to start creating. Now you have a choice in platforms that can achieve the same with similar effort, but you have to start by picking and installing one, whereas those computers came with it.

PS: You also used an Atari? I think it was DRAWTO there :)

Have you seen Scratch [0]? It runs entirely in the web browser and you don't need to install it.

It is designed for kids and it looks a bit goofy with all those drag-and-drop programming commands, but don't be fooled -- it is a pretty modern language, with flow control, variables, functions and all.

At the same time it is great for "just start creating" things -- you start by drawing pictures, then you animate an object and the next thing you know you have a fun game :)

[0] https://scratch.mit.edu/

Never heard of it, looks cool. Thanks!

They have some modern machines meant to replicate that experience, but on more modern hardware (Ex: 480 MHz lets your BASIC code run way faster than Assembly could on those 8-bit machines), but you still boot straight into BASIC (pretty much no OS) in about 3 seconds. Pretty nifty.

Buy an M1 Mac or iPad.

PCs were not the only alternative to Macs in the Early 80s and 90s.

In front of me I have an Amiga 600 (with an accelerator) and the whole OS can be installed from 5 floppy disks and is roughly equivalent to MacOS. I also have an Atari ST 1040 with TOS. No autoexec or IRQ madness to deal with. They mainly just work.

> By the way, a Mac still lets you select a boot drive in the exact same way.

The UI might be similar here, but the experience is vastly different. Back in The Day it was pretty common to build customized System Folders by hand to fit your personal needs and your machine's resource limits, e.g. to fit in a RAM Disk on a PowerBook to save battery on the go. The minimum bootable (note: not "usable") blessed folder could be just two files — a System suitcase and the Finder executable.

I know what you mean, but I wouldn't say it was pretty common. Most of the systems I saw back then had very long boots while all the random 20 extensions fired up.

Yes! This! Sooooo much time tweaking extended vs expanded memory (who came up with those names?) and fiddling with sound card IRQ settings to get a new game running.

I would be delighted to get text copy/paste/selection semantics back from iOS 1. There’s just no excuse for the modern pain.