re: .44 and .45

Yes, what I'm calling "OE" is the inversion of R/W from the CPU. The "RAM-R/W" is OE nanded with phase2. I think this is the same as what you described.
I use the name "OE" because it is useful for driving the Output Enable (OE) signal on memory devices. The RAM-R/W name is self-explanatory.

I'm not opposed to adding bus drivers, if the rest of the group agrees. For this board, I'm not personally concerned with the size of the board.

Pete

Here's a thought (though I realise that it may be getting more complicated than what this PCB is supposed to be) about really dramatically increasing the potential power of this little device:

As mentioned in my post searching for Core-Test code, my 6502 work these days is centering around the SunPlus line of "speech controllers". These devices have <<HUGE>> ammounts of ROM and very little RAM, as they are intended to be used in toys and consumer devices where the applications code is fixed and the needed variables are few -- though many designs include a serial RAM for expansion. Anyway, the on-chip ROM can run as large as 2 MEGAbytes! What all of this memory is used for is to hold huge sets of look-up tables (a GREAT way to implement floating-point or other complex math that executes at lightning speed, by the way) and more frequently, to hold digitized speech and sound effects in the form of 8-bit PCM or ADPM samples that are played by using a timer interrupt to stuff them out through a DAC to an amplifier/speaker. Talking machines are WAY COOL!

Now, how do you patch that much memory onto a 6502 with only 64K of adressing space? SunPlus does it by bank-selecting 32K segments in the $8000-$FFFF range. This poses some compiler problems since the vectors have to be copied into every one of the banks and code/data must jump around it, so I would prefer to bank-select the 16K from $8000-$BFFF and have a fixed ROM from $C000-$FFFF (is this just my Apple II+ background clouding my vision???).

All of this memory and the needed bank-select register are of course too much to put on the basic CPU board, and besides that not everybody will want this feature anyway, so it should all be on an expansion board. But to do that, we would need the ability to SUPPRESS DECODING OF THE ON-BOARD MEMORY in the bank-selected range. I would propose a /ME (active-low Memory-Enable) signal on the main CPU board that ties directly to a pin on one of the expansion headers and is pulled low by a resistor on the CPU board. If the bank-select board is installed, that board ties +VCC to the /ME pin, DISABLING decoding of the CPU board's memory. All other boards would just leave this pin open (passing it through in case an additional board on the expansion bus is the bank-select board).

This might actually be easier if the bank selected replaces the entire $0000-$7FFF block, but such details can best be hashed out through discussion.

Any thoughts?

-- Brian Farley

With the proposed memory-decoding scheme, we could use the "D" input of the LS145 for this purpose. By default, the D input is pulled low, so that A, B, and C will define the current 8K block. If D is high, then the LS145 will be decoding 'blocks' 9 and 10, which don't exist in our system.
The outputs of the LS145 are O.C., so the expansion board can pull them low at any time.

So, it's just a matter of making the D input a "soft ground" (through a resistor), and bringing that signal out to the expansion connector (probably the secondary one, not the primary one ???). Folks that don't care about this feature can replace the resistor with a wire.

I think we should do it (make "D" a soft ground).
I believe the KIM has a similar memory-disable signal - as I recall, it defaults to 'disabled', so you must tie it low to make anything work.

On the secondary expansion connector, we should definitely plan to include *all* of the decoded blocks that are not already on the primary connector; for reasons such as your bank-switching application.

Pete

Hi Mike,

You said

>>About using PAL/GAL or other programmable logic, that's out of the question. No beginner has access to these programmers and we want everyone to enjoy the board.<<

Well there is a (seemingly complete) design at http://ftp.unina.it/pub/electronics/ftp.armory.com/GAL/ called GALBlast.zip . While I havent built this it looks like the sort of project that could be constructed by anyone who is considering puting a 6502 board together.

From my own experience, I started aquiring a GALs on scrap boards a few years ago and eventually built up a fair collection so I started looking into actually using them. I tried a few compile languages and eventually settled on a demo version of WinCUPL (a student version downloaded from a university public ftp site) which is fairly easy to use and had some demo files with it.

I aquired a programmer from an office equipment auction and while DOS based and fairly limited it can handle the JDEC fuse files.

So I built a version of Grant Searle's micro UK101 ( http://www.home-micros.freeserve.co.uk/uk101/uk101.html as I'm sure you know) using a single GAL16v8 to replace all the glue logic (including the part of the clock cct) and allow a 27c256, 65256 and the 6850 to share the top 32k (one 65256 does for the lower 32k)

Once that worked (which, unusually, it did first time) I changed the map to allow 12k for the BASIC and to give me a ROM disable line (the RAM under the ROM is always writeable, the disable allows it to be read instead of the ROM). All this was done without having to pick up the soldering iron or make any circuit changes.

The next stage is to build a new board using a 6551 instead of the 6850, have provision for two 6522s, have a map disable input so that off board devices can steal their own part of the memory map and generate Z80 style read and write signals in case I want an 8255 (or such) instead of one 6522. The best bit is I've allready made, and tested, all the glue logic to do this. It's just one GAL20v8 chip, and it still has two spare input lines so I could make the smallest block 64 bytes instead of 256.

I've found that once you start using PLDs in your designs you wonder how you managed before them as they make layout (swapping input and output pins around for convenience), circuit changes (re write the equations, re blow the chip and no waiting for the soldering iron) and life generally much easier.

Enough for now, just thought I'd add my two cents worth.

Lee.