Having decided that I was going to use an Atmel ATF22LV10C PLD to manage the address decoding for this project, I purchased a couple of these IC’s to try out. I was visited by Murphy’s Law. I found out that the new programmer wouldn’t program these ICs (although it listed these as supported ICs). After searching some forums, I found that I wasn’t the only person having a problem programming these ICs on this model of programmer. It turned out that the problem was down to the flash memory in the Atmel PLD. It required some special timing to program the ICs, which this programmer did not support.

So, my second attempt into this problem was to purchase some National GAL22V10 ICs (which my programmer said it also supported), but did I believe them? After testing them on my programmer and finding that they also didn’t work, I was getting very frustrated (serves me right for buying a cheap Chinese one). I really didn’t  want to purchase a new programmer at that point, considering that it did work for other ICs.

Just to prove to myself that I was not losing it and that my grey matter was not shutting down, I tried some Lattice and National GAL16V8 ICs that I had in stock, and these programmed with no issue. I needed to rethink the address decoding, as I could use the  working parts that I had to hand.

I was not happy to add two additional ICs into the project where I wanted to use one. Could I remove another IC to keep the chip count the same as before? After looking at the schematic it was simple to see that the /RE & /WE signal lines could be incorporated into one of the GALs.

If the first GAL contained the logic for these decoder lines (/RE & /WE) as well as the address decoding for the memory map, the second GAL could be used for the address decoding of the I/O.

This all seemed like a good plan, but NO, there was one sneaky problem that had now crept back in. The current consumption then increased dramatically in the system. Before we even measured this, I estimated that these GALs would burn about 40-80mA each (80 – 160mA in total). This blew the power budget that I wanted as a limit for the system.

As low power consumption was a key prerequisite for this project and as I then could not use the PLDs, I had to look back to using basic logic devices for managing the address decoding. It looked as if we would have to use some 74HC138s and 74HC139s. In the end the chip count increased.

That was a month’s work and planning that I wasn’t getting back.

Now to refocus my attention to the address decoding, using standard logic ICs. 

All the memory devices require an active low control line and A15 will be high when the CPU is reset/starts. We can just use an inverter to get an active low signal from the A15 line which is high when the CPU starts. This is done by feeding A15 into a NAND gate 74HC00 (U4A), in an inverter configuration.

This active low A15 signal with A14 and A13, feed into a two to four line decoder 74HC139 (U5A), which allows us to cut the upper 32K memory space into 4 x 8K pages. Three of these pages can be used for our ROM memory which stores our software. The last 8K page can be used for future expansion, video memory and I/O.

This I/O control line can be fead into another NAND gate 74HC00 (U4B), with address line A9. This gives us a memory space of 512 bytes – it make better use of the memory space. We can feed this control line with A8 and A7 through A5, into a three to eight line decoder – 74HC138 (U10). This gives us 8 x 32 byte address blocks, which can be used for I/O devices such as RTC, UARTS, PIAs.

As we can see there are some unused memory spaces in the revised memory map. These can be used by other interfaces in the future.