I consider myself a "D" or maybe "C" student when it comes to 6502 assembly. In my effort to become at least a B student, I'm studying vectors and how people have used them.

For example, take this paragraph from Wikipedia regarding the SYM-1:



I believe I understand this at a high-level. For example, you have a routine or sub-program that sends a character over the serial port. Something like:



Throughout your program, you use that method a bunch. You have many "JSR SENDCHAR"'s all over the place.

So let's say you're a power user or you want to upgrade the system to not only send the character over a UART, but also record it in a file somewhere. You could alter SENDCHAR and add a branch to the "RECORDLOG" method. But it seems a cleaner way would be to have a vector and have everyone use that instead. Something like:



I hope I'm making sense. Am I understanding the concept correctly?

If so, I'm still puzzled on when you would use that and when you would not. I'm a Java developer by trade so we have lots of little tricks too. But there are always times to use them and times to not.

What are some scenarios where vectoring (hope that's the right term) is best used?

PS,

I also get a little confused on properly handling branching (especially with RTS) in multiple jump tables like that. So if I "JMP (SOMEWHERE)", how does "SOMEWHERE" know to get back from the JMP?


Thanks

_________________
Cat; the other white meat.

I've no experience with the SYM-1. But from a quick look at some source code, it seems their vectors contain JMP instructions. So RAM will contain

The caller can then JSR invec.

The C64 had a different solution. Vectors in RAM are two bytes, containing the address of the routine. There would then be a JMP (vector) instruction somewhere in ROM (usually before the routine itself), and code would call that.

You are very close to a complete understanding, cb. The only twist you're missing is how to return properly from a JMP (COUT) instruction, since the base 6502 doesn't have a JSR (COUT) instruction. The answer is to use a springboard JMP, either in RAM or ROM. When a program wishes to send a char, it simply does a JSR COUT, which saves the proper return address on the stack. The real magic happens next, because at address COUT is a JMP (SEND_VEC) instruction that hops through the RAM vector to the output routine. When the output routine is done, its RTS returns all the way back to the original caller. If COUT is in RAM, you don't even have to make it an indirect jump, because you can modify the address inside the absolute JMP instruction, saving a couple of 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)

And Acorn also used the two byte vector:


You could think of these as a way to override a method, or to hook into a routine to add value. Your example of adding print logging is a good one. Another would be to add handling of control codes in an output stream. Or one might add instrumentation to see how often, or when, or with what arguments something is called. Or insert a bug fix!

If the new handler calls the old, then the insertion method can be used again by another handler, so they daisychain. If it doesn't, then it replaces whatever the current chain is with its own behaviour.

The VDUV in the Acorn list is a good example: PLOT commands could be extended to draw ellipses, patterned lines, do flood fill, and so on.

The two IRQ vectors in the Acorn scheme is an interesting facility: one hooks in early, so the new code can act ahead of or instead of the OS behaviour, and the other hooks in late, so it doesn't add latency to the OS behaviour.

(However, in Acorn land an application doesn't call the vectors, it calls the ABI entry points in high memory. That's because the application might be running on the I/O processor or on a second processor. The vectors are a mechanism used on the I/O processor where the OS actually resides.)

BTW I'm not sure about your code snippets. The vector would be modified once, at installation of a driver, to be used for all subsequent uses. So the installation updates the vectors, possibly saving the old value for use by the new routine in case it daisy chains. The installation doesn't call the newly vectored code at all.

(I've a feeling I haven't been terribly clear)

Another technique is simply a JMP table. In this case, the system loads the RAM on startup, then calls the proper functions via the "hard coded" values in ROM.

Simple example:

In your code, you simply call JSR SENDCHAR, the JMP vectors through to proper routine, and you can change that address whenever you want to something else.

On the '265 board, the ROM interrupts all vector to a RAM table filled with 4 byte JML (JMp Long) instructions to break out of the tyranny of bank 0.