5 ms·

Onno Kortman has taken semu, a minimal RISC-V emulator, and cross-compiled it with llvm-mos, an LLVM port to the MOS 6502 processor, in order to run Linux on th

Onno Kortman has taken semu, a minimal RISC-V emulator, and cross-compiled it with llvm-mos, an LLVM port to the MOS 6502 processor, in order to run Linux on the Commodore 64. Kortman writes: "The screenshots took VICE a couple hours in 'warp mode' to generate. So, as is, a real C64 should be able to boot Linux within a week or so."

mattl 3y ago
I'd be curious to see this running on real hardware. I hope someone's able to make it work.
- pengaru 3y ago
  It might be more interesting than watching paint dry, just via risk that an old C64 will let the smoke out.
  - usr1106 3y ago
    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.
    - pengaru 3y ago
      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.
      - einr 3y ago
        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.
    - hakfoo 3y ago
      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 VIC 20, so it can't convect properly, it will eventually start acting funky. On a related note, I understand the 64's original power bricks are considered timebombs, they might also not appreciate being left on for weeks at a time.
      - userbinator 3y ago
        Can you expect to leave a real 64 on for days or weeks and it will stay up? Yes. These early computers found their way into various embedded control applications too, and I suspect there's quite a few C64s still in operation that way; they would've been replaced long ago if they weren't stable. An article occasionally appears when someone discovers this: https://news.ycombinator.com/item?id=12604414 https://news.ycombinator.com/item?id=12604414
      - exitb 3y ago
        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.
        NoZebra120vClip 3y ago
        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.
      - vidarh 3y ago
        A fairly simple diagnostic test for a C64 is to touch the chips - if the machine is in working order the chips will be warm to the touch but not uncomfortably so. If any are uncomfortably warm odds are they've failed. If you block all air circulation, sure you might eventually end up with problems, but it takes quite a bit.
wk_end 3y ago
The 6502 is a notoriously poor target for C compilation, especially C that hasn't been written with the 6502's limitations in mind. I'll bet if you wrote a RISC-V emulator in native 6502 you could get Linux booting on a real machine in a day instead of a week. Think about how many lives that'd save! https://www.folklore.org/StoryView.py?story=Saving_Lives.txt https://www.folklore.org/StoryView.py?story=Saving_Lives.txt
- johnwbyrd 3y ago
  Says you. llvm-mos generates surprisingly efficient 6502 code given its age and maturity. Don't take my word for it, try some experiments with it on godbolt.
  - wk_end 3y ago
    Sure. Here's a couple of functions to iterate over an array of "Ball" objects, as you might do in a Breakout-style game that has a multi-ball powerup. I didn't do anything to make it particularly 6502-amenable; it's how I'd write it for a modern machine, probably. Even compiled with -O2: as expected, the code is slow and enormous - a single addition compiles to something like 30 instructions. [0] https://godbolt.org/z/f6Ysv7nve https://godbolt.org/z/f6Ysv7nve
    - deleted 3y ago
      [deleted]
    - johnwbyrd 3y ago
      Seems like your problem is more with the venerable 6502 itself rather than the compiler. Most of that assembly code is spent calculating the offsets inside the Ball struct, which must be done at 16 bits of resolution in every case. The compiler's using the indirect indexed (zero page address with Y offset) 6502 addressing mode to get at all the fields in your struct. It has placed all the variables in zero page, so no instruction is more than two bytes long; additionally, the code in question is entirely linear, with no JSRs or other subroutines. Note in particular how it efficiently uses DEY/INY pairs of one byte instructions to get at low and high bytes of 16-bit memory. Hand-written assembly might be speedier, but not by much and still deal with all the corner cases that your generated code does. "While writing Apple BASIC for a 6502 microprocessor I repeatedly encountered a variant of Murphy's Law. Briefly stated, any routine operating on 16 bit data will require at least twice the code that it should." -Steve Wozniak
