6502.org

I am trying to understand the dynamics of address decoding for the 65816 using more than 64k and how it impacts the 65C22 chip selection.

The '816 asserts A16-A23 on the databus and is clocked into a latch on the rising edge of PH2. By the way, my March 2000 copy of the datasheet shows this in the timing diagram while the later 2004 versions have removed it. The setup and hold times are still listed but the diagram is missing.

Now, as Garth had pointed out, the 65C22 expects the RS and CS to be valid on the rising edge of PH2 also.

Now comes the dilema. How can you put IO space in the lowest 64k page only? You cannot wait until the A16-A23 are latched on the rising edge to decode the page because the 65C22 is already expecting the RS & CS to be valid! At 14MHz, the A16-A23 setup time is 33ns max and the clock pulse low time is 35ns. There is not enough time to decode A16-A23 unless you reduce the max clock from 14MHz to allow for the decoder propagation delays.

Am I reading too much into the datasheets? Has anyone else experimented with this?

Thanks

Daryl

1. you can make a lower address latch and merely wait for both to have valid addys before asserting cs and rw.

2. Latch only the 6522 select address so it holds over into a valid time for the lower addresses, then assert at that time...

stupid ideas from a wierd person here
//need coffee
////hates coffee
//////thats my own problem

It seems that reality shows their actual parts are always better than the timing specifications. This is definitely not the first time we've found things in the spec.s that would seem to indicate the part can't work at all at 14MHz, yet WDC had a customer (I don't remember who, and maybe they're still doing it) who was making and selling a product that ran them at 20MHz. Even if they did 100% testing at the temperature extremes and lower end of the allowable power supply range, you know they couldn't build a business unless most of these parts could do at least 20MHz consistently w/o problems. I do wish WDC would get their timing spec.s corrected. This is getting quite irritating. At least the parts are proving to do better than the spec.s and not worse, which is good, but we find that some of the spec.s are worthless and we have to do our own experimentation to find out the truth. What you're pointing out should be brought to Bill Mensch's attention. You wrote, Remember to include the delay in the '573 latch as well.

I have no doubts that it will work, I just want to figure out how. Do I need to incorporate an elaborate clocking scheme that latched the upper address byte before PH2 rises and/or do I just wire it directly using the fastest part I can find and hope it works?

Daryl

The one advantage of latching is that you are guaranteed a valid signal while the other method of hoping for the best is dependant on clocking speed madness.....

I e-mailed WDC about this, and they said that they would correct the error as soon as they could.
A23-A16 is valid on the bus 33ns after the falling edge of Phi2. Therefore, you can use Phi2 to *passively* latch A23-A16 via a 74AC573 chip -- in fact, this is precisely what's recommended in their datasheet. Assuming 12ns of propegation delay for the latch, the new cycle's A16-A23 becomes "valid" after 45ns after the falling edge of Phi2.
I don't like the use of the term "setup" time, because it implies that it MUST be valid 33ns before the rising edge of Phi2, which is clearly not true (The SuperCPU expansion for the Commodore 64 runs its 65816 at 20MHz). The proper way to think of tBAS is as a delay. When viewed in this light, it makes more sense, since it is presented on the bus after 33ns. Note that tBAH is 10ns, so the total time it's on the bus is 12ns for a 14MHz part.

That being said, you are absolutely correct in that you need to slow the clock down to ensure proper setup time for the 65C22.

The only reasonable way to get 14MHz performance out of the discrete processor package is to introduce wait-states for slower logic. This is the curse of single-clock-per-memory-cycle designs. With most other CPUs, this is hidden because it usually takes 2 clocks to 4 clocks per memory cycle anyway.

I've designed a circuit that allows the 65816 to couple with slower, synchronously clocked peripherals. It's probably a good idea to draw it up and put it on my website for others to learn from.

Is there any point to running it at 14MHz in a complex design?

It seems any data to be 'read' by the processor must be presented in 35ns, including all your decoding. A CPLD/FPGA can easily decode fast enough, but DRAM tops out at 60ns. So, every time you access DRAM, you have to have logic that detects this, puts on the brakes, waits for the system to catch up, and then lets the processor go again. Why not just run it at 8MHz, have a cycle time slow enough so you don't need any sync logic, and you can use all the ISA spec'ed I/O chips out there, like the 16C550 with minimal external logic?

A modern system would address this with caching, and I suppose you COULD design your own cache controller using SRAM if you really wanted, but I've done the theory behind it, and it's reasonably ugly.

My next design will either run at 10MHz or 14MHz. I'd like to core to run as fast as possible. Cypress sells a 512kx8 SRAM chip with 12ns access time. This would support 14MHz without caching.

I plan on building a prototype core so I can test it at 14MHz and test the interactions outside the core. One thought was to use a 65C22 as the interface to the lower-speed peripherals. Thus my original questions concerning access to the 65C22 at 14MHz.

I would probably fall back to 10MHz or even 8MHz if the 14MHz speeds prove troublesome.


Daryl

Yes, there is, if you need the bus bandwidth. I was, at one point, planning on building my own guitar effects box around the 65816, and 14MHz would definitely be, shall we say, "nice to have." However, that project is currently on hold since, well, I still can't play the guitar very well.
I was thinking about building an experimental box running at 10MHz or faster, where the cache is managed exclusively by software -- e.g., have a small amount of really fast RAM, and a large amount of slower RAM addressed using a VIA chip or some such. To make it efficient, cache "lines" would be a 256-byte page (thus making this entire system a page-based MMU-dependent system). The overhead shouldn't be any worse than on those computer systems that have a pure software-managed paging TLB on-chip (e.g., early MIPS).

I was thinking of something like this for a memory map:
At least one byte of I/O space would be used to supply A21-A28 (or more) for the RAM, while the slow RAM window provides 2MB of space with which to use MVN or MVP to haul data around.

I was thinking about this because SDRAM has such an awkward bus interface (it makes perfect sense for caching or streaming applications, but is HORRIBLE for random-access chips like 65816). Another way of looking at it is to have up to 2MB of core memory, and 256MB to 16GB of SDRAM "ram disk" for swap space.

Anyway, it's just an idea.

Just an idea...

If the 65C22 proves troublesome, why not just resort to using a 74AC573s for dedicated input or output ports? Although it takes more board space, and you lose the ability to use the timers (though it's possible to work around that as well, using 74AC573s and dedicated down-counter chips).

I figure one 74AC138 to decode write accesses to 8 write-only output ports, one '138 to decode 8 read-only input ports, and maybe one '138 to decode up to 4 16-bit wide timers. That pretty much covers everything I can think of.

Yes, that was one possibility I had considered if the 65C22 can't cut it.

I'm still playing with numbers and layout. For the speed, I am figuring on using the TQFP package (or maybe the PLCC) and a 4 layer PCB.

I have this FPGA chip I want to experiment with also.... I just need more time!!!!!

Daryl

You mean a TQFP package for the 65816 or 65C22? WDC doesn't make the TQFP 65816 anymore.

Well then, that settles that question! Thanks for the update. The latest 65816 datasheet still has the TQFP listed. Guess I need to visit their website more often.

On another note, I was hoping that their 65C51 would support faster speeds than 4MHz. That was somewhat disappointing. Hopefully, they will improve their design over the next few years.

Daryl