C64 OS: make a Commodore 64 feel fast and useful
c64os.com
c64os.com
In the "golden era" computers were more or less advanced calculators. Now we (as a population) expect to give entertainment and give advice about our lifestyle, like we do with smartwatches or fitness devices.
That's a lot more complicated than writing text or inputting numbers into a grid
I always think about Lindy effect [1] in this context: the life expectancy of a technology, idea or (in our case) a societal habit is proportional to its current age. It follows, then, that the idea of a multi-purpose computing device may also wear off in certain areas of life, or for certain types of people. Not always, not everywhere is there a need for complex or complicated devices or systems. There will always be people who seek or prefer a simpler, quieter life that involves as little technology as possible.
What's really interesting is that many of these people seem to have a remarkably deep understanding of technology, and great skills [2]. Possibly because of this knowledge, they're really clear (or, pedantic :) about what they don't need.
In the end, though, I've come to think that this may be more of a simple psychological preference (for less stimulation) than a rationalized choice. Who knows.
1: https://en.wikipedia.org/wiki/Lindy_effect
2: Some of the people I really look up to: http://collapseos.org/, http://joeyh.name/, https://sassenrath.com/
Everything you ever loved about Delphi 7, but with a ton of modernization. LGPL, too!
Not so surprising, given the backgrounds of the key designers of Go, I feel. Griesemer even got his PhD under Mössenböck and Wirth.
"A Programming Language for Vector Computers"
https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.42....
As a user on an hypothetical Oberon workstation, I would rather have Active Oberon than Oberon-07 as official systems language.
I guess if you want to make gobs of cash, fine. You could also just go into finance and make more than FAANG money if you're talented enough.
Even if there is 2 step forwards, one step back, the overall benefit of options available due to the vast number of people contributing their creativity is only possible due to these companies.
They’re also one of the top AI/ML research institutions in the world with a huge chunk of the papers published at top conferences.
Similar statements are also true of Google.
Also there are other Pascal to JavaScript transpilers, which use other dialects of Object Pascal, such as DWScript and Smart Pascal.
Either way those are things that allow you to use Free Pascal code in the web on the client side, but they aren't really "Lazarus" things. Once the full RTL can be used via pas2js or wasm, it could be possible to make a web-based backend for LCL but that would feel kinda alien as you'd essentially be embedding a desktop application inside a web page.
It is also possible to make new form (object) designers for a new type of form (object) that acts more like a Flash page or something like that, but that would require a lot of work. On the other hand it might make making mobile apps better too.
"Microsoft will acquire Skype, the leading Internet communications company, for $8.5 billion"
It's because today isn't about programmer productivity.
It's about enabling teams to work together without tripping over their own feet and killing the business.
So much complexity to solve essentially what is a human problem.
It takes 5 people to do the job of 1 back then, and that's what the industry wants. No one would trust an individual.
Too much money flowed into this industry, leading to waste, as it became clearly a pillar of the future.
That's the entire point of "soft"ware. Otherwise there would be no point on doing on a CPU what could be made on an integrated circuit 1000 times faster.
A single guy writing whatever code they decided to do, may create a good program. But as requirements change, and the ownership gets passed on, it quickly becomes a nightmare to modify or refactor.
Good code made in SlowScript® by a team based on consensus on architecture and coding style has more potential for success as a product than the fast and optimized spaghetti code made by the best hacker in the world.
I believe the sibling saying that it's programmer productivity is correct. That same programmer can and does now spend a week whipping together a program in Python that took a year under the older constraints. And users expect more out of them, with whizz-bang animations and app-store integration.
But if that same programmer _did_ spend the year instead of the week, what could they do? The quality and performance would probably be a lot better. Unless they depend on externalities that don't also scale up their quality game, like basically anything involving the web.
If you believe this is the case then you can put your belief to the test. Build software the way you think it should be built and see if users are willing to pay for it.
"users willing to pay for it" is a very bad and simplistic metric because there is way more to user willingness to pay for something than how that something was made (not to mention that it excludes everything the user doesn't pay for) - it may not even have to do with the software itself.
Also the software in question may not even be "free" to use the better approach: imagine, for example, a client for a chat service that allows embedding images, videos and audio in messages but the way the protocol works is for the server to provide those as iframe and/or html content. At that point the client will have to use a browser component in one way or another with all the baggage that entails even if the features themselves (images, videos, audio and text) could be implemented directly by the client.
There is only so much you can do when you have to interface with a world built on tech that doesn't care about efficiency.
Modern computers have opened programming up to more people by making it simpler but with the tradeoff of more runtime execution cost.
The software we build today is "vastly" more powerful in the sense that, strictly speaking, you can do more stuff, but it is way less powerful - and often broken - than what it could be, considering what you can see being possible on older hardware and what seems to be done in modern hardware.
Also it isn't really something that happens today, here is a nice (and funny) talk from Joe Armstrong on the topic from almost 8 years ago[0]. Though this sort of sentiment goes way back, e.g. Wirth's classic "Plea for lean software" article from 1995[1].
(Joe's talk is more about the broken part and IMO he misidentifies the issue being about trying to make things fast when the real issue -that he also mentions- is that pretty much nobody knows what is really going on with the system itself)
Then again, performance is often a feature in itself. In some cases it can open whole new areas of potential business. Often times it isn't even particularly hard to achieve, it just requires decent engineering practices.
Unfortunately good engineering practices can be hard to find/hire for, especially among a development community/culture that hasn't had to bother caring about performance for a long time.
And for what? to edit a text box?
There are new capabilities around encryption and encoding, things like h265 and etc, which of course help with medical diagnostics and such.
I would take c64 software any time, look at this https://www.youtube.com/watch?v=ROr8JhilPhI its from 1983.
Imagine what kind of software would the people from 1980s write if they just had a raspberry pi 4 to work with..
In the 1980s only a small portion of the developed world's population used home computers. Today the majority of people use computing devices. Most of them use languages that cannot be represented with PETSCII or ASCII. It's amazing what motivated people can do with low power machines, but let's not forget how going back to the 1980s would discard valuable capabilities as well as bloat.
These people weren’t magicians only held back by a lack of computer power, they were (again, “are”) regular people trying to maximize their output given their resources.
Let’s say you go back and hand a powerful computer to them. What would Mac Paint look like? I’m sure it would have colors (assuming you also have them a monitor), probably a lot more of those goofy and useless textured fills nobody wants, layers, probably some filters, higher resolutions, and probably simple brush strokes. But do you really think they would manage to implement any of the seriously impressive features that modern Photoshop has? Content aware fill? AI upscaling? Of course not. It would probably take them a long time to get smart selection working in a halfway decent manner.
Honest question here: have you actually tried to find the answer to that question?
As I'm writing this comment, my 2019 Pixelbook Go is quiet. It's a fanless design, so it being quiet is normal, but it is also not running hot. I've got around 30 tabs open, a few terminals, Emacs, and some other stuff running.
So back to my question - have you looked into what is actually going on in your machine? Dust in the fans?
Though codecs are one of the few cases where you see hardware being taken advantage of because that is basically their entire purpose.
I doubt you can do it without a "modern PC" with hardware graphic accelerator.
Also modern codecs require lot of computations and lot of memory. For example, codecs like VP9 require to buffer up to 8 frames for reference. That would take 8×3840×2160×4 ~ 265 Megabytes of RAM. The program will need to extract bits, decode arithmetic coding and calculate lots of IDCTs.
I did some research to see if it is possible to play Youtube video on 8-bit CPUs. What I found is that there is little hope for this. It's better to develop your own video compression format.
Or an analog signal and you do it the way TVs used to do. There were analog HDTV standards before we all moved to digital.
8-bit computers likely wouldn't be able to keep up with the bandwidth requirements of those systems either.
Also, nothing stops you from implementing an 8-bit CPU with a modern process and push it into the multi gigahertz range except perhaps the fact it’ll be too small for current machinery to manipulate.
Modern digital transfer protocols are generally 10x the pixel clock in analog terms. For a given clock speed, analog video can be several multiples of effective resolution delivered on time.
Analog standards seem to have stopped at 1080p. Nothing prevents signalling faster, but there are no capable displays to read it. I suppose that might be a neat FPGA project. Take 4K analog signals and stream them to a digital display. Really would only need a scanline or two of buffer for the simpler "just push all the pixels" use case. Frame buffer.
Nobody mentioned anything about 60 fps. A ton of video is at 24 or 30 fps.
> requires transferring of 3840×2160×60 ~ 497 million pixels or 1,49 Gbytes per second (if you skip every fourth byte).
You do not need to update the entire screen all the time, you can do partial updates (since very frequently not 100% of the screen changes - it is the most basic fact on which video codecs rely on) and you can "heal" the output over time after partial updates (also important for video playback where you can't guarantee a fast stream).
> I doubt you can do it without a "modern PC" with hardware graphic accelerator.
Why the limitation for hardware graphics accelerators? Hardware accelerators exist for decades now and even hardware video decoders exist for more than a decade. If anything not using those is "not taking advantage of the hardware" that i mentioned.
> Also modern codecs require lot of computations and lot of memory. For example, codecs like VP9 require to buffer up to 8 frames for reference. That would take 8×3840×2160×4 ~ 265 Megabytes of RAM.
Sure, but that is RAM computers also had for more than a decade now - the PC i used in the early/mid-2000s had 2GB of RAM - hell, even the cheapo EeePC netbook from the late 2000s had 1GB of RAM.
> I did some research to see if it is possible to play Youtube video on 8-bit CPUs. What I found is that there is little hope for this. It's better to develop your own video compression format.
Sure, but i never mentioned anything about 8-bit CPUs, YouTube or even existing video compression (or specific framerate for that matter). What i wrote is that you do not need "modern PC power" to do 4K video. You do need more processing power than what would be found in 8-bit CPUs (or at least common 8-bit CPUs you'd find in 80s home computers), but i'm certain you can have a 10 year old PC play 4K video without trying that much. Perhaps even a 15 year old PC with a bit of effort.
FWIW what i had in mind when i wrote that comment was the "8088 Domination" demo which used a custom codec and player to do fullscreen video and audio playback on an original IBM PC and honestly i do not for one second buy the notion that if you can do that on a 40 year old PC you wont be able to have 4K video on a 15 year old PC - if anything i might be too generous here.
You forget that you are expected to keep up to 8 reference frames. And you need to update them too.
> You do not need to update the entire screen all the time, you can do partial updates
This would work only until first keyframe.
You refer to VP9, i explicitly mentioned i do not refer to any specific codec but just to playing back "4k video". The rest were never something that i referred to, implied or even mentioned in the message i replied to.
> This would work only until first keyframe.
This depends heavily on how the video is encoded and that is only assuming you can't find a way to occasionally update the full screen.
That 99% is dedicated to running Chrome
What we've done with it is things like: when you type text into what looks like a simple edit field, each keystroke launches a cascade of javascript.
Layers and layers of API's cause latency. To get this to happen, you have to talk to this broker, which calls this proxy, which delegates to this manager, which queries this store, ...
You will probably almost never see call stacks 27 frames deep when debugging anything in C64.
But, for other tasks, it's not a billion times faster; single-threaded 16-bit integer code might get 0.125 operations per clock cycle on the C64 and 3 operations per clock cycle on a modern CPU with a 4000 times faster clock, making the modern computer only about 96000 times faster. The way I look at things, 96000 is closer to being 100 than it is to being a billion.
In cases like that, it's only making you wonder what we're doing with the other 99.999%.
Once your program is using more data than will fit on a 1541, though, everything totally changes.
Merely adding two 16-bit integers on the 6510 takes 14 cycles on fixed zero page locations for operands and destination. You'll easily spend 150 cycles on a general 16x16 multiplication using look-up tables. Not even measuring the juggling of values into and out of these fixed zero page locations via three 8-bit registers or the stack, we're talking about something like a tenth of your estimated op/s for an even mix of additions and multiplications. So I'd say much closer to a million times faster for a use case like this than 96000.
There may be special cases where the 6510 achieves 0.125 16-bit operations per second, for example multiplying by constant two and adding constant one (10 and 6 cycles, respectively)
16-bit singe threaded integer code seems like a rather contrived example as well. We're after all typically not running 16-bit applications over MS-DOS on our monster machines. Just booting into my OS will result in all cores being used to execute a bunch of 32/64 bit operations.
It would be interesting to see something like a modern cryptographic hashing algorithm implemented on a 6502 and compare performance both on long messages and on many smaller messages. This should give us an idea of how much slower a 6502 is at integer operations.
To clarify, by "16-bit integer code" I meant code that doesn't use floating-point, in which most of the arithmetic is done on 16-bit values, not code for a 16-bit integer machine like the 8086 or code consisting entirely of 16-bit arithmetic operations. My reason for picking 16-bit was that most of my integers fit into 16 bits, but often not 8 bits. Usually arithmetic that needs more than 16 bits of precision is address arithmetic, and on the 6502 (or 6510) that's often handled by the 8-bit X and Y registers. Even multiplies are much less common than addition, which in turn is less common than MOV. And of course jumps, calls, returns, and 8-bit-index loops (inx; bne :-) suffer comparatively less slowdown than the actual 16-bit operations in the 16-bit integer code, and they usually constitute the majority of it.
I agree that cryptographic algorithms routinely do very wide arithmetic. They want as many ALU bits as they can get their little anarchist hands on. But I think they are atypical in this.
When I look at the applications running on the computers sitting around me, most of the things they're doing seem like they would fit well into the 16-bit integer arithmetic bucket, so I don't think it's contrived. The way they're doing those things (in JS, with JIT compilers, using floating point, dynamic typing, and garbage collection) is tailored to the bigger machines we usually use, but the applications (text editing, spreadsheets, networking, arguing with strangers who know more than I do, text layout, font rendering, previously futures trading) are not. The big exceptions here are 3-D graphics and video codecs, which want ALUs as wide as possible, just like crypto algorithms.
https://en.wikipedia.org/wiki/GEOS_%288-bit_operating_system...
> [...] had good intentions but pushed the machine in ways it wasn't designed for, compromising on speed and usability in the pursuit of features available on more powerful computers.
I must be honest and say the statement feels a bit puzzling, since C64OS certainly wasn't something the C64 was designed for...
My C64 now has a USB interface 8)
Shared Libraries for C64 OS - https://news.ycombinator.com/item?id=26590376 - March 2021 (1 comment)
Rethinking the Commodore 64 Memory Map (2018) - https://news.ycombinator.com/item?id=20317767 - June 2019 (17 comments)
C64 OS: A Commodore 64 OS with Modern Concepts - https://news.ycombinator.com/item?id=17997911 - Sept 2018 (42 comments)
> C64 OS has one goal. Make a Commodore 64 feel fast and useful in today’s modern world.
So I guess whatever "useful in today's modern world" means. What does this new OS allow me to accomplish on a C64?
File / Disk management. The file manager program shown looks spiffy, and is definitively a nod toward today.
Write utilities and apps that have a modern workflow.
While not much, the included tool kit has the features needed to make applications and utilities people might recognize today.
The author has put quite a bit into it. Nice work.
http://c64os.com/c64os/usersguide/ (screen shot)
Here's an FPGA-based drop-in replacement for 65C02 that runs at 100MHz: http://www.e-basteln.de/computing/65f02/65f02/
Not tried in a C64 yet, but he did get it working in a Commodore PET.
Most accelerator boards for the C64 need quite a bit of glue logic to overcome these difficulties.
"Upon power-on, the 65F02 grabs the complete RAM and ROM content from the host and copies it into the on-chip RAM, except for the I/O area. Then the CPU gets going, using the internal memory at 100 MHz for all bus accesses except for any I/O addresses"
There's also some soft cores for a Z80 that can work at the stock clock speed, but do more work per cycle, which is interesting.
Edit: Some, not all, things are covered.
This machine had DOS and W4WG 3.11 before that and prior to that I had a 80486 and before that a 80286 plus a '287 co pro with just DOS 3-5ish so I had a preconception on what streaming text consoles should look like. I'd also used some green or amber screens with something large and complicated behind them. That's what IT looks like to most people (something complicated) - don't forget that! My memory grows a little dim but I think it was a Pentium II box that I first slapped Linux on.
25 years later.
I update my various Linux boxes in a minute or two at most. I update Windows boxes in a few hours at most - normally around 15 mins but several hours is not unknown.
I do have 2 C64 but, too bad, this isn't open source, so I won't be going anywhere near it.
But if you've got a C64, you've got a license for it.
"C64 OS", you would have to buy separately. Whether it would make sense to invest time and effort into writing applications for is debatable.
Personally, as a developer who enjoys working on vintage hardware, I'd rather put that effort into either making my software not require "C64 OS" or in writing a suitable, open source replacement to that system.