nxobject 3y ago
Oh wow! This bootstrapping method reminds me of yet another Linux-on-an-8-bit-micro project (https://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bit https://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bi...), which used an 8-bit AVR with an ARMv5 emulator. But, this takes the cake in terms of geek coolness.
- userbinator 3y ago
  That's exactly what it reminded me of too; there's been plenty of HN discussion about it: https://news.ycombinator.com/item?id=19762928 https://news.ycombinator.com/item?id=19762928

mattl 3y ago

I'd be curious to see this running on real hardware. I hope someone's able to make it work.

pengaru 3y ago
It might be more interesting than watching paint dry, just via risk that an old C64 will let the smoke out.
- usr1106 3y ago
  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.
  - pengaru 3y ago
    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.
    - einr 3y ago
      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.
  - hakfoo 3y ago
    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 VIC 20, so it can't convect properly, it will eventually start acting funky. On a related note, I understand the 64's original power bricks are considered timebombs, they might also not appreciate being left on for weeks at a time.
    - userbinator 3y ago
      Can you expect to leave a real 64 on for days or weeks and it will stay up? Yes. These early computers found their way into various embedded control applications too, and I suspect there's quite a few C64s still in operation that way; they would've been replaced long ago if they weren't stable. An article occasionally appears when someone discovers this: https://news.ycombinator.com/item?id=12604414 https://news.ycombinator.com/item?id=12604414
    - exitb 3y ago
      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.
      - NoZebra120vClip 3y ago
        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.
    - vidarh 3y ago
      A fairly simple diagnostic test for a C64 is to touch the chips - if the machine is in working order the chips will be warm to the touch but not uncomfortably so. If any are uncomfortably warm odds are they've failed. If you block all air circulation, sure you might eventually end up with problems, but it takes quite a bit.

wk_end 3y ago

The 6502 is a notoriously poor target for C compilation, especially C that hasn't been written with the 6502's limitations in mind. I'll bet if you wrote a RISC-V emulator in native 6502 you could get Linux booting on a real machine in a day instead of a week. Think about how many lives that'd save! https://www.folklore.org/StoryView.py?story=Saving_Lives.txt https://www.folklore.org/StoryView.py?story=Saving_Lives.txt

johnwbyrd 3y ago
Says you. llvm-mos generates surprisingly efficient 6502 code given its age and maturity. Don't take my word for it, try some experiments with it on godbolt.
- wk_end 3y ago
  Sure. Here's a couple of functions to iterate over an array of "Ball" objects, as you might do in a Breakout-style game that has a multi-ball powerup. I didn't do anything to make it particularly 6502-amenable; it's how I'd write it for a modern machine, probably. Even compiled with -O2: as expected, the code is slow and enormous - a single addition compiles to something like 30 instructions. [0] https://godbolt.org/z/f6Ysv7nve https://godbolt.org/z/f6Ysv7nve
  - deleted 3y ago
    [deleted]
  - johnwbyrd 3y ago
    Seems like your problem is more with the venerable 6502 itself rather than the compiler. Most of that assembly code is spent calculating the offsets inside the Ball struct, which must be done at 16 bits of resolution in every case. The compiler's using the indirect indexed (zero page address with Y offset) 6502 addressing mode to get at all the fields in your struct. It has placed all the variables in zero page, so no instruction is more than two bytes long; additionally, the code in question is entirely linear, with no JSRs or other subroutines. Note in particular how it efficiently uses DEY/INY pairs of one byte instructions to get at low and high bytes of 16-bit memory. Hand-written assembly might be speedier, but not by much and still deal with all the corner cases that your generated code does. "While writing Apple BASIC for a 6502 microprocessor I repeatedly encountered a variant of Murphy's Law. Briefly stated, any routine operating on 16 bit data will require at least twice the code that it should." -Steve Wozniak

nxobject 3y ago

Oh wow! This bootstrapping method reminds me of yet another Linux-on-an-8-bit-micro project (https://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bit https://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bi...), which used an 8-bit AVR with an ARMv5 emulator. But, this takes the cake in terms of geek coolness.

userbinator 3y ago
That's exactly what it reminded me of too; there's been plenty of HN discussion about it: https://news.ycombinator.com/item?id=19762928 https://news.ycombinator.com/item?id=19762928