6502.org

The interrupt vector RAM locations were also often annoying in the C64, because it was very handy to shove the video bank up to the end of the address space to have the greatest amount of contiguous memory available, but always had to make sure the last 6 bytes weren't used by anything.

Any fixed location you pick for anything will always be wrong somewhere.

The ROM IRQ handler did this: If you intercepted the user IRQ vector at $0314, when done you typically JMPed back to the prior vector $ea31 which did the keyboard polling, updated the software timer, blinked the cursor, restored the regs from stack, and RTI'd for you. (and probably other stuff I'm not remembering) The IRQ was set on startup to fire on a 60Hz timer pulse from the CIAs, even on PAL machines.

Am I correct in suspecting many of the other home computers did something similar to allow user IRQs when the ROM vectors were in view? I guess the other options would be swapping out ROM in order to be able to capture interrupts at all, or having the bootstrap code hand over from ROM to RAM in that area.


When the ROMs were banked out, however, it didn't need any other indirection than the vector itself sitting in RAM at $fffe. Only utilities that hooked into the stock BASIC editor environment really bothered hooking into the user IRQ vector, to play nice with the rest of the system. Pretty much everything else went raw.

Yes, the Beeb has a similar idea of user vectors in RAM.

For Garth's point, note that FPGAs have block RAM, which is initialised at power up to whatever content you like, and which could be write-protected if need be. It's single-cycle. So there are no concerns about slow ROM or copying to RAM.

A simple way to have smart interrupt vectors is to export a signal from the core that indicates it's doing an interrupt vector fetch (only takes 2 or 3 lines of HDL). Outside the core, you can then make a vectored interrupt controller that watches the vector fetch signal, and substitutes the address of an interrupt handler.

We've talked about this elsewhere for existing off-the-shelf 6502's, but I was hoping to avoid the added external circuit complexity.


Yes, it was impressive in multiple ways, and sensible and flexible with its expansion ports around the sides and back. My own interrupt code on the workbench computer uses the additional jumps also since the interrupt vectors are in ROM. The user code can install, sort by priority, and delete its own interrupts and service for things I had not thought of when I did the ROM. Much of that overhead is one-time stuff, but it would be nice to have the processor able to reduce the latency when an interrupt actually hits.

It would be external to the core, but still internal to the FPGA. You could put it inside the core too, but I think it would make more sense to put it outside.

Just curious here, can you expand a bit more on what you feel 609 failed to address and what the tacked on nature is?

One of the things that set the 6502 ISA apart from many others is that it doesn't have any prefix codes. It makes the code space clean but also a little sparse. x68 is perhaps the best example of the horror that follows when you go overboard. RCA1802 didn't have prefix codes but 1805 introduced one to expand the instruction set.

Would it violate the purity of 6502 if we introduced a prefix code that (amongst other things) indicated 16 bit effect? So a 16 bit version of INC $05 would be INC $05 ; BNE around ; INC $06 ; around: ...
Similar for ROL, ROR, ASL etc. This might go some way to offset the advantages of SWEET16.

Well, it's just a matter of opinion, but it seemed that the 6809 took a pure but under-powered 6800 instruction set and "tacked-on" the y and u registers, which looked fine in the assembly language, but looked ugly in the machine language, at least to me, due to the pre-byte and post-byte (addressing mode) additions that made using the y or u registers less efficient. The big-endianness was kept as well, but that also boils down to personal preference (although the 6502 was able to pipe-line its little-endianness to its performance advantage). History has shown us that it is a valid and popular method to extend or update an architecture, but, again, it looks "tacked-on" to me, kind of like hitching a Winnebago to a Honda. I might be in the minority here, but it just doesn't "flip my switch" in the same way that a fresh orthogonal encoding paired with an upward-compatible assembler does. I'm not sure that I understand your example, but I would like to say that SWEET16 was an inspiration to me in several of my designs. Its interpretive nature makes it slow, and it lacks several important bit-twiddling instructions, but I simply LOVE its compactness, and I enjoy writing code for it almost as much as I do for the 6502 and 65m32.

Mike

The idea of a prefix for 16 bit instructions is that the cost of one extra byte to process would be more tan saved by using several instructions to operate on a 16 bit word, typically in memory. Applying this to registers such as the accumulator would most likely be too hard without breaking the ISA.

There is little (if any?) sample code in SWEET16 here. perhaps worth considering for the source code repository? And yes, I agree that SWEET16 is elegant. Even the 6502 code that implements it is elegant.

The background, indeed the reason for existence of SWEET16 was compactness, so I guess Woz could afford 300 bytes but not a few KB. It would be odd if Woz did not know of FORTH. Perhaps much more of the Apple Basic could have been done in FORTH but I guess there is always teh trade off between compactness and speed. Anyway, an article on Wikipedia on threading mentioned Huffman compressed threading. I had never heard of this before but I would expect this to be exceedingly compact.

You are right that SWEET16 is lacking a lot of instructions but seeing s there are a few free slots in the instruction set it lends itself to extensions. Since none (that I know of) were written since 1977 suggests people were plenty happy with what they had.

There are two things that still surprise me. First of all that it was never turned into hardware. The simplicity and orthogonality should have made a good extension for 6502 and it might have pointed faster forward to 65000. The other odd thing is that noone else picked up on SWEET16, such as in the BBC computer.

The Programmer's Aid #1 ROM chip for the Apple II used SWEET16 in places (e.g. the BASIC renumber routine), so you can see examples of its use in the listings in the Programmer's Aid #1 Manual (search the web for it).