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<-