I have read a couple of the other threads on the forum discussing the RDY pin, but I still have couple of question about some assumptions I'm making. I would also like to hear any of your opinions how I plan to implement wait states.

I am managing the bus and the PHI2 clock of my system with a state machine running on the FPGA. This has worked out great so far and I have very granular control over the timing of signals throughout the PHI2 cycle.

I want to implement video output with the FPGA and want it to be able to fetch data from a frame buffer in external memory shared with the CPU. Up to this point I have simply had RDY and BE pulled high with a 1K pullup resistor but have had those pins routed to the FPGA for just this sort of thing.

Reading the datasheet on the '816 I see that the WAI instruction may pull the RDY pin low. It also sounds like the CPU never actively drives it high and relies on and internal pull up. Looking at the timing diagram I am making the assumption that the RDY pin is sampled, or pulled low in the case of the last cycle of WAI, at or near the falling edge of PHI2 (its amazing how many assumptions you have to make even when the datasheet is right in front of you). Does this sound correct based on what you guys have seen?

I know I should not actively drive RDY high if the CPU is actively driving it low. But what about having the FPGA and the CPU driving it low at the same time. Is that safe? I would think so as it would be like hooking ground to ground, right?

My video logic will be running asynchronously with respect to the CPU clock, It will signal that it wants to use the bus and the bus state machine will ensure that RDY goes low at about 20ns before the next falling edge of PHI2, at the falling edge of PHI2, BE will be pulled low and the video logic will be signaled that the bus is available. The video logic will drive the bus and read from ram and then signal that it is done. Starting 40ns before the next fall of PHI2 the bus state machine will drive RDY high for 20ns and then set RDY to Z, and at the falling edge of PHI2 it will set BE high. I'm hoping that driving RDY high for a short time will give the pullup resistor a little kick to pull the line high before the falling edge of PHi2, I can adjust the time if I need more. If the video requests or releases the bus less that 40ns before the falling edge of PHI2 it will have to wait for the next cycle for the request to take effect.

I'm also wondering if I should check the state of RDY before I pull it low. If it is already low, I can assume that a WAI instruction has been executed and in that case I will not drive RDY high when I release the bus. (but would still need to drive it low, which is why I asked about that above)

Thanks in advance.

you see there are many obstacles using RDY but I think you figured out how it could go

There is no danger to pull RDY low when it is already low, but that could only happened if there was a WAI instruction and the releasing interrupt is pending.

Driving RDY briefly high is less safe as it might collide with the pull down due to a WAI instruction. On the other hand this contention would be so short that there is no danger of destroying something. But you can easily test whether it is necessary at all by switching from pull down to high impedance directly, your 1K should manage that.

One thing I am wondering about is that you stop the processor from working if you wish to access video RAM. Most circuitry for 68xx or 65xx (due to the similar bus) use PHI2=0 for video accesses ("hidden access"). Having an FPGA it should be easy to read video RAM in advance during PHI2=0 and buffer that datum until it wents to the shift logic. If you "simply" manage to buffer one or two video RAM accesses you never need to stop the processor. Of course, the RAM must be able to serve two reads in one processor cycle as worst case.


Cheers

There is a major caveat with using the "Phi1 hidden access" method with the '816, as the latter (unlike earlier 6502 family CPUs) *does* use the data bus pins during Phi1, to supply the bank address (A16-23). So as well as everything else, you need to isolate the data bus between the CPU and the RAM in order to avoid halting the CPU.

Generally, the Phi1 method also involved having separate address buses from the CPU and the CRTC, with the two being selected between at the DRAM control logic. In the case of the C64, the VIC-II was also the DRAM controller, so the CRTC address was internal to that chip, but most other 8-bit micros had a separate CRTC. With modern SRAM, the address bus is typically connected directly to the RAM, so that's another point you'd have to isolate.

So the RDY method makes a certain amount of sense, even though it would slow down the CPU. Two further options are worth considering though:

- If your video output only needs RAM access on a minority of bus cycles, have it opportunistically read ahead during CPU internal cycles. These are signified by VPA and VDA both being inactive, and you can feed a combination of these back to the BE signal to have the CPU relinquish the bus when it's not using it. You'll still need to use the RDY method if your readahead buffer goes empty, due to the CPU executing data cycles continuously for too long.

- Move your framebuffer to a separate RAM array on an isolated bus, to which the video system has priority access, and which the CPU only accesses for specifically video-related purposes. This allows the CPU to proceed unimpeded for general computation, and it will still respect RDY in case of framebuffer access contention.

Yes, I thought that would be the case. Thanks for the confirmation.


I did think about that, but the timing doesn't work out, and as Chromatix mentions above the '816 puts the upper bits of the address on the bus during PHI2 low. Since I have 4Mb of memory I need the bank address. My cycle time is 140ns, 70ns PHI2=0, 70ns PHI2=1. I can't tristate the bus until 10ns into PHI2 low or I violate the hold time on the data bus from the previous cycle, and tristating takes 30ns so now I've lost 40ns of the 70 I have available. My RAM is 55ns memory and even worse, my ROM is 70ns. I have character data in ROM so blocking the processor is really the only option I could come up with. I am only planning on a resolution of 320x200 so I won't need the bus that often.

By the way, I spent 6 years in Germany when I was younger, my dad was in the army, and he was stationed in Nuremberg in the early 80's. Beautiful country, wonderful people. I miss it quite often.


This might actually be doable, the timing would be tight since VPA and VDA aren't valid until 40ns into the cycle, but I think I could make it work. However, as you noted I would still have to implement halting the processor with RDY and add additional complexity on top of it. I'm already well beyond my feeble capabilities

This is also a good idea, but it would require more IO pins than I have available.

What FPGA are you using?

Also, I don't know anything about your design but I have thought about a similar system for a while. Why not use 12-15ns SRAM? I believe you can still get them in DIP packages and 5V. 3v3 should be even easier to find.

_________________
Cat; the other white meat.

I am using a Mojo v3 dev board from Embedded micro in the final build, and a digilent nexys 2 for designing and testing the individual VHDL modules. I have also been using the nexys 2 as a piece of test equipment for monitoring the bus an control signals.

Going with faster RAM might be an option for version 2. Might even be willing to try some SMD components now that I have a nicer soldering station rather than the crappy $15 iron from Home Depot. Now if I could just find a nicer set of eyeballs to work on those tiny SMD pins

You are welcome!


Using a 70 ns EPROM may not work if you are trying to use PHI2=0 hidden accesses, at least it's not serious.

The "problem" of fetching the bank address does not apply as you would fetch the bank address on the CPU side of a multiplexor that switches between the CPU bus (AB and DB) and the graphic bus.

Using BE to tristate the CPU saves hardware (multiplexor) but took time.

But I think your way of switching between refresh and other accesses by halting the CPU is fine, it saves some hardware at the expense of a little throughput.

As an alternative to deal with RDY you should take a very close look at BDDs idea of stopping the clock for certain situations. There it is used to access slow IO but you can easily (having an FPGA) stretch either half of the clock of the CPU to squeeze a video refresh access into it. You do not need to tinker with RDY, you simply stretch the time. Only by intuition I assume the rising edge of PHI2 is a good place to stop the CPUs clock until you have processed your video work. Perhaps this allows you to increase the CPU clock even further.


Cheers