Take this with a grain of Salt.... Its far beyond my programming capabilities in the amount of
time I have to devote to it. But a tiny ksh or bash would be cool as hell for the X16
All but a tiny bit of it would have to reside in BANKED Ram.
How should file and device I/O be handled?
-
ahenry3068
- Posts: 1136
- Joined: Tue Apr 04, 2023 9:57 pm
Re: How should file and device I/O be handled?
Tom,
Thanks, that makes a lot of sense. And you're right, it's a bit off topic. Sorry.
Ok. The description of Monarch as a "CP/M or DOS like operating system," and Open ROM as a "direct replacement for the X16 ROM, but fully open source." seems to be fairly incompatible with each other. I say that because the X16 is a "Commodore style" computer at it's core, and can't really be divested of that without losing it's identity.
On the other side of that fence, CP/M, DOS and ... I'll add a light version of Unix, are essentially operating shells that are pretty much computer agnostic. (You could easily propose versions of any of these on any computer without raising an eyebrow.)
So put me in the "Monarch as a CP/M or DOS like operating system." camp with a preference to a Unix style shell. But I want to use the X16 as a development platform for that because it has a CPU I like at a speed I like, and I like the VERA. I also like the choice of PS/2 connections for keyboard and mouse.
Can I assume the name, "Monarch" is because of the butterfly logo on the X16? I'm hoping there is a better etymology for that.
So: "How should file and device I/O be handled"
Keyboard, mouse: PS/2 begs to be handled by a microcontroller with 2 way communication. The only current way to do that with the X16 hardware is how it's already being done. Future add would be the 2 way part (At the very least, so we can use the scroll wheel.)
Video: VERA. Direct, low level interface. Already have that. I'm not a fan of where the port addresses are, but that can't be helped at the moment.
Storage: SDcard and FAT32. A new direct interface that only includes the FAT32 components used needs to be written.
Game controllers: Already baked in.
Multi tasking vs. Single tasking. Single all the way. Interrupts and cooperative round robin approaches to have asynchronicity.
For the distant future, one of the problems I see is the discreet interface components, I would love to see the 65C02 as a soft ISA on an FPGA that communicates to the peripherals over a high speed link like "SPI and IC2 trying to be PCI lanes." So you have the CPU communicating over a set of reasonably high speed serial links over a small connector.
Thanks, that makes a lot of sense. And you're right, it's a bit off topic. Sorry.
Ok. The description of Monarch as a "CP/M or DOS like operating system," and Open ROM as a "direct replacement for the X16 ROM, but fully open source." seems to be fairly incompatible with each other. I say that because the X16 is a "Commodore style" computer at it's core, and can't really be divested of that without losing it's identity.
On the other side of that fence, CP/M, DOS and ... I'll add a light version of Unix, are essentially operating shells that are pretty much computer agnostic. (You could easily propose versions of any of these on any computer without raising an eyebrow.)
So put me in the "Monarch as a CP/M or DOS like operating system." camp with a preference to a Unix style shell. But I want to use the X16 as a development platform for that because it has a CPU I like at a speed I like, and I like the VERA. I also like the choice of PS/2 connections for keyboard and mouse.
Can I assume the name, "Monarch" is because of the butterfly logo on the X16? I'm hoping there is a better etymology for that.
So: "How should file and device I/O be handled"
Keyboard, mouse: PS/2 begs to be handled by a microcontroller with 2 way communication. The only current way to do that with the X16 hardware is how it's already being done. Future add would be the 2 way part (At the very least, so we can use the scroll wheel.)
Video: VERA. Direct, low level interface. Already have that. I'm not a fan of where the port addresses are, but that can't be helped at the moment.
Storage: SDcard and FAT32. A new direct interface that only includes the FAT32 components used needs to be written.
Game controllers: Already baked in.
Multi tasking vs. Single tasking. Single all the way. Interrupts and cooperative round robin approaches to have asynchronicity.
For the distant future, one of the problems I see is the discreet interface components, I would love to see the 65C02 as a soft ISA on an FPGA that communicates to the peripherals over a high speed link like "SPI and IC2 trying to be PCI lanes." So you have the CPU communicating over a set of reasonably high speed serial links over a small connector.
Re: How should file and device I/O be handled?
My thoughts on banking:
I'm... not the biggest fan on banking in general. I would prefer to see a far larger "user space" as it were ("user space" is probably not the right term for this. It implies that it's separate from "kernel space" and that doesn't even apply to a non-permissioned CPU.) ... "general usage space?"
Anyway. there are a few core uses for banking. For example: The system has sets of general purpose routines that need to be switched in on a function by function basis. A couple examples would be I/O drivers and sdcard support routines.
Programs proper would be loaded as needed, I have to believe that the SDcard is sufficiently fast that virtually ANY program can be stuffed into the 64K program space in less than a second. We aren't dealing with serial floppy drives connected to a slow port.
There is already a rom flash utility, some rom banks would be off limits, but most should be available for users to load in as they see fit.
ROM banks should not be used for programs that could easily be loaded in from the SDcard.
I'm... not the biggest fan on banking in general. I would prefer to see a far larger "user space" as it were ("user space" is probably not the right term for this. It implies that it's separate from "kernel space" and that doesn't even apply to a non-permissioned CPU.) ... "general usage space?"
Anyway. there are a few core uses for banking. For example: The system has sets of general purpose routines that need to be switched in on a function by function basis. A couple examples would be I/O drivers and sdcard support routines.
Programs proper would be loaded as needed, I have to believe that the SDcard is sufficiently fast that virtually ANY program can be stuffed into the 64K program space in less than a second. We aren't dealing with serial floppy drives connected to a slow port.
There is already a rom flash utility, some rom banks would be off limits, but most should be available for users to load in as they see fit.
ROM banks should not be used for programs that could easily be loaded in from the SDcard.