6502.org

Hello all,

I am getting familiar with the concept of wait-states to communicate to slower devices on a 65C02 bus.
Now, for my 8 MHz SBC i need to talk to a 1 MHz max. peripheral IC (Yes, ... it is a SID, or an ARMSID to be precise).

On several forums and on the internet in general, i can find circuits for 1 or 2 wait-states, but i my case i am going to need 4.
Now, for the life of me i cannot figure out how to accomplish that using discrete logic (which i want to use, no GAL/PAL etc.)
i tried stuff with JK-flipflops in several logic simulation programs, but i cannot figure it out...

Can someone please help me out on this one?
Thanks in advance!

RDY vs CLOCK STRETCHING. Includes 2 very simple circuits.

For four wait-states you'll want to consider the clock-stretch option. Probably the '163 counter circuit could be adapted to drive RDY instead, but I haven't looked into it. Or, just go with clock stretching.

I'm sure we can figure something out.

-- Jeff

Thanks Jeff, that looks promising.
I did see that topic before, but i couldn't read past the "two wait-states" thing...

Seems i can indeed use the clock stretching option with the '163, and use it to control RDY if i NAND the desired output with the inverted /CS.
I will experiment with this further in the morning.
Thanks.

Furthermore, Jeff's circuit using the synchronous counter has been tested on a live system running at 20 MHz. I think that is the route you ought to take.

If you are stretching the clock with the counter circuit you do not have to do anything with RDY. If Ø2 is stopped in the high phase, which is what the counter circuit does, the 65C02 will freeze in its tracks, producing the same effect as negating RDY. While stopped, the 'C02 will maintain all outputs in the state they were in when the clock went high.

Simply tie RDY to Vcc through a 3.3K resistor and pretend it isn't there.

jaccodewijs, I sent you a PM which I see you've not yet read.

You say you need 4 wait-states, and that's fine -- we can easily make the device's chip-select go low for that long. But the other question is, what about the device's /OE signal (and /WE, if the device is writable)?

A simple and common way to generate those signal relies on two NANDs and an inverter. /OE is simply NOT(R/W AND Phi2) and /WE is NOT( NOT R/W AND Phi2). But when this arrangement is used in a system that's also manipulating RDY then /OE (or /WE) will get a series of pulses, not one (unless extra logic is added).

A ROM can probably tolerate that. But for your project RDY maybe isn't a great idea. (Yes, I know I mentioned it!) With Clock Stretching, /OE and /WE will only get a single, stretched pulse.

No matter which method you choose, we need to know the following. What's the minimum time the ARMSID requires the address to be stable BEFORE /WE or /OE goes low?

-- Jeff

Yes, i understand.
Thing is, i am trying to modify my existing SBC so clock stretching is not a viable option at the moment.
For a new design I would probably go that route, but as it is, using the RDY method is the only thing possible.
(Since i don't want to rip up half my PCB to cut the existing clock lines, and i *do* want to keep my VIA's running at a constant (unstretched) clock).
Also i cannot implement the 2XCLK for that same reason.

Thanks for all your quick replies, guys!

Sorrry, our messages crossed.
I get what you're saying, and i might *have* to look into clock stretching then.

Probably have to redesign my PCB anyway after hacking it to run 8x faster

I'm sure with some extra logic the issue with RDY could be overcome. It's just a question of what course best suits the circumstances.

But I repeat: no matter which method you choose, we need to know, what is the minimum time the ARMSID requires the address to be stable before /WE or /OE goes low? Is it OK if they go low very early in the stretched cycle? Simply making the cycle longer is only part of the question. The other part is, how soon in the extended cycle is it OK for /WR and /OE to become active?

A flexible solution to generate a RDY signal for up to 8 wait-states may be to use a parallel-load shift register; the 74HC299 is a useful chip to keep in stock and will work for this. This is potentially a single-chip solution, provided you're using a CMOS 6502 (which you are), and assuming you have logic to generate a select signal. We require the CPU to be sensitive to RDY at the falling edge of Phi2, and to respect it on writes as well as reads.

The '299 is a synchronous universal shift register. The function it performs at each rising clock edge is determined by the state of two control lines, S0/1. When both are low, it holds data; when both are high, it does a parallel load; when just one is high, it performs a left or right shift depending on which one. It can also do a parallel output and an asynchronous reset, but we won't use those. We'll just use Phi2 as the clock input, and tie the /OE and /MR lines high.

