I'm gearing up to put together an RC2014 system based on bluesky6's 6502 board, but I don't care for the existing RAM/ROM boards much (most of them are oriented towards a 32KB/32KB split, which I've never cared for.) I'd like something with a little more RAM in high memory. However, I'm less an electronics engineer and more a programmer who can solder, so I'm working primarily off a basic knowledge of digital logic and would like to get some advice on my tentative game plan from people who actually know what they're doing - hence this thread.

Anyway, to start with the purely theoretical end of things, here's what I have planned from a logic standpoint. The goal is to use two 32KB SRAMs and an 8KB EEPROM plus some logic to give a large area of contiguous RAM with a modest ROM up top. (bluesky's 6502 board already takes care of diking out a page for I/O, so I don't need to worry about that; if the /MREQ line on the RC2014 bus is active, we know that it's not an I/O request.) One additional feature I'd like is for the visible ROM size to be configurable and everything below that to be RAM, so that if I want to move on from running a ROM language interpreter to, say, using a small bootloader to load software off of a CF card, I can reclaim any unneeded ROM space without having to rewire the board.

So the memory elements we'll call RAM A ($0000-7FFF,) RAM B ($8000-ROM base,) and ROM (ROM base-$FFFF.) If I've got all this right, RAM A is by far the simplest piece of the puzzle: the /CS select line can simply be /MREQ ORed with A15, no questions asked.

The top half of memory is a little more complicated. I know a lot of designs just use a 3:8 demultiplexer, but bluesky's 6502 design alerted me to the existence of the 74688 8-bit comparator, which, rather than having multiple select outputs (most of which are redundant for my purposes,) has just one output and allows a lot more flexibility on the input. The way I figure it, setting it up to check that A13-A15 are all high gives the default address range of $0000-DFFF for RAM and $E000-FFFF for ROM, and the additional compare inputs can be jumpered either to result in always-true or check additional address lines (resulting in a smaller ROM window at the top of memory, up to a single page if desired.) Finally, tying the 74688's /E enable line to /MREQ, the result is that its /P=Q output is only low during an access to the top area of memory - exactly what's needed for the ROM's /CS line.

RAM B is where I'm having some difficulty. The basic criteria are pretty simple: its /CS line should be low only when /MREQ is low, /P=Q is high, and A15 is high. The problem I'm having is figuring out a good way to do this without an unnecessarily high parts count. If /MREQ is inverted, this matches the truth table for a 3-input NAND gate, and on bluesky's 6502 board /MREQ is just the inverse of /IORQ, so that is available. Is it a safe assumption to do things this way? I'm not too bothered if it fails over in Z80-land since I have no plans to use it in that capacity.

If the 3-input NAND approach is useable, then the board can feature a 7410 with three of them, leaving two from which to create the OR gate for RAM A. Since the inverse of /MREQ is already available, one NAND gate can be used as an inverter for A15, and the other can give the result of !/MREQ !& !A15 which should be low only when /MREQ and A15 are both low - exactly what's needed for RAM A's /CS line.

Does this all look correct? Did I miss anything obvious? I think I have it pretty well worked out, but I'm no expert on the low-level hardware end of things...

I would use a single 128KB SRAM, which means only one /CS to worry about. Using two SRAMs just makes it more complicated and gives you nothing in return.

With a 128KB SRAM you just tie A16 to ground and work with A0-A15. Your glue logic selects it if the address is below your magic ROM threshold. That's what I did in my POC unit, using nothing more than two gates (RAM is $0000-$CFFF).


In your system, you want all CMOS glue logic, but unfortunately, the fastest form of the '688 is 74HC, with a tPD as slow as 30ns. Contrast that device to the 74AC138 3-8 decoder, which has a worst-case tPHL of 10ns, some 50 percent faster than 74HC688's best-case performance. The '138 was specifically designed for high speed memory decoding, as well as I/O selection. Why make it difficult for yourself?

The other consideration would be programmable logic, which usually has a fixed prop time that is not affected by logic complexity (in most cases).

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Hmm, I hadn't realized the propagation time on it was that long. I suppose programmable logic would be another option - I have no familiarity with designing for it, but then again this whole thing is going to be a learning experience to begin with.

Check out 74LVC:
http://www.ti.com/paramsearch/docs/para ... ax=5.25;36
Very fast, and most of them can use 5V power supply (not just 3.3V and 5V I/O tolerance!)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Most 74HC logic is no faster than 74LS, and a lot of 74HCT is actually slower than 74LS. What the 74HC family primarily offers to the designer is noise immunity and reduced power consumption. 74AC is substantially faster than 74HC, and can source and sink much more current.


I had no exposure to programmable logic before I designed POC V2. Once I understood the concepts and the idiosyncracies of the development environment it wasn't at all difficult. Designing POC V2 around a CPLD opened up opportunities for creating a more powerful system with more RAM and the ability to overlay ROM on top of RAM. There's even RAM underneath the I/O block.

If you can work out the logic using discrete parts you can work out the logic in a GAL or CPLD. You can also design an effective and fast machine using 74AC logic—that's what my POC V1 unit has, and it will boot at 15 MHz. What the programmable logic route gives you is the ability to develop a more elaborate memory map without having to get paranoid about prop delays.


Alas, the 74LVC138 is not suitable for 5 volt systems.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

To make it simple, use two 32KB RAM chips.

Since you are using your own memory design, you can choose to connect pins 1-2 of the A15 option header. This will give you the raw A15 with no inversion.

The lower 32KB can be enabled with A15=0. You don't need to gate it with the /MREQ signal of the RC2014 bus.

