Mike Tsao geeks out.

Emulating a 6809 in a slow ARM mcu

As a thought experiment I’m wondering about a different approach to Project 8821. The STM32F407VGT6 is a 168MHz ARM Cortex M4 processor with plenty of flash and RAM to handle Joust. Could it emulate a 1MHz 6809, drive resistor-ladder analog video, and output sound? I bet the answer’s yes.

New Project: AVR Programmer

I’ve been trying to break the Joust rebuild project into meaningful chunks. My recent attempt at designing a circuit for manufacture in EAGLE didn’t pan out; it seemed both too big, because I hadn’t yet breadboarded all the sub-circuits as a single large circuit, and at the same time too small, because it would have been little more than those simple sub-circuits that I had successfully breadboarded. I’d have taken a lot of risk to fabricate a fairly boring PCB.*

Rather than hem and haw about what exactly to build next for Project 8821, I decided to take Quinn’s approach and gain experience building a tool that I knew for sure I’d need:

This is going to be an AVR in-system programmer and XSVF player. True, I could buy a USBtiny clone for $10 on eBay or a real one in kit form for $26 shipped, and in fact I have plenty of gizmos capable of programming AVRs, but I don’t have anything that can also program CPLDs, the JTAG Whisperer notwithstanding. The JTAG Whisperer is great in a pinch, but I really need it to speak 3.3v and to not require my Arduino, which is often enlisted in other projects.

And unlike any other AVR programmer I’m aware of, mine won’t require that frickin’ ugly and gigantic 6-pin ISP ribbon cable. See that angled footprint in the lower-right corner? It’s going to have a socket sticking out of it at a right angle, so it’ll be a cinch to stick the board directly onto the target without any cable whatsoever. (Actually, by “whatsoever” I really mean it’ll need just a mini-USB cable on the other end, but those are so commonplace and compatible with other devices that I don’t consider it an inconvenience to keep one on my desk. So it doesn’t really count as a cable.)

I’ll be sending this board out for manufacture shortly. I’m excited about it because I honestly think it’ll be a pretty darn good AVR programmer. I might have a couple extra boards left over, so if you don’t have your own programmer and need one, leave a comment. I’ll probably need one more rev of the PCB and still have the small matter of writing the firmware, but I’d love to have others using my creations!

Update: made some changes (VCC separate from 8u2 supply, VCC-5V header removed) after great suggestions from frank26080115, who is also the creator of the USnooBie. Thanks, Frank!

