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

Linux on a Commodore 64

github.com

Post reply on HN
Print view View original

81–90 of 97 posts

Re: Linux on a Commodore 64

#81

Post by diydsp »

johnwbyrd wrote: post #59
wk_end wrote: post #27

Earlier quoted context omitted.

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/…

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 n…

I found it interesting it didnt utilize the X reg. Maybe instead of updating Y, X could have been used. Then I scrutinized the Y reg use:

On line 14, it uses Y, then decrements it to 0, uses it, increments it, uses decrements, uses it, then increment again.. why not perform the indirect load on lines 18 and 26 without the Y index and eliminate lines 16, 21, and 25?

here's my pseudocode:

rc2 rc4 = rc2 + 4 // addr of dx

rc5 = rc5 + 0 // addr of x

rc6 = *(&rc2+4)

rc4 = *(&rc4+1) // get low byte

rc5 = rc6 + *(&rc2) // add high byte

rc4 = rc4 + *(&rc2+1) // add low byte

rc2 = rc5 // store high result

*(&rc2+1) = rc4 // store low result

I believe it could have done more to do the work in place, but my batt is about to die :(

Re: Linux on a Commodore 64

#82

Post by jpc0 »

charcircuit wrote: post #67
speed_spread wrote: post #26

Earlier quoted context omitted.

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.

Video delivered in real time over an encrypted connection, this is a double whammy.

You need to both decrypt and decode all at above the framerate of the video, doubt that will be doable on any older hardware, unless ssid hardware has dedicated components for those functions.

If I had to implement this on an old CPU I would likely be passing network, video and encryption off to co-processors and the older chip will effectively only be running control information.

But that that point why not just use a modern low power chip.

Re: Linux on a Commodore 64

#83

Post by codeflo »

johnwbyrd wrote: post #17
wk_end wrote: post #11

Earlier quoted context omitted.

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

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.

The problem likely isn't what the compiler produces given the semantics of a piece of code, but rather what you'd do with data structures and memory layout if you'd target the 6502 directly.

Re: Linux on a Commodore 64

#84

Post by gattilorenz »

brazzy wrote: post #64

That 16MiB memory requirement makes this rather disappointing, given that you can run Linux on machines with only 4 MiB of RAM: https://tldp.org/HOWTO/4mb-Laptops.html#toc3

That’s written for linux 2.2.x at best, SysV init, old versions of bash (or maybe even ash) and whatnot.

I don’t think you’ll manage with a recent linux kernel. Heck, even 2.6-era stuff won’t fit easily.

Re: Linux on a Commodore 64

#85

Post by Sharlin »

Roark66 wrote: 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…

> but my 386 is actually a pci card in a modern pc...

Now I want one of those. I guess these days you could easily fit a 386, 486, Pentium and who knows what other SoCs on a single PCIe card, passively cooled…

Re: Linux on a Commodore 64

#86

Post by wk_end »

dezgeg wrote: post #75
johnwbyrd wrote: post #59

Earlier quoted context omitted.

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 n…

I think that was partially his point - on 6502, typical-looking C code will be horrifically inefficient, at least when compared to other architectures more suitable for C. For 6502, to get the optimum assembly you'd have to structure your data in structure-of-arrays instead of arrays-of-structures and use indices instead of pointers as much as possible (at least when amount of Ball objects would be < 256).

Yes, exactly. Were I hand-writing the assembly for the 6502, I'd make all sorts of decisions that the C code doesn't - and that a compiler can't - to make it more efficient.

Instead of passing in a pointer to two separate functions, I'd write a single UpdateBalls procedure that operated on global data. This data is going to be core to my game logic and physics, so I'd put it all on the ZP. As you suggested, "structure-of-arrays". I'd choose a fixed number of balls so I don't need an argument; maybe I'd set my loop to iterate backwards so I get a free zero check with the decrement, maybe I'd unroll the loop ("dead" balls can be placed off-screen with a dx/dy of 0). I'd probably decide that I don't need 16-bit precision for the deltas (how fast could the balls move, really?), and a 16-8 addition is going to be quicker than a 16-16 one.

The compiler isn't going to make these optimizations; that's not a slight against the compiler. In fact, I just checked - the output [0] when I write my C code this way is pretty close to what I'd hand-write. It's roughly a third the number of instructions and - I'm not going to cycle count, so this is a stab in the dark - would take maybe an order of magnitude fewer cycles to run. semu wasn't written with performance on the 6502 in mind, it's not going to have taken considerations like this, so it's going to inevitably be slow when compiled.

[0] https://godbolt.org/z/WYKKeh9b7

Re: Linux on a Commodore 64

#87

Post by LocalH »

jandrese wrote: post #48
johnwbyrd wrote: post #25

Earlier quoted context omitted.

The loading screen reports 130 BogoMIPS, but remember that it's emulating the timer as well, so the number is meaningless.

I assume that's the "warp speed" BogoMIPS, on real hardware the number would be around 1.

AFAIK, C64 software cannot detect the difference between normal and warp mode in normal circumstances. Warp mode speeds up the emulation, but all of the internal timings are still accurate to the C64 in a relative sense.

Re: Linux on a Commodore 64

#88

Post by ryukoposting »

whartung wrote: post #32
ryukoposting wrote: post #24

I recently came into possession of a fully-functioning TRS-80 Model 4, and I fantasize regularly about putting some vaguely Unix-esque thing on it. The fantasy continues.

You should be able to boost that up to 128k. Once there you have a solid chance of being able to run Fuzix on it. Start there and you’ll find a rabbit hole of reasonable depth.

Jesus, the documentation for Fuzix is... well, there isn't any is there! This will be an adventure.

Re: Linux on a Commodore 64

#89

Post by jandrese »

LocalH wrote: post #87
jandrese wrote: post #48

Earlier quoted context omitted.

I assume that's the "warp speed" BogoMIPS, on real hardware the number would be around 1.

AFAIK, C64 software cannot detect the difference between normal and warp mode in normal circumstances. Warp mode speeds up the emulation, but all of the internal timings are still accurate to the C64 in a relative sense.

I have to wonder how the Bogomips are calculated on a machine with no RTC.
Post reply on HN