DIAG264

Updates

02/02/2012 – Engineering change. The value of the resistors on the cassette dongle has been changed from 150R to 330R. The previous values can cause some instability of the cassette test on some machines. If you have already built the cassette dongle, I would recommend changing it. – Crock

This document describes the purpose and operation of the 264 series diagnostic tool and harness. It can be used to assist in the identification of faults with RAM, ROM, I/O & CPU ports, and TED registers. It has been tested on a wide range of 264 series (aka TED) machines, including some non-standard configurations and PAL and NTSC machines. This includes the C116, Commodore 16, C232 and Plus/4.

It was developed primarily on a Windows 7 PC using Textpad 5.4 , 64Tass 1.46, Yape 1.0.2 and Vice 2.3

Thanks, in no particular order, to the following individuals.

The HTML version of the document can be found here and you can contact me either by a private message to ‘crock’ on Plus4World, Commodore16.com or Lemon64. You can also send email to a filtered email account at  

Disclaimer

As soon as one undoes the screws and lifts up the lid on an old 8-bit machine, there is an element of risk involved. To use this diagnostic tool in its most effective form, it requires replacing the kernel ROM in the machine and attaching loopback connectors to the interface ports of your machine. The TED chip especially is sensitive to abuse and the built in latch register is easily broken by stray voltages and static. I know this because I have done it!

Although I describe how to build such connectors that I have myself successfully built and used, I do not actually recommend using them for the keyboard and joysticks. This does mean that the tests cannot be run unattended without bypassing the keyboard and joystick tests (a feature which Diag264 does provide), but as these are not usually intermittent in nature, this is not a significant issue.

If you do choose to build loopback connectors for the keyboard or joysticks, I will provide any guidance that I can, but please understand that you do so at your own risk.

Background

I acquired or built most of Commodore's official diagnostic cartridges and harnesses for the 64, VIC-20 and C128 which they sold to service centres, mainly to help me fix the growing pile of computers I’d acquired. Fixing them became somewhat an obsessive-compulsive habit, and I could not bear having broken ones lying around. In amongst them I had a C16 and two Plus/4’s, only one of which worked. I started searching around for a diagnostic cartridge for the 264 series but with no luck. I knew Commodore had definitely made one, but I could not track it down. Finally, I found an image of one on Plus4World, but as I never got any response from the owner, I decided that my only choice was to build my own.

Design and Theory of Operation

The design and operation of Diag264 is modelled closely on the operation of the cartridges available for the 64/128 and VIC-20. One of the aspects that I was most keen to copy was the functionality of the Dead Test Cartridge of the 64. The primary use of this cartridge was to find RAM issues in a machine that otherwise appeared dead.

The majority of Commodores 8-bit offerings used DRAM chips in either a 64k x 1 or 16k x 4 configuration. This usually meant that any dead RAM chip would make the machine completely inoperable, as the zero page ($0002-$00FF) and stack ($0100-$01FF) are rendered practically unusable. The kernal start-up routines in both the 64 and 264's make extensive use of the ZP and implicitly rely on the stack upon the first execution of an RTS instruction! This presents a problem for any normal cartridge based diagnostic tool because we are dependent on the kernal to hand over control to the cartridge ROM. The Dead Test cartridge avoids this problem by making use of the 64's rarely used Ultimax mode, which enables an external cartridge ROM to replace the Kernal of the host machine and therefore bypass the normal start-up routines, making it a superior tool for identifying RAM problems on an otherwise ‘dead’ system.

The 264 architecture does not include any way of auto-booting into an external ROM without trying to pull some dirty tricks with the address lines. So it becomes a trade-off between the conveniences of a cartridge versus the extra benefits of booting straight into the diagnostic. Not being a fan of compromise, the Diag264 ROM can be compiled for either cartridge or kernal.

The kernal option is a simple drop in replacement of the kernal ROM, which is the 28-pin ROM chip with the identifier beginning with 318004 (PAL) or 318005 (NTSC.) The cartridge option involves sacrificing a standard commercial Commodore C16/Plus cartridge (I used Strange Odyssey) unless you are lucky enough to have a supply of cartridge blanks. You will need to remove the ‘low’ ROM and install a 28-pin DIL socket in its place, as seen in my cartridge in Figure 1.