*”Boring” is a strong word. If I stuck a serial port on that board, it’d be at least as fascinating as any home computer that existed before the video-capable Apple ][. But I want to stay on project target; if I added a serial port, then I’d have to write 6809 software to use it. Given my self-imposed project constraint of avoiding getting into 6809 software and instead treating the Williams ROMs as an invariant, the serial port wouldn’t make sense. 

Maxim DS1077 Programmable Oscillator

The Maxim DS1077 is a programmable oscillator. Instead of ordering different oscillators for each different project you have, you get just one on a SparkFun breakout board and program it, using I2C, for whichever frequency you need.

And in fact, after some stumbles on my part, yes, it works.

Things I Learned About the DS1077, The Hard Way

1. The I2C interface (a.k.a. TWI or two-wire interface) depends on someone (i.e., you) to pull SCK and SDA high. Toss some pull-up resistors on those lines. I think there’s something cool going on with this protocol that I might be able to exploit for 8821’s bus arbitration. Must read more.
2. The Bus Pirate doesn’t turn on its power supply until you tell it to. This is very much a feature, not a bug.
3. SDA and SCK are not interchangeable. I hope you didn’t need the internet to tell you that; I almost did.
4. The Bus Pirate’s MOSI connection isn’t labeled for I2C, but it’s what drives the SDA line. This makes sense (master-out, slave-in) but I had to look it up to be sure.
5. When you’re at your wits’ end and not understanding why your lines are full of random glitches, try changing the wires. Sometimes even simple things like wires can be no good!

For posterity, here’s the Bus Pirate sequence I used to program my DS1077 with an approximately 4.03MHz signal on OUT1, with the two CTRL inputs disabled:

HiZ>m
…
4. I2C
…

(1)>4
I2C mode:
1. Software
2. Hardware

(1)>2
Set speed:
1. 100KHz
2. 400KHz
3. 1MHz
(1)>1
Ready

I2C>W
POWER SUPPLIES ON

I2C>[ 0xb0 0x0d 0b00001000 ] (Don’t write every change to EEPROM)
I2C START BIT
WRITE: 0xB0 ACK
WRITE: 0x0D ACK
WRITE: 0x08 ACK
I2C STOP BIT

I2C>[ 0xb0 002 0b00011000 0b00000000 ] (Use just the 10-bit frequency divider)
I2C START BIT
WRITE: 0xB0 ACK
WRITE: 0x02 ACK
WRITE: 0x18 ACK
WRITE: 0x00 ACK
I2C STOP BIT

I2C>[0xb0 1 0b00000111 0b11000000] (Write 31 (133MHz/(31+2)) to divider)
I2C START BIT
WRITE: 0xB0 ACK
WRITE: 0x01 ACK
WRITE: 0x07 ACK
WRITE: 0xC0 ACK
I2C STOP BIT

I2C>[0xb0 0x3f] (Write out the settings to EEPROM)

By the way, this is my first time using the Bus Pirate for a project. I’ve tried a couple times but bounced off because of v4/v3 incompatibility pains. I’m not in love with the interactive serial-terminal interface. But I do appreciate the idiot-proofing, such as starting up with all signals in high-impedance mode. That’ll keep me from destroying my equipment someday, for sure.

Son of ‘9572 is alive

A good night’s rest didn’t help the ‘9572. It remains destroyed. After talking it over with a few people, I believe any of the following is possible:

1. It was close to death already from having powered it from 5 volts for so long, and it simply gave out.
2. I was careless with a logic probe pin and briefly touched two opposing outputs.
3. While juggling pins on the UCF, I uploaded a new program that caused Possibility #2 to happen. I don’t think this was the case, because I think I would have noticed it when I rearranged the pins.
4. Or the chip just died, maybe from ESD, maybe from cosmic rays. It does happen.

No matter what the cause, I don’t think it was the VHDL, and I don’t think it was a currently-held misunderstanding on my part. So I’m back in the saddle with one of the Dorkbot PCBs.

As you can see, the latch clock is tied to the 1MHz Q clock. I managed to flick the latch button for less than a millionth of a second during the clock’s rising edge (it doesn’t look right on this graph, but I think this is sample error or else a difference in opinion between the Saleae and the ‘9572 about when the level fell again). The high value is latched into D0 on the next rising edge, then it’s shifted to D1 as D0 obtains the new low value, then it goes from D1 to D2, etc. Then about 21 clocks after that, we see it shift through A15. If I had more probe pins, we would have been able to see it go all the way from D0-D7, then A0-A15.

There is a bug in this code. The shift into D0 doesn’t happen until the rising edge after the one that should have latched it in. I will investigate. (Update: that was easy. I changed the REGISTER_TEMP vector from a signal to a variable so that it was evaluated in the order of the statements in the process block. There’s probably a better way.)

The ‘9572 is dead

I killed my CPLD Breakout Board. While taking pictures of the “successful” SRAM-loading VHDL I’d written and wired up, I noticed that the power LED on the board was off. I checked the connections, toggled the power a few times, tried re-running the logic analyzer, and eventually concluded that the board was dead. It draws 1.4 amps when I plug it in, and the CPLD itself gets pretty hot. As far as I can tell, everything else on the board is working (except for the power LED, which now appears to be inert).

Here’s my VHDL:

architecture Behavioral of SRAM_LOADER is
  signal REGISTER_TEMP : STD_LOGIC_VECTOR(23 downto 0);
begin
  process (CLK)
  begin
    if (rising_edge(CLK)) then
      REGISTER_TEMP <= REGISTER_TEMP(22 downto 0) & LATCH;
      if OE = '1' then
        ADDRESS <= REGISTER_TEMP(23 downto 8);
        DATA <= REGISTER_TEMP(7 downto 0);
      else
        ADDRESS <= "ZZZZZZZZZZZZZZZZ";
        DATA <= "ZZZZZZZZ";
      end if;
    end if;
  end process;
end Behavioral;

I think the tri-stated address and data pins are the problem. None of them were connected to anything (except four data pins hooked to my logic analyzer). But I’m not at all sure why that would be a problem. The only reason I think it’s related is that one of the last things I did was testing OE disabled (grounded), but it wasn’t the last thing (which was one more OE-high run to take a picture of the registers shifting), so even that evidence is questionable. If I’d obviously shorted something external to the chip, then I doubt I’d have been able to spend the half-hour or so when I successfully tested it. That’s why I believe I did something wrong with the tri-stating.

If you know a way that one could destroy an XC9572XL CPLD by programming it incorrectly, I’d appreciate a tip. 

TTL Voltage and Current Cookbook Recipe

Now that I’m able to do something with this CPLD, I’ve been concerned about replacing $10 of discrete logic chips with a $2 chip that needs $8 of level shifters. Though the Xilinx XC9572XL is a fairly modern 3.3-volt device, I know its I/O pins are 5-volt tolerant, meaning that I can send in a 5-volt signal from my circa-1980s 5-volt 6809E. But the ‘72’s output voltage is selectable at either 3.3v or 1.8v, and not 5v. And as established earlier, 5 volts do not equal 3.3 volts. What to do? Some inspired laziness (“maybe it’ll just work”) led me to read the ‘09 datasheet, and then do a bit more general research.

And I have concluded that yes, maybe it’ll just work. TTL logic levels define a low as zero to 0.8 volts, and a high as 2 to 5 volts. Why not exactly zero and exactly five? Well, there needs to be some margin for error. We software engineers like to think of pure concepts like binary zeroes and ones. But on the oscilloscope, real-world logic values sometimes look like a nervous driver on a twisty road at night. (Sorry, that link is a PDF, but it nicely illustrates what the 45- and 90-degree angles in datasheets really look like.) So low is a range, and high is a range, and 3.3-volt digital logic values are entirely consistent with 5-volt ranges. It’s… as if… (concentrating very hard now)… when The Powers That Be wanted to move to lower-voltage — and thus lower-power — electronics, they didn’t come up with a new standard so much as pick tighter tolerances for the old one. 3.3 is almost exactly in the middle of the old 2- to 5-volt range, and there’s probably some other practical reason why it’s easier to generate 3.3 volts than 3.5 volts.

Anyway, speculative history lessons aside, I’m pretty sure the 6809E will recognize signals from the 3.3-volt I/O lines of the CPLD. I’ll wire something up before committing it to a PCB, of course, but everything I’ve read suggests this will work.

Here’s the current ingredient list for Prototype Board #1:

1. Two power supplies: 5 and 3.3 volts.
2. 6809E.
3. 128KB SRAM.
4. MicroSD card slot.
5. ATmega32u4.
6. 16MHz crystal.
7. XC9572XL.
8. DAC for audio, with an audio jack.
9. DAC for video, with a video-out header.
10. Game-control input header.
11. [Placeholder for generating the digital side of the video signals.]

The ‘32u4 is the star of the show. I think it can do all these things:

• As a JTAG Whisperer, program the CPLD during development.
• Read the SD card and set up part of the SRAM as ROM from the perspective of the 6809E.
• Assert the 6809E’s reset line when everything’s set up.
• Handle all the 6821 game-control PIA duties.
• Depending on what’s left, maybe even output sound using PWM.

Meanwhile, the CPLD should be able to do this:

• Manage the address and data bus.
• Turn the 16MHz crystal into the ‘32u4’s clock, and into the Q/E signals. I don’t yet know whether a CPLD can turn a crystal into an oscillating signal.
• In a dream world where I’m much smarter than I am, fit the Williams Special Chip blitter into the 72 macrocells.
• Feed the digital video signals into the resistor ladder.

And of course the several-dozen other jobs I’ve forgotten. Phew!