6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 10:20 pm

All times are UTC




Post new topic Reply to topic  [ 91 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next
Author Message
PostPosted: Thu Mar 07, 2013 5:19 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
Dr Jefyll wrote:
BigDumbDinosaur wrote:
Also missing were the 65C816's VDA and VPA address bus qualification outputs. Their omission strongly suggested that something had to have been done to prevent the false address bus states that the '816 generates during certain stages of some instructions, especially those with <addr>,X and <addr>,Y addressing.
Interesting point, well worth mentioning. Still, do we conclude that "something had to have been done," or, "it would have been nice if something had been done"?

If the '816 and '802 are the same basic die, differing only in some of the metalization, it doesn't seem plausible that invalid-address cycles would appear (as we know they do) on the '816 but not on the '802. What seems more likely to me is that the '802 also exhibits the invalid-address cycles, and, since VPA and VDA outputs are absent, this is a hazard with no good solution. IOW, people using the '802 would need to be on guard against the possibility that an invalid address would read from an IO device, which, on some devices, can erroneously alter status.

Odd (and disappointing) as this seems, it doesn't contradict the definition of the '802 as a drop-in replacement for an NMOS 6502, since the latter exhibits the same hazardous behavior. (Or was the '802 touted as a drop-in replacement for the 'C02 as well?)


Maybe the '802 uses the same trick that the 'C02 uses (do another opcode fetch instead of invalid address read). What does the '816 do during those cycles ?

Edit: to answer my own question, I tried it out, and the '816 does generate an invalid address cycle for abs,X (but with VDA not asserted, of course). Still, since they had the logic for the 'C02, it is plausible that they have a metal option to switch between the 'C02 and the '816 behavior.


Top
 Profile  
Reply with quote  
PostPosted: Thu Mar 07, 2013 6:38 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
Arlet wrote:
Maybe the '802 uses the same trick that the 'C02 uses (do another opcode fetch instead of invalid address read). What does the '816 do during those cycles ?

Edit: to answer my own question, I tried it out, and the '816 does generate an invalid address cycle for abs,X (but with VDA not asserted, of course). Still, since they had the logic for the 'C02, it is plausible that they have a metal option to switch between the 'C02 and the '816 behavior.

Unless someone has a 65C802 and a circuit in which it can be tested to see what happens with instructions that generate false address bus states in the 65C816 this will most likely remain a mystery.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Thu Mar 07, 2013 7:22 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
Quote:
Edit: to answer my own question, I tried it out, and the '816 does generate an invalid address cycle for abs,X (but with VDA not asserted, of course). Still, since they had the logic for the 'C02, it is plausible that they have a metal option to switch between the 'C02 and the '816 behavior.

Can you confirm for us what the invalid address read was. They were not random, but quite predictable—just invalid. If I'm correctly understanding the article in the Dec '83 issue of Byte magazine, "The CMOS 6502," p.446 says the problem with the NMOS one was that indexing across a page boundary would add a cycle for the carry, and the first read, which is the invalid one done during the correction of the page number, is of the target address minus $100; and if it reads an I/O IC and thus changes some status, there's a problem. Well, this assumes you have a table in RAM or ROM that starts in the same page with the I/O. I expect that would be extremely rare, for example to have I/O from $6000-$607F, then RAM or ROM starting at $6080 and extending into (and probably beyond) page $61. I use an '802 all the time, and in over 15 years of doing so, have never had this problem. However, I also don't have I/O and memory in the same page.

Quote:
Unless someone has a 65C802 and a circuit in which it can be tested to see what happens with instructions that generate false address bus states in the 65C816 this will most likely remain a mystery.

It seems like I need to make a list of things to try when I get a chance to get the fixture out again and do some single-cycling to check things like this.

BDD, can you give us the link to the post again where you described the problem you had before implementing the VDA and VPA signals.

_________________
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  
PostPosted: Thu Mar 07, 2013 9:06 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
GARTHWILSON wrote:
Quote:
Edit: to answer my own question, I tried it out, and the '816 does generate an invalid address cycle for abs,X (but with VDA not asserted, of course). Still, since they had the logic for the 'C02, it is plausible that they have a metal option to switch between the 'C02 and the '816 behavior.

Can you confirm for us what the invalid address read was. They were not random, but quite predictable-- just invalid. If I'm correctly understanding the article in the Dec '83 issue of Byte magazine, "The CMOS 6502," p.446 says the problem with the NMOS one was that indexing across a page boundary would add a cycle for the carry, and the first read, which is the invalid one done during the correction of the page number, is of the target address minus $100; and if it reads an I/O IC and thus changes some status, there's a problem.

The '816 has the same behavior as the NMOS 6502. First, it has a cycle with the address minus the carry in the upper byte, then follows a cycle with the correct address. Here's what I see on the address/data bus. I have X=$F8, and I do LDA abs, X from $206, $207, $208, $209:
Code:
f015 bd (LDA $206, X)
f016 06
f017 02
02fe 00 (read from $2FE)
f018 bd (LDA $207, X)
f019 07
f01a 02
02ff 00 (read from $2FF)
f01b bd (LDA $208, X)
f01c 08
f01d 02
0200 00 (invalid read from $200)
0300 00 (read from $300)
f01e bd (LDA $209, X)
f01f 09
f020 02
0201 00 (invalid read from $201)
0301 00 (read from $301)


Top
 Profile  
Reply with quote  
PostPosted: Thu Mar 07, 2013 7:06 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
I did some additional test on my 65816, with a read, a write and read-modify-write instructions, and I also captured some extra control signals. Here's the code:
Code:
F006  BD 07 02        lda   $0207, x   ;
F009  BD 08 02        lda   $0208, x   ;
F00C  9D 09 02        sta   $0209, x   ;
F00F  FE 0A 02        inc   $020a, x   ;

And here's the trace. Again X = $F8.
Code:
Addr Data (Reset, VPA, Vector pull, Write, VDA)
f006 bd .P..D (LDA $0207, X)
f007 07 .P...
f008 02 .P...
02ff 00 ....D

f009 bd .P..D (LDA $0208, X)
f00a 08 .P...
f00b 02 .P...
0200 00 .....
0300 00 ....D

f00c 9d .P..D (STA $0209, X)
f00d 09 .P...
f00e 02 .P...
0201 00 .....
0301 00 ...WD

f00f fe .P..D (INC $020A, X)
f010 0a .P...
f011 02 .P...
0202 00 ..... (read from invalid address, with VDA not asserted)
0302 00 ....D (read from valid address, now with VDA asserted)
0302 00 ...W. (write cycle with invalid data, VDA not asserted)
0302 01 ...WD (good write cycle with VDA asserted)


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 08, 2013 1:30 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
Arlet wrote:
The '816 has the same behavior as the NMOS 6502.
This is as I already stated several posts ago, here. "The [NMOS 6502] exhibits the same hazardous behavior."

I think the waters got murky when, in the immediately following post, clockpulse reported no difficulty after replacing a 'C02 with an '802. But his success is not at odds with the content of my post, and I apologize for not clarifying at this point. He had no difficulty because read-sensitive IO devices were not present and/or because of the factors Garth mentioned -- ie; that the code and the device mapping have to be "just so" in order for the invalid addresses to actually result in a problem. Were the problem more prevalent, the NMOS 6502 would not have been a success.

Arlet wrote:
to answer my own question, I tried it out, and the '816 does generate an invalid address cycle for abs,X
It's always nice to get the info straight from the horse's mouth! :D But for those of us who don't have test gear and an '816 system handy, just refer to Table 5-7 of the '816 Data Sheet. There's a 7-page listing of what the '816 does on every cycle of every instruction. Far fom being mysterious, the invalid address states are, as Garth says, quite predictable.

cheers,
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 08, 2013 3:16 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
GARTHWILSON wrote:
BDD, can you give us the link to the post again where you described the problem you had before implementing the VDA and VPA signals.

The forum discussion starts here. I also mention it on my POC website.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 08, 2013 3:20 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
Dr Jefyll wrote:
It's always nice to get the info straight from the horse's mouth! :D But for those of us who don't have test gear and an '816 system handy, just refer to Table 5-7 of the '816 Data Sheet. There's a 7-page listing of what the '816 does on every cycle of every instruction. Far fom being mysterious, the invalid address states are, as Garth says, quite predictable.

Hence the presence of the VDA and VPA qualification outputs.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 08, 2013 5:32 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
BigDumbDinosaur wrote:
GARTHWILSON wrote:
BDD, can you give us the link to the post again where you described the problem you had before implementing the VDA and VPA signals.

The forum discussion starts here. I also mention it on my POC website.

So now after having re-read many pages, I still don't see what addresses were hitting the DUART. It appears to reside at D100-D1FF, but I thought the forum topic was saying that the processor was reading D000 and then writing to the final valid address in the DUART in the next cycle. D000 does not enable the DUART though, so there would not be two DUART accesses in two consecutive cycles. What was getting read in that invalid address?

_________________
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  
PostPosted: Fri Mar 08, 2013 6:12 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
GARTHWILSON wrote:
So now after having re-read many pages, I still don't see what addresses were hitting the DUART. It appears to reside at D100-D1FF, but I thought the forum topic was saying that the processor was reading D000 and then writing to the final valid address in the DUART in the next cycle. D000 does not enable the DUART though, so there would not be two DUART accesses in two consecutive cycles. What was getting read in that invalid address?

The DUART is at $00D100—there were some typos on my webpage that seemed to make the DUART appear at $00D000. Dunno if these errors propagated to the forum.

I am using <addr>,X addressing to select a DUART specific register and from what I was able to determine, the STA $00D100,X instruction being used to write to the channel command register was actually hitting $00D100 on cycle four, followed by the correct address ($00D100+$02 or $00D100+$0A) on the final (fifth) cycle. That constituted two consecutive accesses spaced by only one Ø2 cycle, which violated the device's timing requirements when the command registers were involved. Qualifying all memory cycles with VDA and VPA prevented the DUART's /CS from being asserted on the fourth cycle, thus fixing the problem.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 08, 2013 6:22 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
Of course-- D100 is the bottom of the page, so I don't know why I was thinking of D000. Too many distractions. :oops:

_________________
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  
PostPosted: Fri Mar 08, 2013 8:14 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
Dr Jefyll wrote:
I think the waters got murky when, in the immediately following post, clockpulse reported no difficulty after replacing a 'C02 with an '802. But his success is not at odds with the content of my post, and I apologize for not clarifying at this point.

I got your point, but I think there's still two possibilities: the '802 has the same problems as the NMOS 6502, or the '802 design inherits the 'C02 workarounds for the invalid accesses. The fact that there's only metal changes between the '802 and '816 does not necessarily imply that their behaviour in this regard needs to be the same.

The WDC programmer's manual comes close to making a verdict here:
Quote:
Both have a 6502 emulation mode, in which the 6502’s register set and instruction timings emulate the eight-bit 6502 (not the 65C02) exactly (except they correct a few 6502 bugs).

Saying that the '802 resembles the NMOS 6502, rather than the 'C02. However, it still leaves open the possibility that the invalid address cycles are considered 'bugs', and therefore have been corrected. The manual also says:
Quote:
Remember that even as the 65C02 is a superset of the 6502, the 65802 and 65816, described in the next chapter, are supersets of the 65C02. All of the enhancements found in the 65C02 are additionally significant in that they are intermediate to the full 65816 architecture.


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 08, 2013 10:26 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
Arlet wrote:
The WDC programmer's manual comes close to making a verdict here:
Quote:
Both have a 6502 emulation mode, in which the 6502’s register set and instruction timings emulate the eight-bit 6502 (not the 65C02) exactly (except they correct a few 6502 bugs).

Except the 65C816 data sheet contradicts the above statement. The false address bus cycles exist in either mode, which I realized when I first ran into the issue. At that time, POC V1 was operating the MPU in emulation mode. Clearly the timings aren't (can't be) the same as the NMOS MPU, which the '816 timing diagram illustrates.

