Re: Unixisms on top of P8?

[mdj <mdj.mdj@gmail.com>]

On Thursday, 20 December 2012 18:43:52 UTC+10, Steve Nickolas  wrote:

> Well, obviously the regular LC memory is "untouchable" already (it's where 
> 
> ProDOS is); it might be "throwing away" a good chunk of memory but one 
> 
> could perhaps just declare the LC space entirely off limits, to be used by 
> 
> the OS.

Whether or not any of this matters is dependent on certain design decisions. Do you intend to be able to run existing code under the OS? If not, conventional operating system design is to provide an abstraction over all machine facilities, so a user land program can both not have to and not be able to alter machine state directly. In that case the operating system will always know the machine state, unless an errant program crashes it.

If your goal is simply to have a Unix like shell directly on ProDOS, then as someone else mention the KIXX shell from Kyan Pascal already does this quite nicely. It can even be loaded co-resident with AppleWorks allowing you to 'shell out'. The interfacing API is well defined so adding new commands is easy and fun.

Going all-out Unixy requires multitasking, and doing this well on the 6502 is extremely difficult, primarily because of the 6502 having a single 8 bit stack pointer. This means that the stack is at a fixed location in memory - page $01.

In order to do any type of multitasking on a 6502 machine you have to address this problem. 

One way, is to subdivide the stack; you could have 4 64 byte 'stacks' with the hardware stack. Other than as an academic exercise, that's not a practical solution as you either have too few processes, or too smaller stacks to do anything genuinely useful.

Another way is to have the operating system virtualise the stack. This works, but it means every task switch involves copying the stack *three* times. This is sufficient overhead to render this solution an academic exercise as well.

Yet another way is to have the processes running on your operating system virtualise their own stack, minimising use of the systems hardware stack. This works, but comes at an execution speed cost. Worse, it makes reusing existing code impossible. Into the academic exercise bucket with that one.

The only solution that would provide something genuinely useful is one that efficiently solves the stack problem, and there is a solution. A 128k IIe/c has two stacks. A IIe with a 1mb  RamWorks card has 17! More than enough to have a few concurrent processes without either excessive switching overhead - saving 4 processor registers to page zero can be done in 10 cycles.

I don't mean to sound gloomy about it, but this problem really is a 'singularity' that can't be worked around without some form of additional hardware support. If it could, someone would have done it 25 years ago and we'd all be using it. Don't believe me? Check out OS-9 on the 6809 machines. It's extremely Unix-like, and actually superior to Unix on smaller machines whilst providing ostensibly the same functionality. It's a phenomenal achievement.

The reason OS-9 exists on the 6809 and not on the 6502 is a simple one: the 6809 has two 16 bit stack pointers, the 6502 only a single 8 bit one.

Matt