You may be able to do video with a Parallax Propeller or one of these boards:

http://www.4dsystems.com.au/prod.php?id=149

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

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

BDD's right. And we have three processors at issue here: the NMOS, the Rockwell cmos and the WDC cmos. If there's an undefined opcode encountered I think it must have been put there intentionally -- it had a function (intended to execute on the NMOS part). Both of the cmos versions will fail to perform that function. And it's plausible that the failures would differ from one another -- one conspicuous, the other subtle. Perhaps we need to question more closely the observation that the Rockwell cmos runs KB9 properly.

Not yet. IMO it won't be conclusive until you find out what happened, down to the exact instruction.

It's apparent that the WDC chip is somehow different, but not all differences are defects. I think we'll find that the WDC parts live up to their published specifications, if we get to the bottom of the matter. The question is how to do that

-- Jeff

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

Hi Guys,

I specifically ordered the Rockwell 65C02P4 micro, it's the closest I could(can) get to the CMOS W65C02S. My Rockwell CMOS parts arrived yesterday and 'in a way' I was hoping the CMOS Rockwell parts were going fail then I could at least draw a line and tell the world that the NMOS 6502 is 99% compatible with the CMOS 65C02 but thats not what happened as I've said elsewhere the CMOS Rockwell parts rock perfectly.

I know I've said this before but I will say it again, the W65C02S work in my system, it runs the 2kbyte KIM 1 monitor rom no problem, so it does work there, if there were other chips damaged in my system due to my incompetence then the other micro's wouldn't work either and yet they do.

Exactly how close the W65C02S is to the R65C02, is uncertain but I can remember reading the Rockwell data sheet and I destintly remember it having an enhanced instruction set similar to the W65C02S.

Cheers for now
Commie

Hi commie
Note that we do have equivalent sources for the ROM. Have you checked that your ROM is byte-exact with the image you downloaded? Can you check that it matches the ROM sources I posted a link to?

Could you stick BRK at various points in the ROM to see if they are hit? I'm presuming you can arrange BRK to drop into your monitor.

Cheers
Ed

+1. There's nothing wrong with the W65C0S. Bill Mensch, president of WDC, is the designer of the CMOS 6502, and hundreds of millions of units of this processor are going into products even today, including life-support products. Several of us on the forum have been using WDC processors, with no problem.

I'm not familiar with KB-9. Do you have the source code, and if not, does it even still exist? It would be much easier to figure out which way the bear went into the woods if you can troubleshoot with actual source code that you can modify and re-assemble and try again and repeat the cycle over and over as you home in on the problem area. My debugging tips at http://wilsonminesco.com/6502primer/debug.html are what I've used to develop many products that I did in assembly. I would be interested to know which instruction is messing it up.

_________________
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?

I'm pretty sure I already posted the source code - why does it seem that no-one saw it?

Ah yes, you did. I wasn't paying attention. My apologies.

_________________
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?

Sorry Ed. Thanks for posting that; I failed to mention I had a look -- just scanned the README files and glanced at the file sizes. Unfortunately that left me none the wiser.

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

The links in his post at the top of page 2 of this topic have a lot more than the first one did.

_________________
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?

This is where I determined that we do have the source: viewtopic.php?p=22785#p22785
And I posted the assembly listing file at https://gist.github.com/4127984
(The gist contains two files: the symbol table and the listing)

Note: we only have the source if the ROM has been downloaded and programmed with the same bytes that I compared against.

Cheers
Ed

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

Commie, are you still eager to see that WDC chip working per expectations (or at least seeing the puzzle solved)? Let me know what you think of this for a troubleshooting idea:

• set up one of the timers in the KIM-1's RIOT chips to generate a periodic interrupt
• let the interrupt handler dump trace info to the TTY -- some combination of reg's and/or the return address off the stack
• run KB9 and take a picture of the TTY emulator screen or else save it to disk. Swap processors and repeat.

I've skipped over some important details but no show-stoppers AFAIK. You see where I'm going with this. You'll be able to easily collect a lot of data points, and by comparing them you'll eventually find where the execution divergence starts. Then we'll have an answer -- or at least a much-improved set of questions!

Strange stuff there, BDD. Could that rr rr business indicate an address that would need changing if the program is to be relocated? (I'm guessing.)

cheers
Jeff

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

I think the listing must be produced before the assembler has entirely resolved all addresses. As promised on Michael's blog, assembling his code does produce exactly the same ROM.
Cheers
Ed