Here's a scan of something I did 12 years ago for a project that got cancelled before I finished. I had emailed it to Electric_Eye but decided to post it. It does not use RDY.

I'll be honest guys, I don't like slowing down a cpu "artificially" with wait states. My view may change in the future when I learn more, but right now I'd prefer to set a "speed" bit than wait states...

But after looking at Garth's last post, I am questioning a "cycle stretcher" vs. a "synchronizer". A synchronizer is what I posted yesterday. It takes 2 asynchronous frequencies and based on a select signal smoothly transitions without any spikes or runt signals between either frequency.

Is this the same as a cycle stretcher?
Quoting from Garth's last post where it's handwritten, "a 120nS EPROM would let us go about 12MHz...". A 120nS EPROM, assuming your address decoding logic is 0nS, could be addressed maximally at no more than 8.333MHz...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

A speed bit is no more artificial than wait-states. I'm curious to learn why wait states isn't something you're comfortable with.

I think in terms of speed only to keep it simple. If I know my EEPROM has an access time of 200nS, then max speed without any artificial hardware tricks is close to 5MHz. Right now, I push no more than 1/2 of that. Instead of figuring delay cycles, it's easier for me to think in MHz. So I set the speed bit for 2.5MHz when I need to read from the 200nS EEPROM. Right after the copy program is done reading from the EEPROM, I throttle the speed back to as fast as the WDC65C02 will go, which is nowhere near the speed of a 2M 10nS SRAM...

Hence my last question, how does one run a 120nS EPROM at 12MHz without using the RDY signal?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

12MHz is the frequency of the oscillator. With the speed input to my circuit low, you actually get 6MHz, but instead of being symmetrical, it will be high 75% of the time and low only 25%, giving you three times as long a phase-2-high time to work with as you get at 12MHz with a symmetrical square wave.

In your application, you can do with a single oscillator (fewer parts), and start with the speed input to the circuit low until you're done loading the RAM from ROM, then set that input high (which you can do at any time without producing a glitch), and leave it high full-time until the next boot-up. The job of giving the ROM more time to spit out its data is then only on this circuit and not on the processor.

I used 4000-series logic only for the low speed, to make sure I would be able to see any glitches or runt pulses on my inexpensive oscillosclope. I would never use 4000-series stuff on a computer board. The idea was that once the idea is proven, I would move it to at least 74HC if not faster. Actually for that project, I was going to put this and a bunch of other logic in a Cypress CPLD. 4000-series logic is very slow at 12V and ultrasuperslow at 5V. I only use it for interfacing to 12V analog stuff where speed is not an issue.

Interesting; I can't think that way myself. I think of time as an agglutinable resource, where I can snap together units of time to make longer units of time.

In this case, the basic unit of time is the CPU cycle, which I intend to be as small as RAM would permit. If ROM or I/O needs longer to respond, then using RDY to insert wait states would be an acceptable sacrifice to me. It also means I don't have to manually flip bits, which lessens my chance for error.

RDY is particularly useful for I/O with variable latency, though.

Oh, I should also point out that clock stretching/switching is valid; I'm certainly not bashing the technique. I just prefer not to use it. The Apple IIgs worked great, for example, switching automatically between 2.8MHz and 1.0MHz via clock switching, so prior art definitely exists to vindicate the technique.

Here's one reason to go with clock stretching, i.e. extending Phi2 high when accessing slower devices.

If the device's select lines are qualified with phi2, it is much easier to work with a stretched phi2, than to separately extend the select signals when RDY is asserted

André

But, it's the same logic. The select line is driven by the address decoder output. You, in fact, must add logic to extend the clock (in a phase-locked manner to avoid glitches) separately. The amount of logic is exactly the same.

Cycle stretching is definately worth looking into, so I'll pose just a few more questions...

So if I am having success reading an EEPROM at a certain MAX 50/50 Phase 2 speed, could I surpass this speed using 75%/25% cycle stretching?

How would the type of address decoding (i.e R/W with Phase2, or Address with Phase 2) be affected by cycle stretching?

EDIT: Reclarified question(s).

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I didn't say or imply there was anything wrong with it. In fact, it addresses an interesting design issue in a clever manner and with a small parts count. What I was saying for the benefit of those who may not be aware of the way RDY is controlled by the MPU, is that implementing the circuit exactly AS SHOWN could be destructive to the MPU and that gate.


I'm not certain I'd refer to an important part as "needless detail." The unsuspecting hobbyist, who might hook RDY directly to that last gate's output, would be in for an unpleasant surprise if his code executed WAI while the gate was holding RDY high.

I'm not trying to castigate you in any way, but a lot of folks pass through here looking for technical info, many of whom may not be as expert as you or other regulars when it comes to this sort of stuff. Including what we might think of as obvious circuit features helps the folks who maybe want to rig up their own 65xx contrivance to avoid making design errors that can cost them time and money in blown up parts.

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

BDD I see you your point. I used to blow out IC's when I was young. But even back then I was able to read data sheets. If anyone just starts connecting pins without regard to manufacturer spec's, then they should expect to see the "smoke go out" at some point...


I'm concentrating right now on address decoding logic. As I said previously, my intent is to copy any portion of a 512Kx8 EEPROM to anywhere within a 2Mx8 SRAM with software, control phase 2 speeds with a software programmable 1-bit port, and run the OS from SRAM at hopefully @ 14+MHz. Initial tests indicated 20MHz was successful while observing SYNC with a simple delay loop.

