6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Sep 20, 2024 7:21 pm

All times are UTC




Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject: Re: processor detection
PostPosted: Thu Aug 31, 2017 10:30 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10938
Location: England
Interesting that we hit this detection problem today - I was in Hoglet's lab - and we couldn't see a solution for our situation, because not only are there real 6502 chips, but in our case we had Arlet's 6502 core, and also an emulator core, and these might all have different behaviours for undefined parts of the machine.

(Indeed in the case of the emulator they might also have bugs! We were trying to get a version of Bruce's decimal test to run, and of course if you're testing decimal mode then you know it might not be right, so it's maybe not best to try to detect the CPU using decimal mode behaviour...)

The solution in our case was that Dave coded up a menu, so the user can choose whether to test 6502 behaviour or 65C02 behaviour, and whether to test only defined behaviour, or all behaviour.


Top
 Profile  
Reply with quote  
 Post subject: Re: processor detection
PostPosted: Fri Sep 01, 2017 2:37 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
Quote:
Are all unimplemented codes on the C02 NOPs?
The processor thinks they're NOP's, because no flags or registers are altered. But in some cases a data fetch (a fetch other than the instruction fetch) is generated. Depending on the system, that might have potential for a destructive read of an I/O register -- so, perhaps not a NOP from the system's point of view. :!:

On a more positive note, the NOP's are useful for hardware and software hacks. (The software hack, discussed here, uses the NOP to skip a byte or two. It's smaller and may be faster than a BRA.)

The most numerous undefined NOP's have no time for a data fetch, as they are both single-byte and single-cycle. 64 such NOP's are present on older 'C02 processors such as the NCR65C02; their opcodes fill columns $3, $7, $B and $F of the opcode map. Slightly newer C02's including Rockwell use columns $7 and $F to accommodate the bit-manipulation instructions, thus reducing the number of single-byte, single-cycle NOP's to 32. Modern WDC C02's further reduce that number to 30, as the STP and WAI opcodes reside in column $B.
Attachment:
NCR65c02 invalid opcodes.png
NCR65c02 invalid opcodes.png [ 108.64 KiB | Viewed 1163 times ]


GARTHWILSON wrote:
Jeff has used the single-cycle ones for his fast-I/O tricks.
Yes, the single-byte, single-cycle have great potential for hacking. :twisted: :D They're fast, compact and plentiful. And your hardware perhaps won't need to decode the entire opcode -- merely decoding the column may suffice.

That said, the remaining NOP's (non-single-cycle) are the most intriguing, as they give your hardware access to the following address modes (as dictated by an appropriate program):
  • Absolute
  • Zero-page
  • Zero-page,X
  • Immediate
For example, your program might include the two-byte instruction $44, $69. $69 is some arbitrary location of interest, and $44 is the opcode for "NOP" Zero-page. At runtime $44, $69 will cause the processor to obligingly fetch whatever's at $69. The processor discards the byte fetched, and it remains only for your hardware to capture it by snooping the data bus. That's how my KK Computer is able to load a Bank Register in only three cycles. :mrgreen: (Or two cycles, using "NOP" Immediate.)

For detailed specifics on 'C02 NOP's see here.

-- 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  
 Post subject: Re: processor detection
PostPosted: Mon Sep 04, 2017 12:00 pm 
Offline

Joined: Wed Oct 06, 2010 9:05 am
Posts: 95
Location: Palma, Spain
The really curious one is $5C which is apparently a 3 byte, 8 cycle NOP. That doesn't correspond to any addressing mode, not even the illegal RMW (zp),Y / (zp,X) instructions on the original 6502, which are 8 cycles but only 2 bytes long. Anyone know what the memory access pattern is during NOP $5C?

(Edit: it's in Jeff's link - thanks for the info. Bizarre indeed!)


Top
 Profile  
Reply with quote  
 Post subject: Re: processor detection