For the upper 32KB, use a 74HCT138 (or 74ACT138 if you're concerned about speed, available from Mouser) to decode A14 and A13 to give you 4 blocks of 8KB. Of course, you would qualify the '138 with A15=1. The '138 output for the highest 8KB will be used for the EPROM.

The other 3 relevant outputs of the '138 will need to be ANDed and then ORed with /MREQ to generate the chipselect for the upper SRAM. A 3-input AND gate is the 74HCT11 which is also available from Mouser as is the ACT version.

Yes, the '138 has 8 outputs but since we are decoding only for A14 and A13, we will probably just tie pin 3 to ground to get 4 usable outputs.

_________________
Blog: http://ancientcomputing.blogspot.com/
GitHub: https://github.com/ancientcomputing

Yeah, the '138 design is a pretty standard one, and if I don't go for the PLD approach I'll probably fall back on that. It just irks me somewhat to have a whole 8KB of RAM sitting there untouched underneath $E000-FFFF and it'd be nice to at least have the option to shrink the ROM window smaller than that if I feel like it.


I'm curious about this, though. Is gating with /MREQ unnecessary strictly because the I/O page is hard-wired to be in the upper half of memory? I'm thinking of putting the 74688 for the I/O select on a standoff and changing the wiring to relocate it to $0200 instead, so that might not work in that case.

Unless the system contains devices that have TTL-level inputs, ACT and HCT logic is unnecessary and actually imposes a small performance penalty.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Perhaps the '139 would be helpful. It's a dual 2-to-4 decoder, each decoder being sort of like half a '138, although it doesn't have as many gate inputs.

The 74LVC page I linked to earlier has loads of other small gates and gate pairs that might get you the functions you need and still get you in under timing budget even if it takes two or three parts, since you can get cascaded gate pairs with 3.5ns-4.5ns typ prop. delay, and even pairs of parts may land you in the 8ns range.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

That’s right. If I/O is not in the lower 32KB, then there’s no need to gate on /MREQ.



If you doing this professionally and for a net new design for which you can strictly call out the BOM, it probably pays to go through in detail the spec sheets to determine what is TTL compatible etc. However as a hobbyist using stuff from a parts bin that will include NMOS devices, TTL compatibility is the safe route. The first generation (non-WDC) 65C02 and family were all TTL compatible.

But what’s all this obsession with speed/performance anyhow?

If you want the absolute fastest, run a 6502 emulator on an Intel PC. Or for physical, use an SBC with PLCC devices and EPLD/FPGA logic. A simple bus-based design like the RC2014 will impose speed limitations e.g. bus signal integrity, signal lengths etc.



I thought of recommending the ‘139 but then you’ll need to invert A15. The ‘138 has an active high chipselect that you can use for A15 directly.

_________________
Blog: http://ancientcomputing.blogspot.com/
GitHub: https://github.com/ancientcomputing

If you are going to use an EEPROM you probably not trying to break any speed records - most EEPROMs do require about 120..150ns access time. This would roughly end up in 3 MHz cycle time. Using an EEPROM you should remember to insert a jumper or a pushbutton and pullup resistor into /WE to inhibit inadvertent writes.

You didn't say anything about I/O - your decode logic needs at least to have one deselect input (unselect RAM and ROM) to add somehow somewhere I/O space!

If you wish to change the RAM-ROM boundary (even dynamically during runtime) you could use an adder instead of a comparator. They are both similar slow (propagation delay time). Using the CARRYOUT from the adder to select ROM (and deselect RAM) you could change the takeover address as you wish.

Consider a 128K RAM and a 64K or more (Flash-)EPROM. With a four bit adder (74xx83) adding X to A15..A12 produces a carry for X >= 1. That means you could vary the amount of RAM from 4K (adding $F yielding RAM at $0000..$0FFF) minimum up to full 64K RAM (adding $0). The latter means NO ROM at all! If X comes from an I/O device (like 65C22) these lines are inputs after reset, so 4 pullup resistors are needed to start with X=$F => 4K RAM / 60K ROM. The power on setup program may change this then.

my 2 cents

I'll have to double-check, I'm pretty sure I have faster parts on hand, but I need to dig out my list from my previous laptop.


Good to know; I hadn't thought of that.


Well, that was the point behind gating everything with /MREQ - if I did my homework correctly, the /CS line on each memory element should be high when /MREQ is high, and on bluesky's board /MREQ is the inverse of /IORQ, so I would think that should do it.


Hmm, now that's an interesting idea.


I'd wondered about that, but I was saving the question for after I get the logic nailed down and move onto the electronics-engineering side of things. Am I correct in understanding that the pullups would only affect the default, un-driven value of those lines, and changing the pins on a 65C22 to outputs would override that?

If you using CMOS (not LS-TTL) you could "preset" any meaningful value with moderate high impedance resistors (say 4K7 or so). When switching the I/O register to output (say DDRA register on a 6522) they will drive the lines to whatever you previously (and dynamically later) placed in the output register (ORA).

B.T.W.: this way you could use a (faster) Flash-EPROM (like SST39Fxxx). They could be programmed in circuit - but only if you can access at least 32K. By switching in a few pages you can program that device and then reduce its appearance back to something you desire. Once only a fraction is accessible it cannot programmed or erased accidantially.

I simply calculate cycle time >= 2x access time. This is roughly correct for NMOS parts. There you have 170ns tACC @ 3MHz. As you need to add the required decoding overhead there is no much room for getting faster.

Using a CMOS CPU gives some better figures: a larger fraction of PHI2=0 already provides a valid address. So (again roughly) 3/4 of a cycle = tACC which then would cause tCYCLE = 4/3 tACC or 4/3 x 120ns = 160ns = 6 MHz. This is without decoding penalty. I guess you would end up somewhere around 5 MHz.

Ah, you know, I think I was confusing EEPROM with UV-erase EPROM, which I believe I have in 45ns form.