Figure 1 - Cartridge Mod

The TED chip itself supports both NTSC and PAL standards, controlled by bit 6 of register 7. NTSC and PAL machines therefore have slightly different kernals to correctly set the state of this bit, and also some other small modifications to take into account timing differences. When running from a cartridge, DIAG264 could query the installed kernal to determine whether it should be running in NTSC or PAL mode. This could be done by checking the value of $F33F which contains the default for TED register 7. As of version 0.2B, this is not implemented, and it is not possible at all when running from a kernal replacement. For this reason I have made both NTSC and PAL versions of DIAG264 available.

Loop back connectors

To determine the correct operation of the various I/O interfaces, a number of loop back connectors are required. For a C16/C116/C232 you need a minimum of a serial port and cassette connector. For a Plus/4 an additional user port loop back is required to test the Asynchronous Communications Interface Adapter (ACIA) interface and the 6529 8-bit port.

As mentioned in the disclaimer, it is also possible to construct connectors for the Joystick port and keyboard, but this is not an absolute requirement if the user is prepared to manually execute the keyboard and joystick tests.

Cassette Connector

The cassette connector is reasonably simple, requiring a 7 pin mini-din connector, two 330 ohm resistors and a few short lengths of wire. The diagram below is viewed looking at the rear/solder side of the plug.

Figure 2 - Cassette Connector

 

1.     GND

2.     +5v

3.     Motor

4.     Read

5.     Write

6.     Sense

7.     GND

 

The read line [4] is directly connected to the write [5] line while the two resistors form a voltage divider between the motor [3] and GND[7], with the resulting output being sufficient to pull the sense [6] line high when the cassette motor is activated.

7 pin mini-din plugs can be sourced from most electronics retailers such as Maplins, Farnell or Digikey, although they can be rather fiddly to solder given the small pitch of the pins. It may be easier to find another lead with a 7-pin moulded plug pre-attached if you happen to have one to hand. A broken 1531 cassette unit is ideal!

Serial Connector

The serial connector is even simpler. As the data and clock lines are bi-directional, they are internally looped back, the only exception being the ATN line. The connector consists of a single link between the ATN [3] and Clock [4] line. The diagram below is viewed looking at the rear/solder side of the plug.

Figure 3 - Serial Connector

1.     N/C (Plus/4 & C232), +5v (C16 & C116)

2.     GND

3.     ATN (Out)

4.     Clock (In/Out)

5.     Data (In/Out)

6.     Reset

 

6 pin DIN plugs are in plentiful supply and much easier to solder as they usually have cups to hold the wire, so you shouldn’t have to sacrifice an IEC cable to make this.

User Port Connector (plus/4 Only)

The User port connector serves two purposes, firstly to test the 8-bit 6529 port and secondly the 6551 ACIA RS232 interface. This is constructed using a 24-way edge connector with .156” spacing, the same as found on most other Commodore 8 bits. Again, the diagram below is viewed from the rear of the plug. This connector can again be sourced on-line from the usual electronics retailers, and also from the master of 8-bit C= hardware projects, Jim Brain.

You need to make 7 links, four linking ports 0-3 on the 6529 to ports 4-7, which requires joining [B] -> [6], [K] -> [7], [4] -> [J] and [5] -> [F] respectively. Then 3 connections looping back the signals for the ACIA. These are [C] -> [M], [D] -> [L] and [E] -> [H]. This basically implements a standard RS232 loopback (with one minor difference as the +4 does not expose CTS on the user port) as described in datasheet for the equivalent W65C51N from the Western Design Center. (W65C51N Datasheet)

A word of warning, make sure you clearly label your connector ‘top’ and ‘bottom’ or, even better, insert the vertical keys between 1 & 2 and A & B  then 10 & 11 and L & M. If you insert it upside down, you will fry something and believe me, I know, because I did it. (I actually fried two DRAM’s in pre-production Plus/4 SN 190 because the key ways had been cut into the PCB back to front, so I have installed the keys AND written top and bottom on the plug.)

Figure 4 - User Port Connector

1.     GND

2.     +5V

3.     /BRESET - Buffered Reset

4.     6529 – P2 (also Cassette Sense)

5.     6529 – P3

6.     6529 – P4

7.     6529 – P5

