Question about 65c265 vectors - am I missing something?

[RebeccaBlue]

So, everywhere I look, I'm seeing the native mode vectors for the 65816 for IRQ and NMI as $FFEE and $FFEA respectively.

Looking at the w65c265s data sheet, in the table '2.4.2 Native Mode Priority Encoded Interrupt Vector Module', it appears to show IRQ at $FF9E and NMI at $FFBA.

In the table '2.4.1 Emulation Mode Priority Encoded Interrupt Vector Module', where the '816 would have IRQ, they have IRQAT3, and where the '816 would have NMI, they have IRQAT2.

This seems really, really weird. WDC didn't really make the '265 not quite binary compatible with the '816, did they? I'm reading this all wrong, right?

[BigDumbDinosaur]

RebeccaBlue wrote:

So, everywhere I look, I'm seeing the native mode vectors for the 65816 for IRQ and NMI as $FFEE and $FFEA respectively.

Looking at the w65c265s data sheet, in the table '2.4.2 Native Mode Priority Encoded Interrupt Vector Module', it appears to show IRQ at $FF9E and NMI at $FFBA.

In the table '2.4.1 Emulation Mode Priority Encoded Interrupt Vector Module', where the '816 would have IRQ, they have IRQAT3, and where the '816 would have NMI, they have IRQAT2.

This seems really, really weird. WDC didn't really make the '265 not quite binary compatible with the '816, did they? I'm reading this all wrong, right?

The MPU’s native-mode IRQ and NMI vectors are indeed at $00FFEE and $00FFEA, respectively.  Sounds as though the 265’s priority encoder is reacting to VPB being asserted.  Makes me wonder if they (WDC) also are tinkering with the BRK and COP vectors, since software interrupts also assert VPB during cycles 7 and 8 of the processing sequence.  It could also be the ABORT vector is being changed.  With a VPB-aware priority encoder, it’s theoretically possible to put almost anything on the address bus in response to an interrupt.

[RebeccaBlue]

BigDumbDinosaur wrote:

RebeccaBlue wrote:

So, everywhere I look, I'm seeing the native mode vectors for the 65816 for IRQ and NMI as $FFEE and $FFEA respectively.

Looking at the w65c265s data sheet, in the table '2.4.2 Native Mode Priority Encoded Interrupt Vector Module', it appears to show IRQ at $FF9E and NMI at $FFBA.

In the table '2.4.1 Emulation Mode Priority Encoded Interrupt Vector Module', where the '816 would have IRQ, they have IRQAT3, and where the '816 would have NMI, they have IRQAT2.

This seems really, really weird. WDC didn't really make the '265 not quite binary compatible with the '816, did they? I'm reading this all wrong, right?

The MPU’s native-mode IRQ and NMI vectors are indeed at $00FFEE and $00FFEA, respectively.  Sounds as though the 265’s priority encoder is reacting to VPB being asserted.  Makes me wonder if they (WDC) also are tinkering with the BRK and COP vectors, since software interrupts also assert VPB during cycles 7 and 8 of the processing sequence.  It could also be the ABORT vector is being changed.  With a VPB-aware priority encoder, it’s theoretically possible to put almost anything on the address bus in response to an interrupt.

Ok... So what's the difference between $00FF9E and $00FFEE, assuming native mode? Does $00FF9E get triggered a different way than $00FFEE does?

[BigDumbDinosaur]

RebeccaBlue wrote:

Ok... So what's the difference between $00FF9E and $00FFEE, assuming native mode? Does $00FF9E get triggered a different way than $00FFEE does?

Have you read the 265’s data sheet?  Page 10 has a cross-reference of native-mode vectors and the corresponding hardware.  A similar table for emulation mode is on page 9.  I think those tables will help you.

Personally, I fail to see the allure of the 265.  The term “creeping featurism” immediately comes to mind when I look at the data sheet.  Too many things are wired into it that eat up valuable address space.  Also, the thing is slow, running at less than half of the clock capabilities of the discrete 65C816.

[BigEd]

RebeccaBlue wrote:

This seems really, really weird. WDC didn't really make the '265 not quite binary compatible with the '816, did they?

Well spotted... it seems they did! (Checked against Eyes and Lichty, p55)

(
One thing which always bothers me - I have to think twice - is the naming of "emulation" and "native". I think the reason why it bothers me might be that the core starts off in "emulation" mode, for valid backward compatibility reasons. So you have to do something to get it into so-called "native" mode.

I mention this because it makes it difficult for me to hold the two things in my head and compare them, with confidence that I have them the right way around.
)

[RebeccaBlue]

BigDumbDinosaur wrote:

RebeccaBlue wrote:

Ok... So what's the difference between $00FF9E and $00FFEE, assuming native mode? Does $00FF9E get triggered a different way than $00FFEE does?

Have you read the 265’s data sheet?  Page 10 has a cross-reference of native-mode vectors and the corresponding hardware.  A similar table for emulation mode is on page 9.  I think those tables will help you.

Personally, I fail to see the allure of the 265.  The term “creeping featurism” immediately comes to mind when I look at the data sheet.  Too many things are wired into it that eat up valuable address space.  Also, the thing is slow, running at less than half of the clock capabilities of the discrete 65C816.

