Countercomputing Manifesto
-
@mos_8502 hm, what are the capabilities of the eZ80's "something like an MMU"? I tried looking it up in the datasheet real quick but didn't find anything that I'd expect to be what you're referring to...
@mei I know it has some kind of memory management that lets you program the chip selects.
-
@mos_8502 hm, does either the Z80 or 6502 family support an MMU? I feel like a proper multi-tasking operating system would be hard to support otherwise...
@mei @mos_8502 You can do multitasking just fine without an MMU, you just have to trust the programs not to poke addresses they're not supposed to. This is the approach taken by 68k macs. The main thing you need is code that is position independent, something that 6502 isn't really designed for especially since zero page and stack are fixed addresses. But I think the 816 is a bit more flexible, and ez80 probably more flexible still.
-
@mei @mos_8502 You can do multitasking just fine without an MMU, you just have to trust the programs not to poke addresses they're not supposed to. This is the approach taken by 68k macs. The main thing you need is code that is position independent, something that 6502 isn't really designed for especially since zero page and stack are fixed addresses. But I think the 816 is a bit more flexible, and ez80 probably more flexible still.
-
A survey of available CPUs which fit the requirements:
- Z80 family (Z80, Z180, eZ80)
- 6502 family (65C02, 65C816)
- RISC-V (potentially)
The Z80 family has several in-production chips, all of which meet the requirements.
The 6502 family has four in-production chips, two of which are effectively systems-on-chip that expose the full system bus.
There is no current RISC-V CPU which meets the requirements, but as it is an open architecture, it is certainly possible for someone to design and implement one.
@mos_8502 This might be of interest to you - "how to implement memory and I/O protection on a z80 with minimal external circuit." https://youtu.be/DLSUAVPKeYk
-
Let us make a temporary, for-the-sake-of-argument example of what standards might look like:
Level 0:
- Z80 CPU at 18MHz or faster
- VT-100 terminal or compatible emulation
- ROMWBW HBIOS/CBIOS Support
- CP/M-3So level 0 is intentionally very broad, and essentially a reification of several existing systems.
Level 1:
- All requirements for Level 0
- 512KB of RAM
- Hardware designed according to the level 1 guidelines (replacing RC2014 or the like)Level 2:
- All requirements for levels 0 and 1
- CP/M-3 replaced with custom community-built OS (think MSX-DOS but with long file names).@mos_8502 Regarding Level 2, I think it might be make sense to have AmigaDOS like...long name, friendly command set, etc. Not complicated like UN*X/bash.
-
At least initially, having software tools to run on a new system is preferable. There exists no OS we could simply pick up and use for the 65816. The eZ80 is supported by ROMWBW, which provides a fairly complete implementation of CP/M to run on the eZ80.
@mos_8502 I haven't used CP/M since my Commodore 128 days. While I agree CP/M is a "punk rock" choice, it wasn't the most fun thing to actually use. GEOS on the C128 though was very serviceable. I wonder how hard it'd be to make a GEOSish thing for the Z80 that could use CP/M for a terminal?
-
@hatzka Doesn’t have to be memory mapped. Just has to be some kind of parallel bus suitable for connecting, for example, a serial UART.
-
@hatzka Modern MPUs tend to provide very proprietary interfaces. It’s not even possible to access the graphics acceleration on a Pi5 without Linux blobs.
-
@mos_8502 What if you focused on some kind of virtual architecture? Something like, for example WebAssembly (just using it as an example, not an endorsement), then your hardware platform could change and evolve as needed as different CPUs become available, or stop being available? Were this to be a reasonable option, the virtual architecture would have to be simple enough such that a VM for it could fairly trivially be implemented on this set of 8 bit CPUs
@mos_8502@studio8502.ca @TomGwozdz@oldbytes.space
i think risc-v is designed for this sort of thing
-
@hatzka That there isn’t a good alternative? I feel like we’re talking past each other. Modern SoCs are unsuitable for a dozen good reasons. Much as I’d love it to be otherwise - that’s why I’d love to see a good RISC-V FPGA core with an exposed bus.
-
@hatzka That there isn’t a good alternative? I feel like we’re talking past each other. Modern SoCs are unsuitable for a dozen good reasons. Much as I’d love it to be otherwise - that’s why I’d love to see a good RISC-V FPGA core with an exposed bus.
@hatzka I can’t take a design built around the chip from an rpi and sub in the chip from a pine board.
-
@hatzka You can, and it gets you freedom to choose components much more freely. I’m not personally a Z80 guy historically, I’m big invested in 6502 and 65816, but of the options that leave designers free to select components properly, the eZ80 offers the best performance. A discrete RISC-V would blow it out of the water easily, if only someone would make one.
-
@hatzka There’s a severe shortage of purchasable parts to use those interfaces. I can’t just go to Mouser and buy a PCIe UART or the like. And that’s to say nothing of the board level design insanity you have to do to make use of DDR SDRAM.
Older, slower interfaces may well be older and slower, but they have their own advantages.
-
@hatzka Arguably yes, and that sort of thing is why it’s a first draft.
-
J jowek@autonomous.zone shared this topic
