HD6309 Singleboard Computer

I admit I get sidetracked pretty easily. I was really trying to work on a nice, open-source monitor program for the hd6309. I was chugging away, making a bit of progress. Then, as I was casting about on the intarwebs, I was finally able to access the 6809 homebrew computer pages of Grant Searle. (note: I still have very spotty access to his pages - unreliable server?) Grant has done a wonderful job of taking the Microsoft's CoCo Extended BASIC interpreter and thrifting it down to a console version. Bravo! In a matter of a few hours, I was able to work with Grant's source file, adapt it to assemble with lwtools assembler, and do the relatively minor adaptations for my HD6309 SBC. Fire up the EPROM programmer...

It works great! It brings back a lot of fond memories of working with a relatively naked ROM BASIC machine. In no time at all I had loaded in Hammurabi from the Ahl book (101 BASIC computer games) and my 8-year old son Ryan and I were (mis)managing the mythical city and starving villagers left and right. Fun stuff! That's one goal accomplished, then - a working BASIC interpreter. Again, all the credit goes to Grant Searle - check out his pages, especially his MultiComp reconfigurable computer project. Good stuff!

OK, now, back to a monitor, that can now cohabitate with a fully functioning floating point BASIC interpreter.

I've been slowly chipping away at the edges of a dilemma. I've been very comfortable using Dave Dunfield's MON09 monitor program for this project. It's a really nice full-featured monitor that works great, and took almost no effort to port to my hardware (i.e. integrate SCC support). I added some stuff to support the realtime clock, and the CIO, and cleaned up the hex/srec loader a bit. But, other than that, it's pretty much the code I bought from DDS, many years ago. The only drawbacks are, as I see it: 1) it's closed-source, so I can't distribute the source code or even the binary ROM code; 2) it's really a 6809 monitor, and not a 6309 monitor - it doesn't know about the extra 6309 registers, nor all of the additional 6309 opcodes. 

I've avoided the temptation to fix #2, because of #1 - any effort put into the monitor can't be shared, and I'm bummed out about that. I've looked for a 6309 ROM monitor, but don't find one. I've found other 6809 monitors, all quite ancient, but they are also not open source (they predate the concept, for the most part). Ugh. 

I suppose I need to get writing, then. At some point, it'll be done....

Other News

I whipped up the design for a "breakout board" to interface the 6309 SBC expansion port to my trusty Altera DE1 Cyclone II FPGA eval board. It's just a bunch of 74LVC level shifters to bring the 5V TTL down to 3.3V CMOS suitable for input into the FPGA. The idea is that I can use the DE1 to develop the VGA and sound and keyboard interface stuff, before committing to a design.I've got a low-cost Cyclone I FPGA board, also, on hand, so there's another connector to interface with that board, too. I'm not decided between Cyclone I and Cyclone II. The II is more capable and larger, but the I comes in a nice TQFP 100 package that is about the limit of what I'll hand-solder.  Anyhow, this board should be helpful, I think. It's getting fabbed via OSHpark, hope to see the boards in about a week or two.

The 4.10 release of William Astle's "lwtools" assembler/linker toolchain is out. lwasm now includes the ability to write intel hex and motorola srecord output files - courtesy of yours truly.  Get it at  http://lwtools.projects.l-w.ca/   

I've been thinking about video and sound and keyboard for the 6309 SBC. I put the expansion bus connector on the SBC for this very purpose. A video and sound mezzanine card was in the plans. Of course, at that point, it's no longer an SBC. It's a 2BC or TBC, I suppose. 

I was originally intending to put a TMS9918 or a V9938 device on the card. A small group of us working on the N8VEM Z80 project worked out how to replace the creepy TMS9918 DRAM (ancient 4116 chip with a negative bias rail) with modern SRAM and a few octal latches. So, I know full well that using these vintage video chips is possible. What leaves me cold, however, is that after all that, you're stuck with a composite (NTSC) output. On top of that, the TMS9918 chip in particular is quite power hungry. I really want a nice VGA output with a decent 80 column character mode, maybe 320x240 and 640x480 graphics modes as well. No such beast exists.

On the topic of vintage chips, I'm a big fan of the 6581 SID sound interface device chip. This was the voice of the C64, and the fat sounds that subtractive analog synthesis brings are my preference. This is also possible to interface to the 6309, but with a 3 MHz CPU bus, a lot of glue is required to make it work. The SID is vintage, and scarce, and pricey. It runs hot. Love to have a CMOS one of these that runs with higher bus rates. No such beast exists.

I'm led to the conclusion that one way to satisfy my whims here is to use an FPGA to implement a simple VGA controller, and try out the VHDL SID implementation that I found on the intarwebs. I'll prototype first, of course, because if it doesn't sound good, I'm out. I worry about this, because the FPGA implementation will be via a sigma-delta DAC, rather than the linear DAC and analog filters of a real SID. So, time will tell. 

This is certainly a longer term portion of this project, so I'll not likely have much to say about this for a while. But fun to let anyone reading know what I'm considering, and I certainly welcome the opinions and feedback of anyone who cares to chime in.

I've been working for a while on a BIOS for this SBC. I'm shooting for a compromise between flexibility and simplicity. I don't have any visions for direct compatibility with older systems (e.g. SWTPC 6809) so I'm not constrained in that respect. I figure that some set of services, accessed via SWI, that cover character I/O and hardware abstraction (RTC, CIO) will suffice. It's a work in progress, which as soon as I get something reasonably complete I'll put up on GitHub.

