6502.org

As best as I can tell, this isn't possible natively, but I thought someone might have an idea...

Basically, I want to do "JSR (a)". Obviously this doesn't exist - JSR only does "JSR a". I could perhaps synthesize it using by constructing the appropriate values on the stack before using "JMP (a)"? But that seems messy.

Its for a my bios IRQ handler, an outline of which is in the code block below.

Essentially, I want to make it so the user program can specify a custom IRQ handler, without necessarily disabling the native BIOS IRQ handler functionality. Any ideas, thoughts, comments etc extremely welcome.
P.S. There seems to be a bizarre bug in the Assembler on the line "BBS0 biosIrqMode, ?HandlerPrologue" - it states that "biosIrqMode" is an invalid addressing mode... It doesn't complain for the same line with BBS1 or BBR0.... since they're all effectively the same instructions, I am very puzzled.

I would setup the IRQ vector to point to a "JMP IRQservice" instruction somewhere in RAM. (Perhaps after checking whether it was an IRQ or a BRK.) This instruction ($4C XX YY) could be placed in a fixed location in RAM during the initial setup after reset. The address $YYXX provided after reset is the address of the BIOS service routine.

If your application wants to change that, it could overwrite XX YY with a new target address. (You may either save the original value somewhere or perhaps changing the BIOS setup in a way that there is a small subroutine that initializes this JMP to its default direction.)

The BIOS_ISR may even written in a way that it calls another RAM based JMP (say "JMP IRQservice_exit") that is setup to point to a RTI instruction. Then you have the choice of processing interrupts before and/or after BIOS.



my 2 cents

You can "jsr abs" to a "jmp (abs)".

Something like:
etc
    JSR ?ToBiosIrqHandler ; JSR (biosIrqHandler)
etc
JSR ?ToBiosIrqHandler ; JSR (biosIrqHandler)
etc
RTI

?ToBiosIrqHandler:  JMP  (biosIrqHandler)

Just my curmudgeonly opinion, but it seems to me like a convoluted way to go about it. In my POC BIOS, I just have the ISR handler jump through a page 1 vector, which normally points back to the continuation of the ISR. If I want to add something to the ISR I just point the vector to it, with the "wedged" add-on saving the original vector and jumping to it when done. If my wedge is replacing the BIOS' ISR it has the necessary code at the end to restore the MPU state and return to the foreground routine.

As a rule, I never use subroutine calls in an ISR.

Surely there's some setup, but it's not that messy. And "JSR (a)" is an elegant way of doing things (generally, I mean -- not necessarily in context of an ISR).

