PPI Programmed buffers

[Mike_Z]

My CP/M 2.2 machine is a 64K 8080 machine. I have a parallel peripheral interface PPI that uses a 8255. I have found that the outputs are not strong enough to drive too much and generally cause some trouble. A year or so ago I added some buffers 74LS244's to the outputs, which helped tremendously, but I wired them in for output only. I have decided to try and improve this by attempting to program the I/O buffers whenever the PPI is programmed. I decided to only use Mode 0 or the PPI, yet have the ability to divide port C into two 4 bit ports and to have any combination of input and/or output of 4 ports. I had thought that if I could set 4 flip flops according to the Control Register programming I could direct the buffers for proper I/O. So, basically I clock 4 positive edge FF from the control register chip select and the write signal. The flip flops have their data line connected to D0, D1, D3 and D4. These data lines, when WR go low, will have Mode 0 I/O information.

I wired up a circuit and it doesn't work as I had projected. Seems that the FF's are trigger a little early.
I used this test program to see this.

MVIA 200	;Code for all PPI ports to output
OUT  157	;157 is the CTRL REG of PPI
HLT

Single stepping through this program, shows it should work, but turns out the timing is a problem. So I pulled out my 8080 handbook and began reviewing machine cycles again. I don't completely understand the OUT (or any other instruction). According to the 8080 Handbook on page 2-9, figure 2-7 shows the Output instruction cycle. There are 3 machine cycles, which have 4,3 and 3 clock cycles in them. Additional OUT instruction cycle information is shown on page 2-18.

Using the logic analyzer, I monitored the #4 Data Line (this signal controls the I/O of Port A during WR low), Write line and Phase 2 TTL lines. I thought that I could compare these traces with what I saw in the Handbook. But.... as usual something is different.

I copied this right from the handbook, regarding the OUT instruction Machine cycle 3, 'the rising edge of Phase 2 within state T2 clears status info from the CPU's lines and loads in the data which is to be output to external devices. This takes place within the Data Output Delay TDD, following the Phase 2 leading edge (220nSec).' This tells me that the data I want to output to the control register of the PPI should be on the data bus at the end of clock cycle T2. Then when WR goes low in T3, my FF's should capture the I/O data. But this does work this way. I tried data of 200 (octal) which corresponds to Port A output. The D4 of 200 is a zero, yet my FF is set, indicating that D4 was high when the positive edge clock pulse occurred. This is confirmed by the logic analyzer trace.

Here is a picture of the Logic analyzer trace.

The CLK trace is the positive edge trigger for my flip flops, Data is the data bus line 4, Q is the output of the port A flip flop, ~WR is the WRITE (knotted) signal and Ph2 is the phase 2 clock pulses. You can see the my flip flops are trigger when the ~WR goes low (this is actually the PPI chip select AND ~WR). You can also see that D4 is high during the trigger. I figured that D4 should have been a zero since the end of M3 T2. Another unusual indication in this graph is that ~WR stays low for two clock cycles, not one. My machine does not use any wait states for anything. This is why I'm thinking that the ~WR signal is one clock cycle early, If ~WR were to wait one more clock cycle, D4 would be correct. I also tried this with the D4 being high, if ~WR was delayed one clock cycle here also, D4 would be correct.

Anyway, I'm studying the instruction cycles in an attempt to better understand what I'm seeing on the logic analyzer. D4 shows it is zero four different times during the OUT instruction. Obviously, the data bus must be used for items like incrementing the Program counter etal. Seems the more I learn, the less I know. Mike

 

[Mike_Z]

Today I thought I'd try to duplicate the waveforms of the OUTPUT instruction cycle shown on p2-9 of the 8080 MCS80 User Manual, I think I called it the Handbook previously. This figures clearly shows that the ~WR pulse in M3 does not start until after the M3 SYNC pulse is over.



Next I set up the logic analyzer to show most of this traces. The waveforms are, top to bottom
Phase 2 clock
Data bus #4
SYNC
DBIN
WAIT
~WR (actually ~I/OW)



This display is rather busy, but it gave me an anchor point which was the WAIT going high during the halt.
This is the short program that I used for these traces.

MVIA 200
OUT  157
NOP
NOP
HLT

To help show the point of what I think is the problem this display is an enlargement around the trigger point, which was ~WR. Actually ~WR is ~I/OW.



How you can plainly see that ~I/OW goes low while the M# SYNC pulse is still high. So the ~I/OW is one clock cycle early. I have never experienced any I/O problems in the past, so maybe this one clock cycle was not that important for the other functions I use it with. The 8080 generates the ~WR signal. This ~WR is used in the 8228 bus controller to develop the status signals. The 8228 status latch captures status word (at STSTB) and then the status signals are generated using the DBIN, WR and HLDA 8080 signals. I can't see how the 8228 could make the ~I/OW early. Suppose the next item would be to add the CPU ~WR to the traces. This would eliminate the bus controller and point at the CPU chip. The MCS-80 Users Manual does not go into specifics regarding the CPU signals. Does anyone know of another document that does? Thanks Mike

Sorry about the sideways pictures.

 

[Chuck(G)]

I've never run into this situation on any 8080 system. Just for clarity, you're using an 8255A, not the original (buggy) 8255, right?

 

[Mike_Z]

Yes I am. Didn't realize that there was a problem with the 8225 verse the 8255A. I only have the 8255A chips. Hope to work on this some more tomorrow. Mike

 

[Mike_Z]

Today, I added the real ~WRITE signal from the CPU to the logic analyzer traces. What do you know, the ~WR is one clock cycler later. In this picture the ~WR of the prior pictures is labeled ~I/OW and the CPU WRITE is ~WR.



This ~WR is correct, so maybe the bus controller is not working correctly. It took a while for me to search and find a replacement 8228 chip, but after a grueling search one was found and the chip was replaced. I re run the prior test and now the traces appear to be very similar to the MCS-80 manual.



I started to think about how could the bus controller cause the write signal to be early. My guess was that when the CPU issues the status word, early in the machine cycle, onto the data bus, the bus controller grabs it in the status latch. Then later when the CPU issues the write signal the ~I/OW signal is generated. Maybe the WRITE signal logic to the gating array failed and just allowed the write to flow straight through the gating array.

Later when I was cleaning up the shop, I came across the old bus controller. As I was going to toss it, I noticed that this chip case was ceramic rather than plastic. I always thought that the ceramic cases were rather neat. Then while examining the chip, I found the real reason for the early ~I/OW signal. My old bus controller was a 8238 and not a 8228. Looking in the manual, the 8238 has an advanced MEMW and I/OW. The book says this is for 'Large System Timing Control'. What in the world is that? There is no discussion regarding that in the text. Other than the title statement and a dotted line on the timing chart, there is no mention of this. So, I mostly likely shot myself in foot a number of years ago. I must have forgotten that I replaced the bus controller with the 8238. I can't claim bad eye sight in those days. Anyway, I believe that my programmable buffers will now work as I had hoped. More testing is needed. The end goal here is to interface the CP/M machine to my Friden SFD-V. I wrote an output program about 2 years ago, when I had the hard wired output buffers, but could not input from the Friden Keyboard. That will be the next task. Thanks for the help. Mike