Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C64 OS: make a Commodore 64 feel fast and useful

c64os.com

Post reply on HN
Print view View original

101–110 of 112 posts

Re: C64 OS: make a Commodore 64 feel fast and useful

#101

Post by pjmlp »

vidarh wrote: post #100
pjmlp wrote: post #97

Earlier quoted context omitted.

Griesemer PhD's is related to Oberon. "A Programming Language for Vector Computers" https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.42....

I've read it. I "binged" on pretty much everything published by Wirth and Mössenböck's groups at one point. His work on Oberon really underlines the point that it's unsurprising that Go has similarities in terms of design goals.

Indeed, although the pursuit for minimalism is where my appreciation for Wirth's work kind of winds down.

As a user on an hypothetical Oberon workstation, I would rather have Active Oberon than Oberon-07 as official systems language.

Re: C64 OS: make a Commodore 64 feel fast and useful

#102

Post by badsectoracula »

codedokode wrote: post #65
badsectoracula wrote: post #58

Earlier quoted context omitted.

> Playing video is very expensive task. Just updating 4K screen at 60 frames per second 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 change…

> You do not need to update the entire screen all the time, you can do partial updates 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 forget that you are expected to keep up to 8 reference frames. And you need to update them too.

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.

Re: C64 OS: make a Commodore 64 feel fast and useful

#103

Post by badsectoracula »

analognoise wrote: post #88
badsectoracula wrote: post #39

Earlier quoted context omitted.

No but that isn't because of Lazarus itself but because "Netflix/FAANG" doesn't use it as what it does isn't really in their business interests. Lazarus is mainly about making desktop applications. It can do web, etc but it isn't really a focus and you lose most of the visual functionality anyway (yeah ok, you can set up URL routing via the object inspector and connect DB components together, but 99% of the work is d…

There's a JS transpiler in the works for FreePascal, iirc.

AFAIK pas2js doesn't fully support the full runtime library yet and i think the language isn't completely implemented. IMO the wasm target will be more interesting and was merged into the main branch earlier this year, though i don't know how usable it is.

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.

Re: C64 OS: make a Commodore 64 feel fast and useful

#104

Post by boomlinde »

kragen wrote: post #84
kazinator wrote: post #77

Earlier quoted context omitted.

It's closer to something like the other 99.9999999%. 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 s…

"the other 99.9999999%" would imply that computers now are a billion times faster than a C64. For some tasks, that's true; a GeForce RTX 3090 is claimed to be 36 teraflops, which is a billion times 36000 flops, and the C64 is more like 10000 flops if we figure we need 100 clock cycles per floating-point operation. But, for other tasks, it's not a billion times faster; single-threaded 16-bit integer code might get 0.1…

> single-threaded 16-bit integer code might get 0.125 operations per clock cycle on the C64

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.

Re: C64 OS: make a Commodore 64 feel fast and useful

#105

Post by hedora »

boomlinde wrote: post #104
kragen wrote: post #84

Earlier quoted context omitted.

"the other 99.9999999%" would imply that computers now are a billion times faster than a C64. For some tasks, that's true; a GeForce RTX 3090 is claimed to be 36 teraflops, which is a billion times 36000 flops, and the C64 is more like 10000 flops if we figure we need 100 clock cycles per floating-point operation. But, for other tasks, it's not a billion times faster; single-threaded 16-bit integer code might get 0.1…

> single-threaded 16-bit integer code might get 0.125 operations per clock cycle on the C64 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 t…

Also, modern xeons can do 32 dual precision floating point ops per cycle, per core. Since they have dozens of cores, that’s another factor of 1000, with your 10x overhead estimate for the C64, that brings the speedup to ~ a billion. (96,000 * (10 to 150x) * 1000 ~= 1-10 billion)

Re: C64 OS: make a Commodore 64 feel fast and useful

#106

Post by rbanffy »

setpatchaddress wrote: post #76
rbanffy wrote: post #49

Earlier quoted context omitted.

> Playing video is very expensive task. Just updating 4K screen at 60 frames per second requires transferring of 3840×2160×60 ~ 497 million pixels or 1,49 Gbytes per second 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.

> 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.

Not the original 6510, but there are some very fast 8-bit processors out there. If you compress the color space, they may be able to flip every pixel 30 times per second.

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.

Re: C64 OS: make a Commodore 64 feel fast and useful

#107

Post by kragen »

boomlinde wrote: post #104
kragen wrote: post #84

Earlier quoted context omitted.

"the other 99.9999999%" would imply that computers now are a billion times faster than a C64. For some tasks, that's true; a GeForce RTX 3090 is claimed to be 36 teraflops, which is a billion times 36000 flops, and the C64 is more like 10000 flops if we figure we need 100 clock cycles per floating-point operation. But, for other tasks, it's not a billion times faster; single-threaded 16-bit integer code might get 0.1…

> single-threaded 16-bit integer code might get 0.125 operations per clock cycle on the C64 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 t…

I very much appreciate the corrections, particularly from someone who knows the architecture so much better than I do. Most days I regret commenting on HN, but today is not one of those days.

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.

Re: C64 OS: make a Commodore 64 feel fast and useful

#108

Post by kragen »

hedora wrote: post #105
boomlinde wrote: post #104

Earlier quoted context omitted.

> single-threaded 16-bit integer code might get 0.125 operations per clock cycle on the C64 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 t…

Also, modern xeons can do 32 dual precision floating point ops per cycle, per core. Since they have dozens of cores, that’s another factor of 1000, with your 10x overhead estimate for the C64, that brings the speedup to ~ a billion. (96,000 * (10 to 150x) * 1000 ~= 1-10 billion)

Yes, SIMD operations on CPUs are in many ways similar to GPU computation.

Re: C64 OS: make a Commodore 64 feel fast and useful

#109

Post by snvzz »

mvexel wrote: post #81
snvzz wrote: post #72

Lovely. I do have 2 C64 but, too bad, this isn't open source, so I won't be going anywhere near it.

Commodore DOS was never formally made open source either, was it?

AIUI it was not.

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.

Post reply on HN