Memory Testing the H89
by Bill Wilkinson
Copyright (c) William A. Wilkinson 1984
Released to the Public Domain by William A. Wilkinson 1996 (big deal)
As most of you H89 owners know, the monitor ROM in your computer
provides a memory test that you can run when you suspect there's
a problem in RAM. An indication of a problem is when a known-
good program begins to behave strangely. By running the built-in
memory test, you can be almost certain whether or not the error
is due to bad RAM.
Why almost certain? Because not any single memory test will
catch all types of memory errors. Before going deeper into that,
let's cover why the built-in memory test will find most RAM
failures.
The built-in memory test checks for stuck or erratic bits of data
in the H89 RAM chips. Stuck bits are bits that are either logic
one or logic zero and cannot be changed. An erratic bit may be
caused by a RAM chip that intermittently changes between one an
zero.
To check for these types of failures, the memory test will write
a bit pattern to a specific RAM address and then read it back to
see if it was changed. It will do this for all possible bit
patterns. Since the H89 is an 8-bit machine, there are 256
different patterns. If the returned pattern doesn't match what
was written, the H89 displays an error message.
However, as thorough as this test is, it may not detect a RAM IC
with marginally-slow timing characteristics. This is due to the
way the Z80 CPU reads memory. Basically, the Z80 has two types
of memory read procedures: instruction fetch cycle and data read
cycle. In the instruction fetch cycle, the Z80 reads a byte from
memory that will tell the Z80 what to do next (jump to another
part of the program, perform an arithmetic operation, etc.). On
the other hand, a data read cycle takes place when the Z80 reads
a byte of data from memory and manipulates it in some way. For
example, adding it to another byte in one of the Z80 registers.
The problem occurs in the instruction fetch cycle. Besides
fetching an instruction, the Z80 uses half of the cycle to re-
fresh the dynamic RAM. The dynamic RAM must be refreshed at
least once every 2 milliseconds or the contents of memory will be
lost. That's a different type of memory problem and will not be
discussed in this article. The point is, since the Z80 must
spend half of each instruction fetch cycle performing other
chores, it doesn't have as much time to fetch an instruction byte
as it does a data byte. If one of the RAM chips at the memory
location being accessed is a little slow, the Z80 may get the
wrong bit pattern when it fetches an instruction, but get the
right one when it reads data.
The reason the built-in memory test won't catch this type of
problem is that it's strictly a data read/write test. During the
test, all instruction fetches are from the ROM, not from RAM. So
this results in the H89 passing the memory test but still
operating erratically on some programs. Whether or not a
specific program works depends on whether there are data or
instructions at the faulty memory location.
If the built-in memory test can't be used to find a slow RAM IC,
how do you go about fixing the problem? Or even verifying that
the problem is due to a slow RAM chip?
One way to check for slow memories is to run a known-good pro-
gram, note the symptoms that occur when it crashes, swap ICs, and
see if the symptoms change. If you know the location of the
function that the programs attempts to perform, you'll have an
idea what ICs to substitute first.
A more efficient method is to use a program known as a worm test.
This is a program that tests memory by relocating itself through
RAM. As it does so, the CPU prints the current address of the
program on the CRT and then fetches the instruction at that
address. If the RAM ICs are okay at that address, the CPU relocates
the test program to the next memory location, prints the
new address, and repeats the procedure. But, if one of the RAM
ICs is slow enough to return an incorrect bit pattern, the CPU
will misinterpret the instruction and behave unpredictably. However,
it's likely that the display will lock up showing the
address of faulty IC. This narrows the problem down eight ICs,
which is an improvement over having to check as much as 32.
The following program will perform a worm test by pushing an RST
7 (RESTART 7) instruction from the low end of memory on up to the
last working address. The rest of the program remains stationary
and handles the display of the current location of the RST 7
command and its relocation. Incidentally, the program is called
a worm test because, as the RST 7 instruction moves up through
memory, it leaves behind a slime trail of NOPs (NO OPERATION).
To enter the program, enter the Substitute mode after resetting
the H89. The first three bytes start at address 040061 while the
remainder of the program starts at 040200. The listing includes
mnemonics and documentation for clarity, but all you need enter
are the numbers under the Data column.
When ready to run the program, enter "Go 040204" and press the
return key. The program will take about five minutes to run on a
48K system. When the RST 7 instruction reaches the top end of
RAM, assuming that no errors exist, the program will roll into
the starting address of the ROM causing the H89 to return to the
monitor mode.
Modifications
-------------
The PCHL instruction at address 040252 causes the test to jump
over the ever-increasing trail of NOPs. To perform a more
thorough test, so all locations along the trail are tested for
each relocation of RST 7, make the following change:
Address Data
------- ----
040252 000
This change causes the program to take about an hour to test a
48K system, improving the chances of finding an intermittent
failure.
The worm test listing is written for H89s using MTR-88 or MTR-89
system ROMs. In the MTR-90, however, a ROM subroutine called TOB
has be moved from address 005343 to 015020. To make the test
work with MTR-90 systems, make the following changes to the
program listing:
Address Data
------- ----
040225 020
040226 015
040231 020
040232 015
The program source listing follows.
Address Data Mnemonic Comments
------- ---- ---------------------- --------
040061 303 UIVEC+18 JMP UP ;DO IT AGAIN.
040062 200
040063 040
040177 XXX STACK ;STACK GROWS DOWNWARD FROM HERE.
040200 321 UP POP D ;RESTORE DE.
040201 303 JMP UP.1 ;START OVER.
040202 220
040203 040
040204 363 START DI ;PREVENT INTERRUPTIONS.
040205 041 LXI H,STACK ;POINT TO NEW
040206 177 ; STACK LOCATION.
040207 040
040210 371 SPHL ;MOVE STACK POINTER.
040211 041 LXI H,TOP ;POINT TO SOURCE LOCATION
040212 254 ; OF TOP.
040213 040
040214 021 LXI D,TOP+1 ;POINT TO DESTINATION
040215 255 ; OF TOP.
040216 040
040217 345 PUSH H ;SAVE HL
040220 001 UP.1 LXI B,TOTAL ;LENGTH OF RELOCATING
040221 002 ; PORTION OF THE
040222 000 ; PROGRAM.
040223 174 DISP MOV A,H ;GET AND DISPLAY
040224 315 CALL TOB ; THE HIGH-ORDER ADDRESS
040225 343 ; OF TOP'S CURRENT
040226 005 ; LOCATION.
040227 175 MOV A,L ;GET AND DISPLAY
040230 315 CALL TOB ; THE LOW-ORDER ADDRESS
040231 343 ; OF TOP'S CURRENT
040232 005 ; LOCATION.
040233 076 MVI A,15 ;PRINT A CARRIAGE RETURN.
040234 015
040235 315 CALL WCC
040236 302
040237 003
040240 076 MVI A,12 ;PRINT A LINE FEED.
040241 012
040242 315 CALL WCC
040243 302
040244 003
Address Data Mnemonic Comments
------- ---- ---------------------- --------
040245 355 LDDR ;RELOCATE!
040246 270
040247 341 POP H ;SET UP THE HL
040250 043 INX H ; REGISTER FOR
040251 345 PUSH H ; THE NEXT LOOP.
040252 351 PCHL ;JUMP TO TOP.
040253 000 NOP
040254 377 TOP RST 7 ;THE RELOCATEE.
That's it.