Atari CPS SuperSALT Test Assembly ADC

In my last post I introduced the Atari CPS SuperSALT Test Assembly which is used as part of the SuperSALT test to verify the ports on the Atari computer. The test assembly has a number of test functions, so the first one I will look at is the Analog to Digital Convertor (ADC). 

The ADC is part number ADC0816. It has 16 channels and 8 bit resolution. You can see a data sheet here. The channels are assigned as follows:

0 – Onboard 5 volt
1 – 5 volt from SIO port
2 – 5 volt from J1 Port
3 – 5 volt from J2 Port
4 – 5 volt from J3 Port (400/800 only)
5 – 5 volt from J4 port (400/800 only)
6 – Ground from Serial Port
7 – Ground from J1 port
8 – Ground from J2 port
9 – Ground from J3 port (400/800 only)
10 – Ground from J4 port (400/800 only)
11 – Motor control line from SIO port
12 – 12 Volt line from SIO port (400/800 only)
13 – Positive half-cycle current draw (400/800/1200XL)
14 – Negative half-cycle current draw (400/800/1200XL)
15 – Onboard ground line

Which channels are tested is based on the type of machine. The XL series computers only have two joystick ports so the channels for the other two are not needed for these computers. The 400 and 800 supply 12 VDC on pin 12 of the SIO connector, but this is absent on the XLs. The current measurements are done by passing the power from the AC adaptor through the test box so the current draw can be measured. This only done on the 400 and 800 since the current measurement circuit is designed to measure the 9 VAC input voltage they use. 

The ADC is controlled with a combination of joystick ports 1 and 2 and the data signal from the SIO port. The sequence for reading the ADC is as follows:

1. Set PORTA (which controls joystick ports 1 and 2) to output
2. Write the ADC channel number to bits 0 - 3 of PORTA and set bit 7 to 0 to switch the baud rate generator to fast clock.
3. Wait approximately 1280 CPU cycles.
4. Set bit seven of SKCTL to 1 to latch the channel number and reset the ADC.
5. Wait approximately 1280 CPU cycles.
6. Set bit seven of SKTCL to 0 to start the ADC.
7. Wait approximately 2560 CPU cycles.
8. Set PORTA to input. 
9. Read the eight bit ADC value from port A.

Atari CPS SuperSALT Test Assembly

 

The CPS SuperSALT was a system used to test Atari 8-bit computers (400/800/XL) both in a factory setting and for after market repair. The system was composed of a cartridge with the test software and a special test assembly that was build into Atari 850 interface module case. The assembly is needed to completely test the Joystick and SIO ports. 

Here are pictures of two different version of the test assembly.

REV O:

REV C:

The technical reference manual for this device can be found here:

http://www.atarimania.com/documents/CPS_Supersalt_Technical_Users_Manual.pdf

That manual contains schematics that appear to be for the Rev O board since it has a power switch which is absent on Rev C.

There is also an Error Display add on board. In the schematics this is labeled "for future use", but I do have pictures of board, although there are no schematics available for it. 

Over my next few posts I will talk about how this device worked. 

Coleco Telstar Arcade Repair

The Telstar Arcade was a cartridge based video game console released by Coleco in 1977. Unlike later cartridge based systems the cartridges for this system didn't just contain program code, but instead used the MOS Technology MPS-7600-00x chip series which contained a simple CPU, code ROM and some custom hardware for generating video that may have been different in each cartridge. You can find a good article here about this chip:

http://oldvcr.blogspot.com/2022/09/confirmed-mos-76007601-pong-chip-is.html

I acquired one of these systems a long time ago but never bothered to try it out. I recently dug it out and tried powering it up. I could not find the power supply for it which is 9VDC 200ma, so instead I used an Atari 2600 power supply which if 9VDC 400ma and has the same connector and polarity. 

I connected it to a TV and when I powered it up I got no change in the display. Even if a video game system has major problems you will usually see some change in the screen. I disassembled the unit and checked the connections between the boards and everything looked ok. The next step was to check the power. 

The power from AC adapters enters the main board on pins 10 and 11 of connect J3. That is the left side of the connector in this picture.

With the power switch off I can see the 9VDC at this connector and it also makes it to the switch. When I turned the switch on the input power dropped so something was pulling it down. Before I continued troubleshooting I traced out the circuit for the power regulator on the main board:

This is a simple voltage regulator based on a Zener diode, CR3. Here is a picture of that part of the board. The leg on the transistor is lifted because I took this picture when I was testing something. 

With the circuit mapped out I check the components with an ohm meter but nothing looked obviously bad. I tried lifting the emitter leg of the transistor to see if that helped but I was still not getting anything out of it. I ordered some replacement transistors and replaced the one on the board with one of those. When I powered it up I still wasn't getting any output from the transistor, and then I started seeing smoke from the component side of the board. Took me a bit to find the burning component, but it turned out to be the CR3 Zener diode and this also burned out the new transistor. 

Now I had a problem. The diode was burned so bad that I could not read the whole part number, all I could see was 1N75 which told me it was a Zener diode but the last two digits tell you it's operating voltage. I also could not find schematics for the system, so I have no way of knowing what voltage the Zener is. 

I happened to have some surplus 1N75 series diodes so I put in a 1N7532 which is a 5.6v Zener and replaced the transistor one more time. With those changes I finally got a 4.4V output from the transistor. This is as far as I have taken the troubleshooting for now. I would like to figure out what the proper diode is. If you are reading this and have access to one of these I need to either know the full part numbers on CR3, or need a measurement of the voltage between the two points shown below.

1541 Drive Repair - Part 2

In my last post I began the process of repairing a Commodore 1541 disk drive. In that post I got the power on self test to pass but the drive would have some other problems that needed to be resolved. 

To continue the troubleshooting process I decided to write a test program using my IF65 in-circuit emulator. There are other ways I could have tested the drive, but I choose this options for two reason. First, I used the IF65 to do this sort of testing at my first electronics job, so there was some nostalgia for doing it this way. Second, this would give me a tool I could use to quickly troubleshoot other drives. 

The IF65 allows the 6502 code to communicate with a terminal so this made it easy to build a interactive test program. Here is a look at the menu for the test program. 

The first test was pretty simple, by pressing 'O' of 'F' on the terminal keyboard it would turn the activity LED on and off with a simple write to one of the 6522 VIAs. The motor test worked the same way to turn the spindle motor on and off. The write protect test continuously displayed the state of the write protect sensor. The last of the first batch of tests I wrote was the head test which allowed me to move the read/write head in and out. 

On the unit under test all of these tests passed except the head test, it was unable to move the head in either direction. I carefully checked the signals in the stepper drive circuit and everything looked ok, so I tried turning the motor manually and it would not move. I finally used a pair of pliers to grab the motor shaft and I able to break it loose. 

Next thing I had to deal with was a minor mechanical problem. The spring for the drive door latch was missing. I didn't have anything that was an exact fit, but I found a spring that was close and cut it shorter to fit. Initially the spring kept popping out so I had the bend the ends in a little to make a tighter fit on the pegs on either end. 

With the basic functions of the drive tested and repaired, next thing was to check the speed. The drive is designed with a very clever way to do this without needing any test software. If you look at the bottom of the drive mechanism you will see this checkboard pattern on the bottom of the spindle motor. When viewed under fluorescent lights it can be used to adjust the drive speed. Fluorescent lights strobe at whatever the AC line frequency is, so there are two tracks on that pattern, one for 60hz as found in the US and the other for 50hz found in other countries. When the speed is correct the marks on the appropriate track will appear to remain stationary. If it's running to fast or slow the pattern will slowly drift in one direction of the other. On the drive PCB there is a potentiometer that is used to adjust the speed. You turn the potentiometer until the pattern stops moving. 

With the speed adjusted I was able to boot a diagnostic disk. I used that disk to double check the speed, and finally do the head alignment. 

Commodore 1541 Drive Repair Part 1

I recently attended a repair workshop at the System Source Computer Museum in Hunt Valley Maryland. This was my first time attending one of these events so I didn't bring anything with me to work on, I figured I might find someone else that needed help, which is exactly what happened. I met someone who had brought a bunch of Commodore 1541 drives and was hoping to find someone who could help repair them. Even though I had never worked on  a 1541 drive I knew they were 6502 based to I thought I would take a crack at it. 

Most of the drives would not even get through their power on self test, indicated by the activity LED flashing. One started to emit a burning smell when we powered it up, so we put that one aside. Another would not power up at all. We swapped chips on a few but didn't make any progress that way. There was one that powered up properly but as we were trying to do further testing with it connected to a C64, the computer failed. So, we didn't make much progress there but I took one of the drives home to work on.

Before I could dig into the drive I needed some documentation. I found this site which has a good collection of schematics for various versions of the drive:

http://www.zimmers.net/anonftp/pub/cbm/schematics/drives/new/1541/index.html

I also found a couple good books on Archive.org:

Commodore 1541 Troubleshooting and Repair Guide

The Anatomy of the 1541 Disk Drive

The first thing I noticed was the C21 tantalum capacitor had burned up. This cap is between the +12V supply and ground so was probably acting as a filter cap. The +12V supply still looked good with the cap burned out so I continued to work on the drive until I was able to get a replacement. 

The next step was to troubleshoot the power on self test problem. In a previous post I talked about the IF65 in-circuit emulator that I used at a previous job. Troubleshooting this sort of failure was a perfect application for this device. I started by connecting it to a known good drive to make sure everything worked ok. 

With the IF65 setup verified I re-connected it to the unit under test. I started by testing the ROM on the bad unit, and that seemed to be ok. Next I ran a RAM test and immediately saw a failure across the whole RAM address range. The errors were pretty random so it didn't look like just a bad data or address line. Next I turned to the IF65's address trap functionality and checked out the chip enable lines which looked good. The addresses lines also looked good, but I was getting very odd signals on the data bus. 

