Live data from Hacker News

Linux on a Commodore 64

github.com

61–70 of 97 posts

Re: Linux on a Commodore 64

#61
post #44
post #41

Earlier quoted context omitted.

Why would it let smoke out? I doubt a C64 has any power management. So whether it idles or boots Linux via a couple of emulation layers, the thermal load will be exactly the same.

I know there can be issues with thermal saturation on a heatsink design-- it was expected not just to generate N watts of heat, but to only do so for M hours. Can you expect to leave a real 64 on for days or weeks and it will stay up? I wonder if stores that had them as demo units when it was a relevant product, for example, power-cycled them regularly. I know from experience if you block the bottom intake vents on a…

I just saw a museum exhibition that featured a C64C, running all day, with a dust cover on, on what appeared to be the original PSU. I think it makes sense to be cautious about your own unit, but they’re probably not as vulnerable as people assume.

Re: Linux on a Commodore 64

#62
Very nice, but my first thought was "surely this will not fit in 64k of ram!". And it doesn't. It requires a 16MB REU!

To explain for the uninitiated how rare this bit of hardware is. The REU available for the c64 back in the day were 256kB and 512kB. These are most commonly built replicas as there are schematics available for them. Sometime in the late 90s there was also an "expansion" for c64 that contained a completely new CPU (superCPU - 65816) that was code compatible with the original and I believe this device could accommodate up to 16mb.

Later reimplementations based purely on fpga popped up including a REU with 16mb. The original SuperCPU schematic was lost to time. Allegedly fpga based expansions are available to buy for few hundred EUR now, but I don't know anyone that attempted to buy one or has one.

So, although it is a neat trick(still a cool tech achievement) , saying it runs on c64 is akin to saying I got doom3 running on a 386, but my 386 is actually a pci card in a modern pc...

If I can't pull my c64 with hardware available back in the day (or hardware one could realistically built back in the day) I'm not sure saying "runs on c64" is correct.

Coming back to the subject of a REU, why has no one published a schematic for one yet? There are cheap SRAM chips floating on ebay. It should be trivial to put one together. Unfortunately it isn't, because the original (Super Cpu) had two components we need a beefy fpga to emulate. The supercpu itself and it's dma controller which was a custom asic I believe.

Perhaps as cheap(ER) fpgas or uC with fpga-like functionality become available someone will create an open source "super cpu". As of yet, everyone I ever heard using these, uses emulation. Nothing wrong with that, but I get the most out of my "retro hobby" by running original hardware. Emulation is very useful for dev, but for general use it's a bit "meh" for me.

Re: Linux on a Commodore 64

#63
post #58
post #9

Once you add more RAM to a Commodore 64, is it still a Commodore 64?

Expanding from Johnwbyrd's nearby: -- Commodore sold a Ram Expansion Unit named "1764" to bring the C64 to 256kb of RAM; -- it was possible to use the REU for the C128 named "1750" to bring the C64 to 512kb of RAM; -- and it is possible to expand on that to have a 2MB REU for the C64 - see https://www.neperos.com/article/rlut8ce90fbb7701 You can have two megabytes on the C64, pretty "legally".

I can imagine "someone" back in the day could take PC SIMM modules and cobble together some monstrosity that would allow one to fill 16MB of RAM on a c64 using simple bank switching. However, the main "innovation" of these original and later REUs wasn't the memory amount, but the chip that implemented DMA. That DMA chip could be used to copy ram contents very quickly with minimal CPU involvement. This is why c64 equipped with the REU has much better graphics capabilities (used for background animation etc).

As far as I know, we still don't have an open source equivalent of that dma chip.

Re: Linux on a Commodore 64

#65
post #61
post #44

Earlier quoted context omitted.

I know there can be issues with thermal saturation on a heatsink design-- it was expected not just to generate N watts of heat, but to only do so for M hours. Can you expect to leave a real 64 on for days or weeks and it will stay up? I wonder if stores that had them as demo units when it was a relevant product, for example, power-cycled them regularly. I know from experience if you block the bottom intake vents on a…

I just saw a museum exhibition that featured a C64C, running all day, with a dust cover on, on what appeared to be the original PSU. I think it makes sense to be cautious about your own unit, but they’re probably not as vulnerable as people assume.

Definitely the Achilles heel in any C64 setup. Perhaps new PSUs are visually distinct from the old ones, but practically everyone had to replace theirs as they aged.

Now the 64C was released in 1986, four years after the 64 and its faulty power supplies came out. I don't know whether Commodore had decisively fixed the flawed PSUs by that time, but I know for sure that my second PSU lasted for the lifetime of that device too.

Re: Linux on a Commodore 64

#67

This begs the question. What is the oldest hardware that can boot modern Linux but still be used as a daily driver?

The main "daily driver" constraint is probably the crypto required to access most modern websites. You can make the leanest and meanest system you can to run great on the slowest machine but the internet is nowadays an unforgiving place.

Surely video encoding / decoding is more compute intensive than the crypto. Taking video calls is a reasonable part of being daily driver capable.

Re: Linux on a Commodore 64

#68
post #43
post #41

Earlier quoted context omitted.

Why would it let smoke out? I doubt a C64 has any power management. So whether it idles or boots Linux via a couple of emulation layers, the thermal load will be exactly the same.

Just because it's likely an old and long dormant piece of electronics, nothing to do with linux beyond it having to run the machine for multiple days 24x7. My understanding is they don't come out of deep dusty storage in ready for service condition. Leaky caps.

C64 caps are generally fine and do not need replacing. The most common things to spontaneously go bad of ”old age” on a 64 are probably RAM chips and the PLA, and of course the power supply is a time bomb.

Re: Linux on a Commodore 64

#69
post #62

Very nice, but my first thought was "surely this will not fit in 64k of ram!". And it doesn't. It requires a 16MB REU! To explain for the uninitiated how rare this bit of hardware is. The REU available for the c64 back in the day were 256kB and 512kB. These are most commonly built replicas as there are schematics available for them. Sometime in the late 90s there was also an "expansion" for c64 that contained a compl…

If I can't pull my c64 with hardware available back in the day (or hardware one could realistically built back in the day) I'm not sure saying "runs on c64" is correct.

A 16MB REU could absolutely have been built in the 80s. It would have been absolutely astronomically expensive, but there’s no technical reason it could not be done. You seem to be confusing the SuperCPU with a plain REU expansion — the REU is just a bunch of RAM and an ASIC that talks to the 64 and allows it to store or retrieve banks of RAM (because obviously a 6502 cannot address more than 64K so instead you have to tell it to swap out system RAM) — there is no CPU on it.

The SuperCPU (65816) can indeed address up to 16MB directly and that is a different thing. The project in the OP runs on a stock C64 on the stock C64 CPU, it just needs a mountain of RAM that would have cost the equivalent of a house back then ;)

Re: Linux on a Commodore 64

#70

Earlier quoted context omitted.

I've yet to see the 6502 C compiler that can beat good assembly code. I appreciate the convenience and llvm-mos has certainly improved greatly, but if you want speed on a 6502, there's no substitute.

I've yet to see a 6502 C compiler get within sight of good assembly code. C makes many assumptions that are slow to implement on a 6502, and are notoriously hard to optimize.

https://www.youtube.com/watch?v=2lW3WHPtmKo
Post reply on HN