I wouldn't put it quite like that! The interface to linux that a user program sees is a tiny amount to learn about, compared to the (tens of) millions of lines of code that sit behind that interface. That's a very useful abstraction - and in part is necessary because of the very wide variety of hardware supported, and the expectations of portability.

I don't know if I'd call it tiny. And abstraction is dubious - if you ever try to do anything with a serial port, for instance, you will soon come across mountains of strange old stuff with stty, virtual terminals, keyboard mappings, raw and cooked modes, console editing, etc. Honestly, it is not even close to the simplicity of writing directly to the UART, even with interrupts.

Or try to really figure out how the USB subsystem works.

Don't get me wrong - I am a Linux user and supporter. But really, I find the obsession of Linux distros to keep up and compete with commercial systems on their turf a completely misdirected effort. Not to mention the competition between distros...

EDIT: Sorry for getting off topic and sounding provocative... Let's get back to minimOS.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

BDD- I completely agree.

For small machines I would really like to see something along the lines of the Commodore kernal - a set of helper routines that are clearly documented. I would like to see the end user having a choice of using OS services or reinventing the wheel if they decide to (or if the wheel is broken), at their own risk.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

More than that, the Kernal routines in the VIC-20 and C64 completely isolate the built-in BASIC interpreters from the hardware. All I/O the interpreters do is carefully routed through calls to Kernal routines.

They got away from that in the C128's built-in BASIC. It's shot through with direct hardware manipulation. Not nearly as clean.

No doubt the reason was to provide that BASIC with sound and graphics capabilities the earlier interpreters lacked. Still, it would have been possible to write the necessary code to manipulate the hardware and have BASIC access it through another Kernal-like jump table. That would have been cleaner and also have let other software have access to the same capabilities. My own early efforts at a C64 BASIC extension used this approach, so I know it can be done and what it's capable of.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I don't think you can fairly use "BASIC" and "real time" in the same sentence, not in reference to the typical micro BASICs of the day.

I liked the device system on the Atari. It was completely extensible, you could easily override the existing in built drivers, you could add your own, the whole kit. Really powerful.

The modern CPUs with their support for virtualization will make it (potentially) harder and harder to programs to get to the raw hardware, but with the classic micros, it will never be an issue unless the system your bypassing is over aggressive. If you simply don't use the in built routines, most of the systems will leave the hardware alone for you to do with as you please.

Elective-type OSs can get tricky with multitasking. That's why I get a bad feeling when the word is used. It seems that once multitasking is supported, hardware must be virtualized, your code is called from 'above' during specified conditions, IPC must be used to avoid all kinds of tricky deadlocks, and generally, all bets are off. Perhaps it's the only way.

I remember feeling extremely frustrated with TOS on the Atari ST machines. I wanted (and still do) to just take over the machine old school. With today's virtualized hardware you could come close to dedicating VMs with very small OSs to specific tasks, and just reboot machines like we did with the power switch...

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Hmm, I don't think AmigaDOS had any protection mechanisms - certainly not memory protection, although the processor supports privilege levels. Indeed, I think inter-process messaging used the globally shared memory for efficiency.

I just remember reading the TOS manuals and thinking "This is it. The fun is over. Now it's a job, and not a very interesting one". Maybe it was a part of growing up.

I guess I am having a problem expressing my thoughts. My concern is with the presumption: you will follow this framework, link to the libraries and call these functions, and if you don't you can't use any part of it because of state issues.

What I am hoping from an OS is guidance and support, not exclusion unless I follow the rules to the letter. You really should be able to use parts of the OS even if you don't use others.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Pre-emptive multitasking, by definition, has to pre-empt your tasks and therefore wrestles control away from you. Cooperative tasking as Garth described it seems more friendly - the OS can provide support while not forcing the issue.

Garth, an SD card file system is worthy of its own topic. I've avoided this issue on occasions by using a clumsy block scheme, but would love to hash out a minimal 6502-based FAT reader/writer... With a separate IO module that can accomodate bitbanging or a shift register assist if implemented in an FPGA.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Hi! I'm back again after being very busy at work...

Wow! This thread has turned into a very interesting discussion! And it's most welcome -- each one has his own set of goals and opinions (all of them respectable, of course) and I think it's always good to listen to everyone's ideas and points of view, in order to check whether my decisions remain valid or should be given a second thought...

It's now hard to quote every interesting comment here... but I'll make some generic comments anyway, in no particular order:

