6502.org

Hi! I am new to 6502s and I have a few newbie questions. I have started on one simple project to learn how things work and I am already planning the next project. I read Garth's primer and found it extremely helpful but I still have a few questions about address decoding. My plan for the project is to have 512K of RAM split into 32K pages. Two buffers would hold the upper address bits of the RAM chip and A15 would control which one drives the address. To change pages I would write a new value to the buffers. With two buffers I could copy data from any 32k page to any other 32k page without changing the address buffer. I would also like the first 2k of address to always be mapped to the first 2k of the RAM chip so that I don't have a new stack and zero page every time I switch pages. It can also hold some code to do things while the other two pages are being set up.

So my question is, would a 6522 be the best way to get the two buffers I need to drive the upper bits of the RAM?

After I have this working on a breadboard I would like to make an SMD version and I noticed that the 65C22 does not come in a QFP package. Could I use a 74 series latch for the buffers and skip the 6522 altogether?

I am trying to save as much RAM as I can. For this kind of design would a 74HC688 be ideal? I thought about using one to disable the two buffers any time the lowest 2k of address space is accessed. Would it be smart to use something like a 74HC244 that is wired directly to ground in that case? Could I just use pull down resistors?

The only other hardware I need other than maybe a timer is SPI plus one byte of output and one byte of input. Could I use one 74HC688 to grab a 256 byte chunk then use something like a 74HC138 to divide it into seperate areas for that I/O?

Eventually if I can get this running I would like to have my SMD board working close to 14mhz. Would it be possible to have low propogation delay with a design like this or is there a better way to go about it?

Thanks for your help and your patience with newbie questions!

Welcome!
Keep in mind that the reset and interrupt vectors reside in the space of $FFFA-FFFF. No choice. Unless you pre-load RAM before releasing the processor from reset, you'll have to have ROM (not RAM) in the vector space and for the reset routine. Again, there's not really any choice, because it has to be there before the computer has any chance to load it. It might be better for example to have ROM from $E000 to $FFFF, I/O from $C000 to $DFFF, main RAM from 0 to $7FFF, and a 16K window into your larger RAM space from $8000 to $BFFF. Another split might be 16K of main RAM from 0 to $3FFF and a 32K window into the larger RAM space from $4000 to $BFFF which might take a little more glue logic.

I think you'll do well to have enough main memory that's always there at its address space to run most of your program material, and just have data in the larger RAM that you look through that window to access. I thought the RAM banking on PIC16 microcontrollers was bad enough (requiring a lot of instructions just for bank switching, and requiring attention and looking ahead); but recently my code has overflowed the first 2048-word program page into the second, and the mickeymousities of the program-memory page-select bits have caused an awful lot of bugs, and wasted a lot of my time. Doing this kind of thing on a 65xx system, for data only, with only part of the memory map being a window into a much larger memory space, might work fine; but I sure wouldn't want to duplicate the PIC's problems. What a rotten design that was! Now after having been using PIC16's for 17 or 18 years, I am still being stunned by its kludges.
It's kind of overkill if that's truly all it were ever used for, but it does give some nice things you'll almost surely be glad to have later, with the CA and CB lines, timer/counters, and SR.
Sure. Either a transparent latch or an edge-triggered register would work, locking in the output value when phase 2 falls at the end of the cycle. Even if PQFP is hard to get, PLCC is definitely not; so you're not forced to use the DIP.
This part may need some more explaining. It's not clear, to me anyway, what you mean.
Do try to minimize the cumulative propagation delay. The fastest operation won't normally come with fine-grained address decoding.

First, welcome to the forum.
What you've described doesn't sound all that simple for a first effort. Pardon me for being a gruff old curmudgeon, but I think you are making it too complicated. Also, as Garth pointed out, you need ROM at the reset vectors—there's no way around it, as Garth also pointed out.
That's may not be achievable with 74HC logic, especially with your desire to bank RAM. You're going to have a fair amount of cascaded logic, and all those prop times can quickly add up. At 14 MHz, cycle time is 70ns and in the case of 65xx I/O hardware (65C21, 65C22, etc.), chip selects and RWB must be valid before the rise of Ø2. In other words, your glue logic has to be fast enough to do its job in 35ns or less. At that speed, you will need at least 74AC logic to avoid timing violations.

We're not trying to discourage you in any way, but we want to see you experience success with your first project. Making it too complicated increases the likelihood of obscure hardware bugs and a DOA unit.