8.     RxC – Receive Clock

9.     ATN – IEC Attention

10.  9V AC

11.  9V AC

12.  GND

 

A.    GND

B.    6529 – P0

C.    RxD – Receive Data

D.    RTS – Request to Send

E.    DTR – Data Terminal Ready

F.    6529 – P7

H.    DCD – Data Carrier Detect

J.     6529 – P6

K.    CTS – Clear to Send

L.     DSR – Data Set Ready

M.   TxD – Transmit Data

N.    GND

Keyboard loopback

If you do decide to build the keyboard loopback, this is how I built mine. Commodore used at least four different keyboard layouts for the 264 series machines, in fact the only ones that I know for certain have interchangeable keyboards are the +4 and C232, although I’m pretty confident that the 264 itself is the same. The C116 uses the rubber chiclet keyboard which omits the shift lock key but the connector and matrix is the same as the +4 keyboard.

The C16 reuses the keyboard from the VIC-20/C64 but with a number of keys remapped, and uses a 20-pin SIL plug with a 0.1” (2.54mm) pitch. This plug is easy to build using a discarded 40-pin IDE cable from a PC hard drive which has the same 0.1” pitch. Although the plug is the same, the 80-pin IDE cables have each alternate conductor grounded to reduce crosstalk. As a result the signal wires are much finer and more difficult to work with, so you’re better off avoiding them. Peter Schepers has some info on preparing the plug here http://ist.uwaterloo.ca/~schepers/diagnostic.html but the basic process is to split out the odd numbered wires and cut the rest back close to the plug. Number 1 is usually marked by a different colour.

You then need to connect the wires together as shown in Figure 5 and Table 1. Pins 2, 4, 5 & 20 of the keyboard connector (not the IDE numbering) have no connection and pin 2 is used as a key. I blocked off pin 2 by blocking the hole with a pin from another header plug. As the other side of the IDE cable has pin 20 blocked off, this makes it impossible to connect the plug incorrectly. The contacts on a typical keyboard have around 110 ohms of resistance, so I have put small resistors in line to limit the current. There is also a small signal diode with the cathode connected to the keyport 6529 (Signal Out) side of the connector to stop the joystick loopback interfering with the testing of the keyport.

Figure 5 - C16 Keyboard connector

The keyboard connector for the Plus/4 and C116 is more difficult to construct as finding something that connects nicely to 18-way FFC (Flat Flexible Cable) connector is not easy without destroying another keyboard. I leave it as an exercise for the reader to come up with something better than my first attempt in Screenshot 1. The pins are in the same order by numbered differently on the C116 and Plus/4, as seen in columns 6 and 7 of Table 1.

Screenshot 1 - Plus/4 Keyboard Loopback

Table 1 – Keyboard loopback connections

Signal Out

Signal In

Key

C16 Pin Out

C16 Pin In

Plus/4, C116 Pin Out

Plus/4, C116 Pin In

D0

K4

F1

19

7

18

6

D1

K5

S

8

9

7

8

D2

K6

T

12

10

11

9

D3

K7

V

11

3

10

2

D4

K0

9

13

18

12

17

D5

K1

P

1

15

1

14

D6

K2

;

16

14

15

13

D7

K3

2

6

17

5

16

Joystick loopback

The design of the joystick interface on the 264 is quite different to other 8-bit Commodore computers. With the exception of the fire buttons, all the control lines from ports 1 and 2 are all wired together and connected to the TED’s keyboard latch. Whereas the 64’s joystick interface worked by pulling the control line to ground, this interface works by using a buffered data line as the joysticks input; Joystick 1 uses D2, and Joystick 2 uses D1 (‘gotta love Commodore design.)

I toyed with several ways of building a test circuit that I felt was safe for the TED, and the one shown in Figure 7 was the simplest that I was comfortable using. A 74HCT244 is perfect for our needs, it is a TTL octal buffer with two active low enable lines, each enabling 4 outputs. By driving the enable lines with the joystick select lines and holding the inputs low, it effectively emulates the joystick being pushed in every direction at once. Again, as the contacts in the +4 Joystick have a resistance of around 110 ohms, I have included similar valued resistors in series with the outputs. The +5V and GND are available on both ports and can be taken from either or both. Although you can solder the wires to 8-pin mini-dins, it is very fiddly and I would suggest finding and cutting a cable with a moulded plug. Old Appletalk network cables are great for this!

Figure 6 - Joystick Port Connections

Figure 7 - Joystick Test Circuit

 

Operation & Test Walkthrough

Install the ROM or insert the cartridge, connect the loop back connectors, connect a monitor or correctly tuned TV and finally the PSU, then power on the machine. Most of the screen shots that follow are either grabbed from YAPE or VICE2.3 simply because the quality is better, but some of the ones that rely on the loop backs are taken with a camera pointing at my LCD TV.

Low Ram Test

The first sequence of tests is run as soon as the CPU hands over execution to the diagnostic ROM. The principle is to execute a memory test of the address space of $0002-$0FFF without making any use of the Zero Page or Stack. This is actually quite tricky to do as you only have the normal A, X & Y registers available on the CPU and you also need to have some means of communicating a meaningful status back to the user in the case of finding a fault. The test routine achieves this by using the stack pointer (SP) as a fourth register and the screen and border colour to communicate the status.

First is a data-bus test which writes a sequence of values to a fixed location, in this case $0002. The values test each data line in turn, using values 1,2,4,8 etc. Any failure to read back the same value will either indicate a problem with the data line or with one of the DRAMs. I say either because although these tests can give a strong indication of where the problem may lie, it is frequently impossible to be definitive.

If a problem is detected, the border will flash from 1 to 8 times, followed by a short pause. The number of flashes indicates which data line is at fault. Additionally, the screen background colour is set to dark red, so you can tell where in the test sequence the problem was found.

I have found the screen contents to be an invaluable source of information when diagnosing ram faults; it is possible to identify stuck data lines or addressing faults just by looking at the screen contents. For this reason, if the ram tests detect an error and drop into the screen flash, the screen will alternately fill with ‘@’ symbols and ‘¿’, which are values $00 and $FF respectively. It will also alternate from filling top downwards and bottom upwards, to help identify addressing faults. The patterns you should see are shown below in Screenshot 2. If you see the screen filling with values other than this, or the fill is not uniform, you may be able to determine the problem by cross referencing the observed characters with their corresponding value. As there would be no point proceeding with any further tests if the zero page or stack is at fault, the machine will continually repeat the flash cycle until powered off or reset.

Screenshot 2 - Flash Cycle characters

The second low-ram test is designed to identify addressing faults. The RAM tests implemented in the original Commodore diagnostic ROMs were actually rather poor in that they usually wrote the same byte across the entire address space. This makes them unable to highlight addressing related issues, such as failed multiplexers. This Diag264 test works by writing a pattern of bytes across the low ram area in an upwards direction, verifying the contents, then writing a different pattern of bytes in a downwards direction. Again, this test makes no use of either stack or zero-page.

If faults are found, the reporting mechanism is the same as with the data-bus test, except this time the background will be blue if the problem is found while filling upwards and green if filling downwards. The number of flashes may not be that meaningful and further clues may be determined by observing the screen contents during the screen flash cycles. Although this test will complete quicker than the observer is likely to be able to see, the screen will momentarily show something like shown in Screenshot 3.

Screenshot 3 - Address Line Test

The final low-ram test is a device test, which writes a sequence of 20 test bytes across the address space using the same algorithm as found in the C64 dead test cartridge. The bytes are:

$7F, $BF, $DF, $EF, $F7, $FB, $FD, $FE, $80, $40, $20, $10, $08, $04, $02, $01, $FF, $AA, $55, $00

In my opinion, this test is of limited value as a device test given the DRAM architecture. In a system using 8 64k x 1 bit DRAMs, writing the same value across the whole address space will result in each DRAM being all ‘1’ or all ‘0’, which is not much use for identifying pattern sensitivities. Nevertheless, until I get round to writing a better algorithm for identifying them, and given their relative rarity, the original Commodore device test will remain.

The screen border will cycle through a sequence of colours as each test byte is used and, as the low-ram area includes the screen and colour memory, you will see the contents of the screen rapidly change. The same reporting mechanism is used if an error is found during this test, with the screen background being black. If a failure occurs at this point, the number of screen flashes will point very strongly to the defective DRAM. The table below shows which IC is the likely problem.

Flashes

Bit

