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
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...
The cuts to the GAL's reassigned A8-10 signals are visible in the photo above between U17 and U16 (3 small white circles). New (and old) U16 GAL pin assignments, required for the new GAL decoding logic:
MIKUL 6218 U16 GAL22V10
------\__/------
A6 | 1 24 | VCC
| |
A7 | 2 23 | A20 (from W6)
| |
(cut A8) DEC | 3 22 | U15
| |
A15 | 4 21 | U6
| |
A14 | 5 20 | U5
| |
(cut A9) VMA | 6 19 | U4
| |
(cut A10) VUA | 7 18 | U3
| |
(from W5) A19 | 8 17 | R12 (disconnect R12)
| |
ST | 9 16 | A5
| |
E | 10 15 | U10
| |
A13 | 11 14 | A11
| |
GND | 12 13 | A12
----------------
 |
| 4 new signals routed. VMA and UTIL_DECODE needed small holes drilled through the board. |
If you are interested in modifying this board yourself and need help, or GAL programming, please let me know!
Good stuff. I have a frequent 45 minute commute, during which my mind often wanders to 6809 (Nitr)OS-9, the SWTPc, etc. I still intend to bring NitrOS-9 up on the 9619A you traded me for the 9600, and then my Motorola MM17. I've had thoughts of building a complete MMU with DAT similar to (compatible with?) the one on the CoCo 3, but I need to start simple with a Level I system. I found a Prolog system for OS-9/6809 on the Color Computer Archive, extracted the documentation from the disk image, and made a PDF of it for easier reading. The idea of running an embedded Prolog system on a 6809 computer thrills me, though I haven't quite worked out my exact use case yet.
ReplyDeleteThe thought I have about extra memory (some kind of SRAM board) is to use it as a RAM disk. The OS-9/6809 Pascal compiler has its own 'virtual memory' runtime that can interpret p-code (AFAIK not compatible with UCSD p-code) files larger than available memory. With a big RAM disk, this could be almost as nice as a LII system.
Hi Joel, I am working on a clone of the CMS 9639 myself! Hopefully I can get some progress posted in the next few months.
ReplyDelete2MiB definitely gives a ton of options for things like RAM disks,