The email editor here stinks! I wish I could go point-by-point ... <sigh>
> How did you try them?
Well, I didn't try them, though I emailed the WDC folks at a time when I had a solid application for their part. I tried every source and agent I could contact and nobody I could find had ever encountered a 65C02 from WDC, least of all one of the fast ones they claim to make. It does no good that they're making the parts, if, in fact they are, if they won't sell them.
The Rockwell 65C02 instruction of which I'm fondest is the indexed indirect jump, by the way, though the bit manipulations are also handy.
I believe I agree about the package size, and, since all my prototype boards are made as you describe, ground plane on the wiring side and power plane on the component side, with a grounded strip around the outside so one can easily ground a scope or L.A. probe, though I had mine made with dry-film solder mask so I don't have to worry about solder problems. If I need to attach bypass, I normally use a .01 uF or 220 pF cap right at the leads. It's about as good a power distribution scheme as one could want. I've used standard DIP's in this package and managed frequencies as high as 16 MHz without difficulty. The board helps a lot with power<=>ground noise, and I've had circuits on these boards with well over 100 flipflops all driven from the same clock operating quite reliably.
High frequencies are a problem sometimes, but I see no reason to be afraid of them. Of course there are few classical applications that require them. Most control and communication tasks can be managed just fine at modest frequencies well under 100 kHz, so they can be accomplished easily with a 1 MHz CPU. What's interesting to me, however, is to see how much can be done with lots of speed rather than lots of resources.
I've heard talk and read email, etc, about the fast WDC parts, but I don't know anyone who's actually bought them. If you have a proven source, please share it with me. I have some goodies that I'd like to try running on a fast 65C02. One is I'd like to bit-bang a floppy disk and possibly a hard disk interface. I think that would be interesting, since it would be limited only by the programmer's ability. One should easily be able to read any format without worrying about the controller.
Now, about that timing with a "20 MHz 65C02" if one could believe it to exist, I do believe the margins are a mite more generous. First of all, addresses settle during Phase-1, well before the rising edge of Phase-2. From the standpoint of memory timing, however, that should be of no concern whatever, since almost everyone has cache memory lying on the floor of the closet on an old '486 board that uses 8,10, 12, or 15 ns cache. All you have to do is transfer the contents of your EPROM to the SRAM before switching from 2 to 20 MHz. Today's inexpensive GAL's will decode, switch, count, etc, at speeds well in excess of 150 MHz with pin-to-pin delays on the order of <5 ns.
The trouble with getting WDC parts to run at 20 MHz is simply in getting WDC parts. I've experienced no other difficulty. So far, the 2-micron Rockwell parts I've got are the fastest I've used, and the timing I see with them suggests they'd routinely run 2-3x as fast as they're rated. I may have to give that a shot sometime.
I find it's easier, with a 65C02, to use a RAM disable rather than enable. An I/O select disables the RAM, so it's normally enabled. I'm not sure why that works better than driving the enable selectively on memory select. It does, of course, make for fewer transitions on that signal.
I'm working some retrocomputing problems (repair, etc) with old Z80 stuff from time to time, and once that's done and working right, I'm looking to try to translate the CP/M OS from PL/M to 'C' for purposes of trying it out. I've never tried to translate a working piece of software from one processor to a completely different sort of CPU, though I have translated to 650x from 680x. Back in the early '80's I had a multiple processor development system that used a Z80 running CP/M as the system I/O processor, and as the master processor for Z80 development as well. When another processor wanted disk I/O, the Z80's console input buffer was loaded over the shared bus, and the Z80 was awakened while the requesting processor released the bus. When he was done, the Z80 relinquished the bus so the disk buffer could be accessed. It was nice being able to use a single OS console interface for all the processors. If I had to do that again, I'd change a few things, but probably not the OS.
Uli
|
|