Plus/4  IC

C16 IC

C116 IC

1

D0

U11

U5

U5

2

D1

U12

U5

U5

3

D2

U13

U5

U5

4

D3

U14

U5

U5

5

D4

U15

U6

U6

6

D5

U16

U6

U6

7

D6

U17

U6

U6

8

D7

U18

U6

U6

Once in the flash sequence, problems with particular devices will usually be visually obvious as the screen contents cycle between $00 and $FF. For example, if on a Plus/4 U15 has failed leaving bit 4 stuck high, instead of seeing alternating ‘@’ and ‘¿’ symbols, you would see ‘P’ (hex value $10) and ‘¿’.

Once the low RAM tests have completed, Diag264 knows that the zero-page and stack are now functioning correctly, so the stack is initialised and the TED registers set up as they would be on normal machine start-up. As we also know the screen RAM is functional, we can revert to a more human friendly form of communication before moving on to the more comprehensive tests.

Screen Layout

Now is a good time to explain the general layout of the screen, most of which is self-explanatory. Look at the screenshot of a completed test cycle in Screenshot 4. On the top line is the title, with the version number. In the bottom left are the current cycle number, which will loop at 9999, and my handle in the bottom right. Down the left side is the name of current test in progress, followed by the status of the completed tests, which would be OK, FAIL or SKIP. The next numeric column is the total number of failures for this test. If the diagnostic is left on continuous loop, this is useful for spotting intermittent failures. To the right is information specific to the test, which is covered in the detailed explanations below. As each test runs, the cursor will flash to the immediate right of the test name.

Screenshot 4 - Screen Layout

High Ram Test

The high RAM test performs the exact same sequence of tests on the memory area from $1000 to the upper end of installed RAM, which could be $3FFF, $7FFF or $FFFF. The test first identifies the RAM configuration by writing a sequence of bytes to $30 and checking to see if they are mirrored at $4030 or $8030. The amount of installed memory is displayed when the test completes.

On a 64K system, special measures have to be taken to test the RAM that resides beneath the ROM’s. To do this, the high RAM code is copied to $0200 and the RAM made visible to the CPU by writing to the TED pseudo register at $FF3F. As it’s not possible to access the RAM beneath the I/O areas, memory is then tested up to $FCFF and then from $FF20 to $FFFF, skipping locations $FF3E and $FF3F.

In order to speed the tests up, the screen is blanked, allowing us to make use of the clock doubling feature of the TED architecture. On a 64K system they will take approximately 20 seconds to complete and the screen colour will cycle as the test values change.

In the case of a failure, the address where the error occurred will be displayed and an exclusive or between the written and expected value, as can be seen in Screenshot 5.

Screenshot 5 - RAM Test Failure

Screenshot 6 - ROM Test Failure

In this example there is a device related failure at location $8CD2, where bit 3 (value $04) reported incorrectly. The “DEVICE” message could also report as “MUX-UP” or “MUX-DN” if the error occurs in either of the addressing tests.

ROM Tests

The ROM tests perform checksums on any installed ROMS, including those in the Func-Hi and Func-Lo sockets. Each ROM is check summed three times, and if the value changes from checksum to checksum, no rom is presumed to be present and the message ‘SKIP’ is displayed. If SKIP is seen when a ROM is known to be present, this should be considered a failure. If the checksum of the ROM is recognised, the part number and revision is displayed. Any other computed checksum will result in a ‘FAIL’. An example can be seen in Screenshot 6.

The checksum routine is copied to $0400 in RAM to allow the different ROM’s to be switched in. The Low ROM area is summed from $8000 - $BFFF and High ROM from $C000 - $FFFF, with the exception of $FD00 – $FF1F for the I/O area. For high ROMs other than the kernal, the area from $FC00 - $FCFF is also skipped as the 264 architecture always exposes the default kernal in this area to allow the bank switching and interrupt routines to always be visible.

You will occasionally see garbage on the screen for a short time while the kernal ROM is banked out of the high memory area. This is because the character tile data stored in the kernal is momentarily invisible to the TED chip. One observation I made while developing this is that that when reading the two bytes at $FF3E and $FF3F, the contents of the ROM are visible. These are not check summed because this behaviour is not consistently modelled in emulators and the only official kernal to have values other than $00 in these locations is the NTSC R5 kernal ($FF and $FF.)

All known official kernals are recognised, including those with modified characters sets for the Hungarian market. If anyone finds an unrecognised kernal checksum which they know is valid, please let me know. The current list of recognised ROMS is show in Table 2.

Table 2 - Diag264 recognised ROM's

Description

Checksum

Commodore Part Number

Basic ROM (Same in all known TED machines)

$1C3133

318006-01

PAL kernal Revision 1 (only found on EPROM’s in prototype machines)

$1BB9EB

318004-01

PAL kernal Revision 3

$1C0C98

318004-03

PAL kernal Revision 4

$1C0B99

318004-04

PAL kernal Revision 5

$1C089C

318004-05

NTSC kernal Revision 4

$1C1292

318005-04

NTSC kernal Revision 5

$1C2D77

318005-05

3+1 Function Low

$1B1E78

318053-01

3+1 Function High

$1C09A1

318054-01

Hungarian PAL kernal Revision 1

$1BF552

318030-01 (questionable)

Hungarian PAL kernal Revision 2

$1BF085

318030-02 (questionable)

DIAG264

Varies

DIAG264

Keyboard Test

The keyboard test checks two aspects of the keyboard operation, the 6529 single port interface and the keyboard latch on the TED chip. It does not perform an exhaustive check on the keyboard matrix as the original intention was to have the test running unattended with no keyboard attached. As I discussed previously, you can use the keyboard loopback and the software fully supports it, but it is not required.

The test first checks to see if the shift-lock is held down. If so, the remainder of this test, as well as the joystick test, is skipped, avoiding unnecessary delays waiting for keys that will never be pressed. If not, the 6529 keyport is tested to see if it can hold a value by writing to the port and comparing with the values that are read back. If any problems are detected with the keyport, the message “6529 KEYPORT BAD” is shown when the keyboard test completes.

The keyboard port is then cleared (all bits set high) and the TED keyboard latch sampled. If the latch contains anything other than $FF, this indicates a possible keyboard problem. At this point a string of 8 keys to be pressed is displayed on the screen in black, as seen in Screenshot 7.

Screenshot 7 - Keyboard Test

The test will then pull each of the lines low on the keyport in turn, keeping each one low for approximately 2 seconds. The leftmost black key is the one that should be pressed if a keyboard is attached and also corresponds to the loopbacks on the keyboard connector if that is being used. The keys and loopbacks have been chosen so that each line on the keyport pulls a different bit of the TED latch low. If the corresponding bit of the latch does not go low within two seconds, that port/latch combination is deemed to have failed, the key is colour red, and the test moves on to the next key.

On success, the key will be coloured green and an additional test will be done by clearing the port and re-reading the latch register after a short delay. If the same value cannot be read from the latch it indicates a problem with the latch being able to hold the value correctly, a common partial failure of the TED. In this instance the message “TED LATCH BAD” will be displayed, but only after the joystick test has completed!  You can see in Screenshot 7 that the first five keys were successfully detected, 6 and 7 were not, and the final key (2) is currently being waited for. If a loopback is being used the test will complete very quickly if successful.

Joystick Test

The joystick test operates much in the same way as the keyboard test, except that instead of a list of keys, a list of possible directions for the two joystick ports is displayed. They will initially be displayed in black text, which turn green as each direction is detected. As it’s not always easy to be precise if using a joystick to manually provide the input and as we do not have to test an output port, the test does not require the joystick to be actuated in any particular order. The test will be flagged as complete once every direction and fire button has been detected. If directions are still outstanding after approximately 15 seconds, the test will be flagged as a fail.

With a suitable loopback connected, the test will complete very quickly. Without a loopback, the only way to get this to successfully complete is to have a joystick connected to both of the ports. If you suspect one of the joystick port has issues but you only have a single joystick, you should start the test with the joystick on port one, determine that it works or not, then power off the machine and swap the joystick to the other port. Although there is some electronic protection on the joystick ports, you should never swap joysticks over with the power on.

As with the keyboard test, the TED latch is also tested to determine that it can hold a value. If a latch problem is detected in either the joystick test or the preceding keyboard test, the message “TED LATCH BAD” will appear after the test completes. See Screenshot 8.

