CMS 9619 Address Decoder Replacement

In my previous post on the MIKUL 6218 board, I mentioned that was using the lower 32K of address space on the CMS 9619 to swap in 16 banks of external RAM. You may remember that I had previously made some minor modifications on the CMS 9619 to use this space for an on-board 32K SRAM chip and still use the external I/O. What is happening here? Well, I had to remove all of my wire modifications to the CMS 9619, and restore it to the standard arrangement. With my new GAL programmer in hand, I figured out the logic equations to replicate the CMS 9619's U12 address decoder. I made an adjustment to how the U20 ROM/RAM socket and bus tranceiver are addressed so that I can have one GAL to have all 64K on-board and another for the standard external 32K. Now I can just swap out the GAL ICs to change the arrangement!

There is still a small glitch in UTIL_DECODE that I have to resolve (I think this is why CMS orginally used XOR logic PAL20L10 rather than the more common NAND logic PAL20V10), but everything seems to work great.

If you need a replacement decoder for your CMS 9619, or just want to make some modifications to the memory map, this is the way to do it!

MIKUL 1MiB Mods (continued)

With the virtual address jumper for the MIKUL 6218 sorted, I still needed to simplify the address decoding and memory chip selects so that 1 of the 4 SRAM sockets will be selected depending on the state of our virtual A19 and A20 addresses. Since the three I/O ICs (6522 VIAs) share the data bus with the memory, I also need to disable the memory when the I/O is active, and signal the GAL in U10 to select the appropriate 6522 VIA.

Fortunately, the CMS 9619 and 9639 use several signals (VMA, VUA, or UTIL_DECODE) to indicate when the processor board is addressing external memory or I/O. This greatly simplifies the decoding from the original MIKUL arrangment which had the GAL fully decoding all of the address lines from A6 through A15. But, since the MIKUL 6218 board does not use those CMS/EXORbus decode signals, I had to cut a few of the unneeded low address lines to the GAL and replace them. With this simplified arrangement, I had hoped to use a few standard 74LS logic ICs to select the RAM and I/O. But, after a few attempts reduce the number of logic chips I needed, I decided to bite the bullet and just get a GAL programmer.

Here is my new setup which seems to work great with macOS:

• XGecu TL866II plus USB programmer - programs the GAL
• minipro - reads and writes JDEC files to the TL866
• GALasm - turns logic equations into JEDEC file

The biggest obstacle was that the first programmer I ordered (an older model TL866A) did not work due to a faulty pin 10. Unfortunately, this has been my luck with new tech items from China, including the cheap logic analyzer I bought a while back. These kinds of issues take A LOT of time to figure out.

Once I received a functioning programmer, I managed to get everything working well with my CMS 9619. So, now I can switch in 16 blocks of 32K RAM (512K) into the lower half of the CMS9619 address map, using the low nibble of its PIA output (at $FFC4) as a register to drive the virtual address lines. The CMS 9619 does not output a signal on its PIA for A20, so I can only use 2 of the SRAMs. Also, since the RAM addresses overlap the CPU addresses, half of each 512K SRAM chip can't be accessed (when A15 is high). This could be easily fixed by modifiying the U13 jumper board that I made previously, or even the CMS 9619 address decoder. Honestly, the original configuration was probably better for the CMS 9619 because it did not switch out the lower 8K of RAM that an OS would use. However, since my end goal is to use this with the CMS 9639 CPU and its integrated MMU, I will keep it as-is. I haven't fully tested the I/O and the VIAs yet, but I will get to those soon enough.

512K RAM on a MC6809!
Note the rainbow virtual address jumper and the
additional jumpers to route A19 and A20

More of the techincal details below, after the break...