Hacker News Reader

Comment by svachalek | Hacker News Reader

Back in 1989 I ran an application called GeoWorks on my Commodore 64. It had a paint program and WYSIWYG word processor and both applications and documents ran in the C64's available RAM of... 38k?

Roughly 1/100000 of what's on a low end computer today. On a CPU that ran at 1MHz and took many clock cycles per instruction.

In other words, yes but that's nothing new.

View on HN

Of course, the programs couldn't render as many pixels or colors at once, couldn't insert photographs, videos, or complex tables and charts, couldn't load complex fonts or otherwise handle nuanced typography, etc etc.

There's a heck of a lot of pointless bloat. But at least some of the extra power has gone to useful features!

Today feels different. If Slack really have any significant features that couldn't be done on computers 15 years ago?

GEOS was written largely in assembly from everything I’ve read.

Apparently this and other things did not go over well with developers (apparently the apps needed to be done at least partly in assembly too). Wikipedia:

GeoWorks attempted to get third-party developers but was unable to get much support due to expense of the developer kit — which ran $1,000 just for the manuals — and the difficult programming environment, which required a second PC networked via serial port in order to run the debugger.

Even though PC/GEOS is referred to as an "operating system", it still requires DOS in order to load. GEOS and its applications were written in a mix of 8086 assembly (Espire) and C (GOC), both with non-standard language extensions to support the object-oriented design.[5][9]

It's worth thinking about what happens when you touch your phone's screen or reach for your trackpad/mouse and scroll a bit, at 60fps. That's a basic gesture that involves a gazillion C64s of everything.

I'm thinking about it.

Processing the touches into events should take 1 C64 of power or less.

Scrolling shouldn't significantly more difficult. 1 C64 for this.

The screen is much higher resolution, so we need the power to render that, but that's offloaded to the GPU and the GPU doesn't even need to leave idle frequencies.

60fps, well what was the C64? Whatever, multiply the resources by 10.

We've now accounted for... 20 C64s of power.

but that's offloaded to the GPU

It's a little odd to exclude the supercomputer your computer comes with to help with scrolling.

Thankfully, the GPU hasn't been afflicted with terrible inefficient slowness for 2D programs. The interesting questions lie in what the CPU is doing and wasting time on.

And, I mean, the C64 offloaded rasterization to a different chip too.

To scroll the screen on the C64 actually involved a non-trivial amount of CPU usage, because the hardware can only shift the screen by up to 7 pixels, so every 8 pixels, one has to manage all of that because the VIC chip can't — this involves offset copying all of the screen RAM, which can be done over previous frames, and same for the colour RAM, except this must be done in realtime (because the colour RAM has fixed location / cannot double buffer). Doing all of this actually takes a significant proportion of available CPU time per frame in C64 games. And that's just for the character-based graphics mode, not the bitmap graphics mode — which you simply have not got a chance in hell at scrolling on the C64, because the VIC offers no assistance here and the CPU is nowhere near fast enough to do it.

Don't even get me started on drawing more than 8 sprites!

(Ex C64 games programmer here)

I think you either severely overestimate the capabilities of a C64 or underestimate what it takes to put a modern user interface experience together.

The C64 had a resolution of 320x200 pixels with 16 colors. That would cover about 1,5 square inches on a modern phone (modulo the colors, another factor of 6 to 10). You could not dream of re-rendering the whole screen with any FPS number. Games had to resort to all kind of tricks to create a smooth experience, and whatever was put on screen was pre-rendered content combined in clever ways. Calculations involving floating point like a mandelbrot set in said resolution took hours to days per _frame_.

Increasing the DPI doesn't affect the CPU, only the GPU, and it's the CPU causing problems. So please ignore pixel count when explaining why a "modern user interface" requires so much more computation that it can't react to input in 15 milliseconds.

And the C64 does re-render every frame, because there's not enough memory for a frame buffer!

I'm not worried about games here, and word processors don't need fractals.

Reply on news.ycombinator.com