Although memory decoding was incorrect and SRAM was only active between $0C000-$0FFFF, the loop was running successfully, and delays were changing as expected. I was not using zero page or stack. The delay variable was in the Y register...

Last night I was able to run the display init routine from anywhere within the CPU's 64K using EEPROM only. Except for addresses $00000-$001FF & $08000-$0BFFF (zero page, stack and I/O). I think I have the /CE's correct.

Next step is correcting the /OE decoding logic for the SRAM/EEPROM. Tomorrow I will have dedicated time to iron it out.

I need to update my memory map from a few pages ago.

Next I will attempt to interface to a mini PS2 keyboard using Daryl's interface with an Atmel ATTiny 24.

EDIT:
SUCCESS! on the morn of 9/27/2010.

I'll skip all the irrelevant, improper address decoding techniques I was using, and get right to the "solid food".

I was using an FDCE "D" type flip-flop inside the Spartan 2 for the Phase 2 control bit. This flip-flop controls what the WDC65C02 sees on the O2In and simultaneously controls the SRAM_OE and EEPROM_OE's in conjunction with a $00000-$0001FF address decode. After ramping up the "higher" speed for Phase 2 from 5MHz to 20MHz, I would notice the speed, at a random time would switch back down to 2.5MHz. Meaning D0 was being latched right on the edge, incorrectly. I knew it was a speed issue as this did not happen when the "higher" speed was set to 10MHz...

Switching to an IFDX "D" type flip-flop, (which is the same type of flip flop, without a reset, except that it is internally connected to input pads (pins), namely Phase2, D0, and an address decode), is working very reliably now running more than 30 minutes at 20MHz.

Once I learn to clear display I will make a small video on Utube. Right now I am unsure why I am addressing a small window in the display. Within the window, the software loop is displaying the correct data, nothing random @ 20 MHz.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I found out why I was addressing a small window, instead of the entire 640x480 display. Apparently an STZ to display registers is not sending correct data. Although the data is consistent it was not a zero value. I found this out this morning before heading to work. I was experimenting with the display init values and decided before changing some values, that I would rewrite the code to do an LDA, STA to make it easier to just change a few values. SO starting with LDA #$00, STA displaydata, instead of STZ displaydata, it worked! as it should have from the beginning?... I know it's not a speed issue, as I've tried running from SRAM down to 2.5MHz (same as EEPROM copy speed) and have seen the same result.

So although I m pleased with this progress, I seem to be regularly making 2 steps forward, 1 step backward (sometimes even 1 step foward, 2 steps backward)...

Also I have learned alot about using symbols in the Xilinx ISE 10.1. It was about a 2 week struggle to get my custom symbols (symbols=schematic reduction)to work like the original schematic without symbols. Symbols in ISE are chunks of a main schematic, similar to making your own custom IC. I found it necessary because my original single schematic was growing beyond the limits of ISE's largest setting. Initially, I divided it into 3 symbols. 1 for memory decoding , 1 for banked address decoding, and 1 for the phase 2 switching circuit. Made sense to me, but not so easy... ISE 10.1 software was optimizing out my memory decode symbol. It saw bank address decode as priority, and negated wherever else the Address bus went. I realized this after synthesis errors... After combining the address decode and bank address symbols into 1 symbol, which both use A8-A15, the circuit worked as the original... I'm still learning. Maybe one day I learn VHDL.

Anyway, I once again have a working circuit within the FPGA with the W65C02 running @20MHz. My address decoding is still leaving alot to be desired...

Which is why I am posting tonight... System runs great until I hardware reset. It's a SRAM bank issue, it's ok. Now I've made it this far I want to strive for something ever better...

In my original idea, I wanted the address decode to switch down to the lowest 16K block inside the 2Mx8 SRAM ($000000-$0001FF) when zero page or stack was seen on the address bus (A0-A20) for the lower 16K block, and to switch to the highest 16K block for where the OS resides $1FC000-$1FFFFF.

Now I am thinking of 32K memory blocks with current zero page/stack memory spread across every 32K block within the 2M SRAM. So when I switch 32K memory banks $xx0000-$xx7FFF, zero page /stack is retained. Is it even possible to rewrite multiple chunks of memory simultaneously? This way, bank switching in between a 32K copy using Indirect-Indexed would be successful.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

sorry, long day...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

It sounds like you have a 65CE02 and got something else in the Z register, so when you do STZ, you get something other than 0. The 65CE02's Z register is initialized to 0 upon reset, but you can store other values in it, IIRC. But on the 65c02, I have never had trouble with STZ. It has always stored 0.

An individual SRAM chip won't let you write to more than one address at a time. Why not have your CPLD divide up the SRAM in 64 32KB sections, and have the lowest one alway be addressable regardless of which section is being pointed to by the CPLD for the other part of your 64KB address map. You need more than just ZP and page 1 to remain common, for reasons of variables and having code that stays in control when you switch the banking. You'll have more useful space because you won't have redundant sections of RAM. If I misunderstood you, just disregard.

Yes very strange about the STZ. It may be a clue to a future unseen snag. I dunno.... Wish I could find a 65CE02 core, it sounds like such an awesome progression of the 6502.

Not going to be able to use 32K blocks... Found an error in my thought process. Have to rewire a few address lines...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502