Hacker News new | past | comments | ask | show | jobs | submit login

> I suspect the argument against modern Intel chips is just their complexity.

Well that, and the fact that we already have plenty of OSes to run on x86(-64).

Looking at arch/ in linux's source:

  alpha  avr32     frv      Kconfig  microblaze  openrisc  score  um
  arc    blackfin  h8300    m32r     mips        parisc    sh     unicore32
  arm    c6x       hexagon  m68k     mn10300     powerpc   sparc  x86
  arm64  cris      ia64     metag    nios2       s390      tile   xtensa
I'm surprised that it doesn't have support for Z80 if it's so common.

I'm also surprised that I can't see mention of Z80 in GCC's documentation.

The z80 is an 8-bit processor released in 1976. It's not an appropriate target for Linux for many reasons, including: no processor support for process isolation, massively divergent hardware setup in different applications, lack of processing power, lack of modern c compiler, etc. I don't think any of the mainstream Linux ports run on anything less than a 32-bit processor; although there are some fringe ports to 16-bit systems.

I'm somewhat surprised there's no Z80 support for GCC, I recall running a gcc for Motorola's 68HC11 which is a similar processor. That said, most general purpose C compilers are a bad fit for 8-bit processors; you really want to write assembly for these small systems to ensure your code is compact and fast; it's much too easy to write code in C that will be significantly slower than if well written in assembly because of limited memory indexing modes or lack of registers. It's probably possible to carefully constrain your C usage to encourage reasonable assembly output, but then you're not going to be able to use existing C code. You won't have that much code that fits in your roms anyway, so you may as well dig in and write assembly.

The Z80 can't run Linux due to the lack of an MMU. (Though it's possible to get around that through emulation: see http://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bit for example.)

There is Fuzix.

[1] http://www.fuzix.org/

And Symbos.

[2] http://www.symbos.de/

I wonder if he knows about them?

No 6502, either. There aren't many 8 bit CPUs that are considered a reasonable platform for any UNIX. Which is why I think I'd prefer 68000 family. It's "modern enough" to use with modern compilers and operating systems, but simple enough for a one man garage shop to build/maintain a computer that uses it. I guess earlier 80x86 chips could fit that bill, too, but 68000 has a better assembly language.

The 68000 still did not have an onboard memory-management unit, though.

The was only introduced with the 68030, which is roughly analagous and contemporaneous with the Intel 80386.

The 68040 added an onboard FPU, like the 80486. (And like the 486SX, the 68040EC had the onboard FPU removed again.)

>I'm surprised that it doesn't have support for Z80 if it's so common.

That's because it's an 8 bit computer, my dude. Back in the old days, when "the internet" was still a military project, and you'd phone up your local BBS at 2400 baud on a POTS with suction cups; that's all the little people had access to as recently as the early 80s. And as other people said, there are apparently many of them around, and they run on shit power supplies.

It's a cool idea, but obviously it requires both cheap and dirty hardware implementations and a paper manual. Pretty sure "hacking" will be low on the hierarchy of needs in the event of apocalypse. Also pretty sure something like CP/M would be more useful. I know where there are CAMAC crates with Z80/CPM punched card/paper tape readers that would probably do great in a post apocalyptic environment.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact