OK, outside of chasing women and recovering from a cold I got absolutely nothing done on the project since my last post - until this weekend. I managed to finish my IEEE-488 port test program and finish off the hardware testing.
So here is some babbling about the successful IEEE-488 hardware testing and implementation.
I did finally discover one electrical error in the PCB layout, which fortunately is quite easily rectified (picture attached). I'm not sure how I missed this, but in one of the two 74LS245 octal line drivers/receivers that I am using as receivers in my IEEE-488 port, only six of the eight buffers are used. Instead of grounding the two unused input pins I accidentally grounded the two unused output pins instead. I noticed that this chip was getting a bit warmer than it should. Fortunately the unused input pins, numbers 8 and 9 are inline with pin 10, the ground pin, so fixing the problem is just a solder blob shorting these three pins together. The buffers are non-inverting, so the two unused output pins accidentally grounded rather than left unconnected can just be left as they are.
The long obsolete Motorola IEEE-488 interface chips originally used in the PET were unusual in that a separate receive output pin and transmit input pin were provided for each I/O pin. All IO, as per the original IEEE-488 standard, was open-collector with a resistive (voltage divider) pull-up to approx. 3.5V. Logic low=true. In these Motorola chips the receive output pin simply reflected the logic state of its respective I/O pin regardless of weather the I/O pin was asserted true (low) by either an external device or by the respective transmit input pin being asserted low.
Consequently in the PET there isn't a direction control register of any sort for IEEE-488 communications, but separate output and input register bits for all of the CPU-controlled I/O pins, with the exception of SQR, which is an input only and therefore doesn't have an output register address. There are also two control pins which have no register addresses at all as they have no hardware provision for CPU control. These are RET and IFC. The RET line is electrically tied to ground. This asserts the PET as a permanent host. IFC is asserted by the power-on system reset (555) timer only. There is a total of 16 lines in the IEEE-488 standard - 8 data lines and 8 control lines.
To implement the IEEE-488 interface as per the original PET hardware configuration using current production parts rather than those obsolete Motorola chips, I used a pair of SN75ALS160 as the output line drivers and, as mentioned above, a pair of 74LS245 buffers as the line receivers. The 74ALS160's are wired in uni-directional mode with the active pull-ups disabled. In this mode the I/O are open-collector outputs with an internal resistive pull-up to ~3.5V. The 74LS245's are perfect in this application as line receivers as they have TTL-compatible switching thresholds with hysteresis. They also have special high-impedance inputs courtesy of emitter-follower input buffers, so they will not load the internal resistive pull-ups of the SN74ALS160 operating in open-collector mode.
Pictured below is a screenshot of the IEEE-488 test program that I wrote this weekend. The screen is divided into two halves - the left hand side for the output register status/control and and the right hand side for the input register status. The current logic state of a register bit is indicated by the O graphic symbol next to its respective pins name. A logic high (false) is indicated by a solid O while logic low (true) is indicated by a empty O.
The logic state of any IEEE-488 pin can be toggled by pressing the letter key indicated to the left of the pin name listed in the output register table. With the exception of pins ATN and SRQ, with no external device connected to the IEEE-488 port the status of the input register bits on the right hand side of the screen simply reflect the output register status. Basically, there are two ways to make an input register bit show a logic low (true) - by either asserting the pins respective output register bit low (true) or by shorting the pin to ground at the IEEE-488 port. The program I wrote therefore makes for a handy hardware test even without any device connected to the IEEE-488 port - if, when toggled, the logic status of any input register bit does not reflect the logic status of the respective output register bit, then there is a hardware malfunction, either with the output driver or with the input receiver for that register bit's respective I/O pin.
Pins ATN and SRQ are a little special. All other input pin registers are asynchronous and indicate true when their respective I/O pin is pulled low by whatever means. ATN and SRQ however are edge-triggered inputs, their respective register bits being set on a high (false) to low (true) pin transition. In order to give an unambiguous test indication for the operation of these pins in my program, I configured these pins to behave as flip-flops. In the input register side of the screen there is an N key indicated to the left of the ATN input register bit and an O key indicated to the left of the SRQ input register bit. Pressing the N on the keyboard will clear (set high = false) the ATN register bit wile pressing O will clear the SRQ bit. The only way to get either ATN or SRQ to indicate true after being cleared is to assert the respective hardware pin true (low). The SQR pin, as mentioned previously, is an input pin only, so the SRQ I/O pin must be externally forced to ground. ATN however is both an input and an output, so it can be asserted true either by shorting the ATN I/O pin to ground externally or by toggling the ATN output register bit from high (false) to low (true). Once set true both the ATN and SQR registers will remain in that state (indicating that a false-true transition was successfully registered) until manually cleared by pressing the respective clear key.
Oh, and one last thing. The EOI output resister bit is utilised in the PET to serve a secondary hardware function - when asserted true the video screen is blanked! Asserting the EOI I/O line true externally (and thus the EOI input register bit) does not blank the video screen however. It is only the logic state of the EOI line at the input side of the line driver that controls the video blanking. This freaked me out a bit the first time I pressed K on my keyboard whilst running my developing test program, until I remembered the hardware configuration of the EOI line. Oh no! I've killed it!
Home
Help
Search
Login
Register