PostPosted: Mon Sep 04, 2017 2:56 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
Quote:
I tested the instruction "5C 1234h" (stored little-endian as 5Ch 34h 12h) as an example, and observed the following: 3 cycles fetching the instruction, 1 cycle reading FF34, then 4 cycles reading FFFF.

The pattern for $5C is pure nonsense, I'd say. It certainly doesn't correspond to any legitimate address mode. But we don't expect it to. The single-byte, single-cycle NOP's don't do so, either. Only a minority of the undefined NOP's happen to display semi-meaningful behavior -- and even that is more by fluke than by plan. The only requirement is that the undefined NOP's be benign.

To me it's clear the 'C02 designers wanted to ensure processor registers and flags were unaffected by undefined instructions. They fully met that spec, but they weren't the least bit fussy about how it was done -- they just chose whatever cheesy shortcuts were easiest. It's not surprising that some of the resulting behavior is gobbledygook.

The main shortcut is to throw a wrench in the instruction-fetch procedure when a column-$3 or -$B opcode is fetched. As we know, a 65xx processor's usual procedure for beginning an instruction is to
  1. put SYNC high and fetch the opcode byte
  2. put SYNC low and fetch at least one more byte

But when a 'C02 detects a -$3 or -$B opcode it simply shrugs it off and restarts the opcode fetch procedure. Here's the 'C02 procedure:
  1. put SYNC high and fetch the opcode byte. If it's column-$3 or -$B then GOTO Step 1.
  2. put SYNC low and fetch at least one more byte

Evidently the predecode logic is at work here, as the usual pipeline is short-circuited. But it successfully prevents whatever non-benign gobbledygook might otherwise result from the -$3 or -$B opcodes.

_________________
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  
 Post subject: Re: processor detection
PostPosted: Tue Sep 05, 2017 7:51 am 
Offline

Joined: Wed Oct 06, 2010 9:05 am
Posts: 95
Location: Palma, Spain
Dr Jefyll wrote:
The pattern for $5C is pure nonsense, I'd say. It certainly doesn't correspond to any legitimate address mode. But we don't expect it to. The single-byte, single-cycle NOP's don't do so, either. Only a minority of the undefined NOP's happen to display semi-meaningful behavior -- and even that is more by fluke than by plan. The only requirement is that the undefined NOP's be benign.

It'd be interesting to see how the 65C02 decode ROM compares to that of the 6502. In column $xC, there are some new instructions (TSB/TRB abs, JMP (ind,X), etc), so I guess it's conceivable $5C ended up with unusual behaviour, and they just added the minimal number of patches to the PLA to ensure that it was benign. I guess we'll only know for sure with a Visual 65C02!


Top
 Profile  
Reply with quote  
 Post subject: Re: processor detection
PostPosted: Tue Sep 05, 2017 8:45 pm 
Offline
User avatar

Joined: Tue Mar 02, 2004 8:55 am
Posts: 996
Location: Berkshire, UK
As I can see the individual cycles it turns out that a single JMP ($FFFF) is all you need to tell the processors apart. Just like Goldilocks.

My dummy boot code is at $1000. A 6502 executes 5 cycles and the address calculation bug means that $FFFF and $FF00 are accessed. Too cold!
Code:
FFFC R 00
FFFD R 10
1000 R 6C
1001 R FF
1002 R FF
FFFF R 00
FF00 R 00

A 65C02 uses an extra cycle re-reading the high byte and accesses $FFFF and $0000. Too hot!
Code:
FFFC R 00
FFFD R 10
1000 R 6C
1001 R FF
1002 R FF
1002 R FF
FFFF R 00
0000 R 00

And a 65C802 doesn't use an extra cycle and accesses the correct addresses. Just right.
Code:
FFFC R 00
FFFD R 10
1000 R 6C
1001 R FF
1002 R FF
FFFF R 00
0000 R 00

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs


Top
 Profile  
