Memory-mapping logic - a thought

[commodorejohn]

Alright, I'm kinda at the point right now where I want to get rolling on getting this up and running and I'm willing to cut back on some of the flexibility that I'm normally inclined to want. So, rolling back to simpler requirements, I'm going to just shoot for a fixed 8KB ROM area that can be switched out for RAM, plus the ability to write to RAM when ROM is banked in. Nice and simple. My thoughts on this:

The upper-memory select is active-high, in order to fit into the ROM select better. It's obtained with a 3-input NAND gate connected to A13-A15 NORed with /MREQ. We'll call it UMEM.

ROM banking is controlled with a ROM-enable line, presumably driven from one of the I/O lines on the VIA board, and pulled high by default. We'll call this /BNK.

Finally, the last component of the ROM select is the /WR line, which is already on the bus. The ROM select is obtained with a 3-input NAND gate connected to UMEM, /WR, and /BNK, so that ROM is selected only during a read access to upper memory with ROM enabled. The ROM select is also an input to the upper RAM select logic, which we'll call /ROM.

The upper RAM select is obtained with a 3-input NAND gate connected to A15, /ROM, and /IORQ, so that upper RAM is selected only during an access to the high 32KB of memory and ROM is not selected.

Finally, the lower RAM select is obtained by NORing A15 and /MREQ and inverting the result (with another NOR gate,) so that lower RAM is selected during any non-I/O access to the lower 32KB of memory.

The way I figure it, this can all be accomplished with one 7410 triple 3-input NAND and one 7402 quad 2-input NOR, with one NOR gate left over for...whatever. Does this all look correct? Did I overcomplicate anything? Is there anything I missed?

[Dr Jefyll]

commodorejohn wrote:

Is there anything I missed?

A schematic would be helpful -- certainly for us, and perhaps for yourself, too.

[BigDumbDinosaur]

Dr Jefyll wrote:

commodorejohn wrote:

Is there anything I missed?

A schematic would be helpful -- certainly for us, and perhaps for yourself, too.

I concur with Jeff. It's hard for me to visualize what you are attempting to accomplish with only a prose description for reference. A memory map with schematic would be a big help.

[whartung]

commodorejohn wrote:

plus the ability to write to RAM when ROM is banked in.

