Countercomputing Manifesto
-
While the eZ80 at 50MHz obviously outperforms the 65C816 at 14MHz, the eZ80 is a large surface-mount package, while the '816 is a simple DIP. For the hobbyist, this is also a factor. However, in the modern age, it is simple to have a breakout module or carrier board made which puts the eZ80 on a pin grid array, for example.
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.
-
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.
Then again, there is an excellent cross-compiler for the 65816 arch (Calypsi), which might make developing an OS easier.
All of this is moot, of course, if there turns out to be a better option for CPU.
-
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
As long as you provide simple IO routines, you can run C64/PET BASIC on the 6502. The C64 kernel has actually quite a nice operating system API even though it's single threaded and lacks in memory management. Itball comes down to providing IO drivers -
Countercomputing Manifesto
Draft 0.0.1
For decades, computing power has been steadily growing, without a commensurate boost in the utility to the user. In fact, this increase in power has largely been used against the user -- extracting value from the user, at little or no benefit to the user, primarily for the benefit of corporations who produce and sell nothing of real utility themselves.
We assert that the sole agency over the use and output of privately owned tools belongs with and only with the owners of those tools; we assert an inherent right to decide for ourselves what software will and won't run, and when, on computers we own and operate for our own private benefit, and the same right held collectively over shared computers.
Further, we assert the right to revoke our consent to be used as a resource by the advertising and surveillance industries, as well as any other party not named specifically.
We therefore resolve to create, under common purpose and shared ownership, a new standard for a computing device, which is designed to educate and empower the owner, rather than to expose and exploit them.
I like where you're going with this. We need a new personal computer revolution that stays personal and accessible.
Once the corpos took control of the PC revolution they steered it in the direction they wanted. The new revolution needs more people like Woz and his open designs and less people like Steve Jobs and Epstein's good friends like Bill Gates.
-
Then again, there is an excellent cross-compiler for the 65816 arch (Calypsi), which might make developing an OS easier.
All of this is moot, of course, if there turns out to be a better option for CPU.
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). -
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 I wonder how hard it would be to port UXN to a system like that.
-
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).The level 1 hardware standards would be designed to use as much common, off-the-shelf hardware as possible, to make it easier to build a compliant system.
Imagine, for example, an RCBus system that fit into an ATX case and power supply?
-
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 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... -
@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 The Z180 and eZ80 have something like an MMU baked in, but multitasking may be asking a bit much.
-
The level 1 hardware standards would be designed to use as much common, off-the-shelf hardware as possible, to make it easier to build a compliant system.
Imagine, for example, an RCBus system that fit into an ATX case and power supply?
@mos_8502 Seconding the Z80. RC2014 has a massive ecosystem on Tindie etc. The Microbeast is halfway to a portable option. I think as soon as someone opens a central place to dump info and plug it into this framework to make those things do actual, current day work instead of just being individual pieces of nostalgia and experimentation, that place will be packed within a year.
-
@mei The Z180 and eZ80 have something like an MMU baked in, but multitasking may be asking a bit much.
@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... -
@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