The monitor is a different story. I've been using the wonderful MON09 from Dave Dunfield (DDS). It's not open source, so I cannot share it, otherwise i would. It's very nice - breakpoints, disassembler, S19 and ihex loading, etc. I extended it to add support for the peripherals on the hd6309 SBC, such as the CIO, the RTC, and of course the SCC. Aside from the open source, it's not a real 6309 monitor - so it cannot disassemble the 6309 opcodes, for example. So, I'm moving towards porting the venerable ASSIST09 monitor to this hardware. It's not as nice as the DDS monitor, and STILL not 6309-aware. So, if anyone knows of a real 6309 ROM monitor, please let me know! I'd rather not reinvent the wheel.

Finally, I cannot believe how long I managed to not stumble across the NoICE debugger tools. This is a PC based remote debugger that interacts with a small debug client on the target hardware. It provides source-level debugging on the PC side. This seems to be a perfect fit for my needs. The second SCC serial channel can be used for a dedicated debug interface (PC side seems to top out at 115.2kbps, otherwise I'd go faster) so it doesn't hog up the terminal I/O channel. As I get that integrated into the monitor and BIOS suite, I'm sure I'll have more to say on this. Best of all, the 6309 and 6809 NoICE debugger tools are FREE if you send the author a short email telling him about your project. I got a reply back within a day, and a free license for the 6309 debug package. Nice!

Turns out, the reason behind the SD card refusing to init was painfully stupid. My theory was that the SPI clock was too fast for the special transaction that takes place to bring the SD card from native (SD) mode to legacy (SPI) mode. So, I added more VHDL to include a second clock source for a slower SPI rate (375 kbps) and a bit to select between it and the faster rate (3 Mbps). Modded the sdtest.asm code, and...nothing. A few minutes with my trusty Saleae logic analyzer (I cannot say enough good things about this tool!) confirmed that the SPI rate was switching correctly. But it also let me see that the bits were shifting out of the SPI master in reverse order; that is, LSB first, MSB last. Ugh. That'll teach me to not double-check borrowed code. So, I fixed it. Voila! Working SD transactions! It even works without slowing down the SPI rate for the init sequence. But, I'll leave the two-clock-rate capability intact, because a slower clock is mentioned in most SD/MMC writeups. I did cheat a bit and economize, however: the 'fast' SPI rate is now 6Mbps and the 'slow' SPI rate is now about 460kbps (used the SCC baud rate reference clock for the slow clock). 

There's one lingering issue with the fact that I cannot run my sdtest.asm prog twice in a row without removing and replacing the SD card in between runs. I don't think this is a hardware issue, however, and more of a software topic.

I thought I would be all clever and throw in a hardware SPI master into the latest CPLD VHDL code. Prior to this, I bit-banged the SPI via a set of I/O bits in a CPLD register. The bit-banging was fine, but I wanted to unburden the CPU from all of this twiddling as well as increase the transfer rate with the SD card. So, I cast about on the intarwebs and found a very lightweight SPI master implemen ted in VHDL. Remember, this is a CPLD, not an FPGA, so lightweight is really important. I removed all the register-controlled I/O bits and integrated the SPI master.  Simulated fine. Worked fine on the PCB, even. What it doesn't do, however, is its intended function -- talk to the SD card!

I can't init the SD card.  I think I know why. I wanted the SPI clock rate to be fast - faster than I could bit-bang - so it ended up being 3 Mbps (a function of the 24 MHz system oscillator). Big deal, right? SD cards work with clock rates into the 10's of MHz, so what's the problem? It all gets back to how the SD card is being used. The SD card SPI mode is a legacy mode, not the native mode, and so a special initialization dance needs to be done on the SD card I/O to get it to switch modes. Briefly, clock in  at least 74 pulses with the CS line negated. That's not a typical SPI transfer, but that's just the point: this is a special action. What I overlooked, it seems, is that another requirement of the init dance is that the clock rate is between 100 and 400 kbps. Oops. My SPI port is twerking at 3Mbps while the SD card is looking for a 400kbps slow-dance partner.

So, I'll either throw in a bit to dump the SPI clock rate down by a factor of 8, or else I'll add some provision to manually toggle the CLK line to the SD card. I think the former is the most prudent path, and I hope that I've got enough macrocells left in the CPLD to squeeze this in. I'll write later as to whether or not this fixes the issue.

I was using the venerable Motorola AS9 MC6809 assembler for firmware development. This was not ideal for several reasons: it's a DOS application, it lacks macro capability, and worst of all doesn't know the HD6309-specific registers and mnemonics. There is an AS9 linux port (by Albert van der Horst) but that still didn't address the HD6309 topic. Fortunately, I eventually found LWTOOLS, a nice open-source toolchain (assembler, linker, librarian) that addresses all of these issues. It works well and is, by and large, compatible with the syntax of the the Motorola assemblers. Its only shortcoming, for my purposes, is that the assembler lacks the ability to produce ASCII hex (S19 or Intel-hex) output. I threw together a command line utility to convert the (TRS-80 CoCo) DECB format to S19 and Intel hex. I submitted patches to lwasm to generate S19 and Intel hex, and the LWTOOLS author (William Astle) indicated that these options would make it into the next official release.  You can find LWTOOLS at  http://lwtools.projects.l-w.ca/

I've created a repo for the HD6309 SBC on GitHub and committed the design files. You'll find schematic and PCB in PDF format, gerber files for PCB, the CAD files for the schematic and PCB, and the VHDL files for the CPLD glue.   https://github.com/tomcircuit/hd6309sbc