If a joystick loopback is not available, activating the shift lock before the test starts will cause the joystick test to be skipped.

Screenshot 8 - Failed TED Latch

Cassette test

The physical implementation of the cassette interface varies from machine to machine. Common to all the models is the use of P1, P4 and P3 of the 7501/8501 CPU for write, read and motor control respectively. On a Plus/4 the cassette sense is implemented by either P2 on the user port 6529 or by P7 on the CPU. This is controlled by two jumpers on the board, J8 & J9. On every Plus/4 board I have seen, I have only ever seen the cassette sense implemented by P2 of the 6529. There is no 6529 on the C16, C116 or C232 but the equivalent cassette sense operation is mirrored using a tri-state buffer to drive D2 to the state of the sense line when reading from $FD10. The cassette test implementation being used by the tested machine will be displayed after the cassette test completes.

If the cassette test fails at any point, a status byte will be shown to the right of the cycle count which will indicate exactly which step of the test failed. The steps in the test are as follows:

01.  Start with write low (P1) and check read (P4) is high.

02.  Hold write high and check read is low.

03.  Hold write low and check read is high again.

04.  With the motor off, check if P7 of CPU or D2 at location $FD10 is being held low.

05.  Check motor is still off (high)

06.  Turn cassette motor on.

07.  If cassette sense is using $FD10-D2, check this is now high.

08.  If cassette sense is using CPU-P7, check this is now high.

All of the CPU output ports are inverted by a 7406 at U6 on a Plus/4 and U9 on a C16/C116. Assuming the loopback is installed correctly, any failure in steps 1-6 strongly indicates that either the CPU or the 7406 is faulty. If a failure occurs at step 7, it implies the cassette sense circuit is at fault or, more likely, that the cassette motor circuitry is at fault.

Serial test

The IEC serial port is internally looped back, with the exception of the ATN line, which is looped back to CLK in in the connector. As with the cassette test, a status byte will be shown to the right of the cycle count which will indicate exactly which step of the test failed. The steps in the test are as follows:

01.  Start with DATA out (P0), CLK out (P1) and ATN (P2) low and check DATA in (P7) and CLK in (P6) are high.

02.  Hold DATA out high and check DATA in is low.

03.  Hold DATA out low and check DATA in is high again.

04.  Hold CLK out high and check CLK in is low.

05.  Hold CLK out low and check CLK in is high again.

06.  Hold ATN out high and check CLK in is low.

07.  Hold ATN out low and check CLK in is high again.

The serial port shares much of the circuitry with the cassette, so any problems with this test strongly indicate an issue with the CPU ports or the 7406 inverter.

User Port Test

The user port on the Plus/4 contains two interfaces, the 6529 single port interface and the 6551 ACIA RS232 interface, which are only normally present on the Plus/4. This test exercises both to determine correct operation, starting with the 6529 port.

After setting all port bits high (inactive), the port is read over a period of time to ensure the value is stable. This is a best endeavour to ensure the port is present on the machine being tested, as the data lines usually float with random values if not. The test will say ‘SKIP’ if it can’t be found. If you know the port to be present, this should be read as a fail.

The individual data lines of the port are activated in sequence to ensure they pull the corresponding looped back data line low (see Figure 4) if not, the test will fail. In this instance, the status byte will contain the hexadecimal representation of the failed port bits.

ACIA Port test

The ACIA is rather more complex to test as communication is interrupt driven. First an interrupt handler is set up in the low memory error to catch the communication related interrupts and then the port is configured for 8-bit words, 1 stop bit, 2400 baud. If this value cannot be read back from the control register, the ACIA port is assumed not to be present and skipped. If any of the following steps fail, the step will be indicated in the status byte.

01.  RTS and DTR are cleared. DSR is checked to see if it is set.

02.  DCD is checked to see if it is set.

03.  Interrupts are enabled and DTR is set ready. After a short delay, check that an interrupt has occurred and that DCD has been cleared.

04.  RTS is set ready. After a short delay, check that an interrupt has occurred and that DSR has been cleared.

Now a sequence of 192 test bytes is set up and transmitted using the ACIA. All the communication is interrupt based, interrupts being generated when the receive register (all 1 byte of it) is full and when the send register is empty. The location for the received message is set up to be about ¾ of the way down the screen, so if the message is received correctly, you should see something like Screenshot 9.