Indeed, it was those tables that set me off on this tangent. That's where I found the IRQ vector was moved to $00FF9E.

And I agree about the allure of the 265. It's just a mess for so many reasons.

[BruceRMcF]

BigDumbDinosaur wrote:

... Personally, I fail to see the allure of the 265. ...

I think the allure is what people assume is there when seeing the features dot points, and then when they investigate, many find out that it's not what they were imagining.

I know that happened in the X16 project, which at the outset (Dream computer video #1) was going to be built on the 265 development board until they looked into the datasheet and saw that some of the dot points were mutually exclusive when they wanted to have both, so that idea was soon abandoned (Dream computer video #2).

[BigDumbDinosaur]

BruceRMcF wrote:

BigDumbDinosaur wrote:

... Personally, I fail to see the allure of the 265. ...

I think the allure is what people assume is there when seeing the features dot points, and then when they investigate, many find out that it's not what they were imagining.

I guess I’m an old stick in the mud, since I prefer to work with the “bare” MPU, along with the usual glue logic and I/O suspects.    Too much extraneous...er...stuff in the 265, and there’s that slow-as-molasses 8 MHz clock limit.

[BruceRMcF]

BigDumbDinosaur wrote:

BruceRMcF wrote:

BigDumbDinosaur wrote:

... Personally, I fail to see the allure of the 265. ...

I think the allure is what people assume is there when seeing the features dot points, and then when they investigate, many find out that it's not what they were imagining.

I guess I’m an old stick in the mud, since I prefer to work with the “bare” MPU, along with the usual glue logic and I/O suspects.    Too much extraneous...er...stuff in the 265, and there’s that slow-as-molasses 8 MHz clock limit.

The thing about the 265 is that even people who would rather have an "all in one" solution look at the details and often have the reaction, "no, wait, not put together that way!"

[BigDumbDinosaur]

BruceRMcF wrote:

The thing about the 265 is that even people who would rather have an "all in one" solution look at the details and often have the reaction, "no, wait, not put together that way!"

It’s like buying a new car from the dealer’s inventory.  Dealer stock usually includes some options that may be desirable, but also includes options, e.g., trim packages, that have little value, but drive up the price...and dealer profit. 

The most integration I’m interested in building into my units is programmable logic and a microcontroller-based console.

[Proxy]

didn't WDC say that they only tested it up to 8MHz and don't actually know if it could run faster?
i would imagine it could reach atleast 16MHz. but even with the pre-demultiplexed address bus it doesn't really make it worth all the hoops you have to jump through to make it work.
man i wish there was just a 48-pin DIP version of the 65816, 8 extra pins for the upper 8 bits of the address bus. similar to the 68008.

[GARTHWILSON]

Proxy wrote:

didn't WDC say that they only tested it up to 8MHz and don't actually know if it could run faster?

That's what Bill Mensch told me.  I would think they'd want to see what they could do and what could reasonably be guaranteed, and update the data sheet, every time a new batch with smaller die feature sizes were implemented.  Why they don't is beyond me.

[BigDumbDinosaur]

Proxy wrote:

didn't WDC say that they only tested it up to 8MHz and don't actually know if it could run faster?

If they are testing at 8 MHz maximum, a prudent designer would not exceed that, since performance would not be guaranteed.  Who knows what elements of the design are adding prop time to the device.

Quote:

man i wish there was just a 48-pin DIP version of the 65816, 8 extra pins for the upper 8 bits of the address bus. similar to the 68008.

I’d rather it be in a 52-pin PLCC.  The foot print will be noticeably smaller and would include the extra VCC and ground connections of the PLCC-44 package now available.

[BigDumbDinosaur]

GARTHWILSON wrote:

I would think they'd want to see what they could do and what could reasonably be guaranteed, and update the data sheet, every time a new batch with smaller die feature sizes were implemented.  Why they don't is beyond me.

I think the reality is the 265 has very limited market potential.  Any investment WDC might make in developing the 265 beyond its present state would probably not be amortized in a reasonable amount of time, similar to the issues involved in fixing the TxD bug in the 65C51 and the shift register bug in the 65C22.

Consider that at the low end of the MCU market, the PIC-style 8-bit units are more than adequate for a lot of tasks, and are significantly cheaper than the 265.  Going up the scale, even the slow, 32-bit, ARM-based MCUs will run circles around a 265, with the ARM units also being cheaper, and having up-to-date development tools.  About the only place in which the 265 might be competitive would be in an application that already has a body of software developed for a discrete-parts 65C816 system, where aside from rejiggering the memory map and reassembling, would require no major development investment.  Outside of hobby projects, where are those applications?

Aside from the FMAX angle, the 265 doesn’t have any NVRAM, and has a ROM that has to be mask programmed.  Any field programming would be limited to what can be stuffed into on-board RAM or external RAM attached to the MCU.  Since such RAM is volatile, the 265 is not a replacement for an MCU that has flash space, e.g., the PICs.  I really don’t see how the 265 fits into today’s requirements for an MCU.