So the premise here is to be able to write to the RAM blind? (Since you can't read it?)

[commodorejohn]

Yeah, I suppose I should try and draw up a schematic - I just have precious little familiarity with them so I tend not to think in those terms.

whartung wrote:

commodorejohn wrote:

plus the ability to write to RAM when ROM is banked in.

So the premise here is to be able to write to the RAM blind? (Since you can't read it?)

Yes - I'm aiming to do it like the Commodore 64, where you can write to the RAM "underneath" ROM at the same address, so you can get interrupt vectors set up and/or copy over whatever bits of ROM you need before banking the ROM out.

[GARTHWILSON]

commodorejohn wrote:

Yeah, I suppose I should try and draw up a schematic - I just have precious little familiarity with them so I tend not to think in those terms.

It's not necessary to do a full schematic, especially not all on one drawing. To make things easier, just do the particulars like address decoding. Things like data lines, address lines to the memories and processor, the power & ground, and probably other things too can be assumed without drawing them out. In my 6502 primer, you'll find lots of little schematics that stand on their own to represent individual small portions of a computer. I didn't do a full schematic until after several newbies insisted, the I did the one at http://wilsonminesco.com/6502primer/pot ... ml#BAS_CPU . I don't do this for my own use though. All the hardware info on my workbench computers is in a tiny ring binder as shown at viewtopic.php?p=2337#p2337 .

[commodorejohn]

Oh, right. The address decoding logic (plus I guess the pull-up resistors) is really the only thing I'm concerned with anyway since all the rest of the computer is on bluesky's RC2014 boards. I've just literally never done a schematic at all before - but hey, there's a first time for everything.

[commodorejohn]

Please excuse the laughable MS Paint crudity, I could not for the life of me find a free online schematic editor that both worked and didn't try to extort a subscription out of me after ten minutes:

[Alarm Siren]

commodorejohn wrote:

I could not for the life of me find a free online schematic editor that both worked and didn't try to extort a subscription out of me after ten minutes:

For that sort of logic diagram, you could use Logisim. Its GPL, multi-platform (Java) and you can very easily draw out logic diagrams. As a bonus, it can also interactively simulate them. I've used it many times in my adventures in computer design, all the way from testing memory decoding logic to designing entire processor architectures.

For actual circuit (and PCB) schematics, see KiCad. Also GPL and multi-platform.

However, given that you did it in MS Paint I have to say I'm actually quite impressed

[commodorejohn]

Yeah, I tried it in LogiSim but I didn't think to take a screenshot. The simulation definitely seemed to provide the results I wanted, but I'm definitely interested in hearing the input of the folks here with more actual hardware-design experience.

[GARTHWILSON]

Even reviewing the entire topic, I was not able to determine what /MREQ is, except that it's part of the RC2014. So I did a web search for RC2014, and found it's some sort of small backplane-oriented Z80 computer, one which looks rather attractive for modularity for hobbyists who aren't looking for much speed. How do you plan to feed /MREQ? I also don't recognize /BNK. I assume all memory-map accesses that are not for memory are for I/O. The 6502 does not differentiate between memory and I/O though. You can even use the indexed and indirect addressing modes on I/O.

Regarding the schematic CAD: You might find Wikipedia's EDA software page helpful. I got very proficient at OrCAD at my last place of work (1985-1992) but there are things about every schematic CAD that I don't like, so I still do my schematics by hand and then scan them if needed, as you see on my website, with this one being the biggest one I've posted there. The most complex ones I've done have hundreds of components, drawn small on 18x24 velum. Kinko's and other such office or drafting supply places can photocopy up to to 60" width, and much greater lengths.

[commodorejohn]

Yeah, I suppose I should've explained that more clearly. As you note, some of this is quirks of the RC2014, and bluesky's 65C02 board for it. The full explanation is here, but in brief: /MREQ indicates that a bus access is a memory request as opposed to an I/O request, which is indicated with the /IORQ line. Since the 6502 doesn't make this distinction, bluesky's board simply reserves one page of the address space for I/O, and assumes that any other bus access is to memory - so on his 65C02 board, /MREQ is literally just the inverse of /IORQ, which is the output of an 8-bit comparator checking A8-A15 against a constant value.

/BNK I alluded to in my initial description - it's a bank switch for the ROM, which I plan to connect to one of the I/O port pins on the 65C22 board (plus a pull-up resistor to ensure that it's valid on reset.) When it's high, ROM should be enabled.

[GARTHWILSON]

If I understand what you want to do, it looks right as far as logic goes. Make sure your gate delays will be ok though. RAMB\ has four gate delays, maybe more counting the MIRQ\.

[commodorejohn]

Yeah, the delay times are one of the things I wasn't too sure of as I'm much less familiar with the quirks of real-world hardware than I am with basic binary logic - if I'm reading the datasheets correctly for the 74HCTxx parts in question, the maximum propagation time should be ~50ns plus whatever the propagation time on the 65C02 board is, plus the RAM/ROM access time, but I still need to go over everything and work out the worst-cases.

I can't remember exactly how clock timing/access delays work on the 6502 - does a worst-case access time of, say, 100ns correspond to a stable clock speed of ~10 MHz, or is it generally less than that?

[GARTHWILSON]

From my 6502 primer, specifically the page on address decoding, about 30% of the way down the page:

• Note that 100ns memory is not fast enough for 10MHz on a 6502! It's only a slight oversimplification to say that the 6502 basically does a memory access in half a cycle, meaning 50ns @ 10MHz, 500ns @ 1MHz, etc., and some of that time will be taken up by glue logic, set-up times, etc., leaving less than you might think for the memory itself. In fact, the Apple II did two memory accesses per cycle, two million per second at 1MHz, with the video accessing the memory during the first half of Φ2, and the processor during the second half, interleaving, so both could access the same memory at the same time at full speed, with no conflicts. Anyway, speed is not just the inverse of the access time.
  
  To expand on the scenario above, consider 100ns memory (let's say it's ROM, so we can leave Φ2 out of it) and a 10MHz 6502. One period at 10MHz is 100ns; but from there you have to subtract the specified address setup time (tADS, 30ns for a 14MHz 6502) and the read data setup time (tDSR, 10ns for a 14MHz 6502) and probably some address-decoding logic time, let's say 10ns but it will depend on your circuit and how fast your logic is, leaving you with about 50ns for the ROM at 10MHz. If you're running it at 3.3V, the specs say you need to take off another 15ns, leaving you with ROM that can dish up the data in 35ns @3.3V. That's if you want to be sure the product will always work. It's nice to know that parts are usually faster than the guaranteed worst case; but for production, you can't assume they always will, because at any time the suppliers could give you slower parts that are still within spec and they won't work at your speed and it won't be any fault of theirs!
  
  Each part's data sheet will have the timing diagrams and timing specifications. Don't ignore them!
  
  There's more in the section, "74xx Logic Families and Timing Margins." I must also point out Jeff Laughton's excellent animated, drawn-to-scale (unlike most in data sheets), visualizations of timing margins, in the forum topic "Timing Diagrams. Visualizing 65xx Timing." These .gif's help understand what timings are constant and what varies with clock speed.