Improving the 6502, some ideas

[White Flame]

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.

[GARTHWILSON]

The memory was rather limited in the C64, which won't be the case with any 32-bit big brother, but I guess I hear you saying you'd prefer it be in processor registers, not RAM. The C64 method sounds like it made for further delays in getting the the ISR, since it had to not only go through the regular vectors at FFFA-FFFB and FFFE-FFFF, but also through a JMP(ind) after that.

[White Flame]

The ROM IRQ handler did this:

Code: Select all

FF48   48         PHA
FF49   8A         TXA
FF4A   48         PHA
FF4B   98         TYA
FF4C   48         PHA
FF4D   BA         TSX
FF4E   BD 04 01   LDA $0104,X
FF51   29 10      AND #$10
FF53   F0 03      BEQ $FF58
FF55   6C 16 03   JMP ($0316)   ; normally FE66 (user BRK vector)
FF58   6C 14 03   JMP ($0314)   ; normally EA31 (user IRQ vector)

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.

[BigEd]

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.

[Arlet]

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.

[BigDumbDinosaur]

GARTHWILSON wrote:

The memory was rather limited in the C64, which won't be the case with any 32-bit big brother, but I guess I hear you saying you'd prefer it be in processor registers, not RAM. The C64 method sounds like it made for further delays in getting the the ISR, since it had to not only go through the regular vectors at FFFA-FFFB and FFFE-FFFF, but also through a JMP(ind) after that.

The JMP (<ADDR>) instruction, of course, slowed down interrupt response but was very useful, since one could patch additional code into the ISR without much effort. Considering when the C64 was developed, it was pretty advanced for the time.

[GARTHWILSON]

Arlet wrote:

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.

BDD wrote:

The JMP (<ADDR>) instruction, of course, slowed down interrupt response but was very useful, since one could patch additional code into the ISR without much effort. Considering when the C64 was developed, it was pretty advanced for the time.

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.

[Arlet]

GARTHWILSON wrote:

Arlet wrote:

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.

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.

[BigDumbDinosaur]

GARTHWILSON wrote:

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.

Possible with the 65C816 by using VPB to tell programmable logic when to set up the indirect vector.

[Alienthe]

barrym95838 wrote:

The 6809 addressed many (but not all) of these issues, and is quite a capable little unit IMO, discounting the 'tacked-on' nature of some of its features.

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.

[barrym95838]

Alienthe wrote:

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

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).

Quote:

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.

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.

Quote:

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.

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

[Alienthe]

barrym95838 wrote:

Alienthe wrote:

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.

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.

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.

[GARTHWILSON]

Although I had heard of Sweet16 years ago, I just now looked it up and scanned the article at http://www.6502.org/source/interpreters/sweet16.htm . Wow, it does look elegant, although as you say, there would be some big limitations from not having even an OR or AND or a lot of other things. I suppose the idea was to go back to assembly for those. figForth existed by then (1977) but I hadn't heard of Forth until the mid-80's, and I wonder if Woz hadn't either. It would be at least as fast-executing, very compact, and far more capable than Sweet16-- it's just that it requires a kernel of a few K (instead of 300 bytes) before the application can be compiled.

[Alienthe]

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.

[dclxvi]

Alienthe wrote:

There is little (if any?) sample code in SWEET16 here.

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).