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!

CMS 9600A MPU Revival

I was recently able to trade one of my extra CMS 9619 SBCs for a CMS 9600A MPU (Thanks Joel!). This EXORbus processor card has very similar specs and layout to the CMS 9609 MPU card, but it uses the Motorola 6802 processor (an MC6800 with integrated RAM), rather than the MC6809.

If you are ambitious enough, you could even modify the CMS 9600A to use a MC6809 processor. Neither of these boards are as advanced as the CMS 9619 single board computer I have been working on, but nonetheless, I have been eager to get my hands on a MC6800 system to play with.

The board is in great condition, but had some areas of concern:

1. There are no RS232 line drivers installed, instead using DIP program headers/shunts in their place.
2. There is no boot or debugger ROM installed.

I mostly addressed the second concern before I even received the board. I OCR'd and transcribed the SYSMON debugger from the source code in the CMS 9600 manual (thanks for the scan Roland!). With a few adjustments, I was able to assemble it and format it for programing to EEPROM. Unfortunately, I could not get my AT26C16 EEPROMs to program in-circuit as I have for the AT28C64 EEPROMs. Anyway, I ended up using an adapter to use 1/4 of an AT28C64 EEPROM for testing.

As for the missing RS232 line drivers, this board was configured to use external line drivers on an RS232 breakout module (likely the CMS 9601-501). I tried connecting the appropriate serial lines directly to a TTL to USB serial adapter, but I did not receive any response from the board. I decided to just buy and install the line drivers to be consistent with my other CMS boards. This would eliminate a few variables while I focused on getting everything to boot from the EEPROM. Once I installed them it became clear that the new drivers were interferring with the baud rate generator due to an unusual wired jumper configuration that was causing contention. I removed some of the wire wrap jumpers so the settings are more consistent with my CMS 9609 board, and observed a nice clock signal arriving to the ACIAs.

Next, I added a small jumper to bring a constant 12V to the Power Failure Protect/Restart Circuit (connect 12V VIA to the "CR2" through-hole). Without it, the board stays in "locked reset" due to an assumed power failure.

While I was debugging these issues, I noticed a few distinct puffs of white smoke coming out of the CPU! I am not sure how that happened. I assume one of the address lines was pulled to ground through a test lead, but I was being quite careful. Anyway, with the CPU shot, I had to wait a few weeks for a replacement to arrive.

With a new CPU installed I was still troubleshooting with the logic analyzer when I noticed a column of asterisks in the terminal! I double checked the manual and realized that the monitor had been prompting me for a command for several reboots!

*V
FROM ADDR FF80

FF80 04 48 49 4E  5A 56 43 0D  0A 15 00 04  0D 0A 42 4B  
     .HINZVC.......BK
FF90 41 44 44 20  04 0D 0A 46  52 4F 4D 20  41 44 44 52  
     ADD ...FROM ADDR
FFA0 20 04 0D 0A  54 48 52 55  20 41 44 44  52 20 04 54  
      ...THRU ADDR .T
FFB0 4F 20 41 44  44 52 20 04  56 41 4C 55  45 20 04 4D  
     O ADDR .VALUE .M
FFC0 FA 42 45 F8  9B 47 F9 14  52 F9 35 54  FA A2 48 F9  
     .BE..G..R.5T..H.
FFD0 B7 56 FD DD  49 FA 07 4A  F9 FD 46 FA  67 51 F8 1C  
     .V..I..J..F..Q..
FFE0 44 FA 9D 4B  FA B4 31 F9  00 32 F8 EF  4C F8 1C 53  
     D..K..1..2..L..S
FFF0 F8 1C 4F F9  B6 4E F9 B8  F8 4F F8 59  F8 54 F8 00  
     ..O..N...O.Y.T..