Quote:
The manual also says:
Quote:
Remember that even as the 65C02 is a superset of the 6502, the 65802 and 65816, described in the next chapter, are supersets of the 65C02. All of the enhancements found in the 65C02 are additionally significant in that they are intermediate to the full 65816 architecture.

The Eyes and Lichty manual has a number of errors, which mostly exist because that tome was written in the 1980s and never updated to reflect WDC enhancements that were subsequently made (which I believe coincided with the conversion of the 65C02 and 65C816 to static cores). For example, the manual states that the BBR, BBS, RMB and SMB instructions were unique to the Rockwell version of the 65C02, which they aren't—these instructions are present in the W65C02S. The manual also implies that the 65C816 and 65C802 are exactly a 65C02 when operating in emulation mode, which isn't the case. BBR, BBS, RMB and SMB do not exist in the 65C816 in either mode, the B-accumulator is always accessible, and so are the data and program bank registers (but of very limited value). 65C816 instruction timings are the same in either mode as well when acting on eight bit values. It's also important to note this caveat from the 65C816's data sheet:

Quote:
7.8 All Opcodes Function in All Modes of Operation
7.7.1 It should be noted that all opcodes function in all modes of operation. [emphasis added] However, some
instructions and addressing modes are intended for W65C816S 24-bit addressing, and are therefore less
useful for the emulation mode. The JSL, RTL, JMP al and JML instructions and addressing modes are
primarily intended for W65C816S native mode use.
7.7.2 The following instructions may be used with the emulation mode even though a Bank
Address is not multiplexed on the Data Bus: PHK, PHB and PLB
7.7.3 The following instructions have "limited" use in the Emulation mode:
7.7.3.1 The REP and SEP instructions cannot modify the M and X bits when in the Emulation
mode. In this mode the M and X bits will always be high (logic 1).
7.7.3.2 When in the Emulation mode, the MVP and MVN instructions use the X and Y Index
Registers for the memory address. Also, the MVP and MVN instructions can only move data within the
memory range 0000 (Source Bank) to 00FF (Destination Bank) for the W65C816S, and 0000 to 00FF for
the emulation mode.