Thanks for the welcome!
I remember that from your tutorial. I had planned to use a small amount of ROM around that area for the vectors and boot code.
This sounds similar to what you described in your primer. The problem is that I would lose 8k of address space for I/O when all I really need is a way to latch out four different bytes and input one byte. This is why I was asking about using a 74HC138 and a 74HC688. Is there a way I could take out just one 256 byte chunk of addresses with a 74HC688 and use that for all five bytes of I/O?
Yes, I don't mean to make it overly complicated but if past experiences with microcontrollers are any indication I will need much more than 32k for my code. I do see how switching banks can be a real headache.
I mean A15 through A18 of the RAM should be driven by the buffers except when the processor tries to access addresses 000000xx.xxxxxxx (the lowest 2k). In that case A15 through A18 should be all zeroes and the two buffers should be disabled. When both buffers are disabled, would pull down resistors be enough to make A15-A18 all zeroes?
Right. I meant that I am working on another simple project now but I wanted to go ahead and describe the second project to you guys, even though I haven't started yet, because I am not sure how the decoding would work.
That makes sense. Maybe the AC series would work like you suggested or one of the other series that is SMD only.
No problem. Thanks for the help!

My POC unit runs at 15 MHz with 74AC (through-hole) logic. However, RAM, ROM and I/O decoding is not complicated, with no more than two gates between the relevant address bus lines and the device being controlled, keeping glue logic prop time reasonably small. If you want to bank RAM with the 65C02 as you are contemplating you may find yourself looking at programmable logic to avoid too much cumulative prop time and board real estate consumption. Also, you may find implementing the banking scheme in discrete logic to be onerous.

Yes, but it'll require quite a few logic gates to decode it (you'll need to check A15-A8 for equality for a particular value in this case).

The most simpler way you divide your address space, the less glue logic you'll need. If you want something too "complicated" with many "zones" of memory for different hardware, you'll need to either 1) use a GAL chip or 2) slow down the clock rate and have a whole lot of 74xx chips.

By the way, 74xx138 and 139 are your friends when it comes to decode an address space
In D.C. this would work fine but overall it's just a poor idea. Big resistors will make falling edges too slow, and small resistors will consume a lot of current for absolutely nothing and make rising edge slow.
Use AND gates instead for this.

In order to keep things simple, I'd suggest the following :
$0000-$3fff : Fixed RAM bank (1st bank)
$4000-$7fff : Switchable RAM bank
$8000-$bfff : I/O interface
$c000-$ffff : BIOS ROM

