If I understand what's being suggested ..

The stack is the jump table and you set up the jump for the return
before you do the jsr. The rts is sort of a double indirect jump
through a special location, the stack pointer.

You'd still have to do a software stack if you want nested subroutines.

I can't think how you'd manage with interupts if there were more than
one possible return address though (and if there's only one possible,
it'd be implied, ie wouldn't necessarily have to be set up prior to a jsr).

k, you can set the stack so it can point to ROM. Wait, ok, got it, stack pointer increments through the returns table.

One trick to avoid other variables would be to have the program routine actually be what is going on or the state. bunch of compare and jmp festivities, sort of a choose your own adventure thing based on a conditional, then any other would created a new conditional. This would mean duplicated routines for every possible variable state but it could add to the versatility.

start
get the work variable
if variable = 1 then goto routine 1a
if variable = 2 then goto routine 2a
if variable = 3 then goto routine 3a
goback to start

1a
get letter variable
if letter = a then goto routine 1a1
if letter = b then goto routine 1b1
if letter = c then goto routine 1c1

2a
get letter variable
if letter = a then goto routine 2a1
if letter = b then goto routine 2b2
if letter = c then goto routine 2c3

3a
get letter variable
if letter = a then goto routine 3a1
if letter = b then goto routine 3b2
if letter = c then goto routine 3c3





Anyhow, you see where my line of logic is going here.
(this is the thinking of someone who had the nervous breakdown, and is still kind of nuts, so I hope you can follow the logic. It SEEMS ok, but my thought processes are kind of suspect right now.

_________________
"My biggest dream in life? Building black plywood Habitrails"

How did I forget the program counter as 16 bits of storage! Reading the above I remembered since the hidden state of where you are in the string is the program counter. This technique of encoding state into the program counter has important applications on modern CPUs too, where you do it for efficiency since it allows the code to know the state at assembly/compile time.

Someone asked about JSR being unusable: the instruction would be usable though mostly useless, as a JMP would do mostly the same thing in less time (except decrementing the stack by two). JSR doesn't care whether the memory writes actually go somewhere. Even RTS doesn't care whether there is any memory to read from; it just fetches whatever is on the data bus and jumps to that (plus one, of course).

In a very early design iteration for the Kestrel-1, I was thinking of mapping a few bits of the address bus to various control signals for the monitor (e.g., A14 -> HSYNC, A13 -> VSYNC, A12 -> Display Enable). This means that the ROM image can itself be no more than 4K in this case, which is repeated on 4K boundaries. That way, to control these signals, you'd just jump to different locations in the ROM.

Thank goodness I don't need to do that anymore.