I currently use attached glue for my setup with an EEPROM, SRAM and two VIAs. It shows the 5 signals that decide when to enable which parts. Each of the "targets" use two pins to enable it (OEB/CSB for EEPROM and SRAM, CS1/CS2B for the VIAs). This setup partitions the address space like so:
The glue is implemented using a 7400 and a 7414. To make it more flexible, I am replacing it with an ATF22V10C. Two questions:
Is there a reason to "split up" the glue logic like in the picture? For instance, for the SRAM, OEB is A14, and CSB is combining PHI2 and A15 - can I simply tie OEB to ground and put all glue logic on CSB? When using the 22V10, I can then reduce the total number of output pins to 4 instead of 8.
Currently, the EEPROM and SRAM are disabled when PHI2 is low (as per an advice in a previous thread). Would it make sense to also disable VIA1 and VIA2 when PHI2 is low?
As always, thanks for your insights, much appreciated!
Your memory map is almost the same as what's in the 6502 Primer's address-decoding page, about halfway down the page, which is simpler and faster and allows for further expansion. See also the whole-computer schematic at the top of the Primer's "circuit potpourri" page, at http://wilsonminesco.com/6502primer/pot ... ml#BAS_CPU, and the notes following it. On the subject of the '138: Note that 138's are generally quite slow, unless you go with something like the CY74FCT138CT which is only 5ns.
I definitely recommend going through the entire 6502 Primer. It was written many years ago to address problems and questions that kept coming up on the forum, and still gets frequent updates, to handle new things that come up.
I currently use attached glue for my setup with an EEPROM, SRAM and two VIAs...When using the 22V10, I can then reduce the total number of output pins to 4 instead of 8.
The 22V10 has 10 pins that may be used as outputs, so I’m not sure why you are worried about it. At some point, you may want to add a UART and/or something that controls mass storage, so I suggest you keep two of those output-capable pins as spares. You can also generate qualified /OE and /WE outputs with the 22V10 to control your RAM, ROM and non-65xx I/O hardware. That uses eight of the possible 10 outputs—the remaining two could be defined as inputs if you need more decoding granularity.
As for your memory map and decoding scheme, it is terribly inefficient. Why did you constrict the amount of RAM that is available? RAM is like money in today’s economy: there is never enough. Also, 4K for a single chip decode? That’s extremely wasteful. Ditto for the 32K you have allocated to ROM. 12K to 16K is more than enough for ROM.
If you are going to use a 22V10, you can make your decoding a lot more granular and drastically increase the amount of available contiguous RAM. It’s even possible using only discrete logic:
65C02 Glue Logic
One thing I recommend you not do is qualify any chip selects with Ø2. All that does is narrow the timing window that is available to select a device. Only use Ø2 to qualify the read/write logic, which is illustrated in the above schematic. In a 6502/65C02 circuit, it is primarily the write that must be qualified by the clock—read cycle contention is almost never a problem (not the case with the 65C816).
Most importantly, DO NOT use Ø2 to qualify the chip selection of any 65xx peripheral, such as the 65C22. Those devices “understand” the 6502 bus cycle and will not function if chip select and read/write aren’t valid before Ø2 goes high.
GARTHWILSON wrote:
On the subject of the '138: Note that 138's are generally quite slow, unless you go with something like the CY74FCT138CT which is only 5ns.
The 74AC and 74AHC renditions of the ’138 perform at about the same level as the 74FCT version. It is the 74HC rendition that is somewhat slow. I’ve used the 74AC138 in my POC units—versions since V1.2 are able to run at 16 MHz or better.
Jeez - dunno why I was rambling about PHI2 in the glue for a VIA, sorry 'bout that.
I should have explained - I enjoy poking at things, see if I can get my brain farts transformed into something kinda working. For instance, I know that you can get a PS/2 keyboard working just fine with a "standard" 65-series setup, but I decided to use a PIC18F-series IC to handle the keyboard and to present the ASCII key presses to a VIA using an interrupt. Same with display output - used the same PIC to control one of those tiny TFTs in SPI mode for a 80x40 text display (all this made me ingest most of the 1,000+ pages data sheet on that PIC).
So I do appreciate the suggestions for simpler glue setups, but in my weird way I wanted to explore what a 22V10 could do, and a very simple application would be to program it for glue (note that my setup will run at 1Mhz, and the ATF22V10C-7 data sheet gives a max "input to combinatorial output" of 7.5 ns). And that IC brought me to that first question - can I have the 22V10 do all the glue logic to just one of the pins on the SRAM/EEPROM/VIA and simply tie the other pin to ground (or 5V for an active-high pin)?
I guess my confusion stems from this: is there a reason why these ICs use two pins to decide they are active? Is it just for convenient's sake (so some glue setups are easier) or is there something I am overlooking? Something functionally different between OEB and CSB on the SRAM for instance?
Many memory devices work as follows:
CE = chip enable = wake up (if this is inactive, OE & WE don't matter)
OE = output enable = turn on data bus drivers (often faster delay than CE)
WE = write enable = remember what is on the data bus (often faster delay than CE)
It is often faster to activate CE as soon as an address is reasonably stable to give the device time to select a byte.
Then activate OE or WE when everything is stable.
For more detail check the device data sheet, particularly the timing diagrams.
On the subject of the '138: Note that 138's are generally quite slow, unless you go with something like the CY74FCT138CT which is only 5ns.
The 74AC and 74AHC renditions of the ’138 perform at about the same level as the 74FCT version. It is the 74HC rendition that is somewhat slow. I’ve used the 74AC138 in my POC units—versions since V1.2 are able to run at 16 MHz or better. According to my NSC data book, the 74AC138's delays are in the range of 9-13ns, depending on which inputs you're measuring from. From a TI datasheet, it looks like the AHC is just a hair faster. With the CY74FCT138CT I mentioned, I should have also mentioned the importance of the CT at the end, which makes it twice as fast as the 74AC138, at 5ns max (not typ).
I guess my confusion stems from this: is there a reason why these ICs use two pins to decide they are active?
Yes.
The reason for the presence of separate /CS (aka /CE), /OE and /WE control inputs on RAM, ROM and other non-65xx devices is they are designed to be adaptable to the buses used by many different MPU types. The 65xx family uses a synchronous bus, which works very differently than that of, say, an Intel x86 MPU. Hence when you use, for example, a 16550 UART or a 28C256 EEPROM with a 65C02, you are adapting an asynchronous device to a synchronous bus. That involves manipulating /CS , /OE and /WE so the device correctly interacts with the 65C02.
Quote:
Is it just for convenient's sake (so some glue setups are easier) or is there something I am overlooking? Something functionally different between OEB and CSB on the SRAM for instance?
Let’s clarify what the control signals /CS, /OE and /WE do and perhaps that will answer your questions.
Asserting (grounding) /CS tells the device to “wake up,” read the bit pattern on its address inputs and prepare for access at the cell or register that corresponds to the address. Unless /CS has been asserted, the device will not respond to /OE or /WE.
All 65xx MPUs set up the address bus during Ø2 low—the 65C816 even tells you when this happens. Typically, /CS is controlled by the address-decoding logic and for best performance, should not be qualified by Ø2. Keeping /CS continuously asserted forces the device to stay in the “awakened” mode at all times. Not only does this increase the idling current draw of the system, it creates the possibility of bus contention and/or data corruption if the read/write logic is not carefully designed.
Asserting /OE when /CS has been asserted will cause the device to enter the read-enable state and drive the data bus with whatever is in the cell or register that is being addressed. /OE in a 65C02 system may be controlled by an inverter connected to the MPU’s RWB output. In a 65C816 system, /OE must not be asserted during Ø2 low unless a bus transceiver is used to isolate the system data bus from the MPU while the clock is low.
Asserting /WE when /CS has been asserted will cause the device to enter the write-enable mode and copy whatever is on the data bus into the cell or register that is being addressed. /WE must be qualified by Ø2 so it (/WE) is not asserted when the clock is low. Doing so protects all asynchronous devices from a wild write during the time when the MPU is in the process of stabilizing the address bus.
In some devices, simultaneously asserting /CS , /OE and /WE is acceptable, if not optimum for performance—the device will be in the write-enable state, the same as if only /CS and /WE are asserted. In other cases, such a combination may cause undefined behavior or possible device damage. My designs never assert /OE and /WE at the same time.
The 65C02 decoding example I post earlier shows how this all works. It’s by no means the only way to go about it, but the circuit’s timing characteristics will allow it to perform at 25+ MHz with 74AC or 74AHC logic.
I will add that there is no harm in experimenting—you can learn a lot that way, even when it accidentally lets out the magic smoke (been there, done that). Just know that if you substantially deviate from proven circuit design techniques, you may be frustrated by random crashes and/or data corruption, and may expend considerable time in debugging your design.
I guess my confusion stems from this: is there a reason why these ICs use two pins to decide they are active? Is it just for convenient's sake (so some glue setups are easier) or is there something I am overlooking? Something functionally different between OEB and CSB on the SRAM for instance?
In the case of the 6522 the pins are CS1 and CS2#, note however in the 6522's case (as is the case for many non RAM/ROM type devices, see the wonderful notes above from others about RAM/ROM), there is no requirement that both of these pins be connected to complicated decode logic. The device is perfectly happy to have one of the pins wired directly to VCC or GND and let the other remaining pin be the one that is used for decoding.
For example, most often the chip enable outputs are active low inputs, so I usually wire my 6522's CS1 pin directly to VCC, and then hook the CS2# up to my decoding logic.
Let’s clarify what the control signals /CS, /OE and /WE do and perhaps that will answer your questions.
Thank you, this info is exactly what I was missing!
BigDumbDinosaur wrote:
I will add that there is no harm in experimenting—you can learn a lot that way, even when it accidentally lets out the magic smoke (been there, done that). Just know that if you substantially deviate from proven circuit design techniques, you may be frustrated by random crashes and/or data corruption, and may expend considerable time in debugging your design.
Yes, this is how I like to approach my new hobby. I am sure I can get it all working by simply copying what others do, but that often doesn't let me understand the ins and outs. An example of this is when I was working on getting a PIC18F IC to drive an ILI9341 TFT using the SPI interface of the PIC. Getting the SPI to behave was a challenge (lots of 'scope poking, re-re-reading the data sheet), and trying to understand the TFT init sequence was almost impossible. The data sheets are hardly any help, searching around got me lots of "easy, just use this library" (how helpful). I had to disect one of those libs to learn that the ILI people told the lib makers to "just use these commands, it will initialize properly" without any explanation. It seems nobody knows why these commands work. But that display now works on the PIC as a 80x40 text screen, now I can work on setting up my 65c02 to use a termcap-style interface to get it functional.
Thanks all for indulging my basic questions! It all makes way more sense now.
Yes, this is how I like to approach my new hobby. I am sure I can get it all working by simply copying what others do, but that often doesn't let me understand the ins and outs. An example of this is when I was working on getting a PIC18F IC to drive an ILI9341 TFT using the SPI interface of the PIC. Getting the SPI to behave was a challenge (lots of 'scope poking, re-re-reading the data sheet), and trying to understand the TFT init sequence was almost impossible. The data sheets are hardly any help, searching around got me lots of "easy, just use this library" (how helpful). I had to disect one of those libs to learn that the ILI people told the lib makers to "just use these commands, it will initialize properly" without any explanation. It seems nobody knows why these commands work. But that display now works on the PIC as a 80x40 text screen, now I can work on setting up my 65c02 to use a termcap-style interface to get it functional.
Betting all those "helpful" libraries were all for Arduino or similar devices....
The ILI9341 has an 8-bit interface, and can be placed on the 6502 bus. However, if you are using the module prebuilt by Adafruit, you'll find their built in 74LVC245s are hardwired to be enabled all the time. This causes contention on the data bus as it never goes into a high-Z state. To get around this problem, you can add an additional 74xx245 that you can then control the OE# pin of.
Betting all those "helpful" libraries were all for Arduino or similar devices....
Yup, the vast majority were Arduino. I found the reference to the ILI devs comments somewhere in either the libs for an STM32 or on their forum.
Yuri wrote:
The ILI9341 has an 8-bit interface, and can be placed on the 6502 bus. However, if you are using the module prebuilt by Adafruit, you'll find their built in 74LVC245s are hardwired to be enabled all the time. This causes contention on the data bus as it never goes into a high-Z state. To get around this problem, you can add an additional 74xx245 that you can then control the OE# pin of.
I did look into the 8-bit interface, but my thoughts were to use this display and the PS/2 keyboard to work as a "serial terminal replacement" (I foolishly gave away my two HP 700/96 terminals years ago), so all input/output processing would be offloaded to the PIC.
The ILI9341 has an 8-bit interface, and can be placed on the 6502 bus...To get around this problem, you can add an additional 74xx245 that you can then control the OE# pin of.
I did look into the 8-bit interface, but my thoughts were to use this display and the PS/2 keyboard to work as a "serial terminal replacement" (I foolishly gave away my two HP 700/96 terminals years ago), so all input/output processing would be offloaded to the PIC.
Sorry to barge into this thread, but I have a few (dumb) questions:
How does a 6502/65x02 µp reacts if /CS goes active low when /OE or /WE (or both) already low ?
Will it cause some kind of glitching or other distortion ?
Can I expect any problems from RAM/ROM memory or peripherals, or any other odd behaviour ?
Gr tings, Louis
May your wires be long and your nerves be strong !
The 6502 won't care what order things happen in at the memory. If the 6502 is running a read cycle, it will expect data to be available at the rising edge of the ph2 clock; if it's a write cycle, then the 6502 will put data to be stored. It won't care if the timing constraints on the memory mean that it can't work; for that you need to refer to the datasheet for the particular memory part.
Of course, if the memory timing isn't right, then you may write something or nothing; probably not good for your program data.
Neil
EDIT: FALLING EDGE, not rising. D'oh.
Last edited by barnacle on Thu Oct 09, 2025 6:41 pm, edited 1 time in total.
Also, 4K for a single chip decode? That’s extremely wasteful. Ditto for the 32K you have allocated to ROM. 12K to 16K is more than enough for ROM.
Just know that if you substantially deviate from proven circuit design techniques, you may be frustrated by random crashes and/or data corruption, and may expend considerable time in debugging your design.