Unfortunately, I no longer have a 65C802 data sheet and no longer recall that MPU's details. I do seem to recall, thought, that like the 65C816, the 65C802's 'C02 emulation wasn't exact.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Sat Mar 09, 2013 5:21 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
Thank-you, all. Arlet, your INC example demonstrates (among other things) how VDA de-asserts during the "modify" cycle of a read-modify-write instruction. It's good to be reminded that VDA doesn't pertain only to indexed addressing issues.

BDD wrote:
from what I was able to determine, the STA $00D100,X instruction being used to write to the channel command register was actually hitting $00D100 on cycle four, followed by the correct address ($00D100+$02 or $00D100+$0A) on the final (fifth) cycle. That constituted two consecutive accesses spaced by only one Ø2 cycle, which violated the device's timing requirements
Interesting case. If the device gags on two consecutive accesses then that'd be a problem -- a problem that qualification with VDA will correct. Glad you got that sorted out; I can imagine how much "fun" you had. :roll: One minor point: although the indexed address mode caused two accesses, they would not be to D100 then D102 for example. I think we've established that the issue is the CPU resolving whether or not the indexing addition produced a carry. If not, the two accesses will have identical addresses; if so, the two accesses will have addresses that are $100 apart.

Garth, I agree that only rare sets of conditions allow the carry-less access to result in a destructive read of an I/O device (different, of course, and more common than the problem BDD faced). As you say, trouble can arise if there's a table in RAM or ROM "that starts in the same page with the I/O." But there's another wonky circumstance to consider. Say I/O is in page 7 and a small RAM/ROM table is in the bottom of page 8. Some poor schmo is coding away in assembler and wants to index into the table, but they know the value they have in the index register is, say, $80 too large. So, rather than inserting code to subtract $80 from the index register, they just subtract $80 from the hard-coded base address stated in the assembly source. That puts the base address in page 7... :cry:

