If I do use BRK, that allows the address to change without the user knowing- meaning the vector changes but BRK will still work as long as the function it calls is still the same. Right?

_________________
It may look hard, but it won't take long if you take it one byte at a time.

Yes, but the same is true when you put a jump table into your OS. If you only have a single OS entry point, that's just a single entry jump table.

(Now I think of it, the Beeb also have a system whereby utility ROMs can offer a multitude of services, which are always available at a specific entry point address. All ROMs are mapped, successively, into the same part of the address space, so the entry point is the same for all of them.)

Right. And JSR can be used in a similar way. Here are the two options, stripped to essentials:

• Make it a rule that the user always calls the OS by coding a BRK. That never varies. Revisions to the OS may result in a new vector associated with BRK but the matter is of no concern to the user.
  
  Or...
  
  
• Make it a rule that the user always calls the OS by coding a JSR $FF00. That never varies. ($FF00 is just a value I used for example. But whatever value you choose, it needs to be "cast in stone.") At $FF00 there may be a JMP to some other location, and said location may vary following revisions to the OS. But that's of no concern to the user.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Oh ok. Makes sense

_________________
It may look hard, but it won't take long if you take it one byte at a time.

That's certainly true and the programmer who is writing the kernel can't afford to forget it. However, at the most, a handful of microseconds will elapse from when the BRK (or COP) is executed to where IRQs are re-enabled, assuming the software ISR front end promptly does a CLI or equivalent.


I guess it would depend on how much software has been written to use the jump table. I rearranged POC's BIOS jump table once to reduce the footprint and had to reassemble nine other programs so they would continue to work following the change. Also, I had to rebuild the boot block on the hard disk because the BIOS API calls in the MBR were no longer valid.

These gyrations caused me to cogitate on how to avoid such work in the future, leading to the decision to call POC V2's BIOS APIs via software interrupts, rather than via JSR. Also, as POC V2 will have much more RAM than POC V1—the latter has 52KB addressable, all in bank $00—there was the consideration of being able to access the BIOS from any bank, which is not possible with JSR/RTS. Yes, I could use JSL/RTL to circumvent the cross-bank issue, but that wouldn't address portability. Hence the code to call an API in POC V2 will be something along the lines of:

Code:

         lda #parm1            ;parameter if needed
         ldx #parm2            ;parameter if needed
         ldy #parm3            ;parameter if needed
         pea #api_num          ;API index (16 bit push)
         cop $00               ;call API
         bcs excep             ;if exception is returned

No API in POC's existing BIOS requires more than three parameters, which means they can be passed via the registers. Only the API index would be pushed before the call, the index being defined in an INCLUDE file. This method of calling BIOS APIs will work from any bank, as any interrupt automatically forces $00 into the MPU's PB register. Also, if a new function is added to the BIOS the corresponding API index will be the highest current index plus one—existing applications will not be affected, as the previous API index numbers will be immutable.

The front end of the API handler would look something like the following:

Code:

icop     rep #%00110100        ;16 bit registers & enabled IRQs
         pha                   ;save .A for return access
         phx                   ;preserve .X, as it will be used
         phy                   ;preserve .Y if necessary
;
;———————————————————————————————————————————————
;Stack Frame Definitions
;
.reg_y   =1                    ;.Y
.reg_x   =.reg_y+2             ;.X
.reg_c   =.reg_x+2             ;.C
.reg_sr  =.reg_c+2             ;SR
.reg_pc  =.reg_sr+1            ;PC
.reg_pb  =.reg_pc+2            ;PB
.api_num =.reg_pb+1            ;API index
.s_frame =.api_num+2           ;stack frame size
;———————————————————————————————————————————————
;
         lda .api_num,S        ;get API index
         cmp #maxapi           ;index in range (16 bit comparison)?
         bcs icop01            ;no, error
;
         asl a                 ;double API index for...
         tax                   ;jump table index
         jmp (apidptab,x)      ;run appropriate code
;
;
;    invalid API index error processing...
;
icop01   ...handle invalid API index...

The above front end consumes 34 clock cycles on the 65C816, amounting to 1.7 microseconds if operating at 20 MHz. The COP $00 instruction needed to call the API consumes 8 clock cycles, equal to 400 nanoseconds at 20 MHz. The RTI at the back end that returns control to the caller consumes 7 cycles or 350 nanoseconds at 20 MHz. I daresay most of the execution time will be in the internal API code, not the front and back ends of the API calling process.

The above is trivial code for the '816, but would require some rework to accommodate the 65C02, as it lacks the ,S addressing mode, as well as 16 bit registers (the latter only matters if more than 128 API functions exist). Also, BRK would have to be used, which is slightly complicated by the fact that that instruction is often used to assist in debugging programs. Fortunately, the 65C02 does have JMP (<addr>,X), so that method of accessing the internal API jump table can be retained.

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

As long as you are willing to "sacrifice" a register to pass the jump table index.

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

The way I see it is I could push the original value of A, X and Y to the stack and then BRK. When the ISR returns you could pop those off (after processing the returned data) and no registers are sacrificed. Unless, of course, you are low on stack space.

_________________
It may look hard, but it won't take long if you take it one byte at a time.

So like this:

_________________
It may look hard, but it won't take long if you take it one byte at a time.

Or you could have your BRK handler push and pull registers for you, like any other ISR. This method would reduce the size of the code needed to call your API, as you could reduce it to loading the registers as required and then executing BRK.

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

If you are using the 65C02 (which you should), you can directly push .X and .Y.

Better yet, bite the bullet and write a BRK handler front end that allows you to pick up the signature associated with BRK and use it as the API index.

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

I don't mean to sound cheap but I had an NMOS version on hand and want to use what I have before I buy more.

_________________
It may look hard, but it won't take long if you take it one byte at a time.

That's fine - there are a lot of NMOS chips and machines out there, and they are valid targets!

I understand. However, the 65C02 confers significant advantages over the NMOS part. Here are a few issues you will have to consider if you design your machine around the NMOS part:

• Weak fanout, which means bus loading may become a design consideration.
  
  
• Instructions with dummy bus cycles execute spurious writes that can be disruptive to I/O hardware.
  
  
• Executing "illegal" instructions may cause a crash.
  
  
• JMP (<addr>) malfunctions if <addr> is $xxFF.
  
  
• If an IRQ occurs at the same time a BRK instruction is executed the IRQ will be serviced and the BRK will be ignored. Should this happen during an API call that call will mysteriously fail.
  
  
• No NMOS version of the 6502 responds to RDY during a write cycle.

Cheap or not, it is my opinion that there is no good reason to design anything new around the 6502.

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

The amount of software doesn't really matter, if the development environment is set up to handle it. With good use of symbolic constants and/or macros, it could be a simple matter of 'make all' to rebuild everything. Assuming of course, the changes aren't too radical.

BigDumbDinosaur, thanks for your advice. I will consider the 65C02 and do some research on it.

Arlet, I'm assuming you are referring to using a makefile for the project?

Also, who thinks I should put this project on SourceForge? I would love it if you guys could help me on this via Git.

_________________
It may look hard, but it won't take long if you take it one byte at a time.