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 http://forum.6502.org/viewtopic.php?p=7442 maybe we can stay on cp/m)

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.

maybe i like a clear well documented kernel call list as in cp/m 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?

Both Commodore and Atari had these (admittedlly, Commodore was public long before Atari was, but still).



The Commodore API was pretty regular as long as you realized that parameters were established via KERNAL calls. For example, to open a file, you'd call OPEN, but before that, you'd use SETNAM to set the filename, and SETLFS to set the logical file handle information first. It's not as convenient as CP/M's FCB structures (Atari's OS shared more in common with FCBs), but there was a rationale to it, believe it or not.



CP/M had no memory management capacity what-so-ever, so we know that isn't a strict necessity. However, I agree, a modern system will do well having such capability.



The 6502 is actually somewhat difficult to multitask well with, due to the limited, non-relocatable stack space. If you implement an external MMU with the ability to relocate the hardware stack throughout RAM, you'll do better.



More than anything else, though, I think this is the single biggest feature request for a 6502 OS. Most CP/M machines had to go through serious design gyrations to ensure that binaries could run portably. For example, the Z-80 expects ROM to appear at 0000h, but yet applications are built to execute at 0100h. Oops!

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.




Most OSes for 8-bits had these, and more. Curses is an abhorrent abomination. Trust me on this, as an OS developer myself, you do NOT want to deal with the terminal stack as you see in Linux, Unix, etc. Just pick one terminal emulation standard (Amiga chose VT100, for example) and go with it. It will make your life so overwhelmingly easier that you'll swear whoever wrote the terminal stack for Posix-style operating systems was clinically insane.



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.

You have to note that when Unix terminal handling was implemented, there really were lots of different physical terminals, connected to a single computer, which had to be supported. Amiga was never a computer where people would likely connect any dumb terminals, and therefore it was a straightforward decision to support (and emulate in GUI) only one terminal type. In today's Unix systems the curses system is something we just have to live with, although it is uncommon to require support for more than one terminal type anymore (extended VT100 emulated by xterm etc. and Linux virtual console).



I definitely miss AmigaOS too. It was just cumbersome to use a basically unsupported machine architecture with high upgrade costs, so I bought a PC and installed Linux a long time ago already. But if someone wants to design an operating system for resource-constrained computer (especially without an MMU), one should get to know how AmigaOS works first, as it was really ahead of its time and it was quite well-designed in general. I'd rather do a clone of Amiga EXEC and Shell instead of some CP/M or MS-DOS clone.

Yes; exec.library is quite easy to clone, too, including its support for libraries. If you've ever heard of "Dolphin" in the context of a PC OS, that'd be my clone.

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.

Right -- multitasking is possible on the 6502, but it's not easy. Unless you seriously constrain the stack space use, you'll find that a task switch will involve block copying data into and out of $01xx memory space.

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.



A generic I/O interface can be based on a small set of primitives: open, read, write, close. No need for ioctl or seek -- these commands can be implemented via opening a command-channel corresponding to the intended resource.

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.



This is plenty doable, but you'll still need to define I/O interfaces into which the DOS plugs into.



This isn't valuable without a memory manager, so if the heap manager proves non-useful, you end up not using a task switcher, AND you end up not supporting libraries (bad idea, if you ask me!) you'll probably not want to support lists either.

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.)



A simple cooperative multitasking engine should be relatively simple to implement. Caching task stacks might add a bit of complexity, but from a performance perspective on the 6502, it might be necessary. (As long as a task doesn't depend on its S register remaining constant from task switch to task switch, it'll be fine. Note that this is fully compatible with stack-relative addressing.) Preemptive multitasking can be implemented by tying a timer interrupt into the task-switch primitive; HOWEVER, beware that you'll then need to rely on messaging and semaphores for synchronization.



I see these as loadable device drivers that hook themselves into the virtual filesystem hierarchy.



Not sure what you mean here; without further context, it's pretty ambiguous.



This is the relocation support you discussed above. You really can't have it both ways.



I would instead recommend looking at how PC/GEOS used virtual memory files. I'm using a crude prototype of this in my Forth-written blog implementation for my website (which will be revealed unto the world soon enough; maybe in a week or two) to implement its message store. I build it on top of block-storage.