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...

Never Valid User Address

After finding out that my CMS 9619 Advanced Single Board MicroComputer was having problems accessing the EXORbus, I tried some trouble shooting. My MULTI-PLANE EXORbus backplane made it easy to accesss the various signals with an extra card edge receptacle attached. I tried pulling down various lines of the data bus with a resistor, and noticed that the 8 bits of data seemed to be responding appropriately. So, probably not the data bus tranceiver.

With little more to go on, I ended up buying an inexpensive USB logic analyzer and installing PulseView software for it. I was quickly able to identify that the bus's VUA (Valid User Address) signal was not rising when it was supposed to, even though it was receiving the correct signal from the PAL address decoder. Without this signal, the I/O card was never properly addressed, and the data bus was always floating. I tested another CMS 9619A board I have which displayed similar symptoms and found that it too was suffering from a failure of the same IC. Odd coincidence. So, after some desoldering, super-gluing a trace that was inadvertently partially pulled off the board, and re-soldering a new 74LS244 8-bit driver (U9), I am back in business. The chip came off of the other board much easier with the help of a heat gun.

I can't recommend these cheap logic analyzers enough to a hobbyist, although the first one I recevied was not working properly on some channels (make sure to test them before you rely on them for anything).

I also bought an EspoTek Labrador USB oscilloscope to try out, but I received, tested, replaced, and finally used the cheap logic analyzers from ebay while I was still waiting for the Labrador to arrive.

CRLF ≠ LFCR

I thought it would be an easy and quick project for last night to go back and properly fix the CRLF problem I was having. Unfortunately, it was not. I spent hours and hours testing the HTTP input string, hex-dumping, debugging, testing, and comparing strings using the lwip's built-in data compare functions. I still could not find what was going wrong. I started losing faith in the lwip code, the MPW complier, the Motorola 68000 processor, all of computer science. Was this really happening? It is getting so late, am I dreaming?

Finally, I double-checked a hex dump on the string to search for: "\r\n" and it reported: 0x0a 0x0d. At first, I thought 'that looks right', but then I noticed that it should be returning 0x0d 0x0a instead! How could it be transposing these predefined character escape sequences? A quick search on google revealed the problem: MPW transposes these two standard escape characters by default. I could't believe it. Of course, it is documented in the Apple SC/SCpp Reference for the MPW C/C++ compiler:

The compiler will by default map \n to the value 10 and \r to the value 13 to conform to the MPW environment. The -noMapCR option will turn off the mapping of the newline to carriage-return and carriage-return to newline.

If you are familiar with Macintosh line breaks (CR only), this makes sense, but if you are familiar with ANSI C code, it does not.

In the context of the lwIP web server, it was erroneously looking for 2 LFCRs, but wouldn't get them until there were 3 CRLFs: CR[LFCRLFCR]LF. Once I regained my sanity, the fix was easy:
/* #define CRLF "\r\n" */ /* WTF? I hate computers... */ #define CRLF "\x0d\x0a"

Compiler character mapping quirks, swapped characters and pulling hair out all seem to be themes in the RetroChallenge.