Hacker News Reader

Comment by SwellJoe | Hacker News Reader

I'm already subbed to all of the subreddits about Commodore and retro computing. But, good tip for anyone who might not know there's such a thriving scene still hanging in there. The old machines are fun in ways that modern things can't replicate. Sure, we can do so much more today, with so much less effort...but a single human being can hold all of the Commodore 64 in their head (by that, I mean, it's possible for someone to understand every component, and if really ambitious reproduce all of it, or some components of it, from scratch...and a few people have, in FPGAs, among other things).

I have a real C64 (along with a MSSIAH cartridge to make a nice synth), but rarely have the time or space to tinker with it.

View on HN

I dug up an "old" link to a presentation on the history of CPU design the other day, and part of it comes to mind now.

He talked about how back in the early days ram and cpu was pretty much equal in clock. Thus if you could fit your program in ram, you could calculate how fast your program would run based on how many instructions you used to do things.

These days the cpu is many multiples fasters than ram, and thus cache misses is these days what disk access was back then. And because of how the cpu is now multiple cores, pipelines, and multiple tiers of cache, you can't simply sit down and step through the code to look for instruction bottle necks.

Never mind the layers upon layers of libs and whatsnot sitting between your program and the hardware.

Even games consoles are like this now, as they have turned into multimedia gateways. The last generation of consoles that came close was perhaps the PS2 and Gamecube (the Xbox was more a stripped down PC than a games console, and likely started the trend leading us to the present day).

> He talked about how back in the early days ram and cpu was pretty much equal in clock. Thus if you could fit your program in ram, you could calculate how fast your program would run based on how many instructions you used to do things.

That's exactly how I started programming, as a child, on a Z80 based system.

> back in the early days ram and cpu was pretty much equal in clock

Not "pretty much". On most early system they were clocked exactly the same. That includes things like the C64 and th Amiga, where there was no cache on the basic models (on Amiga models with 68020 or above there was some cache).

On the C64 in particular, timing things to the clock cycle was essential for some demo effects. E.g. if you used a hardware sprite, it'd "cost" the CPU access to RAM for two clock cycles per scanline that you had to account for if you wanted certain effects to work, for example.

The "hold all of the <machine> in their head" is what I'm missing today. I wish there was something more modern along those lines my kid could grow into--essentially a C64 with HDMI. [edit] And a SD card slot!

There's Maximite, which is VGA: http://geoffg.net/maximite.html

Let's be honest, 6502 assembly is way better than x86 assembly, any day of the week.

Could you explain why? I have quite a bit of experience with Z80 and x86 (16bit) assembly. I remember that I've tried to learn 6502 many years ago but lost interest after a while. I remember that 6502 didn't feel superior to me then, quite opposite.

It's extremely simple. It's too simple for modern use, given that it doesn't have 16 or 32 bit instructions and lack mul/div etc., and doesn't have a decent sized stack, but for a small system like the C64 the simplicity was great - it was easy to learn, and for things like demo programming it's easy enough that you can quickly learn to remember how many cycles each instruction + addressing mode takes.

If someone where to build a machine like that I think the 8080 (or at least the z80, which is still manufacturered) would probably be the best choice. The Intel 8080 is very clean and well thought out compared to the 6502. (try writting an emulator or assembler for both)

Reply on news.ycombinator.com