Reply with quote  
 Post subject: Re: processor detection
PostPosted: Wed Sep 06, 2017 3:37 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8390
Location: Midwestern USA
BitWise wrote:
As I can see the individual cycles it turns out that a single JMP ($FFFF) is all you need to tell the processors apart. Just like Goldilocks...And a 65C802 doesn't use an extra cycle and accesses the correct addresses. Just right.

What about the 65C816?

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


Top
 Profile  
Reply with quote  
 Post subject: Re: processor detection
PostPosted: Wed Sep 06, 2017 9:33 am 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
Wouldn't the '816 behave much the same as the '802?
I'm assuming that the '802 is an '816 that's been wired up differently internally.


Top
 Profile  
Reply with quote  
 Post subject: Re: processor detection
PostPosted: Wed Sep 06, 2017 1:04 pm 
Offline
User avatar

Joined: Tue Mar 02, 2004 8:55 am
Posts: 996
Location: Berkshire, UK
That would be my assumption too. The board can't take a 65c816 to test that hypothesis though.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs


Top
 Profile  
Reply with quote  
 Post subject: Re: processor detection
PostPosted: Wed Sep 06, 2017 3:09 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
BitWise wrote:
As I can see the individual cycles it turns out that a single JMP ($FFFF) is all you need to tell the processors apart. Just like Goldilocks.

My dummy boot code is at $1000. A 6502 executes 5 cycles and the address calculation bug means that $FFFF and $FF00 are accessed. Too cold!

How do you detect cycles consumed?


Top
 Profile  
Reply with quote  
 Post subject: Re: processor detection
PostPosted: Wed Sep 06, 2017 4:05 pm 
Offline
User avatar

Joined: Tue Mar 02, 2004 8:55 am
Posts: 996
Location: Berkshire, UK
The various trace outputs show the address bus, W/R signal and data bus content. For a read the data content is provided by the PIC at this stage in the boot process.

Unfortunately there wasn't enough pins to get the RDY signal so after the /RES line is release the code uses the address bus values to determine when the reset vector has been accessed and the first opcode read.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs


Top
 Profile  
Reply with quote  
 Post subject: Re: processor detection
PostPosted: Wed Sep 06, 2017 10:01 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8390
Location: Midwestern USA
DerTrueForce wrote:
Wouldn't the '816 behave much the same as the '802?
I'm assuming that the '802 is an '816 that's been wired up differently internally.

A key difference between the two is the '802 lacks the VDA and VPA outputs, which are key to error-free hardware management in 65C816 systems. Hand-and-hand with that is different hardware behavior involving memory accesses. They are not interchangeable parts by any means.

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


Top
 Profile  
Reply with quote  
 Post subject: Re: processor detection
PostPosted: Thu Sep 07, 2017 7:26 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10938
Location: England
What differences BDD? I'm inclined to believe it's the same die repackaged.


Top
 Profile  
Reply with quote  
 Post subject: Re: processor detection
PostPosted: Thu Sep 07, 2017 3:09 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8510
Location: Southern California
BigEd wrote:
What differences BDD? I'm inclined to believe it's the same die repackaged.

It's the same until they get to the final stages of the wafer fab, and then there are small differences in the final metalization masks, or something like that. IOW, it's slightly more than a bonding difference.

_________________
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  
 Post subject: Re: processor detection
PostPosted: Thu Sep 07, 2017 3:35 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
GARTHWILSON wrote:
there are small differences in the final metalization masks, or something like that. IOW, it's slightly more than a bonding difference.

That sounds about right. But are the internal details pertinent? What is it we're trying to establish? Didn't the original question have to do with cycle counts?

- the cycle counts ('816 vs '802) are identical AFAIK
- internal differences (ie the die itself) can be described as minor
- the '816 drives A23-16 onto the data bus during PHI2 low, which is non-trivial from an external perspective (ie the motherboard design)

_________________
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  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC


Who is online

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