6502.org Forum Projects Code Documents Tools Forum
It is currently Sat Apr 27, 2024 8:11 pm

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Programming

All times are UTC




Post new topic Reply to topic  Page 1 of 1
  [ 14 posts ] 
  Previous topic | Next topic 
Author Message
RebeccaBlue
PostPosted: Sun Feb 18, 2024 9:42 pm 
Offline

Joined: Thu Nov 26, 2020 2:01 am
Posts: 8
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?
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Sun Feb 18, 2024 10:52 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8144
Location: Midwestern USA
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
RebeccaBlue
PostPosted: Mon Feb 19, 2024 12:52 am 
Offline

Joined: Thu Nov 26, 2020 2:01 am
Posts: 8
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?
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Mon Feb 19, 2024 2:17 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8144
Location: Midwestern USA
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
BigEd
PostPosted: Mon Feb 19, 2024 7:53 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England
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.
)
Top
 Profile  
Reply with quote  
RebeccaBlue
PostPosted: Mon Feb 19, 2024 2:18 pm 
Offline

Joined: Thu Nov 26, 2020 2:01 am
Posts: 8
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.
Top
 Profile  
Reply with quote  
BruceRMcF
PostPosted: Mon Feb 19, 2024 4:31 pm 
Offline

Joined: Wed Aug 21, 2019 6:10 pm
Posts: 217
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).
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Mon Feb 19, 2024 7:41 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8144
Location: Midwestern USA
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.  :D  Too much extraneous...er...stuff in the 265, and there’s that slow-as-molasses 8 MHz clock limit.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
BruceRMcF
PostPosted: Mon Feb 19, 2024 9:14 pm 
Offline

Joined: Wed Aug 21, 2019 6:10 pm
Posts: 217
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.  :D  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!"
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Mon Feb 19, 2024 10:31 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8144
Location: Midwestern USA
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.  :D

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

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
Proxy
PostPosted: Mon Feb 19, 2024 11:02 pm 
Online
User avatar

Joined: Fri Aug 03, 2018 8:52 am
Posts: 745
Location: Germany
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.
Top
 Profile  
Reply with quote  
GARTHWILSON
PostPosted: Mon Feb 19, 2024 11:06 pm 
Online
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Tue Feb 20, 2024 12:31 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8144
Location: Midwestern USA
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Tue Feb 20, 2024 12:52 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8144
Location: Midwestern USA
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 1
  [ 14 posts ] 

Board index » 6502.org Users Forum » Programming

All times are UTC


Who is online

Users browsing this forum: dmsc and 35 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
6502.org is an ongoing project by Mike Naberezny and contributors.