This can be decoded with half of a '139. You can use the other half for decoding four different I/Os for example. You'll also need a register to remember the bank you're using, and a '08 or equivalent to AND the register's outputs with A13 and make the 1st bank fixed. So with 3 chips, you can make the computer you wanted, and since the chips are not cascaded, you'll be able to make it reasonably fast (well actually both sides of '139 are cascaded for the I/O in what I was talking about..., but since I don't know what is your I/O I can't help much).

Could you tell more about how you calculate those kinds of timings? Also, is the minimum time for the up phase of phi2 also 70ns or could you use an asymetrical clock with a longer down phase and shorter up phase?
Like I was saying, I just need to be able to set 4 different latches and read one byte in. I see that splitting the addresses into 4 zones is a simple way to do things but it seems a bit extreme to lose 25% of your address space for just 5 bytes of I/O when you are trying to maximize how much memory you can work with. Maybe I will slow the clock down then if it turns out I really need as much memory as I think I will.
I am almost finished with a scientific calculator and the microcontroller in that has 16k of flash. Everyone scoffed and said there is no way you will ever fill that up making a calculator but with trig, log, sqrt, etc the code went to 26k. Some of that is bloat from the functions used to bitbang parallel SRAM since it doesn't have an external memory interface and for communication since I had to spread the firmware out over two 16k chips but that was just for basic functionality. Adding a programming mode like I originally planned would surely have pushed it over 32k.

All it takes is simple math—there's no rocket science involved. The "AC characteristics" and timing diagram in the data sheet are your friends.

Assuming a 14 MHz Ø2 clock (the highest rate officially supported by the W65C02S)...
...then the machine cycle time is 70ns and each phase of the clock is 35ns, assuming a symmetric clock source. As tADS is 30ns maximum, that leaves 5ns (not 6ns) during Ø2 low for your RAM, ROM and I/O devices to respond to chip selects before Ø2 goes high. 35ns later you're back to Ø2 low and tDHR or tDHW become the controlling values. What they define is how long a device must continue to drive D0-D7 after the fall of Ø2 (tDHR) or how long the MPU is guaranteed to drive D0-D7 after the fall of Ø2 (tDHW).
Using an asymmetric clock is stealing time from Peter and giving it to Paul, and is not advisable. For example, if asymmetry favors chip selection, meaning Ø2 low is longer than Ø2 high, then read or write operations become constricted due to the reduced Ø2 high time. Better to fix the design by choosing the correct logic instead of monkey-rigging with an asymmetric clock.
Well-written machine code is surprisingly stingy when it comes to memory usage. My POC V1 unit has 52KB of RAM ($000000-$00CFFF) and I have yet to use more than about 10 percent of it.

Garth highlights something that seems to be frequently overlooked.

Implementing your design with a 65C816 is not much more challenging than with a 65C02, and gives you far more flexibility. Even if you never intend to go beyond 64KB, the '816 makes for faster and more succinct code, thanks to 16 bit operations and the very useful stack pointer relative instructions. You don't have to use all that, of course, as the '816 powers up or resets into 65C02 emulation mode. However, using the '816 in native mode opens the door to a much richer programming environment.

As you progress with your design and decide to add more than 64KB of RAM, you'll find that addressing beyond 64KB with the 65C816 is much more efficient than any banking scheme you might develop for the 65C02. Contributing to the efficiency is the fact that indexed instructions (which can use 8 or 16 bit index values) can span banks and treat RAM as contiguous, rather than segmented. You aren't going to be able to achieve that with the 65C02, no matter how clever the design.

So think this through before you start loading up your circuit with a lot of glue logic. Also, consider this: prior to construction of my '816-powered POC unit, I had absolutely no experience scratch-designing and building a computer. Despite that, POC was functional on the first try once I patched a missing connection. There's nothing scary about the '816. If I can do it, I know you can.

I hope to someday get to play around with sliding timings one way and another, using digital variable delay lines, to see how fast I can get it to go. That's kind of for the sport of it though. If I can get another 10-20% speed, I don't consider that to be very substancial. The idea is that although it might be robbing Peter to pay Paul, it could be that Paul peters out at a lower frequency and the whole thing could be sped up a bit if some of Peter's time were given to Paul. My 36µs number came from 1/14MHz=71.43ns, which, when I cut it in half, rounds to 36µs as the nearest µs. A few degrees' temperature change will probably make more difference than that though (hotter being slower). Whatever you end up with, test it with a variable-frequency oscillator if you can, and slowly increase the frequency until it starts having problems, then back it down to get a safety margin. I have one VFO circuit at viewtopic.php?t=1576, and another one that's not as fast, at viewtopic.php?f=1&t=2013&p=17478#p17478 which is the one I used to test my workbench computer which, with 4MHz parts, started having problems at a hair over 7MHz, so I run it at 5MHz (with a 10MHz oscillator can and a flip-flop to divide it down). There are things I could do now to improve it a bit, but I don't think I'll bother. I'll just apply the added knowledge to the next computer I make.

A calculator? That's neat! Are you on the MoHPC forum? There are people there working on new calculator firmware. I think the original HP-41c's firmware took 12K but there are individual modules that add that much by themselves. What I've seen of canned library routines is pretty inefficient though, partly from trying to cover all kinds of possibilities that may not even apply to a particular user.

I don't think you realize that by "wasting address space", you are actually not wasting anything at all. However if you make a too complicated address space with many uneven zones which are complicated to decode, you're actually going to waste hardware for this extra unnecessary decoding.

I think I understand how it works. So for an 8MHz chip I would have a 62ns phase and lose 30ns of that to tADS meaning total propagation delay would have to be under 32ns?

Could an average CPLD come near to 6ns for address decoding? I have been looking around out of curiosity and it seems 10ns is the maximum delay for a lot of chips.

Thanks for explaining everything and being patient. You guys have been really helpful.
I don't follow that forum but I did eventually get an HP-48GX back when I was collecting calculators. I also tracked down a 4MB SRAM expansion card for it too. I sold them in college though after I figured out that I didn't want to be an engineer. I like the HP-41 series but I added a soviet MK-61 to my collection instead. I don't collect calculators any more but I did get into electronics about two years ago to build them for myself. Here is a forum post about the one I am working on:
http://forum.43oh.com/topic/5003-rpn-sc ... alculator/
Here is the case for it I finished last week. Still needs some work though:
http://joldosh.blogspot.com/2014/05/rpn ... -case.html

That's basically it. You can see from that number why 74HC logic would have a problem at elevated clock rates. That's why I recommend the use of 74AC logic, especially for relative slow devices such as the 74xx138 decoder. The fastest discrete logic that may be purchased from stock is 74ABT, with single digit prop times in may cases.
A 10ns CPLD, such as an Atmel 1504AS, will readily support the fastest 65C02 or 65C816 you can build. Keep in mind that the 10ns rating is pin-to-pin, that is, total prop time through the CPLD. That's almost as fast a single piece of 74AC silicon, and you'd need more than one of the latter to achieve what can be done with programmable logic.

You could also consider using a GAL for a first-effort system. Such a system doesn't need (shouldn't need!) the logic complexity possible with a CPLD. Standard GALs operating at 10ns are readily available.

That's 32ns to when phase 2 rises. But remember the 65-family I/O ICs need their register-select, chip-select, and R/W inputs valid a certain amount of time before that. Logic ICs you might use for unintelligent I/O might get away with timing that's quite a bit less stringent.

The calculator project is sure impressive. I suppose the number of digits and the fact that it's variable partly explains the amount of code required.