Hi guys

I've recently been looking at memory maps and decoding and am pursuing several different avenues for my future designs.
In the meantime, I've also been looking at adding additional devices to Garth's set up found here (which I'm currently using): http://www.wilsonminesco.com/6502primer/potpourri.html

The following should hopefully allow for a VIA at $6000 and one at $6010


My experience with dealing with decoding is very limited so I'm hoping the above way is both correct (it works) and efficient (it's fast)

It may be easier to accomplish this with a single 74AC138 3-8 decoder (data sheet attached). You'd rig it up so it is selected when the address range is what you want and then use A0-A2 to select one VIA or the other (or other I/O devices—eight maximum). My only question here is your choice of addresses. $6000 is generally RAM on most systems. "Traditional' 6502 practice is to place I/O hardware in the $D000 block so as to maximum the amount of contiguous RAM. For example, this is how I did it in POC V1.0, before I added SCSI to it:

Perhaps you can post a memory map and we can then discuss it some more.

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

The memory map currently:

$0000 to $3FFF - RAM
$4000 to $7FFF - I/O space
$8000 to $FFFF - ROM

I currently have one VIA at $6000 and am hoping to end up with one every 16 bytes. So something like this:
$6000 VIA#1
$6010 VIA#2
$6020 VIA#3

If I manage this then I should be able to reduce the amount of I/O space, move the VIA's and give the freed space back to RAM

So a memory map like this:
$0000 to $6FFF - RAM
$7000 to $7FFF - I/O space
$8000 to $FFFF - ROM


With regarding to 74AC138's I have got some of these and was thinking about using two by using one to divide the memory map into 8K segments then using another to divide the I/O segment down into 8ths again (which sounds like what you're suggesting). However, the speed had me concerned, although that might not be such an issue as the AC version seems to run at 20ns (if I read the datasheet correctly).
With regard to where the I/O space is in the map: I wanted to keep 32KB for ROM/OS until I find out how large the firmware/BIOS/OS will end up.

Your diagram does not appear to provide for disabling RAM when I/O is being accessed.

That would require more logic levels than if you run address lines directly to one of the CS inputs of each I/O IC. More logic levels incurs more gate delays (reducing the maximum clock speed the system will work at), and might require more parts too. If you work out a good scheme to have I/O in the $6000-7FFF range, you could have I/O ICs at $6010 (not $6000), 6020, 6040, 6080, 60100, 6200, 6400, 6800, and 7000 with no additional logic. Putting them at $6000, 6010, 6020, 6030, 6040, 6050, etc. requires more logic.

For me it was important to have lots of ROM, for the functions I use all the time, so I don't have to keep re-loading those. My 32K ROM is about 75% full. It would have been ok for the memory map to have I/O take a small chunk out of the bottom of the ROM area, like $8000-8800, but not much above that.

_________________
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?

I've got /OE of the RAM hooked up to A14. This should prevent the RAM outputting when addresses $4000 to $6000 are being accessed.
With regard to 6010, 6020, etc. I see what you mean and it would be faster that way.

You might consider using something like Daryl's Memory Decoder (GAL) IC... It even includes PHI2 qualified /RD and /WR lines so it's pretty much a single chip solution...

Regards, Mike

But you want to get more than 16K of useful RAM, right?


I had forgotten about that one. I give it a "Like".

_________________
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?

I think I may have mentioned the CLC modules in some Microchip PIC devices in one of your other threads. Here are a couple decoder configurations;

The 16F1704 is a fourteen pin device ($1.28 single quantity @Mouser). A small PIC program runs at power-up to configure the CLC modules but after that you could actually put the microcontroller to sleep (the CLC modules run independently from the microcontroller). The CLC modules are using seven of the fourteen pins. Two additional pins are used for power. Of the five remaining pins, you might use one for a reset switch input, one for a conditioned reset signal output, two for a crystal, and the last pin for a CPU clock (1, 2, or 4-MHz).

Food for thought... Regards, Mike

Here's a good one... Please check out the decoder logic for Daryl's SBC2.5 project using a 74LS00 and a 74LS30 to map I/O into the $7F page and to provide PHI2 qualified /RD and /WR signals for RAM and EEPROM... It's a work of art!

The above would make more sense, as you can decode your I/O a page at a time and reduce the number of gates needed to generate chip selects.


The 74AC138 has a worst-case prop time to a chip select output of 11ns running on 5 volts. I use the '138 in POC V1.1, and it (the '138) has no trouble staying with a 12.5 MHz clock.


32KB is a bunch of space. POC's entire firmware is stuffed into 8KB ($E000-$FFFF), and not only includes the BIOS and device drivers, it has a full-tilt machine code monitor and a primitive console display driver. Unless you are going for a UNIX-like kernel, I don't foresee you using up even half of that ROM.

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

Mine at over 23K includes a Forth language that has a lot of features you won't find on other 6502 Forths, plus the assembler. Just an OS may not take nearly that much.

_________________
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?

I wonder why we bother with EPROM/EEPROM in our contemporary designs? RAM generally runs faster than ROM and address decoding is a whole lot easier when you only need a single chip select for I/O and a single chip select for RAM (or a single chip select that can control both RAM and I/O). Since it's relatively easy to use a skinny 14, 20, or 28 pin PIC or AVR as a "blind loader" to fill RAM with a pseudo ROM image at power-up or after a reset, you can get essentially the same functionality as ROM while reducing PCB real-estate requirements. What are the advantages for including an EPROM/EEPROM in a design?

2 cents... Mike

Yes, a very nice, simple and effective decode for an I/O page. I would hesitate to call it a "work of art" but would consider it a classic and elegant reference for the 6502. I used the same 3 chips (in HCT versions) for a 65C02 SBC setup back in the 80's... and I'm still using it now. I put the I/O page at $FE00 and use the 74HCT138 decode for 8- I/O selects where each is 32 bytes wide. I do consider Daryl's projects as excellent examples of building up 65xx systems however, and a great resource for anyone starting out... and also must call out Garth's site as well.

_________________
Regards, KM
https://github.com/floobydust

Cool. I was being cautious regarding the ROM space, so I might well dial that back and move the I/O space forward into that region.
In the meantime I have some GALs (22V10B's) on order and will need to save a few pennies for the programmer. I was thinking of a G540.
I'll also have a think on the CLC modules.

Cost, simplicity and not having to write code for yet another device. If using a PIC or AVR instead of a ROM were an advantage, your average PC's BIOS would not be in a flash ROM.

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