I've read through the various suggestions for the address decoding and thought I'd add my thoughts on it.

With the size of available memory devices, I believe one RAM and one ROM socket will be enough. This would put ALL memory on the Main PCB. This could simplify the decoding question. RAM needs to be at the bottom of the memory map & ROM needs to be at the top of memory. I suggest the following memory map.

A15 --------------- /RAMCS $0000 - $7FFF 32K

Jumper selectable 2K (6116), 8K (6264), or 32K (62256)

-------
A15 ----| \
| 7400 ()--- /ROMCS $C000 - $FFFF 16K

A14 ----| /
--------

Jumper selectable 2K (2716), 4K (2732), 8K (2764), 16K (27128)

--------
A15 ----| \
| 7400 ()--- /IOCS $8000 - $BFFF 16K
/A14 ----| /
--------

This could then go to a '138 or '154 to give 8 @ 2K or 16 @ 1K or to a '138 with one select going to another '138 giving 8 @ 256 for the Main PCB with the other 7 from the first '138 going to the BUS. I really don't believe there will be many systems that would be larger than seven Expansion PCB's. Then further decoding could be done on the Expansion PCB, if it was needed.

The following logic will givee the needed Read & Write signals for the RAM, ROM, & 16550.

--------
R/W ----| \
| 7400 ()--- /WR This would be the Write for RAM & 16550
PHI2 ----| /
--------

-------
R/W ----| \ _______
| | 7400 ()------| \
|--| / | 7400 ()--- /RD This would be the Read for
------- PHI2---| / RAM, ROM, & 16550
--------

There's nothing wrong with starting new threads, maybe it would help us organize our ideas better.

Ted, I tried to look over your decoding scheme but your diagrams ran together because the browser throws out the extra spacing. There are two solutions to this: you can write it down using boolean logic like A*B=Y (A AND B = Y) or you can switch Delphi into Advanced Mode. Once you're in advanced mode you can insert HTML tags into your messages. This will allow you to use the <PRE> and </PRE> tags to preserve your character spacing when drawing diagrams.

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

Sorry, I didn't really mean to open another thread, I just wasn't sure how this forum works.

I also didn't know it hacked out the spaces. I went back & looked at the post, and it's not what I sent.

The idea is to divide the address space into two 32K blocks with A15. The lower 32K for RAM when A15 is low. The upper 32K is divided into 2 16K blocks. A15 & A14 high into a 7400 generates a Chip Select for the ROM socket. A15 high & A14 low into a 7400 generates a Chip Select for a '138 (2K Blocks) or '154 (1K Blocks) for I/O Chip Selects, or a '138 with "Y0" going to another '138 (256 Blocks) that would provide Chip Selects for I/O on the Main PCB with the other 7 Chip Selects of the first '138 going to the Expansion Bus connector. I'm not quite sure what the deal is wanting 8K blocks with size of memory chips available. There has to RAM at Low memory & ROM at High Memory for the system to work.

$0000 - $7FFF RAM
$8000 - $BFFF I/O
$C000 - $FFFF ROM

The RAM socket should have jumpers to accomodate 2K (6116), 8K (6264), and 32K (62256) parts.

The ROM socket should have jumpers to accomodate 2K (2716), 4K (2732), 8K (2764), & 16K (27128).

I think the system should be designed to have All the memory on the Main PCB. I'm not sure why the BUS would have all the 6502 signals. I'm looking at it as an I/O Expansion.

The Read and Write signals for the memory & 16550 could be generated with 3 gates from a 7400. I've used the on several designs. I believe these signals are being called RAM R/W & OE on some other posts.

I hope this is a little clearer.

Ted

TEDM9 wrote:

>I'm not quite sure what the deal is wanting 8K blocks with >size of memory chips available. There has to RAM at Low >memory & ROM at High Memory for the system to work.

Your 2nd sentence is certainly true.
There's nothing special about 8K blocks. The real point of what I proposed is in using a LS145 to decode the 64K into 8 equal chunks, each with an *O.C. output*. With OC outputs, the eight 8K blocks can be combined in any way desired, without any additional logic. For example, RAM could be assigned to the lower 7 blocks (56K). Or maybe some folks would want ROM to be only the top 8K, while others might want it to be the top 16K. So, the same memory map that you propose can be done with a 145 and a 138 (and 3 or 4 pullup resistors). But, different maps will also work, without requiring that the lower 32K be decoded as a single block. By using plug-on jumpers, the map can reconfigured at any time by the user.