The RAM chip on my good drive was soldered in, so swapping was not an option, so I removed all the other chips on the bad unit that were connected to the data bus, but the RAM test still failed. I started to look through my surplus chips to find an equivalent RAM chip and quickly noticed the problem. The chip in the RAM socket was actually a ROM from another drive and not a RAM chip! Not sure if this happened when we were swapping chips at the repair day or happened during a previous repair attempt. I did find an equivalent RAM chip in my collection, put that one in the drive and it passed the power on self test. 

This was not the extent of the problems with this drive, I will cover more of the repair process in my next post.

Infotron Systems IF-65

 

Back in the late 80's and early 90's I worked for Infotron Systems (later Gandalf Technologies) which manufactured data communications equipment. A lot of Infotron’s equipment was based on the 6502 microprocessor, so much so that they designed and manufactured their own 6502 in circuit emulator (ICE) the IF65. The IF65 was a great tool for both developing embedded 6502 software and for troubleshooting 6502 hardware. The IF65 was mainly used in house, but I know of at least one other company that Infotron sold them to. Fortunately, I ran across a working IF65 at a flea market a long time ago.


The built in monitor software is accessed through a serial terminal. The monitor provides functions to read/write memory, test RAM, assemble and disassemble code, and access the EPROM programmer.

I worked in the repair department, initially doing manufacturing repair and then eventually customer return repairs. We used the IF65 to run special test programs and as a general troubleshooting tool for 6502 based boards. This version of the IF65 has 64K of static RAM that can be configured to overlay the product's memory in 4K blocks. You would normally set this up to overlay the ROM portion of the product's memory map. Code could then be loaded by reading it from an EPROM using the EPROM programmers, downloaded from a host computer (we used VAX mainframes at Infotron), or even entered using a built in line assembler.

A really useful feature for troubleshooting was the address trap function. If, for example, you wanted to troubleshoot the address decoding hardware you would set the trap address to the address you were trying to test and then set the switches for read, write, and/or opcode access. Now any time that address is accessed you would get a sync pulse output through the connector on the lower right side. You would hook this signal to one channel of an oscilloscope and then use the other channel to probe the circuit and you would see what a signal state was as the moment the memory access was happening. 

Another feature that comes in really handy for running test software is the ability of the 6502 code to access the serial ports on the IF65. This allows the test software to interact with the user even if the unit under test is totally non-functional. This functionality, when enabled, is accessed with the 6502 BRK instruction. The byte after the BRK command contains the command you want to execute and the Accumulator is used to pass data. For example, to print a character you would do this:

LDA #$30

BRK

.BYTE #$11

HLL65F - INDEN/UNDEN - Mystery Solved

In my previous post I talked about some mysterious code in the macro definitions for the Atari Crystal Castles arcade game source code. Someone responded to my post about this and pointed me to Franz Lanzinger who was one of the original authors of Crystal Castles who in turn pointed me to Dave Shepperd who wrote that assembler. He confirmed that this was a custom assembler developed for Atari:

"Yes, I wrote both versions of mac65. We called it macxx way back when (because it would assemble for the 6502, 65C02, 6800, 68000, and others). The first version was written in PDP11 assembly for RT11 and it used linkm as a linker, the other tool I wrote. We used those tools for a year or so after getting the VAXen. The second and current version was written in C (first DEC C for the VAX, then subsequently others and finally gcc) and compiled on various O/S. I've only been maintaining it on Linux, but it probably will still build on many others, especially those Linux like. Not sure if it would work anymore on 16 bit machines. This version uses another of my tools also written in C: LLF (Link+Locate+Format) as the linker."

He also provided an explanation of how he believes the two mystery lines worked:

.LIST SRC(...S1,1)

The .LIST pseudo op controls what get's output to the listing file. The SRC flag says to turn on the output of the assembler source code and the values in parenthesis after it control the details of the output. The first parameter tells the assembler which columns to start outputting the source on. The second value, if present and not zero, tells the assembler to wait until the next line before changing the output column instead of doing it on the current line.

.PRINT ..NST$(37,1,16,1,38'->')

The .PRINT pseudo op prints text to the listing file. The expression after .PRINT is evaluated and the result it what will be printed. Again, we have a list of parameters to control this output. This is a pretty esoteric command so I am not sure if I would have every figured this out:

37 = Column to start the print on
1 = How many characters of the value to print out 
16 = The radix of the value, in this case it will be printed as hexadecimal
1 = If present and non-zero, print the leading zeros
38=This parameters is usually used to indicate that the sign should be output, but since it has a text string after it it functions differently. In this case the text "->" will be output starting at column 38.

Let's look at the end result of all of this. Here is a chunk of source code using two nested IF macros:

IFEQ
INX
IFEQ
LDX 40
ENDIF
DEY
ENDIF

The listing output would end up looking something like this:

                                     0->

           F004  D0 FE                      BNE .

   10      F006  E8                         INX

                                     1->

           F007  D0 FE                         BNE .

   12      F009  A6 28                         LDX 40

           F008  02                            .BYTE ...S0

                                     1<-

   14      F00B  88                         DEY

           F005  06                         .BYTE ...S0

                                     0<-