What we want to do is to parallel-load the shift register after every cycle that is not wait-stated, and shift right for every cycle that is wait-stated. This is easily accomplished by using the Q7 output to drive both the S1 input and RDY, and tying S0, DSR and DSL high. We then arrange for addresses that do not require a wait-state to present high states to all of the parallel I/O pins on the '299, and those that do to present low states on the correct number of high-order parallel pins, and high levels on the rest.

For an 8MHz CPU driving a device that requires almost 1000ns pulse width of /CS and /OE, it would be appropriate to insert 7 wait states, making the CPU spend 8 cycles in total on the access. So you would tie parallel I/O lines 1-7 to the select line of the device, and tie I/O 0 high.

I am told the ARMSID has exactly the same timing requirements as the original MOS6581/MOS8580 SID.

https://www.waitingforfriday.com/?p=661#6581_SID_Timing

As far as i can see, the address should be stable 0 nS before R/W goes low!
But we all know that the SID datasheet is not exactly errorless...

I attached my current address decoding circuitry as a .gif to this post.
(very standard '688 and / '138 arrangement)
Keep in mind i use the direct R/W line for the (ARM)SID, not the qualified /READ and /WRITE.



@Chromatix: your solution sounds very interesting indeed. I'll check in to that as well.

*EDIT: By the way, using the two halves of a '109 as Jeff described *almost* made it work; there are come crackles but generally the ARMSID sings.
Not sure if that is anything to go by, but does give me hope.

Okay, here's an early draft of a diagram I'll eventually add to my main post. Comments (and proof-reading!) welcome.

This spills the beans on a '163-based RDY sequencer. I've shown detailed timing for only two possible examples, but others exist (based on different counter load values).

As you see, /SELECT being inactive (ie high) means the counter will surely load 0xF. But the value loaded when /SELECT is low varies between examples. If you wire the counter inputs so the counter loads 0xF or 0xE then the extended cycle will take 2 cycles total, and if you wire the counter to load0xF or 0xB then the extended cycle will takes 5 cycles total.

Optionally, you can do more than simply lengthen the cycle (pull RDY low). You can connect one of the counter output bits as a timed enable that trims the width of the /RD pulses and /WR pulses sent to the slow IO device -- note the bottom trace in each of the timing diagrams. You're giving the device extra address setup time before /RD or /WR go active; also extra address hold time after they've gone inactive. In a high clock rate system, this is the sort of pampering many sluggish devices require.

Without this timed enable you'd probably be forced to use Phi2 to qualify the /RD and /WR pulses -- and using Phi2 means each access will yield not one continuous /RD or /WR pulse but instead a series of short pulses, shown in the timing diagrams as /RDWR(a). Some ROM's may tolerate this, but /RDWR(a) is clearly not an ideal choice


Chromatix's '299 suggestion also bears consideration -- and I agree the 74HC299 is a useful chip to keep in stock. (BTW for this application the physically smaller 74_166 would work, too, although it'll require an inverter.) As described, the suggested circuit doesn't offer the timed enable I just mentioned, but that's easily remedied simply by adding a second '299 (or 166). One would output to RDY, the other to the enable signal.

Compared to a '163, the pair of shift registers give more flexibility in adjusting the setup and hold times to the minimum required. In some cases that should buy you a modest performance boost.

Doubling up the shift registers involves a space penalty, of course... unless you're willing to piggyback one '299/'166 atop the other. The upper chip would have its parallel inputs tied high/low in a different pattern, but AFAICT only one pin (the serial output) will need an awkward flying lead to connect to the motherboard.

-- Jeff

edit diagram: one minor tweak, one outright bug fix!

Becoming quite the interesting topic here

I see what you mean, Jeff. Clever.
If i was to use this setup, as i understand it,. I would have to add another inverter to the now stretched /RDWR line, as the (ARM)SID normally uses the processors (combined) R/W line directly.
Should not be problematic, just an extra logic block added to the SBC

I am going to experiment with this for a bit (if i can dig up a '163 from my stash).

Thanks again.


*EDIT* I stand corrected, the stretched /RDWR line IS a combined line for read and /write...

Apologies -- I didn't really complete the picture, having not yet considered devices which use the 68xx/65xx style bus interface.

I guess I was thinking R/W from the CPU would go straight to the 65xx device's R/W input. And of course /SELECT (presumably from an address decoder) goes to the 65xx device's /CS input.

Leaving us with the device's Phi2 input. Which I guess would be driven by an *inverted* version of one of the trimmed-width pulses. I mean the Q outputs -- /RDWR(c) or /RDWR(b), depending which extended cycle length you've opted for.

But when the device isn't being accessed Phi2 will remain low -- no clock at all. Will your (ARM)SID object to that?