• Please review our updated Terms and Rules here

PCjr POST 8255 test bug

MicroCoreLabs

MicroCoreLabs

Veteran Member
Joined
Feb 12, 2016
Messages
1,181
The test writes to the 8255 port-A, reads it back, then writes to port-B and reads this back, but only check the results from port-B.

There doesn't seem to be a test for the 8255 in the 5150 and 5160 POSTs.

1780334462006.png
 
Last edited:
>>> The test writes to the 8255 port-A, reads it back, then writes to port-B and reads this back, but only check the results from port-B.

What is wrong with that?

Whatever is written to port A should be read back from port A.

This is then written to port B and the readback from port B should be the same.

Dave
 
Because they are not checking port A - they are combining write/read to/from port A with write/read to/from port B and checking the overall result. Whether it is port A or port B that is faulty is irrelevant - the 8255 is faulty.

Dave
 
Then why perform the read back of data written port-A at all? :)

I suspect that they forgot to add the CMP and JNE code for the port-A check...
 
The logic appears to be "let's test ports A and B as a unit and see if the value survives passing through both". If the value read back from port A comes back clobbered, it's sent to port B anyway, but even if B doesn't change it again it'll still differ from AH, and the JNE will branch.

So it doesn't look like a bug, more of a design decision where they didn't care which of the two ports alters the value.
 
I see your point(s). Not a bug I guess. Interesting that this check not done for the 5150 and 5160.

It's similar to the 8088 register tests where they chain the result of one access to the next and perform just one check at the end. Doesnt matter which specific register was bad.

1780339786048.png
 
>>> Then why perform the read back of data written port-A at all?

Because if port A reads back incorrectly, this incorrect data is subsequently written to port B and then read back from port B.

Irrespective of which port is at fault (A or B) the value read back from the chain will not be the same as the value written into the chain.

All the code is interested in is "is the 8255 faulty or not" not "exactly which part of the 8255 is faulty".

The Tektronix 4052 microcode does this on start-up - it writes a value into register 0, then reads a value from register 0 and writes it into register 1, ..., reads the value from register 15 and compares it to what was originally written into register 0. Any discrepancy indicates a register fault, and the microcode halts (having written the pattern it wrote into a diagnostic register for the human to examine).

The POST does the same thing as the Tektronix then - a faulty register is a faulty register. It doesn't matter which register it is - because the register is inside the CPU chip and you need to replace it...

Dave
 
Last edited:
If address[0] is stuck then the 8255 is effectively inoperable yet their test will pass. Had they implemented it as: write_A write_B then read_A read_B it would have revealed this type of error.

If their code passes in the presence of an address fault then its a bug...
 
Report it as a bug then...

The CPU address and data lines should have been previously tested for being 'stuck' much earlier on in the test sequence.

Besides, if address[0] is stuck, it would be odds-on favourite that the CPU/BIOS would have given up the ghost many, many instructions ago anyhow.

Now, we could argue about which address bus buffers could have been faulty...

My hardware engineering lecturer's voice is now ringing in my ears about not designing hardware that can't be tested. Of course, this is a PC, so the BIOS is a very quick (and dirty) test of basic functionality.

Dave
 
Last edited:
I would even say different programmers within the PCjr BIOS department.

Aside from the register chaining mistake they also test the data registers 256 times which is a bit excessive.

This is different from the 8259 testing code that just uses patterns of 0x00 then 0xFF - same as the 5150.

Maybe an IBM PCjr "junior" programmer was responsible for the 8255 test code? :)
 
The fact that they bothered at all with this for a computer that was literally being sold as a toy is certainly a perfect demonstration of IBM just being genetically incapable of not IBM-ing.

If you really wanted to detect this "is the A0 pin not connected" condition I guess a trivial fix would be to just add a single instruction between the write and read of port B: After writing port B write a hardcoded value (255 is the obvious choice) to Port A; if the A0 line isn't connected it'll clobber the "0" you wrote to Port B on the first pass. Otherwise it does nothing since it's overwritten when you do the next test loop of Port A.
 
Eudimorphodon said:
The fact that they bothered at all with this for a computer that was literally being sold as a toy
Click to expand...
I always wondered if the IBM POSTs were made deliberately long because they felt user would think the computer was cheap if it snapped to life immediately upon power-up. *REAL* computers take a while to power up and perform internal checks... Toys are expected to immediately turn on...
 
You must log in or register to reply here.
Back
Top