That does sound like a good idea. Acorn's OSWORD interface is similar, in that a parameter block is passed (the address is passed in X and Y) and that block of memory can be used both for inputs and outputs. Using the stack makes sense, on a processor which has good stack access (and lots of stack space).

You can also use the method of interrupt vectoring used on some Z80 and 8080 systems: when VPB is asserted, feed two bogus bytes to the CPU (you won't be needing them), followed immediately by a JML instruction to the desired 24-bit address. At the cost of a few extra cycles for handling interrupts, you can place your ISR anywhere in memory. Moreover, each device can have its own vector, so you can save yourself the cost of polling in software. With enough devices, this can even lead to a net savings in ISR response time.

This approach can also be extended to handle COP and BRK vectors too. When VPA is asserted and the data bus reads $02 or $00 (respectively), this same hardware can load the JML instruction to the COP-/BRK-handler. You'll need the help of a CPLD (at least) to implement this in a space-efficient manner, but it ought to be well within the realm of feasibility.

The other thing that I've not seen mentioned is the JMP ($xxxx,X) instruction. Load the function ID into X (ensuring bit 0 is clear), then JML, BRK, or COP. That leaves A,Y for passing an address to a parameter block, or using the stack.

The reason you want to avoid using a single COP and a single pool of function IDs as BDD feels more comfortable with is because there is **zero** performance advantage and **negative** usability advantages to monolithic kernels on the 65xx architecture. You absolutely want the ability to dynamically load and unload modules/libraries (exactly the same thing in 65xx land), and these modules can be (and almost certainly will be) loaded at a different address every time you load them.

So, if you use COP, you'll want one register to select which module you're addressing, and X to select a function within that module. A better solution is to use a well-known kernel function similar to Amiga's OpenLibrary() call which manages library sharing and lifecycle, and returns the address of the library just opened (thus, if three processes all use the same library, they will all get the same address back). This pointer can be saved into your program's data area like so:



For example, here's how I'd 65816-ize the start-up code found in Tripos-compatible applications, assuming someone were to port Tripos to the 65816:



As you can see, now you can call the library directly without incurring any kernel overhead by loading your function selector in X and executing JSL libA. Easy peasy, it's probably the 2nd or 3rd fastest method of invoking services on a 65xx CPU (you might remember an earlier set of reasoning I did here on these forums a decade or so ago about how to support OOP dispatch -- it's exactly the same problem), and it's infinitely (RAM permitting) open-ended. You're not limited to just what the kernel offers in functionality. (While I enjoy the everything-is-a-file metaphor, I don't believe it should be followed religiously. There are legitimate counter-cases where this is demonstrably not true, such as GUIs).

Just as contribution to this discussion, in my c16 computer i'm developing system calls through 'cop' instruction; i use 'signature byte' as 'function number'.
For example, printing a character to console, is accomplished with this code:



The code i use for cop handler can be see at http://65xx.unet.bz/c16sw/index.php.
Error condition is returned raising the carry flag (the error code in lower byte of y register).
System functions can reside anywhere in memory, but not in bank 0, and parameters can be
passed through registers or/and through stack.
The table that hold the system function address (3-bytes) use a 4-th byte for hold the count
of bytes passed on stack (for clean stack when cop handler exit).

Marco

_________________
http://65xx.unet.bz/ - Hardware & Software 65XX family

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