• My real desire is to build (and design) several, fairly heterogeneous computers, thus I need some kind of abstraction (hardware independence) in order to hopefully reduce the effort of writing software for them. Certainly, abstraction adds complexity and impairs performance, thus a reasonable balance must be found.
• I'm a firm believer on 90% solutions: by setting my goals a bit lower, effort and complexity might be greatly reduced. But if one tries to get the full functionality/flexibility of a "current" OS, things will get awfully complicated, well beyond the capabilities of a human being, even a bunch of them.
• I like GUIs, I've been using them from 1987 (Atari ST, then since 1995 with MacOS). I haven't used a CLI since then... well, not quite: after switching very unwillingly to OS X in 2005, I had to use that bash thing So my ultimate goal is to implement at least a rudimentary GUI, while keeping compatibility with previously written unaware, console-type applications.
• I was taught in college that an OS was, among other things, "an organic set of routines". It seems that a collection of useful routines is always a nice thing, but what does make it into a full-fledged OS? Hard to tell, I'm afraid...
• Also, in my platform (at least in the current state of things) there isn't a clear separation between firmware, kernel, OS, even applications. I don't mind putting a "whole" OS into ROM, or if I limit the firmware to the initial hardware test and booting the desired OS from a mass storage device into RAM. I'm more interested in a sort of logic modularity -- the ability to combine the set of desired kernel functions, device drivers, etc for the required system.
• I understand that for some uses (control devices, etc) maximum efficiency is needed, thus a versatile, abstract OS won't do -- direct hardware access would be the key then. But even if the driver architecture I implemented (a last-minute addition, I admit ) allows programming with no knowledge at all about the actual device (for no direct access is needed), the OS itself doesn't prevent direct access if needed -- obviously, the advantage of device-independence is lost then. See next point for an exception:
• As a proof of concept, I designed some protecting hardware which causes exception-like calls in case of direct I/O access, "illegal" instructions and the like. But such hardware is optional and, anyway, my current API provides a mechanism for direct hardware access (although slow). If speed is a concern, that mechanism could be used for disabling the protection hardware, if installed, and then do freely whatever is requiered.
• FORTH is quite interesting as a programming language, both for efficiency and ease of implementation. But I prefer letting it as a developer application running into the environment, than being the main interface between apps and hardware. Could be used as well as a shell interface for the underlying OS although I'm not very fond of CLIs... but definitely will be useful during the development of the GUI I made a stub of a debugger (which IMHO is the main justification for a CLI) in a similar RPN fashion, indeed.
• While cooperative multitasking is OK and in a way makes some things easier, there's also a catch: it works too as an application quality metric. If the app doesn't yield CPU to other processes in a regular and timely fashion, system responsiveness will suffer greatly My idea was to implement preemptive multitasking which isn't hard to set up, but needs to take care about some issues: particularly, reentrancy. While my system calls are (or will be) reentrant, I'm afraid that my current device drivers aren't At this present, early stage, no form of multitasking is implemented; but this will change soon, and some drivers should be revised. While some access control mechanisms might be implemented, a workaround is disabling interrupts within driver's I/O-operations, if they aren't taking too much time (say, less than 1 ms) -- there's even a disable interrupts call in my API, in case of a protection device is installed.
• Current documentation is non-existent but I hope to solve it as soon as I get the GitHub thing running (and understood by this poor brain of mine!). Certainly, I shoud explain about the goals, the hardware requisites, directions for porting to other architectures and many other things...

Whew... my apologies for the long brainstorming session. I hope to reply some other threads in the next few days. Certainly, I haven't made much progress on it... rewriting the source code to the new naming convention (but still to be assembled and tried, to check that no errors were added) and writing a menu-driven monitor/debugger useable on the LED-keypad but also suitable for any ASCII I/O device, like the keyboard I made

Once again, many thanks for your contribution. See you soon!

_________________
---
Carlos J. Santisteban
IES Turaniana
Roquetas de Mar, Almeria (Spain)

That is a lot of information to digest! I am happy that you are interested in a variety of views.

I wanted to address the GUI bullet. Back in the 80's I was happy as a clam when the Mac OS came out. I thought of myself as a GUI person - I wasn't crazy about command line interfaces, and it seemed just so easy! I was less crazy about the TOS on the ST as it seemed bolted on in a crude way.

After many years of working with GUIs I became more and more disillusioned. Outside of the annoying fact that your applications become enormous and you spend more and more time keeping up with the rapidly growing GUI frameworks, the nature of your application changes in a subtle way leading to a what I consider a pretty bad situation - you are so GUI bound that you can't script your application anymore. Scripting is enormously important; once you get over the explorative nature of GUI apps (which is good), you will then try to do something useful with them. That involves either automating repetitive tasks, or automating entire processes. Both require scripting and/or integration into a command-line batch, or something like that.

So paradoxically, the best GUI applications happen to be ones written by people who love and understand command-line integration, and write pretty much command-line applications with the GUI as another way to drive the application. Often the scripting component is integral to the application, and the menus simply invoke scriptable commands.

After spending a lot of time in GUIs, I became more and more amazed at how easy it is to do simple tasks on a command line. I discovered Linux and loved the ability to pipe output of one app into another, or set up complex redirections between files, serial ports and programs. I also realized the futility and terrible limitations of GUI apps, as well as the proprietary nature of the files they write (the two go together as you often need to store GUI state which you just can't possibly document).

I also discovered that the software developer often intends to do things a certain way, but the users will try to do it their way. With an unrestricted environment, the users will often amaze the developer by using the software in a truly unexpected way. That happens less often if at all in a GUI environment. Following a 'wizard', there is not much you can do. I find myself cursing the idiot who wrote the software for making me click a dozen times on options that are not even used before anything good happens.

So command line software, while often intimidating at first, completely wins in my book. I use the GUI file manager, for instance, because it's easier to select files and drag them around. And a GUI word processor. But I always have a few bash windows open, even though I am no linux CLI wizard. I use simple batch-like shell scripts for many things that I do.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!