Hi all. I haven't fully developed this crazy idea of mine, but it has been buzzing around in my head for awhile, and I thought that I would enjoy hearing your input.

First of all this idea is split evenly between the topics of programming and hardware, so I just flipped a coin to decide which sub-forum to disturb, and the coin landed on "programming".

This plan is based on the idea of "smart" I/O, which basically acts as both I/O and as a type of supervisor. A potential memory map would be very simple, with RAM from $0080 all the way to $ff7f, and 128 bytes of I/O at each end. ROM would not appear in the "user" memory map.

I said "user" memory map, because my plan would allow one or more processes to exist, each with 64K as indicated. The 6502 vectors would be intercepted by the smart I/O system, the same as any other I/O access. It would provide the vector and the appropriate executable code to which it points, either from it's own private "supervisor" ROM paged into the small I/O space or whatever. I'm not a hardware guy, so I don't know how difficult or clumsy this would be in real life.

The benefit of this would be lots of RAM for each "user" process, which is a good thing. If a user needed to make a system request, it would either set up some registers and BRK, or tickle some smart I/O ports and proceed immediately. A couple of examples would be:

With a sufficiently agile and smart I/O system, a "user" could concentrate more on being productive, and less on crashing the system with a wild jump or an inadvertent I/O access that could disable the entire system. An NMI-driven watchdog timer could even time-slice or time-out an infinitely looping process with a preemptive context switch or core dump.

This "smart I/O" idea probably isn't new, so I apologize ahead of time if I implied that it is, but I would like to see if any of you friendly wizards would like to help me build on this idea or change it ... or discard it, if it's just plain rubbish.

TIA

Mike B.

[EDIT: added a padding NOP to guarantee NMI intervention.]

I like the possibilities here.

But, if there's to be a supervisor mode and a way of calling to the supervisor to get things done, there's no need for I/O in the user space. The user could see a full zero page, whereas possibly the supervisor will benefit from having I/O in some fraction of zero page to save a few cycles. Not only does the user get a full zero page, but it's harder for the user to poke the hardware in a bad way.

Thanks Ed. Well, the user does get a full zero-page, but half of it is plain storage and the other half is "smart" in that an I/O triggered command-port-specific NMI could be used to make it into a small "communication" area, where small messages of various types can be passed automagically (at least in the user's eyes). The supervisor would decide if each zero-page port for a given process was internal or external (or just plain RAM, for that matter), and act accordingly.

Mike B.

I see - that is pretty flexible. I think though that you don't need much 'width' to an OS ABI in 6502 land. The Beeb's OS offers about 15 subroutine vectors at the top of memory, with parameters passed in A, X and Y if needed, where in some cases X and Y form a pointer to a parameter block. Using BRK or WDM or COP instead would each allow for up to 256 calls, again with the possibility of parameters in registers. I see though that a magic area of memory could be used to hold parameter blocks - or to access the registers of an FPU or other coprocessor.

ABI -- I don't use that term in daily life, and I had to look it up to get a feel for its exact meaning ... yes, it seems that I'm at least partially trying to describe a type of ABI, and hiding it under a memory-mapped I/O disguise. What's going on behind the scenes could be a bit of hardware and a lot of firmware (mapped to a different bank), or vice-versa, but essentially what I need to do is read up on what the more sophisticated 65xx systems have been doing before trying to re-invent the ABI wheel from scratch.

Mike B.

The third page here sketches the OS calls offered by the BBC Micro's OS:
http://8bs.com/mag/09/informantrom.txt
(For a thorough treatment, see the User Guide and/or the Advanced User Guide.)

It's the 6502 OS I'm most familiar with, but I think it might also be the most sophisticated 6502 OS from the 1980s. Of course people have written large OSes for the 6502 since then.

(Just to note the way I think of this: the set of OS calls is an Application Programming Interface or API, but because they are always offered at fixed addresses in the FF00 region, they also constitute an Application Binary Interface, or ABI. The difference is that you can run a binary which uses an ABI, but to use an API you might need to rebuild from source. As it happens, the OS interface is implemented for quite a few different CPU architectures, so across architectures it is indeed only an API. But for Acorn's Beeb-generation 6502 offerings, it's an ABI. It offers access to the front end machine's hardware and filing systems, either locally or from a second processor connected by Tube.)

One of the best known examples in the eight bit world of an API (or ABI) is the Commodore "kernal" jump table. Every eight bit Commodore computer had the same basic jump table, although it got expanded as time went on. Any Commodore assembly language programmer worth his or her salt knew this table backward and forward.

In the UNIX/Linux world, the API is often referred to as the "kernel calls." Unlike the Commodore version of an API, in which functions are called via JSR, UNIX/Linux kernel calls are made with indexed software interrupts. The same method can be modeled in 65C02 or 65C816 assembly language, the former by using BRK and the latter by using COP (recommended) or BRK.

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

Interesting - as many as 39 callable routines in the kernal.

Also interesting is the different design philosophy - these 42 look pretty specific and relatively low level, whereas the Beeb's rather fewer entry points are a bit higher level and often very multifunction. (OSBYTE does a lot of get and set actions for example.)

(Looks like the first version of Unix offered 21 system calls, by 1979 that was 50 calls, and Linux had 380 at one point - probably more now...)

I think Commodore's kernel API design came out of their experience with PDP-11 and VAX hardware. I do know that the C-128 firmware was entirely developed on a VAX, running a custom-developed 6502 cross-assembler that eventually became the HCD65 assembler that was bundled in Commodore's DevPak for the C-128.


According to Ritchie in the above referenced paper:

Although the PDP-7 and PDP-11 are both small computers...

That statement would be amusing to anyone who was accustomed to the size of a PC and then stood before a PDP-11. The PDPs may have been "minicomputers" in name, but small in the physical sense they weren't—even before hooking up the Tele-Type machines.

As for Linux's hundreds of kernel calls, that is a classic example of creeping featurism. While an increase in calls would have been inevitable when networking was introduced to UNIX, I'm still baffled how we went from the 50-or-so calls of the seventh edition of UNIX to 300+ in the Linux 3.0 kernel.

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

I'm most familiar with the term "ABI" as meaning how registers are used, how function calls are made, and how memory is accessed (usually within a process context). Basically, the interoperability requirements at the function layer to be able to link together software to run together compatibly [as a process] within an OS, where individual functions could come from any high level language.

For example, Forth environments usually have a particular ABI on how native words are implemented, like assigning .X to the operand stack pointer, how NEXT occurs, and if carry is clear at the beginning of the word or means something as an output flag.

On a 6502 in general, I would assume this to include which zeropage addresses are available to the user program, how OS functions are invoked (JSR vs BRK for instance), and if it's multitasking also how memory is addressed in a shared manner.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Yes, memory management is well in scope - the Beeb's OS has a means of allocating low memory for things which need it, and an arrangement for who gets to use which parts of zero page. It's not exactly multitasking, but ROMs kind of coexist in parallel with the OS and with each other, as do filing systems. As a simple example, a BASIC program's start address varies depending on whether the machine is using a tape, or disk, or high density disk filing system. Likewise the highest address available depends on the graphics mode. Or, instead of BASIC, it could be any other application ROM, whether another language or a word processor. Utility ROMs coexist whereas applications are mutually exclusive.