>I think the system should be designed to have All the memory >on the Main PCB. I'm not sure why the BUS would have all the >6502 signals. I'm looking at it as an I/O Expansion.

It's just for flexibility - it's hard to predict what someone might want to experiment with, and it seems a shame to have built-in limitations, if we can avoid them at 'no cost'.

>The Read and Write signals for the memory & 16550 could be >generated with 3 gates from a 7400. I've used the on several >designs. I believe these signals are being called RAM R/W & >OE on some other posts.

I do this with a single 7400 gate, plus an inverter (which is made from a 2nd 7400 gate). I copied it from the way it was done on the KIM-1 board.
What do you use the 3rd gate for?

Pete

BTW, for an example of what I've proposed with the LS145, goto www.6502.org, "Homebuilt Project", "U2PO robot", "U2PO CPU schematic".
Sorry about the poor quality of the image, and the hand-drawn schematic.
In U2PO, I hard-wired some of the decoded blocks, but others go through jumpers so that I can move them around. For example, a portion of the flash decoding, and the RAM, are jumpered so that the top 8K block can be *either* RAM or flash (the RAM is non-volatile). This lets me boot from RAM-based code, then I blast the needed stuff into flash, then next time boot from flash. That is, this CPU board can blast it's own boot code. It was very handy while debugging and such.

While there, take a look at the use of an LS148 with part of a 6522 port to give a priority-interrupt scheme. With a few lines of code, it can figure out which of 8 different inputs generated the interrupt.

Pete

I studied your decoding with the '145. I agree that it is a flexible way to decode the address bus. I had been looking at from my application ideas, and not from the idea of flexibility for experimenting. I think your way would probably be better for this board.
Ted

I sketched up something like your Interrupt Priority circuit several years back, but never implemented it. I started using Rockwell's controller chips that had it built in, so never followed up on it. I'll see if I can dig up my sketches. I think it's a good idea, but probably for an expansion board & not the Main PCB.
Ted

Yes, I agree that the priority interrupt hardware doesn't need to be on the main board.
For little options like that, I'm thinking of doing this:

Use two of our 'standard' boards, stacked PC/104 style, with the CPU and most other components on the bottom board. On the top board, add a 3rd 65C22 in one spot, then make a little daughter-board that plugs into the 2nd 6522 spot. In the 2nd PROM spot I'll put a EEPROM, so that I can execute code from one PROM, while programming the other.
Or something like that - I might change my mind tomorrow .

Pete

I wondered what you meant about stacking two "standard " boards. I'm not quite sure about how you'll address them. Cut & jumpers maybe.

I guess the first expansion boards will be for more I/O. I guess that will wait until we get the CPU board done.
Ted

As for how to address stuff on a 'stacked' board:
A bunch of notes back, we had discussed including jumper positions on the PC board for all chip selects. This would allow a second, identical board to be connected pin-for-pin, but the second board would have it's chip selects jumpered differently. It is assumed that some extra decoded address blocks would be available on the 'bus' connectors to allow this to work.
So, each stacked board would have 'all' decoded blocks and chip selects available, so that things can be moved around in the address map as needed with multiple boards.
So, no cutting of traces would be needed.

Pete

OK. I see that, now. If you leave out the 6502 on the second board, the bus would drive the decoder on the second board. I hadn't thought of that. That will make expansion easier.
Ted

Wouldn't it make sense to use one of the 65k-Byte 10-15 ns SRAMS commonly discarded along with the '486 motherboard on which it lives (cache) rather than paying ridiculous prices to the hobby electronic parts vendors for parts, e.g. 6116's which have been obsolete for 10 years? If ALL your memory map is populated in this way, you need merely tie the /select line to any specifically addressed device to a common MEMORY DISABLE signal.

Why hobble your system with designed-in flaws like an interrupted memory mask and fragmented I/O, not to mention slow (and long-obsolete) devices?

Uli