I've setup some tables with callbacks and parameters indexed by x. Unfortunately I didn't realize an instruction didn't exist when I wrote it so now I'm having trouble thinking of a workaround (and scrapping and starting over doesn't seem like a plan as I can't see any way else to do it with variable size parameters).

The offending instruction:



Which is part of a "JSL (JumpTable, X)"


The biggest problem, I think, is my JumpTable is in RAM... but maybe that's not an issue? Also, I'm not in Bank 0 afaik, but if that's an issue I can definitely try to shove some code around.
Any help with this? I'm stumped. Thanks in advance!

Welcome!

This is hurriedly written and untested, but maybe it'll give some ideas. I hope you can tolerate the fact the A register gets bombed. And I'm assuming your jump table doesn't straddle a bank boundary.

As you can see, my suggested code copies the three-byte destination address to stack, then does an RTL. But it's awkward pushing an odd number of bytes to stack when the 816's Acc/Memory are in 16-bit mode. So, I use PHA to push 2 bytes then use STA to write 2 more bytes... after only having made room on stack for one. If I this works as intended then the mid byte will get copied to the same place twice, but that's harmless.

About equally good would be to push 16 bits then set Acc/Memory to 8-bit mode and push 8 bits; then set Acc/Memory back to 16-bit mode. I think coding it my way saves 2 bytes, although it's not any faster.

(edits)

-- Jeff

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

I'm digesting this, haven't used PEA yet and my callbacks are 16-bit I think, although I may have done that part wrong... Thank you so much for helping me out! I'll ping back if I have further problems. Thanks again!

Edit: *understood PEA yet*, I was tired when I wrote this. Clearly I used it. Those 3 lines are actually from somewhere on this site...

Hmm, it's also possible I've misunderstood your overall intent. But focusing just on the JML (JumpTable, X) instruction you wanted, here are some suggested replacements. They require that each entry in the table will point to (desired destination)-1.

This version destroys A ...... but to preserve A you can precede the above with a PHA and require that each of the code sequences jumped to via the table must do its own PLA.

This way preserves A somewhat more slowly, but omits the need for a PLA at every jump target.

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

If you have room in the bank of tables why not write:

JMPTABLE:
jmp (jmptable,x)

ldx #something
jsl JMPTABLE

and end each JMPTABLE code with an rtl?

cheers,
Andy

Yes! The "springboard" technique can potentially be very useful and economical in these types of situations.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I already covered that with handyandy via PM. It's a callback. Therefore the jump table is in RAM (x-indexed in this case because it's multi-callback) if it was in ROM it wouldn't actually be a callback. Loading code after every RAM slot is doable I guess... still... The other issue of course is said jumps in table are long. Still contemplating what Dr. Jefyll said and trying to make it work, think I might have something? If not, I'll post the code. Was trying to avoid that as it's long, not the most elegant, and makes the question read more like: "Do it for me!"

(All this assuming I'm understanding the intended springboard correctly of course.)

In pseudo-C for ?clarity?:

I said my 24bit address *was* 16bit though. (Which I didn't realize was wrong, need to store and restore the bank's 8 bits)

The springboard doesn't need to be anywhere near the jump table itself. In particular it exists in Program space while the table is accessed through Absolute data space, so may be in different banks of memory.

JMP (abs) and JMP (abs,x) always interpret the address as being in the same program bank as the JMP itself. JMP [$abs] always interprets its address as being in bank 0.

If your vector table is in bank 0 and you have code space to spare then you could JMP (abs,x) thru a table of addresses to a JMP [vec] for an appropricate slot in your table.

If your vectors are not in bank0 then pushing the address to the stack and performing an RTI (or address - 1 and RTS) might be easiest solution.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I could be repeating the ideas of others in a slightly different manner, but here's how I see it. Looking at your pseudo-C, it seems that your jumptable[] is an array of 24-bit addresses. How hard would it be to make it an array of 32-bit JML al instructions instead, with a JMP (jumptable,x) hanging out nearby in the same bank with the array? If I'm not mistaken, you can then simply JSL al to your JMP (jumptable,x) from anywhere, and the double springboard does the rest for you (at the expense of an extra byte for each array element, a 3-byte JMP and a handful of machine cycles).

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Thanks all. I think I might have an idea on how to do this now. Will report back with whatever comes of it! My references might not be the best though.
Afaik you could say JSL is roughly equivalent to PHK : JSR meanwhile RTL roughly is "PLK" : RTS, correct?
If so, what is RTI roughly? (ie, how does it effect the registers/stack? I've been using https://wiki.superfamicom.org/65816-reference, which is probably not the best thing out there...)

Download a copy of the programming manual
http://archive.6502.org/datasheets/wdc_65816_programming_manual.pdf
Or buy a paper copy
https://www.amazon.co.uk/Programming-65816-Including-65C02-65802/dp/0893037893/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=1563915710&sr=8-1

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Err ... no. I don't believe either of those statements to be correct in general practice, unless you're strictly limiting yourself to a single bank, in which case they are superfluous (and the stack order must be wrong for one of of your examples too).


RTI is almost like PLP : RTS but there's an annoying "off-by-one" for the return address.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

In native mode, RTI is more nearly equivalent to PLP : RTL - but again with that one-byte offset. The difference is simply that the PBR is reloaded as well as the status register and the PC, with a total of 4 bytes being pulled off the stack.

There's also the detail that these are atomic operations; separate PLP : PLK : RTS instructions would usually re-enable interrupts (and thus permit entering a nested interrupt handler) before either of the latter two were executed, and the PLK would potentially move the program counter off the RTS so that it never gets executed. That's probably why there is no PLK instruction.