#z85c30

[techav]

Returning to Z80

It dawned on me a few days ago that I have a Seeed Studio TFT shield for Arduino that uses a controller with 8-bit 8080-compatible interface and has built-in​ pixel memory ... Meaning it should be easy enough to drive it from my breadboard Z80 computer, and I wouldn't have to keep the entire display in RAM (since 320x240 > 64k). I've spent what time I could spare over the last few days porting the sTFT Arduino C++ library to something that would compile with SDCC for Z80. It's a simple library, and the interfacing is actually easier on Z80 than AVR because I can just use the OUT instruction instead of manually strobing GPIOs. I pulled out the breadboard tonight to see how far I could get in testing. I've not touched it since January, and worse I've moved since then. Storage has not been kind to my little computer. It was carefully wrapped in anti-static bubble wrap, and nothing seems out of place, but it gives no immediate signs of life. Logic probe sings, so I know it's doing something. I pulled out out my cheap logic analyzer, and I was able to trace the data bus all the way through initializing the SCC (Serial Communications Controller, Zilog Z85C30) chip and into the first printf() call, but terminal never prints anything. Best I get is what appears to be randomly spaced 0x0D output on TxDA. That SCC is a fickle beast. It's a great chip with a lot of features for its time, but it is always a pain to get up and running. Here, since SCC is the first thing initialized by my monitor code, and my putchar() function is blocking, the program never moves on. It just sits in a tight loop, waiting for confirmation from the SCC that it's ready to transmit. Hopefully I can figure out the problem with the SCC without too much trouble. I really don't want to have to start over just to test the LCD shield. And perhaps I should add some blinkenlights so it's obvious the computer is doing something, without having to pull out the probes.

[techav]

The newest addition to my Z80 experiment, back in the back of that forest of wires, is the Zilog Z85C30 Serial Communications Controller. I added it to ease writing and debugging software, since right now even minor code changes require pulling, erasing, and rewriting my aging flash ROMs. To get to that point though, I’m going to need a monitor program to handle setup of the hardware and copying program data into RAM.

The SCC is a 2-channel USART perhaps most commonly known for its use in early Macintosh computers for serial and LocalTalk. It’s not exactly the easiest chip to use though, with sixteen registers per channel which have to be programmed in the right order to get the thing operational. The manual calls attention to this, but then fails to specify what order they should be initialized. I had a heck of a time trying to get it to work the first time I used it, so I just copied what worked that time, and changed the appropriate registers for baud rate and clock settings. 

The hard part this time was just getting a stable enough clock. The SCC can generate a clock with a crystal between its sync and clock in pins, but on a breadboard it can be hard to get a stable clock that way. With modern hardware, I could receive whatever the SCC sent with no problems, but the SCC is not as flexible in its timing. It had about 1 in 20 odds of mangling a byte it was receiving. In the end, I replaced the crystal with a 1.8432MHz oscillator, and receiving data has been much more reliable. That particular clock frequency was chosen because it’s one of the standard clocks that can generate common baud rates without jitter.

As for the monitor program, I want something that can accept data from serial in Intel Hex format and copy it to RAM, then jump execution to any point in memory. I also want to be able to dump the contents of memory back out the serial port in Hex format. I’m sure I could find a monitor program and modify it to work with my setup, but where’s the fun in that?

Instead, I’m modifying the sketch I wrote to program my flash chips using an Arduino Mega, since it already has the ability to input/output Hex format over serial. That was certainly an interesting exercise—porting C++ code heavily dependent upon specialized libraries for a modern embedded microcontroller to C code for for a 1970s microprocessor. I’ve finished with porting it, and at the very least my menu structure is working, but I’ve got a lot of debugging to do.

Most notably, the system reboots nearly every time I call atoi() (but of course, not every time). I’m going to have to either dig deep into the standard libraries for SDCC or just write my own atoi() function. 

Still though, this is further than I’ve gotten down this road before. Software is not my strong suit. I’m getting better though, and I feel like the more I learn about the hardware itself, the better I understand how to write software to use it. I’m even making decent progress with Assembly.