Once I knew that everything was working, I took another stab at programming the EEPROMs in-circuit. After some jumper configuration changes on my CMS 9619A, I was finally able to program a few 28C16 EEPROMs. As it turns out, the CMS 9609 has some timing differences from the CMS 9619 that apparently prevent it from programming the EEPROMs. But with the CMS 9619 configured to accept the smaller 24 pin 28C16 EEPROM, the programming worked fine.

With everything else up and running, I wanted to try a TTL level USB/serial connection using the board's original DIP program headers, rather than the RS232 drivers that I added. Following the manual, it was easy to swap out the drivers and connect it up:

PHEW!

MIKUL 6218 Memory and VIA EXORbus board

I haven't spent much time working on my CMS 9639 SBC because, unlike the CMS 9619, it does not have any usable on-board RAM and does not include a monitor/debugger in ROM. Instead, it is designed to use an external memory board (which I don't have) on a back plane (which I now have) and boot OS-9 from a disk drive (which I don't have). What is nice about the device is the built-in memory manager which uses up to 1MiB of RAM. Unfortunately, EXORbus RAM cards are still prohibitively expensive on eBay and only have 16K to 64K of RAM capacity. Since the components would be far less than the price of those boards, I took a stab at designing a 1MiB SRAM board with a bonus additional I/O expansion.

I had just started to get components inserted into an EXORbus prototype board when I noticed the MIKUL 6218 Memory and VIA boards appearing on eBay at reasonable prices (<$45 shipped). Let's take a look at the board:

Click below for more details...

NitrOS-9 boot from ROM

One of the shortcomings of this CMS 9619 system is the fairly complicated OS9 bootstrap procedure I had to use in the absence of any sort of disk drives. To summarize:

1. DEBUG19 (in ROM) starts
2. Host computer transfers a small loader program using DEBUG19's memory edit routine
3. DEBUG19 jumps to the loader program, loading the kernel track from the drivewire server and runs it
4. NitrOS-9 starts and continues loading the rest of the bootfile from drivewire

This works pretty well, but has several drawbacks:

• 8K of address space is taken up by DEBUG09 ROM
• The host computer needs a separate script to efficiently transfer the loader program using DEBUG19
• 2 x 256 byte blocks of RAM need to be reserved to hold the RAM interrrupt vectors and data for DEBUG19

I had hoped that the kernel file could run from ROM and directly load disk images from drivewire. Unfortunately, the NitrOS-9 code is tied closely to the CoCo's hardware, and always relocates the kernel from ROM to RAM. To combat this problem, I replaced NitrOS‑9's relocation routines and added a module to initialize the CMS 9619 hardware for booting directly into the NitrOS-9 kernel. From there, the NitrOS-9 booter (on ROM) will load a disk image over drivewire. This is very similar to the set-up for the CMS 9639 (and I assume other computers sold with OS9). NITROS9 ROM BOOT NitrOS-9/6809 Level 1 V3.3.0 CMS 9619A (C) 2014 The NitrOS-9 Project ** DEVELOPMENT BUILD ** ** NOT FOR DISTRIBUTION! ** Wed Dec 16 16:07:07 2020 http://www.nitros9.org * Welcome to NitrOS-9 Level 1 * * on the CMS 9619A ASBM * yyyy/mm/dd hh:mm:ss Time ? 2020/12/12 05:55:55 >> Clock Initialization Errors << December 12, 2020 05:55:55 Shell OS9:

(The Clock init Error is because the code currently expects the DEBUG19 clock setting routines to be installed in ROM, which they are not. I still need to add these.)

It took some careful configuration to ensure that the CMS 9619 can boot from the DEBUG19 loading process OR directly from ROM, with no wasted memory in either case. Since the final NitrOS-9 boot ROM is less than 4K in size, an abbreviated DEBUG19 can also be programmed into the EEPROM. The code is available on Github.

On the note of programming EEPROMs, I discovered back when I was disassembling DEBUG19 that I can use DEBUG19's memory edit routine to program an EEPROM on the board. Of course, the timing is all wrong and the editor returns an error because the EEPROM takes much longer to store the value than RAM would. With some help from an expect script, it is fairly easy (though slow) to continuously run the memory edit routine, once for each byte, and ignore the errors. So, I can program EEPROMs on board by simply moving a jumper and running the script. If anybody has one of these boards without a ROM, I would be happy to send you a fully programmed EEPROM with NitrOS-9 and DEBUG19. In fact, I think I will add that to my tindie store soon!

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.

CMS 9619 Hardware Mods (continued)

Update: Since this post I have figured out how to change the address map using a GAL IC.

I recently posted some minor hardware modifications I made to my CMS 9619A Advanced Single Board Microcomputer to get it to use a 32K SRAM chip. Unfortunately, I had to disable the EXORbus data bus transciever to get it to work. So, although the board works properly as a single board computer, it cannot access the EXORbus. With NitrOS-9 up and running, I would really like to regain the ability to use external I/O cards.

To get this to work, the data bus transceiver (U11) needs to be re-enabled, but only during the External I/O address space at $FF80 to $FFBF (checkout the CMS 9619 memory map for details). This can be done by combining the normal data bus transceiver enable signal with the signal for address line A15. This works because the only time the transceiver is normally enabled in the high address space is in the External I/O address space (because everything else in that range is onboard the CPU module). All we should need to do is invert the normal data bus transceiver (U11) enable signal, and NAND it to the A15 address line.

Fortunately, there are a few ICs on the board that are not fully utilized. We can use the 1st gate (pins 1->2) on the U1 74LS04 inverter IC to invert the data bus transceiver enable signal, and the first gate (pins 1+2->3) on the U3 74LS00 gate IC to NAND the inverted signal to A15.

 

No traces visible to pins 1 or 2 on U1 or U3

This is almost too perfect that these logic gates are available, so I'm sure it won't work. Also, since the board is already bodged in this area with the factory's dead-bug'ed delay line, all of the modifcations are easily reversible with no traces to cut.

Before

After

After the modifcations, everything booted up properly and I was able to access my 32K SRAM at $0000-$7FFF However, I was unable to read any data from my known-good CMS 9650 8 port Serial I/O card. After some basic troubleshooting, I got to thinking... I don't think this processor card was EVER able to access the external bus- which is why I think I chose it for modfications. Major troubleshooting to come...

CMS 9619 Drivewire Boot to NitrOS-9

I finally got drivewire running on the CMS 9619 SBC. As a result, I managed to complete the bootup and have a virtual disk! Source code available on github.

EXORbus MULTI-PLANE Kit Now Available

The EXORbus MULTI-PLANE backplane is now available on my Tindie Store!

RC2020/04 Finale and Wrap-up

After getting OS9 to boot to the shell on my CMS 9619 SBC, I was hopeful to get the DriveWire module working to load in disk images in a more intuitive way. I don't have an extra RS232 to USB adapter currently available to me, so I tried using a USB to TTL level serial adapter on the board's peripheral port connected to the MC6821 PIA. Using the DriveWire module intended for use with the Tandy CoCo's serial "bit-banger" port (also connected to a MC6821 PIA), I was hopeful that I could get things running. Unfortunately, I am pretty sure I am having some sort of baud rate mis-match. The module issues a single character (probably indicating an INIT), then everything is stuck. I am not totally sure what baud rate I should use since my board is running at 2 MHz, compared the the Coco's 0.89 MHz. I think that is probably a lost cause without significant modifications to the timing in the software. (Actually, 57600*(2/0.895) ≈ 128000, a standard baud rate. I will give this a try...)

Once I get my other RS232 to USB adapter, I should just be able to run it off of the serial port, without any bit-banging related timing issues.

RC2020/04 Wrap-up

So, I am fairly happy with my progress this RetroChallenge, despite having to move to a new house. The extra month certainly helped. I was able to:

1. Make some hardware modifications on my CMS 9619 to get enough on-board RAM to run OS9 (Part 1, Part 2)
2. Get OS9 booted to the shell on the CMS 9619
3. Order my EXORbus backplane card design (Part 1, Part 2).

Once I get the rest of my supplies out of storage, I will get some of the backplanes on tindie for purchase.

EXORbus ATX Power Backplane Arrived...

Excited to see these EXORbus backplane cards arrive:

EXORbus ATX Power Backplane Ordered!

I just put in my first order for PCB fabrication today. After making some final modifications my ATX Powered EXORbus Backplane "MULTI-PLANE 9600", I finally got the courage to click the "Submit" button. If all goes well, I expect to sell the first round on Tindie at cost. I will keep this blog updated on the results.

OS9 shell on a real CMS 9619!

I finally got it working thanks to the advice of a kind member of the Tandy Color Computer (CoCo) discord channel. Interrupts! Once I connected the 6551 ACIA's IRQ line to the 6809's IRQ (using the CMS 9619's TS8 jumper block), the OS9 shell came alive:

You can see the system start up with the ROM's "DEBUG19" prompt. Then it proceeds to:

1. clear some memory
2. use the edit memory command to enter in the ZMODEM program and a mini boot-loader
3. jump to the boot-loader to get the first part of the kernel into memory sector by sector from a disk image
4. jump to the NitrOS9 Kernel.
5. The kernel starts loading in more sectors using its ZMODEM boot module, until it finally runs the terminal shell and gives me an "OS9:" prompt.

And now, with interrupts enabled, the shell responds! Now I need a proper ZMODEM file manager to load in and run other programs.

Fortunately... Unfortunately...

While I was waiting for my RAM to arrived, I tried burning an EEPROM for NitrOS-9 so that I could make the load time shorter and avoid the relocation problems I thought I was having. Well, it did not work.

Filled up Sockets! This would have cost
many hundreds of dollars back in the day.

Fortunately, my SRAM chips arrived early, so I got to work on installing them. Since the board expects EPROMS where I am putting the SRAM, I had to remove some jumpers that disabled writing to the sockets. I felt bad removing the beautifully wire-wrapped jumpers and replacing them with plastic jumpers, but it is for a good cause. With writing to the SRAM enabled, I tried booting. I thought it worked perfectly at first, but I realized I had run my expect script for the emulator instead of the real board. When I ran the correct script, I was sorely disappointed to find that everything was getting stuck just before the kernel was supposed to get loaded. After a lot of debugging, I figured out the problem. I had padded out the boot modules to align with the beginning of memory pages so that everything was easy to debug and compare to the source listings. Unfortunately, the emulated MC6809 was much more tolerant of scanning past the fill characters than the real MC6809. Once I got rid of the padding, everything started working... to a point. Where I was supposed to be greeted with the NitrOS-9 startup screen, I was getting gibberish:

Fortunately, this particular type of gibberish is recognizable as a baud rate mismatch, which makes sense. NitrOS-9 uses a completely different system for getting the baud rate than the CMS 9619 uses. After an adjustment to the terminal description files, I had an improvement:

YES! I was so excited until I hit the return key and... nothing. It does not respond with another prompt or an error or anything. Just stuck. More work to do...

Interru(o)ptions

This post is just to document and explore some of the interrupt options on the CMS 9619 that could be compatible with NitrOS-9's interrupt requirements (60Hz based on VSYNC).

RTC-58323 Real Time Clock

The CMS 9619's RTC can output a standard clock signal. The CMS 9619 has jumper block (TS10) that allows you to select a signal to connect to the Control B input (CB1) on PIA0. The signals are:

• 1 hour
• 1 minute
• 1 second
• 1024 Hz

1024Hz seems too fast and 1Hz is too slow for the interrupt we need. But, it's nice to know it is there. Probably better for a watchdog timer.

MC6840 Programmable Timer Module

The MC6840 timer in the CMS 9619 can generate a continuous square wave from 1MHz (1/2 the system clock speed) to about 141 years. The MC6840 can generate an interrupt every low transition of the output, or any of outputs can be jumped to the Control A input (CA1) on PIA0 using the CMS 9619's TS14 jumper block. I am not sure why there are 2 options to generate the interrupt here though.

To get an approximately 60Hz signal, I need to configure the MC6840 with a $4000 (16,382) divider of the system clock (1/((16,382+1)(2E-6)*2) = 61.03Hz). This should be easy to configure in the MC6840 16-bit Continuous Operating Mode.

Using the MC6840 PTM with a jumper wire to the right side of the TS10 jumper block (at the RTC), which connects to the MC6821 PIA's CB1 seems like the most suitable choice. It is almost identical to NitrOS-9's standard VSYNC interrupt on the CoCo's PIAO CB1 so I can re-use most of the code, and seems highly configurable.

External Circuit

The MC6840 Application Guide contains a circuit for getting a 60Hz TTL signal from the 120V power lines. I think this signal could work as a trigger to the MC6840 or the MC6821 PIA. However, it is overly complicated for this project, which does not need exact long-term timing.

Aside

I spent some time watching the "Virtual" CoCoFEST for inspiration today. Check it out!

Kernel of Truth

I spent some time today trying to get NitrOS-9 booting on the CMS 9619 SBC. I was able to get this working in emulation, so I was hopeful that it would be an easy job with real hardware. After some minor modifications to deal with timing in the slower environment, the ZMODEM module is working perfectly! However, getting NitrOS-9 running has been much more complicated.

As part of the boot process, NitrOS-9 relocates the kernel "disk" sectors from $2600 to high memory. Memory was cheap with my 6809 emulator, so everything that is not ROM was configured as RAM. The emulator easily relocated the kernel to $C000-$Dxxx, just below the main debug ROM at $E000-$FFFF. On my real board, that address range is not populated with RAM, so, I was relocating the kernel into thin air! I changed the load area to $7000-$8xxx, but had a problem because the relocation routines expect the video buffer at $8000, and over-write part of the kernel. I could keep toying with the relocation routines, but I think I just need to get more SRAM to populate the empty ROM sockets. I just put an order in, and am hoping for for some new 8K SRAM ICs by the end of next week.

CMS 9619 Hardware Mods

Note the 5 28 pin sockets on the right side of
the board for 4K or 8K SRAM or ROMs

In order to get NitrOS-9 running on my CMS 9619 SBC, I am going to need a lot more RAM. This board is configured to have up to 8K of onboard RAM and 32K of onboard EPROM, with options to use 4K or 8K chips. 32K and 64K RAM expansion boards were available in several configurations, including battery powered non-volatile SRAM to retain state during power off. Unfortunately I haven’t seen any of these available at a decent price, so expansion boards are not a good option for me. I do have a 32K SRAM chip with a similar pin-out (part of an eBay Dragon 32 IC kit) to the 8K module which would fit nicely.

My board already has 8K of RAM installed in socket U34 ($8000-$9FFF), and 8K of ROM in socket U7 ($E000-$FFFF). Socket U20 is not selected by the PAL decoder on this particular board, either by design (being configured for 1 x 8K DIP SRAM vs. 2 x 4K SRAM) or due to some problem with the PAL. My new 32K SRAM needs to be selected and addressed, which requires some minor modifications to the board.

To select the new 32K RAM chip, I first raised pin 16 of the PAL decoder IC normally responsible for enabling the U20 RAM socket (apparently not working on my board). Once that was done, I used the A15 address signal to enable U20 socket instead. This required a short jumper wire from pin 3 (A15) to pin 16 (U20 CS') across the PAL address decoder. So now, whenever the A15 line is low ($0000-$7FFF), the SRAM in U20 will be enabled. This is perfect since the SRAM IC is 32K, and will fill the bottom half of the board's address space.

To address all 32K of the SRAM, I first cut the GND signal from pin 1 of the U20 socket. This is tricky since the trace is right against the socket. I ran a jumper from pin 5 of the PAL decoder to pin 1 of the U20 socket (A14). Then I set the jumper at TS19 to connect pins 2 and 3 (A13), and the jumper at TS6 to connect 8 and 10 (A11). Socket U20 now has the address lines it needs to decode all 32K of memory.

Two long jumpers to connect A13 (I realized later this is handled by jumper TS19) and A14,
and one short jumper for A15

I was hopeful that everything would just work with the modifications, but of course it wasn’t that easy. The problem has to do with the data bus transceiver (U11) on the board. It is driving “data” from the EXORbus onto the processor data bus in the address range of the new RAM. However, there isn’t anything on the bus to drive and it is just causing contention with the new SRAM. For now, I disabled the transceiver by disconnecting the dead-bug'ed delay line from the enable pin (pin 19) of the transceiver, and pulled that enable pin high with a short jumper wire to Vcc. This isn’t ideal because it disables all of the external bus, including the I/O address range in addition to the low memory range that we need. So right now the CMS 9619 can’t read anything else on the EXORbus.

Short jumper to disable the EXORbus data bus transceiver (U11)

So, with 40K of RAM (8K in U and 32K in U20), and 8K of ROM with sockets for another another 16K, the board is nicely outfitted to run some real programs.

Setting a Real Time Clock with ZMODEM

I have had a little extra time lately since I don't have to commute for a while, so I pulled the CMS boards out of their storage boxes. One of the the things I really wanted to test out on real hardware is a routine I developed for setting the real time clock on the CMS board. Since my MC6809 ZMODEM routines are working pretty well, I decided to try out sending a command over ZMODEM, instead of a file.

Basically, if the receiver allows it, a ZMODEM sender can send a command for the receiver to execute. With the right flags, the standard lrz program will execute the commands in the system shell. Unfortunately, the receiver does not respond with the results of the command - it is not part of the protocol, since it is a receiver. But, the protocol allows you issue a command to start a ZMODEM send process to send the results, stored in a file, back to yourself! So, if I have the CMS 9619 send a ZMODEM command like this: date "+%y%m%d %H%M%S">/tmp/date.txt; lsz -y /tmp/date.txt

My terminal computer will get the date and time in the CMS 9619's expected format and save it to a file. Then, as ordered, it starts the lsz ZMODEM sender program, and sends the file contents back to the CMS 9619! The sender and receiver temporarily switch places to transfer the date string. Then the debug ROM's standard time setting routine is run to load the time into the RTC. It seems weird but it is the result of a very flexible protocol.

Now, ZMODEM does include an extension to get the system date, but it is sent as seconds since the Unix epoch. Converting that to an actual date and time without the proper libraries in 6809 assembly was beyond my skill set. Instead, the terminal (my MacBook Air) can do all of the work.

With gnu screen running on the terminal computer it is all pretty much automatic:

The screenshot of the session with the CMS9619 shows:

1. set the incorrect time
2. verify it is wrong
3. run the ZMODEM command routine, which instructs on how to start lrz
4. screen automatically starts lrz on my terminal
5. everything completes
6. checking the time with the "T" command, shows the correct date and time for the RTC!

Now to get the board setup to run NitrOS-9!

NitrOS9 on (an emulated) CMS 9619

I have been working on some ideas to expand my CMS 9619 SBC. I thought an SD card interface would be a nice option, but I didn't want to use any modern microcontrollers or FPGAs. I had a circuit pretty much worked out, but then thought a Compact Flash card would work better for 8 bit transfers.

While working on a circuit to interface with the MC6821, I realized that I already have a nice RS232 connection to the computer, why not use it? So, I wrote a 6809 assembly tool for the CMS 9619 debugger (debug19) to download blocks of data using the zmodem protocol.

This was working so well, that I figured I could use it to boot load NitrOS-9 on the board. Since I am moving soon, my computers are all packed away, but I couldn't wait to try it. I made some changes to sbc09, a simple 6809 emulator, to emulate the CMS 9619. Here is a video of the boot process to NitrOS9 all the way to the shell:

And it works! I need to finish a real zmodem driver to get it running other commands on the disk image though. Once I move, I can test it out on a real computer.

New EXORBus ATX Power Backplane

I recently designed this backplane/extender/ATX power injector for EXORBus:

The rendering does not show the card edge connectors that will be populated on the board. Hopefully, I can get the PCB produced some time in the near future. Please post a comment if you are interested, and would like me to order an extra for you. ~$30.

CMS 9619 SUCCESS!

With the the power and serial port breakout boards hooked up, I tried turning on the CMS 9619, with no luck- nothing from the serial ports. The ROM I received with the unit is set up to run some user code on the second ROM at start-up, skipping the debugger. So, I made a patch to the ROM to make sure that the reset vector points to the debugger init code. The update has now been committed to the CMS_SBC GitHub code archive.

Unfortunately, this 2 byte change took several hours to get into an EEPROM, since I only have my Apple IIe and a Super Serial Card (SSC) to use as an EEPROM programmer. I had to make some changes to the BASIC EEPROM programmer script (Read More to see the program). I modified it so that it allows me time to switch in each 2K bank of the 8K EEPROM. Then I made the mistake of trying to upload the hex dump using a terminal connection to the Apple IIe (using another SSC with the standard ROM). Even at 19.2K bps, it took over an hour due to an overly conservative text pacing setting. I'm not sure why it took so long, but, of course, I soon realized that I had forgotten to move the jumpers to allow the programmer SSC to write to the EEPROM. The jumpers where located under my bank-switching adapter board, so I had to shut everything down to reach them. Then I discovered an off-by-one error in the BASIC code and had to start the upload over. Switching to the method I previously described by using c2t to encode the ROM hex dump, then using the Apple //e's cassette input port made things go MUCH faster.

After installing the new ROM and powering on the CMS SBC, I still did not get anything from the serial ports. Some voltage testing led me to discover that the +12V was not making it to the RS232 receivers. I had hooked up the power to an ambiguously marked (and fortunately unused) pin 'U' rather than pin 'T' on the extension board.
With power now going to all the right places, I was shocked to be greeted by:
DEBUG19 :
It worked! But it did not seem to be accepting any input. As it turns out, my wiring to the serial port adapter was slightly wrong in implementing a cross-over cable. After referring to a nice diagram online, and moving my Carrier Detect lines, it started accepting input!

Here are some of the commands I had a chance to disassemble and use ("H" is a hex digit):

• R - Display the 6809 registers.
• P - Enter the EPROM programmer.
  • STAT for status.
  • EXIT to quit.
• T - Show the time from the RTC.
• S - Set the time for the RTC. Format: "S YYMMDD HHMMSS"
• E - Edit Memory. Format: "E HHHH"
  • Responds with "HHHH HH"
  • Enter: "HH" to set the hex value in memory.
  • [space key] for next byte.
  • "-" to go back a byte.
• V - View Memory. Format: "V HHHH HHHH"
• M - Move Memory. Format: "M HHHH HHHH HHHH", Source, Destination, Length.
• G - Go to Memory (run). "G HHHH"
• C - Clear Memory. Format: "C HHHH HHHH"
• DI - Disassemble Instruction. Format: "DI HHHH", subsequent DI disassembles next address.
• DB - Disassemble Block. Subsequent DB disassembles next block.

I very happy that this finally worked. It goes to show how useful an old Apple II is: I used a Centronics printer card to figure out the scheme of the PAL address decoder, a Super Serial Card to download the EPROMs and program the EEPROMs, and settled on the cassette input port to upload data. Now, to figure out something useful to do with the MC6809 SBC!

Check out all of the related blog posts for more details.