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.