Arlet wrote:
[The WDC programmer's manual] leaves open the possibility that the invalid address cycles are considered 'bugs', and therefore have been corrected.
OK, looking at the excerpts you posted I agree it's possible to take that interpretation. But the NMOS bugs (plural) they refer to as being fixed could merely include stuff like the $6C problem with operand xxFF, the fact that reset and interrupts ought to clear the Decimal Flag, the problem of a simultaneous BRK and interrupt, the invalid flags following Decimal operations... it's quite a list.

The scenario I envision is that they had their hot new product, the '816. The '802 was just a down-rated variant designed to fill a temporary need. I doubt there was any financial incentive for them to give the '802 the same workarounds that allow the 'C02 to avoid invalid addresses.

cheers,
Jeff

ps- Oops... sorry, BDD - didn't see your post until after entering my own. How'd THAT happen -- I though I had notifications turned on???
pps- I'll check and see if I have any 6SL7s for you...

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
PostPosted: Sat Mar 09, 2013 6:47 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
Dr Jefyll wrote:
OK, looking at the excerpts you posted I agree it's possible to take that interpretation. But the NMOS bugs (plural) they refer to as being fixed could merely include stuff like the $6C problem with operand xxFF, the fact that reset and interrupts ought to clear the Decimal Flag, the problem of a simultaneous BRK and interrupt, the invalid flags following Decimal operations... it's quite a list.

I agree, there's room for both interpretations, so unless someone finds a good '802 datasheet, or a working part, we can't be sure.

However, looking at the behaviour of the '816, I can't understand why they changed the perfectly fine 'C02 workarounds, and changed it back into bad address cycles, but protected by VDA/VPA, basically requiring the hardware designer to take into account those two additional signals in hardware addressing. They could have simply kept the 'C02 behavior, and added the VDA/VPA as additional signals. This would have allowed to make those signals optional, simplifying addressing for those designs that didn't care. Given that decision, I can see where they thought doing the same for the '802 was a good idea.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 91 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 27 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: