A couple of other questions that I've been asked revolve around programming the CPLD, which I'll try to summarize here.

CPLD Programming

Questions regarding the Altera EPM7128S seem to fall into two 'buckets': tooling, and issues with flashing.

CPLD Tooling

I use Altera (now Intel) Quartus v13 software, which can be downloaded from the Intel website here. You need to download the Quartus II Software, and the MAX 7000 device support package. Install these, and ensure that you can start Quartus II. Download the SBC Quartus project from the GitHub repository. You should be able to open the HD6309_glue_top project file (*.qpf) from Quartus. Compile the project (Processing -> Start Compilation) to build the output file.

Also part of "tooling" is some sort of JTAG interface between the host PC and the SBC PCB.  Search for an Altera USB Blaster and choose any model that supports 5V JTAG (most/all do). I use a nice unit from Terrasic which has been very reliable over the years, but certainly the lower-cost no-name units would probably work just as well.

CPLD Flashing

In general, CPLD flashing is either trivial, or impossible...

Normally, after connecting the USB blaster to the PC and the SBC, it's simply a matter of starting the programming feature from within Quartus (Tools -> Programmer). There's a little dance required to get the PC to see the USB Blaster via the [Hardware Setup] button, but then it's just a matter of clicking the [Auto Detect] button to see that the CPLD is able to communicate via JTAG. If it is, click [Start] and wait for the flashing to finish and you're good to go!

JTAG Issues

So...what if the Auto Detect fails? First, visually inspect your solder joints to be sure that you've got a good joint and no bridges to adjacent pins on the PLCC. Hopefully that's the issue.

If the solder joints look good, then we have to consider the CPLD itself. First off, it must be a EPM7128S... type. Examples: EPM7128SLC84, EPM7128SLI84. The S is critical, because it indicates that the device supports JTAG programming. Non S devices require the nearly-impossible-to-find-and-no-longer-supported Altera parallel programming hardware.

If you have an S device but it won't respond to Auto Detect, and you purchased it from anywhere other than a big distributor (e.g. eBay) then there's a very good chance that it's used and that the JTAG pins have been disabled. This is fairly common for CPLD's purchased from eBay sellers, and I'm sorry to tell you that there's (nearly) nothing you can do to remedy this. Re-enabling the JTAG pins requires the aforementioned Altera parallel programming equipment. Desolder the CPLD and throw it away...

My personal solution is a small PCB that I made with an 84 pin PLCC socket and connections to 5V and the USB blaster, to allow me to test the JTAG functionality of devices prior to me soldering them to a PCB...

There are people building HD6309 SBC, which is great to hear! I've received a couple of questions regarding construction that I will address in a couple new project logs:

FT230XS Configuration

A "fresh" FT230XS device will enumerate as a VCP, but needs a tiny bit of tweaking in order to operate as intended on the SBC PCB:

The FT_PROG configuration tool is available from FTDI here.  On the same page is the FT_PROG user guide. Connect the USB, start FT_PROG, and use the "Scan & Parse" option to find the FT230XS device. Afterwards, the configuration can be edited:

In the USB Config Descriptor section, set the following.
    bmAttributes = Self Powered
    MaxPower =     500mA

In the Hardware Specific section, set the following:
    CBUS Signals
        C0 = VBUS_Sense
        C1 = TX&RXLED
        C2 = Drive_0
        C3 = Drive_0
    IO Pins
        CBUS Drive = 8mA

There are two oscillators on the SBC, Y1 and Y2.  Unfortunately, the information on what these are is missing!

Y1 is "XOSC" and is 24 MHz, from which the 3 MHz quadrature ECLK and QCLK signals for 63C09 U3 are derived inside of CPLD U7.

Y2 is "WOSC" and is 14.745 MHz, which CPLD U7 divides by 8 and 4 to produce the signals that are applied to SCC U5 ACLK and BCLK, respectively.

Below is a snippet from the HD6309_glue_top.vhd file documentation, which seems to be the only place I bothered to document this information :-/

