Welcome!
Druzyek wrote:
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.
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.
Quote:
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?
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.
Quote:
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?
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.
Quote:
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?
This part may need some more explaining. It's not clear, to me anyway, what you mean.
Quote:
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?
Do try to minimize the cumulative propagation delay. The fastest operation won't normally come with fine-grained address decoding.