Help needed on a simple microprocessor project

Thread Starter

slowmo

Joined Aug 4, 2006
6
I'm building my first microprocessor circuit with a Z80 CPU and a 29C256 eprom, all I was trying to do is to get the Z80 to read in and process a few simple instructions. The circuit is really simple with the two chips' address bus together, and the data bus together. The 29C256's OE(output enable), CE(chip enable) are forced low, the WE(write enable) is tied to the Z80's WR(write) pin, and none of the Z80's other control pins are used.

The program inside the 29C256 is as follows:
LD A,0Fh
LOOP: LD (00FFh),A
JP LOOP

The following is the assembled opcode:
3E 0F 32 FF 00 C3 02 00

All this program does is after the Z80 fetches the first instruction, it loads it's "A" register with 0F, then it attempts to write what's in register "A" to address 00FF, and just keep doing this in a loop.

What I got was upon power up, the Z80 fetches it's first opcode from 0000, and just stays there. This is true because the data bus reads 3E, which is the first opcode, and the address bus reads 0000.

Any suggestions? I'm happy to provide further details if needed. Thank you all in advance.
 

Papabravo

Joined Feb 24, 2006
21,094
It is OK to leave the EPROM Chip Enable at ground for the time being. You need to connect the RD-bar pin to the OE-bar on the EPROM. There may be other problems so if you could post a diagram it would be helpful. I don't have a Z80 datasheet handy, and we don't know which Z80 chip you might be using.

Check your reset circuit. If you hold the chip in reset then that would keep it at address 0.

Checkk your clock input to make sure it is beating up and down at the correct frequency. Note there are more stringent requirements for the voltage levels on the clock pins.
 

Thread Starter

slowmo

Joined Aug 4, 2006
6
Thank you Papabravo.

Yes, I purposely leave the eprom's CE at ground for the time being, the Z80's RD(read) pin was tied to the eprom's OE before, but because it wasn't working, I just tied it to ground also for the time being. It is the 8MHz version of the Z80 I'm using and the manual/data sheet can be found here:
http://www.z80.info/zip/z80cpu_um.pdf

Also, there's no reset circuit, I just want to get it to start working first so the Z80's RESET is not connected to anything.

One thing I'm suspecting right from the beginning is the clock source, I'm using an EPSON 8MHz clock chip(SGR-8002JA-PTB-ND) to generate the clock, it's supposed to be precise but the waveform didn't look that great to me, I took 3 snapshots and you can see them here:

http://kalawala.freewebspace.com/clock01.JPG
http://kalawala.freewebspace.com/clock02.JPG
http://kalawala.freewebspace.com/clock03.JPG

Thank you once again for your help.
 

BladeSabre

Joined Aug 11, 2005
105
Do you literally mean that the Z80's RESET is not connected to anything? I've not read the datasheet, but normally a reset pin has to be connected to something because otherwise it floats and has an undefined value.
 

beenthere

Joined Apr 20, 2004
15,819
Hi,

Your clock does not have to resemble a square wave. All it has to do is go low enough to satisfy the logic low requirement, and high enough to cross the logic high threshold. If you saw the clock in a 3 gigahertz motherboard, you'd just be amazed.

Bladesabre is correct in the need to tie control inputs either high or low. You might want to pull up the reset with about 10K to Vcc. If it's cmos, use 100K.
 

Papabravo

Joined Feb 24, 2006
21,094
A floating RESET(tch-tch) would certainly explain the inability to fetch any instructions at addresses other than zero. Unlike some PIC processors which allow RESET-bar to be connected to Vcc I don't think this will work for a Z80. I think there is a minimum low time to allow the clock to start, but its been more than 20 years since my last Z80 design. I seem to remember using an RC to a schmitt trigger to the RESET. A time constant on the order of 40-60 milliseconds comes to mind but don't quote me on it.

Check the datasheet very carefully for high and low thresholds on RESET and on the clock pins. They are very likely to be different from the rest of the pins.

On your debugging technique of grounding the OE input to the ROM; this is poor practice because you can potentially have the ROM and the processor both trying to drive the same lines at the same time. We used to call this TTL butt humping and the early parts were not too fond of it as you can imagine.

The better technique is to tie the individual data lines high or low through a tri-state buffer to form a NOP or other instruction. RD* goes to the buffer enable. Then observe each address line, data line and control signal until you can understand and verify what is going on. Since every instruction is a NOP you should be able to observe everything with a scope. A logic analyzer would be even better. If you get really good at this you should even be able to see the data lines being tri-stated.

Your next trick is to make every instruction a RST 7. Then you will see the process of saving the instruction address on the stack and vectoring to location 38 where it will fetch another RST 7 instruction and repeat the process.
 

Thread Starter

slowmo

Joined Aug 4, 2006
6
It's embarassing but yes, I did not connect the reset pin to anything. For the many advices that was posted, thank you for giving me a place to start and I'll try them to see how it goes.

My special thanks goes to Papabravo, thank you all! :)
 
Top