entity HD6309_glue_top is
	port ( 
		XOSC : in std_logic;			-- Oscillator input for CPU (nominally 24 MHz)
		WOSC : in std_logic;			-- Oscillator input for ACLK/BCLK (nominally 14.745 MHz)

		QCLK : out std_logic;		-- Q phase clock output (nom 3 MHz, XOSC divided by 8)
		ECLK : out std_logic;		-- E phase clock output (nom 3 MHz, XOSC divided by 8)
		BCLK : out std_logic;		-- SCC ch B baudrate (WOSC/4 for SCC BRG)
		ACLK : out std_logic;		-- SCC ch A baudrate (WOSC/8 for 115.2kbps in SCC 16x mode)

Possible source for Y1 (DigiKey):  https://www.digikey.com/products/en?keywords=SER1213-ND

Possible source for Y2 (DigiKey):  https://www.digikey.com/products/en?keywords=SER1234-ND

One thing that's high on my wish list for the 6309sbc is high level language support. After writing the SD card stuff in 6309 assembly language, for example, it was clear to me that C support would make using the 6309sbc a lot more fun (and easy).

I did take a look at the bipom MicroC toolchain. It's a windows IDE coupled with the Dave Dunfield MicroC compiler. I've used Dave Dunfield's stuff before - the monitor package has very nice ROM monitors and cross assemblers for about a dozen different CPUs. The monitor on for my own sbc6309 board is a hacked version of his 6809 monitor. Micro C is a limited dialect of C. It didn't take too long to adapt the runtime files for the sbc6309 hardware. I was up and running in less than an hour. I'll put the runtime files up on GitHub soon, in case anyone wants to give it a try.

But...it's not "real" C. There are a lot of limitations that have to be observed. Even then, stuff that should have worked, didn't. I can't really recommend springing $150 for this tool for the 6809 unless you're really, really curious. Don't get me wrong - I don't feel ripped off - I am just spoiled when it comes to embedded toolchains. I use Keil uVision for the 8051 for my day job, and that tool is rock solid. It is also about 20x the cost of the bipom offering. I get it.

I see that there's a 6809 target for gcc, but really have no idea how to make it work with something like the sbc6309. Anyone want to take this on? If so, contact me and we'll see what we can work out (e.g. trade hardware for a working gcc6809 for the 6309sbc)

Nothing going on with the SBC for a while - it's summer, and instead of electronics, I've been 'hacking' on a cottage rehab: down to the floor joists and the wall studs, complete re-plumbing, and a sorely needed electrical upgrade. It's a ton of work, but it will be nice when it's done. In the meantime, I've been thinking about VGA text and graphics support and I think a way to improve the sound quality from the FPGA. Of course, I've also spawned a couple new project ideas, which I'll put up here when I'm more in a position to actually work on them! For the time being, emjoy the summertime!

Fellow retroputing enthusiast Daniel Tufvesson found a nice set of tools to convert MIDI tunes into an intermediate format, very suitable for playing with a very simple program on the hd6303 and hd6309. What I think it reveals is that my lazy approach at sound interface from the emulated YM2149 to the audio CODEC is causing some rather unpleasant artifacts.

The YM2149 core ticks along at approx 1.56 MHz. This is the rate at which the tone generators update and the final output output is made avaialable. The audio CODEC interface (shamelessly stolen from Steven Edwards FPGA Apple II project) hums along at 18.43 MHz, which is 192x the 48 kHz DAC rate. So the audio CODEC interface consumes the YM2149 output at a rate that is not related to the YM2149 output update rate. I suspect that this is where my problem is. The asynchronous nature of the sound source and the CODEC interface are causing audible uglies.

I think I'll try to find some way to derive the YM2149 clock from the audio clock chain - I think that's the most straightforward way to do it. Otherwise, some sort of interpolation filter is required, which is really beyond my ability at this point - I'm no DSP guru; I just know enough to almost be dangerous.

If anyone reading this (does anyone read these?) has any suggestions or advice, I'd welcome it!

Very short update - latest ROM BASIC (Microsoft Extended BASIC) and the Quartus VHDL project for the glue logic CPLD are up on Github now.

Since my hacking about with the hd6303 (the Hitachi version of the 6800) I've managed to keep in touch with a fellow hd6303 enthusiast, Daniel Tufvesson ( check out his blog at http://www.waveguide.se ). Daniel has been looking very deeply into the FLEX operating system for the hd6309, and he's come to the conclusion that there's really only one (big) roadblock that complicates porting FLEX to this hd6309 SBC: the I/O page is located at $C000. FLEX OS was mostly run on the SWTPC-09 ( read more about this vintage machine at http://www.swtpc.com/mholley/swtpc_6809.htm ) and it has IO located at $E000. The SWTPC-09 has RAM all wrapped around the IO area, and the FLEX OS has program and data intermixed very freely. To untangle FLEX to work with a different memory map would be a LOT of work. Well, I think it'd be fun to have an OS, and I'm not about to write my own, so I guess I'll move the IO page to $E000. This involves no real hardware changes, thanks to the CPLD that handles all the glue logic.

Speaking of which...the last released CPLD version (1.2) sports about as much utilization as the EPM7128 will stand - something around 100 macrocells. Sure, there's 28 more, but routing to them becomes really difficult and the Quartus fitter just cries uncle and gives up. As I put together CPLD version 1.3, still pushing around 98 macrocells, I took a real hard look at the circuit that resulted from my VHDL code. This is most easily done using the RTL viewer feature in Quartus. What I notices was that the address decoder was really "lazy" and the implementation was a bunch of n-bit comparators - not very efficient. So, on a whim, I re-wrote the address decoder using only plan-vanilla, hand-minimized logic equations. I was rewarded with the total design implemented in 73 macrocells - a 25% reduction! That allowed me to clean up some other things that bugged me in the CPLD, so version 1.3 preserves some room for growth/fixes in the future.

So, coming soon is the CPLD 1.3 with ROM bank 1 from $C000-BFFF and bank 2 from $E200-FFFF. Each bank can be switched out for RAM. Writes to the ROM space will always write to RAM, so it's easy to copy ROM to RAM; just read and then write each byte back to its original location - no need for a page buffer elsewhere in RAM.  Of course, this means that I need to do some changes to the MS BASIC, and the monitor program, to accommodate the new I/O page location. Moving can be a pain!

Spring has finally spring here in Southeastern Michigan, so I'm finding more non-electronic things to do lately. Still, I managed to continue experimenting with the DE1 Cyclone II eval board that I've bridged to the hd6309 SBC. I found several nice VHDL implementations of PS/2 keyboard interfaces. I settled on a GPL'd set of code I found at eewiki.net

http://eewiki.net/pages/viewpage.action?pageId=28279002

That not only does the (easy) job of receiving the PS/2 clock and data pulses, but also the (less easy) job of converting the PS/2 keyboard "scan codes" into simple ASCII values. So, in short order, I could use the hd6309 ROM monitor program to read keys from a PS/2 keyboard connected to the DE1. I implemented the read-only keyboard data port "Apple ][ style" where the MSB is high when new key data is available, and low if it's already been read. The ASCII value of the key pressed is contained the lower 7 bits. So, for example, if I hit the "A" key, the first time I read the port it will read $C1 ($80+$41) and on subsequent reads it will read $41. Simple. 

Recall that the goal for the FPGA is to implement PS/2 keyboard, a sound chip (see previous log), a paged memory unit, and a VGA-compatible video interface. I'm convinced that the Cyclone II FPGA is capable of all of these things - much more, really.  For example, I did notice that opencores has VHDL for several IEEE-754 compliant Floating Point arithmetic units...hmmmm...

I recieved my hd6309 SBC bridge PCB right around Easter time. This is just a small PCB that interfaces to the expansion connector on the SBC. It brings the address, data, control lines through 5V to 3.3V level shifters (74LCX541 and 74LCX245 do the work here). A 40-pos ribbon cable interfaces these shifted signals to my Terrasic DE1 FPGA dev board. The DE1 is a fabulous board with an Altera Cyclone II FPGA and a very rich set of peripherals included (SDRAM, FLASH, SRAM, CODEC, LEDs, Switches, RS232, VGA...the list goes on).

After a simple I/O port implemented in the FPGA as a test (read the DE1 switches, write to the DE1 LEDs) I tore into a very nicely done GPL VHDL model of a Yamaha YM2149 sound chip (courtesy of MikeJ at FPGAArcade.com). The YM2149 is essentially an AY-3-8910 at heart. I altered the bus interface section to provide a demultiplexed bus (A0-A3 inputs, RD strobe, WR strobe) and removed the YM2149's two 8-bit I/O ports. I implemented a very simple address decoder of the hd6309 CPU address lines, and routed the audio out via the DE1 onboard CODEC. Voila! The hd6309 SBC now can make cool beepy-boopy sounds via a synthesized YM2149 soundchip.

This was a nice diversion that definitely proves out the idea that an FPGA can easily be interfaced to the vintage hd6309 CPU. As I wrote earlier, the intent is to eventually implement an FPGA-based VGA video controller, sound chip, PS/2 keyboard interface, and a paged MMU for RAM expansion. Sure, the FPGA could hold the CPU, also, but that's not what I'm after, here, so I'll stick to actual hardware for the CPU!