Hi guys

I've been looking at trying to speed things up in my future projects. My current project runs at 10MHz fine, but cannot get to 12MHz.
Here are the details:

Assembly method: Wire wrap on perf board, ICs almost shoulder to shoulder
CPU: WDC W65C02S 14MHz, DIP
RAM: LY62256PL-55Ll (256Kbit/32KByte, 55ns, SRAM), DIP - was a Toshiba 70ns, but I swapped it out to try speeding things up.
ROM: Winbond W27C512-45Z (512Kbit/64KByte, 45ns, EEPROM), DIP
Decoding: 3 gate NAND (see Garth's primer here)

To help address the speed issue, I'll be using a star ground plane in my next project and possibly using a GAL (or GALs) to do the address decoding as I want to do some RAM bank switching

One thing which I'm strugging with is RAM and EEPROM speed. With RAM I can try using 10-12ns SOJ or SOJIC packages and solder them to wirewrap sockets (as demonstrated in another post on these forums). However, EEPROMs & EPROMs just seem to be deeply slow compared to RAM with the avergae being 120-150ns and the occasional one getting to 55ns (and most of those being OTP).
I've been lucky in scoring 45ns Winbond EEPROMs from eBay in the past, but have not been able to find anything like it on Mouser & Farnell.

What do you guys use is situations like this? I ask as I know many of you manage to get much higher speeds than my little project. I don't really want to use a microcontroller to feed the system the firmware.

Any advice welcome

How about the "simple" thing? Have a dual-speed clock circuit, start the system in "slow" mode, copy your ROM out to RAM, set your bankswitcher to map out the ROM, and kick the clock into high gear?

Or the other "simple" thing? Wait state the ROM.

I've been running at 10MHz solid on a 2-board setup for about a year now... RAM is Alliance 32KBx8 at 70ns and ROM is Atmel 28C256 rated at 150ns (yes its being pushed but is solid). My decode is fairly old and classic... 74HC00 and 74HC30 for memory read/write qualification, ROM select and I/O page select and a 74HC138 for 8- I/O selects. I did try 12MHz but it wasn't stable, likely due to the EEPROM speed limit. I'm using both a 65C22 and 65C51 (both WDC parts) and they have not been an issue so far.

As your EEPROM has a faster speed rating than your RAM, I would suspect either noise getting too much or possibly your clock source may not be clean enough, at least something to check out. I did add some additional bypass caps for power supply decoupling to get the 10MHz setup working in a stable manner, but with simple 2-layer PCBs and a short ribbon cable to connect the I/O board to the CPU board, it's going to be limited on clock speeds.

_________________
Regards, KM
https://github.com/floobydust

POC V1.1 is running rock-solid at 12.5 MHz, using an AMD 27C256-55 EPROM, a 12ns SRAM and 74ABT and 74AC glue logic. The unit will boot at 15 MHz, but some I/O timing violations make that speed unreliable.

Your 55ns SRAM is probably running right on the ragged edge, as it can only be reliably read or written during Ø2 high. Also, EPROMs tend to generate significant transients on Vcc during chip enable, so you may need to pay closer attention to bypassing in that area.

Lastly, it may be helpful to look at your schematic and see if your handling of the EPROM's and SRAM's /CE, /OE and /WE (SRAM) control inputs could stand some timing refinements.

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

Thanks for the responses, guys.
The circuit diagram is attached below.

It seemed to be the case with the 70ns Hitachi I had fitted as it could barely cope with 8MHz. I replaced it with a Toshiba 70ns one which allowed for 10MHz. As that seems to work, I thought that putting in a 55ns one would allow for another 2MHz up to 12MHz.

However, it could be the lack of star ground plane on the project if everyone else is not having issues at 12MHz with these speed devices. I do have 100nF decouping caps on the VDD-GND pin on every other device. I'll put more on just to be sure.
With regard to the clock: My oscilloscope is a 25MHz Owon so will only give me a stable wave form up to 2-2.5MHz so it's hard to check as I don't know if what I'm seeing is right.
How should the distribution of the clock be set up? Mine's a bit haphazard as I ran out of space coming off of the oscillator can.

If your 120ns EEPROM can handle 12MHz then, as you say, surely my setup should be able to if one goes by just the parts?
As I said in my reply to BDD; I'm going to add more decoupling caps. The clock comes from various places as I rtan out of room on the oscillator can. I don't run anything off board unless it's through a VIA.

Well, I'm running a 150ns EEPROM from Atmel which is obviously overclocked beyond specification. Don't count on all manufacturers having a similar overclock ability with their rated parts. I would certainly double up on decoupling caps and also add a few larger caps, like 100uF at a few points on the board layout. Also, you may want to try a different clock circuit, using a flip-flop as a divide-by-2 to get a sharper clock drive. Of course this means your CAN oscillator needs to be double frequency.

Looking at your schematic, I see you have the CAN oscillator driving the CPU, the 65C22 and the decode logic. On my 2-board board setup, I use the Phase 2 clock output from the CPU (pin 39) to drive everything else, the CAN oscillator only drives the CPU directly. You might want to try swapping that over as it decreases the load on the main clock. Also, I use a 74HC00 to take the CLK and R/W lines to generate Phase 2 qualified memory Read and Write lines which go to both the RAM and EEPROM (I have code that allows programming the EEPROM insitu).

_________________
Regards, KM
https://github.com/floobydust

If you have no issues with additional hardware, how about a simple logic circuit to hold the 6502 off the bus on startup while a pair of 590 counters dump your ROM into a 10ns SRAM? After dumping the ROM, set the 590 CE's high, and drop the 65C02 BE and reset. This way, you talk to only a single 10ns SRAM.

In my current test setup I have running on a badly wired breadboard, my 65C02 ran a memory exercise test for a few days without a glitch at 25.175MHz.

Of course, I don't obey speed limits, so my suggestion is just a hacker's version of how I got my 6502 out of second gear!

Cheers,
Brad

Reminds me of how one (some? all?) Alpha CPU module starts up. Once the PLLs are stable for its clocks, it streams the initial contents for every register and cache on the CPU from a serial EEPROM, then starts executing at a fixed place in the instruction cache. From there, the startup program initializes the bus interface so that it can talk to RAM, I/O, and a parallel EEPROM that contains the (typically SRM) console.

You could use a dual-rate clock. After a reset the CPU runs at half the speed and the ROM region really selects the ROM. The reset routine copies the ROM to the RAM which overlays the ROM. Once the ROM is copied you throw a switch (a R-S-Latch which is cleared by reset and set by any access to some address range not used by the bootstrap code) which turns the speed to full throttle and disables the ROM and the CPU only runs from RAM. Now it is up to you whether you want the RAM region that holds the ROM to be write-protected. If you are going to use a GAL as the address decoder this is very straight forward. You can even implement the R-S-Latch in the GAL using only one OLMC. Also the chip enable of the RAM should not be qualified with PHI2 but just with the address, RW and the R-S-Latch. You better create a master-write-enable and a master-read-enable that go the /WE and /OE of the RAM that are qualfied with PHI2.
Another option I'm currently using is a dual-port RAM and a microcontroller, I know that you want to avoid that, but on the other hand you don't need a ROM. So you swap a ROM that needs to be programmed outside the computer with a microcontroller that can be programmed in-circuit, or even better you can download (XMODEM) a ROM image. That's what I'm testing at the moment and it is very convenient to be able to download a image via XMODEM. In addition after the bootstrap the dual-port RAM and the microcontroller start their second life as the frame-buffer and the VGA controller. The same micro controller could be used to attach a PS/2 keyboard (at the moment I still use a dedicated micro controller for the keyboard).

Cheers

Peter

Reading from slow devices is exactly what RDY is useful for - something like a shift register or counter should use the chip select to produce a few cycles of RDY, to allow the device time to produce the data.

(It's somewhat harder to slow down for writes - in that case you do have to modify the clock.)

Not that I've given it any substantial attention, but it was the NMOS 6502 that did not do anything if RDY is negated during a write. CMOS does.

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

Good point! Of course at these speeds it must be a CMOS part.

The ROM-to-RAM copy approach has some interesting advantages. But sometimes we want to "just make the darn EPROM work"! -- using the simplest means possible.


Generating wait states:The circuit above generates a one-cycle-long wait state when the EPROM is accessed. (For WDC, it's best to add a series resistor -- see below.) One wait state may not sound like much; but, when you're pushing the CPU close to its maximum clock rate, adding one wait-state roughly triples the time available for the EPROM to respond! Here's why. At high clock rates tADS and tDSR delays (which each consume a fixed number of nanoseconds) end up accounting for about 50% of all the nanoseconds in a clock cycle. (65xx timing is graphically explained in the Visual Guide to 65xx CPU Timing).

The access time remaining for memory to do its job works out to roughly 50% of the nanoseconds in one clock cycle. Adding a one-cycle-long wait state changes this figure from 50% to 150%. (The tADS and tDSU delays don't get applied again when a wait-state cycle is inserted.) Stated another way, if the cycle time is 100 ns, say, then adding a one-cyle-long wait state increases the available memory access time by 100 ns.

-- Jeff

ETA: There's an implicit assumption. The circuit only works if /CS goes low before the rise of Ø2 -- which is normally the case. BDD touches on this in the following post. Also: using the both halves of the '109, two wait states can be provided (see circuit below). The extra access time thus provided will be 200% of one cycle. The total access time will be about 5 times what's available using no wait states.

Further edit: in contrast to Rockwell and other suppliers, WDC makes the RDY pin bi-directional. A WDC 'C02 or '816 will pull its own RDY pin low as a result of executing a WAI instruction. This can result in excessive current flow if the RDY pin is driven high by external logic at the same time.

One solution is to use an Open-Collector or Open-Drain gate to drive RDY (as shown in the upper diagram in image below) but this limits the ability for RDY to quickly return high. It's better to use an ordinary gate and simply include a series resistor to limit current flow (lower diagram).

WDC's datasheet was revised to include a comment about the series resistor (as well as a comment about pullup resistors).
Unfortunately WDC doesn't suggest a value for the series resistor, so let's look at that question. Too low a value means increased dissipation, and the risk that a valid logic-low voltage won't be achieved. OTOH too high a value will produce unacceptable delay re the RC of the gate and resistor driving the capacitance of the RDY input. I myself would use a series resistor of around 470 ohms -- a rather low value, but IMO not so low as to prevent a valid logic-low voltage from being achieved. In another thread Garth suggests putting a small (~22 pF) capacitor in parallel with the resistor, which allows use of a much higher resistance but of course increases the component count slightly.

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

Something I noted is that it appears that you are gating the SRAM chip select with Ø2. That is generally not good practice. The problem as it stands is that the SRAM will not respond to chip select until sometime after Ø2 has gone high, which will set a hard limit on performance. It's better to select the SRAM (and ROM) as soon as a valid address appears on the bus, which is early during Ø2 low, and then gate /OE or /WE on the rise of Ø2. That way, all of the Ø2 high period is available to read or write.

Also, many SRAMs respond faster to /OE and /WE than to /CS. So the procedure I recommend (and use in POC) is to assert /CS as soon as the address is valid and then assert /OE or /WE only when Ø2 rises. As an example, the SRAM I'm using in POC V1.1 is guaranteed to respond to /CS in 12ns or less. If /CS is already asserted and /OE is then asserted, the SRAM will drive the data bus in 6ns or less. If /OE is already asserted and /CS is used to gate the device the elapsed time until the SRAM starts driving D0-D7 is 12ns.

I also saw a mention of the using the clock outputs of the 65C02 to drive all the other devices that need to know about the clock, and only driving the 65C02 from the Ø2 clock generator. Here's what WDC has to say about it:

3.8 Phase 2 In (PHI2), Phase 2 Out (PHI2O) and Phase 1 Out (PHI1O)

Phase 2 In (PHI2) is the system clock input to the microprocessor internal clock. During the low power Standby Mode, PHI2 can be held in either high or low state to preserve the contents of internal registers since the microprocessor is a fully static design. The Phase 2 Out (PHI2O) signal is generated from PHI2. Phase 1 Out (PHI1O) is the inverted PHI2 signal. An external oscillator is recommended for driving PHI2 and used for the main system clock. All production test timing is based on PHI2. PHI2O and PHI1O were used in older systems for system timing and internal oscillators when an external crystal was used.

In other words, WDC does not recommend the use of PHIO1 and PHIO2 in new designs. You should also consider the fact that PHI1O and PHI2O lag Ø2 by an amount that is not specified.

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