Screenshot 9 - RS232 Test

The test waits approximately 2.5 seconds for the message to be received before checking the following conditions have been met.

05.  Check that ‘bytes to send’ is now zero.

06.  Check that ‘bytes received’ is now 192.

07.  Check no overflow errors occurred.

08.  Check no framing errors occurred.

09.  Check no parity errors occurred.

10.  Check the contents of the receive buffer match the send buffer

Interrupt & 2X Clock Tests

The interrupt tests checks that the interrupt sources on the TED chip are all functioning correctly. The TED has 4 usable interrupt sources; 3 timers and the raster interrupt. These are initialised to a specific pre-condition and then allowed to run for approximately half a second (525353 cycles) before a count is made of the number of interrupts that occurred. If this number falls outside of the boundaries shown below, the TED may be at fault.

A number of factors can affect this number such as running the Diag264 from a cartridge or kernal ROM (the latter bypasses the normal interrupt vectors, so is slightly quicker,) the PAL or NTSC television standard (different number of lines to render,) the kernal version, and the presence of an ACIA on the system (causes more interrupts). So if you see a value which falls just outside of the boundary conditions, I would be interested in knowing about it.

The test is performed twice, the first time with the TED forced into single clock mode and the second time with the screen blanked, thus running at twice the speed. The interrupt sources and the boundaries currently defined for both single and double clock operation are seen in Table 3.

Table 3 - Interrupt Sources and Boundaries

 

Single Clock

Double Clock

Interrupt Source

Lower Bound

Upper Bound

Lower Bound

Upper Bound

Timer 1 with a reload value of $2000

$53

$57

$25

$27

Timer 2, initialised with $0100

$0B

$0C

$05

$06

Timer 3, initialised with $FF00

$0A

$0B

$04

$04

Raster Interrupts at scan line 204

$26

$2F

$11

$16

Each count will be displayed as it completes; in green if within the boundaries defined above, otherwise red. An example of the output for a successfully completed test is shown in Screenshot 4, earlier in the document.

TED Register Tests

The final sequence of tests attempts to test as many of the TED registers as can reasonably be achieved in a short space of time. Some of the registers have already been tested prior to this section, for example the screen blanking, clock doubling and timers. For most of the remaining registers it is not possible for the software to determine an ‘OK’ or ‘FAIL’ state so it relies on the observer to make that decision after comparing the results to this document.

A sequence of three screens is displayed, and the observer should be on the lookout for deviations to what is described and shown below. A musical scale is played for the duration of each screen using one of the three voices for each of the screens.

Colour Palette

This screen plays a scale on voice 1 and displays a cycling colour palette. It doesn’t really do much more than show off the TED’s colour palette.

Screenshot 10 - Colour Palette

TED Graphic Modes

The second screen has much more going on and is designed to show the available graphics modes on a single screen. You should check carefully that what is shown on the screen matches Screenshot 11 - TED Graphics Modes.The modes displayed are shown alongside the screenshot.

The top three sections show the three different text modes. Each section shows four rows of characters with tile values of 0 – 39, 64 – 103, 128 – 167 and 192 – 231 respectively. The attribute (colour) values are set to the same value.

The first, with the dark blue border is the default Hi-Res text mode. Although not seen in the static picture, the third and fourth rows will be flashing. The second, with the black background, shows multicolour mode, which is not really suited to the inbuilt character set but should nevertheless be noticeable on characters 8 – 15 and 24 – 31. The third text mode, with the yellow background, shows the rarely used extended background mode, where the first 64 characters are rendered on a different coloured background depending on the value of bits 6 and 7 of the tile value.

The bottom two sections highlight the bitmap graphics modes, Hi-Res and multicolour, with respective green and red borders. The top should show a grid of white lines and the bottom a grid of alternating vertical blue and red lines with green horizontal lines.

Screenshot 11 - TED Graphics Modes

Smooth Scroll

The final TED register test demonstrates the smooth scrolling and the 24 row, 38 column modes. The status screen is moved in a sinusoidal wave. There should be no visible artefacts on any of the borders or any shearing of the display. The white noise generator should be heard during this test.

The End

At the end of the test, the display will pause for a few seconds before looping round and continuing from the High RAM test again.