i understand that cp/m needs 16 bit registers and it had binary compatibility (and copyrights) problems, but i can't understand why in the past a similar general os wasn't so public as cp/m was.
Another example, with different target, was msx platform, also based on z80.
i'm not sure, but i think that it doesnt exist a 6502 porting of cp/m
(i dont wanna open a duplicate of this viewtopic.php?p=7442 maybe we can stay on cp/m)
CP/M and 6502
You're correct; CP/M doesn't exist for the 6502. Though, all things considered, knowing what we know today, it's probably not a good idea to implement a CP/M clone today. Commodore's KERNAL and Atari's OS are surprisingly competent as operating systems go, offering an I/O and single-process model not unlike Plan 9 from Bell Labs today.
In roughly 2KB of code, you can implement a more contemporary version of Commodore's KERNAL interface that supports both per-character and per-buffer I/O (e.g., Unix-like read() and write() calls), kernel-managed handles, etc.
In another 2KB of code, you can implement a hierarchial directory service mapping files, directories, sockets, etc. to installable device drivers.
All of this assumes no multitasking, of course. If you want multitasking, add another 1KB or so of code to manage processes. You might find you need another KB of so to dynamically manage memory.
I think, what you seem to be lamenting about really, is the lack of a command-line shell that sits on top of such a substrate.
In roughly 2KB of code, you can implement a more contemporary version of Commodore's KERNAL interface that supports both per-character and per-buffer I/O (e.g., Unix-like read() and write() calls), kernel-managed handles, etc.
In another 2KB of code, you can implement a hierarchial directory service mapping files, directories, sockets, etc. to installable device drivers.
All of this assumes no multitasking, of course. If you want multitasking, add another 1KB or so of code to manage processes. You might find you need another KB of so to dynamically manage memory.
I think, what you seem to be lamenting about really, is the lack of a command-line shell that sits on top of such a substrate.
kc5tja wrote:
I think, what you seem to be lamenting about really, is the lack of a command-line shell that sits on top of such a substrate.
and maybe it's not so portable, but i'm not full competent about that: i think that calls are full of internal state and irregoular parameters passing.a command line invole a dos, but maybe before that an o.s. need memory management, basic independert hardware i/o at least, as you write me.
irq/nmi must be managed also and, why not, tasks?
also a kernel reloc/loader?
for example, i'd like to have a clear video and keyboard driver, where i can call "cls" "home" "print" "newline" like a vt100 terminal and, asking more, curses lib if and only if it can fit in some kbytes, portable.
some 6502 emulators have some kernel trap like that: a kernel trap maybe is too slow in a real 6502 environment, but sometime to time speed is not so important like usability, so a kernel call table with indirect jumps (amiga?) costs cpu, but is it so important?
ptorric wrote:
maybe i like a clear well documented kernel call list as in cp/m
Quote:
i think that calls are full of internal state and irregoular parameters passing.
Quote:
a command line invole a dos, but maybe before that an o.s. need memory management, basic independert hardware i/o at least, as you write me.
Quote:
irq/nmi must be managed also and, why not, tasks?
Quote:
also a kernel reloc/loader?
Using a relocatable object file format (o65 comes right to mind) will ensure that programs can be loaded at any address and expect to work. It also permits software to use standard libraries too.
Quote:
call "cls" "home" "print" "newline" like a vt100 terminal and, asking more, curses lib if and only if it can fit in some kbytes, portable.
Quote:
some 6502 emulators have some kernel trap like that: a kernel trap maybe is too slow in a real 6502 environment, but sometime to time speed is not so important like usability, so a kernel call table with indirect jumps (amiga?) costs cpu, but is it so important?
Personally, I rather like the idea of a static jump table for libraries. I find the system of dynamically linking used by contemporary operating systems to be confusing, implemented in a half-assed manner, and in the particular case of Linux, fundamentally foreign to what the OS kernel actually expects from binaries. This isn't to say I don't appreciate the services they provide -- but is the complexity of dynamic linking REALLY worth it?
My experience tells me no.
I miss AmigaOS.
kc5tja wrote:
Quote:
call "cls" "home" "print" "newline" like a vt100 terminal and, asking more, curses lib if and only if it can fit in some kbytes, portable.
Quote:
Amiga's libraries got the idea of a jump table from the Commodore PET, 64, and 128 computers, actually. KERNAL implements a jump table into OS in upper ROM memory (e.g., $FFD2, used to send a character to the current output device, is coded as a JMP to the actual code).
Personally, I rather like the idea of a static jump table for libraries. I find the system of dynamically linking used by contemporary operating systems to be confusing, implemented in a half-assed manner, and in the particular case of Linux, fundamentally foreign to what the OS kernel actually expects from binaries. This isn't to say I don't appreciate the services they provide -- but is the complexity of dynamic linking REALLY worth it?
My experience tells me no.
I miss AmigaOS.
Personally, I rather like the idea of a static jump table for libraries. I find the system of dynamically linking used by contemporary operating systems to be confusing, implemented in a half-assed manner, and in the particular case of Linux, fundamentally foreign to what the OS kernel actually expects from binaries. This isn't to say I don't appreciate the services they provide -- but is the complexity of dynamic linking REALLY worth it?
My experience tells me no.
I miss AmigaOS.
6502 exec.library? mmmmhh.... fascinating!
(btw: i'm googling around for getting better doc about commodore kernal, because i think i miss a decade from '90 to '00 maybe 'cause amiga and work, of course )
exec is a task oriented, that maybe is not what a 6502 environment needs, so semaphore, messages and other sweetes.
what about a wish list?
let me try, i split in two parts:
------- section without d.o.s., the core -------
* vt100 like i/o
* memory manager
* relocator (but without dos...i'm not so sure)
* irq/nmi manager
* list manager? (8 bit list can be nice too)
* basic task switch? optional if kbytes permit.
------- section with d.o.s. -------
* extended i/o for disk-like devices (disk, flash, rom)
* buffered i/o
* loader/saver/overlay with "segment" support like in o65 format
* virtual memory like in first mac co-op o.s.? forth does!
* thread, signals
in this forum i read a lot about 16bit 65xxx, i'd love to speak about 8bit 65xx if possible, so 64k arena with few kbytes for o.s. maybe in rom like in '80.
(btw: i'm googling around for getting better doc about commodore kernal, because i think i miss a decade from '90 to '00 maybe 'cause amiga and work, of course
)exec is a task oriented, that maybe is not what a 6502 environment needs, so semaphore, messages and other sweetes.
what about a wish list?
let me try, i split in two parts:
------- section without d.o.s., the core -------
* vt100 like i/o
* memory manager
* relocator (but without dos...i'm not so sure)
* irq/nmi manager
* list manager? (8 bit list can be nice too)
* basic task switch? optional if kbytes permit.
------- section with d.o.s. -------
* extended i/o for disk-like devices (disk, flash, rom)
* buffered i/o
* loader/saver/overlay with "segment" support like in o65 format
* virtual memory like in first mac co-op o.s.? forth does!
* thread, signals
in this forum i read a lot about 16bit 65xxx, i'd love to speak about 8bit 65xx if possible, so 64k arena with few kbytes for o.s. maybe in rom like in '80.
ptorric wrote:
exec is a task oriented, that maybe is not what a 6502 environment needs, so semaphore, messages and other sweetes.
ALTHOUGH....there is an interesting innovation in the field of operating systems called a "cache kernel", whose techniques can be used to amortize this cost. It might be worth considering.
Quote:
* vt100 like i/o
This will sound a lot like Plan 9 from Bell Labs -- but, in fact, Commodore PET used this technique first in 1977 (instead of "everything is a file", they used "everything is a GPIB device").
The enhancement over KERNAL I'd add is support for a hierarchical namespace to replace GPIB device IDs, so that devices can be attached to a virtual filesystem in kept entirely in RAM. I've done this before for the C64, monkey-patching KERNAL in the process, and it takes no more than 2KB to implement. It'd most likely take less space if I didn't have to monkey-patch KERNAL.
Quote:
* relocator (but without dos...i'm not so sure)
Quote:
* list manager? (8 bit list can be nice too)
Which brings me to add a suggestion which, I think, takes higher priority than anything else:
* If you're going to support code relocation anyway, you might as well add a system of supporting libraries. (Which justifies the list processing code inside the OS too.)
Quote:
* basic task switch? optional if kbytes permit.
Quote:
* extended i/o for disk-like devices (disk, flash, rom)
Quote:
* buffered i/o
Quote:
* loader/saver/overlay with "segment" support like in o65 format
Quote:
* virtual memory like in first mac co-op o.s.? forth does!