6502.org

Hi there,

I was wondering if someone here had some insight into a question I had.
I recently got one of the new 65C02 chips made by Western Design
Center, and wanted to try using them in a couple of Commodore PETs. I checked the notes on the chip at WDC and found that you needed to tie pin 36 (bus enable) high to use the chip as a direct replacement for a MOS 6502. I did this with a small socket adapter, and tried it out in a PET 8032 - and it worked fine. Same thing in a PET 2001 (32k DRAM) with no luck - came up to a garbage screen. Any ideas about what could cause this difference?

Speed or timing difference as the PET DRAM may react differently?

Another might be if the PET used undocumented opcodes, since the WDC NOPs those as well as some bug repairs.

Actually, they aren't "new." The W65C02S (static core version) has been around since the mid-1990s.
Aside from caveats about illegal opcodes mentioned above by Tony, be sure to no-connect pin 1 of the W65C02S (the WDC part). That is a vector pull status signal that has no analog in the NMOS part. I'll repeat: Pin 1 *MUST NOT* be connected to anything when the W65C02S is plugged into a NMOS socket.

Sorry, forgot to mention that I did make sure to disconnect pin 1 of the 65C02S. Not sure if illegal opcodes are used in the PET ROMs.. just looking through the schematics for the 8032 and 2001 to see if I can find anything that would cause it to work in one and not in the other.

I'm not very familiar with the older Commodore boards.

Could the issue be TTL logic chips not being able to provide the CMOS 65C02 proper logic high levels?

Just a thought.

Daryl

Just for a sanity check, you could try re-installing the original CPU to make sure the machine still works. Who knows -- maybe there's a bad solder connection or a funky IC socket that's gotten disturbed just by the physical act of swapping the CPU. Stuff happens, eh! Static discharge... loose connectors... the list goes on. Then swap again to your 65C02. The idea of illegal opcodes in the ROM is plausible, but we shouldn't get distracted and lose sight of the basics.

BTW I think the CMOS CPUs still accept TTL input levels [see note]. It's only if you had to go from TTL to 74HC or 4000 series CMOS that you'd have a potential problem.

cheers,

Jeff

Edit: Oops, correction: the WDC 'C02 does not accept TTL input levels. However, TTL levels are OK for the Rockwell 'C02. Possibly those of other manufacturers, too -- you'd need to check.

Given that this is a Commodore product, it's highly unlikely. There's no guarantee that an illegal opcode will be the same from one part to the next. It would be folly for a production design to depend on a behaviour that, by definition, is not dependable.

Your thoughts about loose parts, static, etc., are more in line with what I would think. It is very old hardware, after all.

The NMOS illegal op codes were dependable but were not an intentional part of the design and were considered too wierd to be of much use. I understand GEOS for the C64 used on them heavily though. There's an article on them at http://www.pagetable.com/?p=39 which I've linked on my website but I'm sure there are more complete ones.

The 6502 on the 2001 and 8032 series are used differently. For example the 8032 has pin 5 connected - which is N.C. on an NMOS 6502 but /ML on the W65SC02.

In fact, knowing this, I would have almost expected the behaviour the other way round. Pin 5 on the 8032 is "NOROM" - it switches off the ROM so an extension ROM could be used from a board plugged into the CPU socket. But then /ML only switches the ROM off during read/modify/write operations - at times when no opcode fetch is done between the read and the write.

Otherwise I can't think of any other difference though.

Garbage on the screen does not mean that the computer does not work at all. There is a diagnostic pin on the user port. If held low during startup, the system boots into the buillt-in monitor. But I'm not sure if that is checked after video initialization which does not seem to work (or the CPU does not get there) in your case.

Does the system still work with an NMOS CPU?

André

Both machines still work fine with their original 6502 CPUs. And the 8032 consistently works fine with the 65C02S, with the previously mentioned connections. Interesting about pin 5 on the 8032 -- but as you mentioned it would seem to indicate that things would work the other way around.

I'm investigating this in the context of building a ROM/RAM replacement board for a PET - basically a shim board that fits into the 6502 socket and replaces the mainboard's RAM and ROM using an onboard SRAM chip preloaded with a microcontroller. So far the board is working with all the MOS 6502 chips I have tested it with, and also worked in the 8032 with the 65C02S connected as described. When the same configuration did not work in the 2001, I tested both computers without the shim board and found that the 2001 had issues with the 65C02S. It would be nice to have a recently manufactured part to use in the design. But basically I'm just curious to find out the answer in this case.

If it provides more information, when I tried the 65C02S in the 2001 with the shim board, the data bus was buffered with a 74LS245, which I would think would help with any issues about driving the levels on the data bus.

It might be worth trying replacing the LS245 with an HCT245. The problem appears to be that the LS may not be pulling up high enough for a valid logic "1" for the W65C02S. Going the other way however, the CMOS processor can drive the buses much harder than the NMOS could, even pulling up to a valid logic "1" with 40mA! (This is assuming the pin drivers are the same ones that the '22 has, which I have experimented with for this.) The CMOS processor does not need the bus buffers, but the computer design might be relying on the timing given by the 245's delay.

Hm, maybe try it in the 2001 without the buffer? Or in the 8032 with the buffer, to see if it stops working then?

For write timing I don't see any issues with the buffer. The WDC chip should be way faster. For read timing the additional 'LS buffer might prove one chip delay too much for that old slow logic stuff. Try replacing it with an 'ALS, 'HTC (which should both be way faster), or leaving it out.

André

That or try some 74F logic if available. That stuff operates in the single digit nanosecond range.

Sorry for resurrecting a topic that's over a year old....

Did you ever work out what the problem was using the WD65c02 chip in the PET ?

It seems odd that it won't work, as I've used it successfully in a BBC micro and an Acorn Atom which are of similar vintage and use similar LS chips.

But when I do try it as withe the OP I get a screen full of junk, it looks like it's not clearing the screen.

Cheers.

Phill.

There's definitely a potential issue here (as Garth also pointed out). The WDC 'C02 is not specified as accepting TTL input levels (although TTL levels are OK for Rockwell and perhaps other 'C02s).

Maybe the BBC micro and Acorn Atom happen to include pullup resistors (which would raise the TTL levels from LS series chips up to WDC's spec)...?

Edit: you could try adding pullups to the 2001 as a remedial measure. Wish I'd thought to mention that to the OP
Or just use a Rockwell 'C02 -- they're not that hard to find.

cheers,
Jeff