Z80 Project

Z80 Project Mark 2: Flashing lights progress

Last updated: Sept. 20, 2009, 5:38 p.m.

I have made some progress on the Z80 project. Another mod, some software and learned some new lessons about PIC programming on Linux.

Another Mod I realised the other day that my plan to start testing peripherals with the PIC before inserting the Z80 would not work. My design has bus buffering to ensure the mash up of TTL and CMOS components all get valid signals. However the decision about what chip is driving the bus is made based on the status of the BUSACK line from the Z80. This means that without the Z80 fitted, or with it held in RESET the two sets of bus drivers (one from the Z80 and one from the PIC) could be in conflict as their enable line states are undefined. To deal with this problem I've added a 10K pull down resistor under the Z80, this will make sure that if the Z80 isn't driving the pin (because it's not fitted or it's in reset) the PIC has control of the data bus.

Software The first bit of software I wrote was a trivial light flasher, I've made up a plug with an LED and resistor that connects to the header I left for the SD card interface between SDO (RC5) and ground. The second bit of software I've written that actually does something to the system is an arbitrary IO bus write routine. This can write a byte to any address on the IO bus and supports block IO by writing the top half of the address bus too, I've also written an IO bus read counterpart but that's untested. The example code at the end of the article is the code I've tested, it flashes the LEDs on the debug port alternating every pair on-off and off-on. (0x55 = b'01010101', 0xAA = b'10101010') This is working correctly so the data bus is probably okay, and the address decode for this port is working as expected.

I've coded the PIC to drive the bus with approximately the timings the Z80 would at 5MHz so that any time based issues will show up when debugging with the PIC. I considered driving the bus slower with the PIC but decided this would be a waste of time as a debug tool.

Compiling the code on Linux I'm used to using the RES directive on 18F chips to dynamically allocate the data registers. I've never had a problem with using this in MPLAB, but when I tried to use it with gpasm I got warnings about no memory being assigned. After some digging I found that I needed to make a relocatable object and then link it. I thought this only affected program addresses but found it also assigns data memory.

To generate a relocatable object I needed to run gpasm -c <filename.asm>, then link it to create a hex file with gplink -m -c -s /usr/share/gputils/lkr/18f4520.lkr <filename.o> -o <filename.hex>. Once I did this and programmed the device the code ran perfectly. I need to incorporate these options into my Dwarf PIC programming UI.

Powering up the system for testing This is the first time I've powered up the system with enough chips in to make anything happen, so I wanted to make sure that nothing was conflicting seriously when I turned it on, so I set up a little test power supply.

Test power supply setup

The input is from any old DC power supply that's lying around mine was a 7.5V DC regulated one. I fed that through a 7805 regulator on a small heatsink to get 5V regulated, then through an output switch so I could easily turn it off if smoke appeared, and the return runs through my multi-meter via a couple of 4mm banana plugs to measure the current. The system powered up at about 200mA which was about right considering there are 10 LEDs drawing about 15mA each and a few logic chips.

AttachmentLast UpdateSize
pic_master_debug_flash.asm_.txtApril 23, 2014, 9:06 p.m.7.7 KB
Section:
Z80 Project
Tags:
Z80 Mark 2,
PIC,
GPASM

Comments

Posting comments is not currently possible. If you want to discuss this article you can reach me on twitter or via email.


Contact

Email: nathan@nathandumont.com

Mastodon: @hairymnstr@mastodon.social