A 6502 or 'C02 takes 6 bytes (and 10 cycles) to put the return address on stack ( LDA#, PHA, LDA#, PHA ). An '816 can use PEA, which is even smaller and faster (and doesn't trash A).

See my comments below to BDD.
That is definitely the simplest method and one I have considered, but I rejected it because it requires the user programmer have an understanding of the internal operation of the IRQ handler in order to properly handle the various different circumstances. Also, if a naughty programmer didn't save the original IRQ vector but instead hard-coded it "because it never changes" and then I did change it.... my method doesn't allow the programmer to make that mistake and because its treated like a standard subroutine call within the ISR, doesn't require any special knowledge of the internal workings of the ISR.

Basically, I'm trying to make my BIOS API inherently backwards-compatible by not relying on any specific addresses, and insofar as is possible, make it resistant to programmers doing naughty things.
Why not? I know there will be a small performance hit from using JSR/RTS over JMP (a) JMP, but based on my reading of the datasheet, looking at 12 cycles vs 8 cycles respectively, which is hardly the end of the world...
Thank you, I hadn't considered that possibility but of course it provides the required functionality and is dead simple.
Unfortunately the whole BIOS IRQ routine is in the BIOS ROM, so this isn't an option.
A very good point. In the case of my API design, I'll make a note. Either you should SEI/CLI around that bit or you could BBR the relevant bits of my IRQ Control register. I think I prefer the latter in that is doesn't prevent the IRQ from firing immediately for vanilla functionality, but will also not cause the incomplete address to be dereferenced.
Your website is a literal treasure trove, sir! I've most recently been having a good long read through your Stacks Treatise. Admittedly I've implemented it a bit differently to your method (I didn't like the idea of putting it in ZP as that space is precious), but I have got a software stack now for parameter passing.

Thank you all for your kind assistance, as always.


----


For my P.S. where is for some reason (as best as I can tell a bug in the assembler) rejected due to an "invalid addressing mode" on biosIrqMode,
would you say the following code is equivalent? If it is I'll stick that in a macro and use it instead of the native BBS0 opcode that is apparently broken.

Probably not, as the $ represents the program counter which is 16-bit, so the result would be a word, not a byte. Is there any chance that the branch calculation results to being out of range? Also, you didn't specify which assembler you're using (or I missed it). I use the BBRx/BBSx instructions with the WDC assembler and it hasn't given me any such errors. In any case, worth checking to see if it's an out of range error that is shown incorrectly.

Bad programmers will be bad programmers, period. You can't really compensate by coding. (Like BDD), I also use soft vectors (albeit in page $03) for IRQ, BRK, etc. and returns via vectors as well. This makes it easy to wedge in another routine pre or post.

The problem is in the effect of scale, not in the occasional use of a subroutine. Just for example: if a running program were to do a full screen (80×25) repaint and your machine is running a UART that doesn't have a FIFO, such as the 65C51, nearly 2000 IRQs will occur in rapid succession (specifically, at about 104 microsecond intervals if the serial data rate is 9600 bps). If your ISR has just one subroutine in it as you are planning, that amounts to 24,000 clock cycles expended just in processing the JSR/RTS pair, versus 16,000 cycles to process a JuMP indirect. A lot of foreground processing can get done in those extra 8000 clock cycles, y'know.

Can you copy just that portion of code to RAM upon boot-up?  Preventing the performance hit of the indirects in an ISR may be quite desirable.
What I didn't think of when I wrote the above is the possibility that the different places to jump to could either be in the same page, or start at the same byte in different pages, so you only need to change one byte of the address, not both.  In that case, there's no worry about an interrupt hitting between the modification of two bytes.
Thank you.  Remember that the ZP data stack doesn't need nearly the depth one might think, and that it might pay for itself (or more than pay for itself) anyway by reducing the number of ZP variables you'll need.  Testing may be the only way to know for sure.  But yes, if you don't need the extra ZP addressing modes in the kinds of things you put on the data stack, you could, with the small one-cycle penalty, put the data stack elsewhere in RAM.  Even without implementing a data stack though, there's a lot in the stacks treatise that any 6502 programmer can take advantage of.

Fair point on the out of range error. I too am using the official WDC assembler, insofar as I'm aware its the most recent version.

The EXACT code is: The error is: I don't believe its out of range or an incorrect type. If I replace BBS0 with BBS1 it compiles fine. Interestingly it also seems to compile OK if I change it to BBS0 <biosIrqMode, ?HandlerPrologue... maybe its getting confused about the addressing mode to use in this instance? Still seems odd since none of the other BBSx instructions complain.

You should consider a couple of API functions to ADD and REMOVE a custom IRQ handler with at least one option like REGS_ARE_SAVED/REGS_ARE_NOT_SAVED.

You should consider that there are more IRQ sources and polling is required to obtain the true originator. The customer may want to solve this by adding/removing specific handlers. So you need to maintain a chain of IRQ handlers. (Polling may even necessary if you have hardware for vectoring interrupts! e.g. 65C22) There should be an option to enchain an IRQ handler to the top of the list in order to gain quick response.

I don't know if it is appropriate to require a signal/flag from each enchained IRQ handler whether it has found its IRQ or not - just to have an option of "early exit" the chain. (Perhaps you have a hardware where an unused port input can be used to monitor the IRQ line, this way you could check whether the IRQ is already serviced or not.)

Well, I tried changing some of my code and used BBS0, it works without error. Also, the WDC Macro Assembler hasn't changed version in a very long time... should be 3.49.1. Perhaps try using full labels, i.e., sans the "?" in front of the label. It's not clear what the cause is, but make sure you check the source very closely for syntax. I've made several changes to a BBSx line in my source and it always assembles correctly. It would be interesting to figure what it is. You can also contact WDC and give them a sample of your code to try.

Yes -- and my reverse-engineering instincts are aroused by the intrigue. Certainly the sensible thing is to contact WDC. But, purely for sport, I'd be tempted to try to fix the problem myself. I'm making some assumptions, but it wouldn't surprise me if this could work:

Using a hex editor one could open the assembler executable and search for the text strings BBS0 (...) BBS7. Then have a look at the surrounding bytes, and see what pattern exists. Presumably all eight BBS instances will have accompanying bytes which are identical; also one which varies according to the associated opcode.

The smoking gun is if you find a byte(s) which is identical for only seven out of eight BBS instances. Presumably that encodes the permissible address modes, and for whatever reason it's corrupted in the BBS0 case. Change it to match the others, and see what happens!

Not everyone will consider this fun or worthwhile, and I'm half joking after all. But floating prospective solutions exercises creativity. A challenge like this is catnip for me!


Edited to add:

• >for whatever reason it's corrupted in the BBS0 case
  
  Hmm, the corruption could be a typo or copy-paste error in the source code for the assembler, but it could also happen later when the code actually loads into RAM and runs. If it's the latter then I'm SOL.

If the addresses you are testing are relative then you will need to prefix them with a '<' for force the assembler to see them as page zero (although in this case they must always be) I hadn't spotted the '?' prefix for temporary label. Thanks for point that out.