EDIT: Do not use version 0.1.7, it has a bug on 68030 CPUs. See below for newer versions of YAART RAM tester.

Hello,

it always bothered me that RAM test software for the Atari was mostly very simplistic in their test algorithms. There are much better ways to find (especially subtle) faults, which are for example used by Memtest86 on the PC. So I ported a selection of these tests to Atari. I humbly named it YAART, Yet Another Atari RAM Test, but I think it provides better test coverage that the usual RAM test software for Atari systems.

You will find YAART beta version v.0.1.7 attached to this post.

YAART comes in two flavors:

YAART.TOS only runs on ST-type machines (ST, STE, MegaST, MegaSTE), does direct hardware access and can thus test almost all RAM, including screen memory and -- to a lesser extent -- also memory already in use by TOS. However, I still recommend a clean boot from a floppy disk without drivers or AUTO-start programs.

YAARTTT.TOS should run on any Atari machine. It can test ST-RAM and Alternate RAM/TT-RAM, but only memory that is currently unused. So a clean boot is even more important here to maximize coverage.

After start, YAART/YAARTTT will repeatedly test memory and print the current iteration, the number of errors and the address of an error found. Press and hold ALT to terminate the program.

Also note that it's a beta version that may still suffer from bugs.

You do not have the required permissions to view the files attached to this post.

Last edited by czietz on Fri Dec 09, 2016 6:06 pm, edited 1 time in total.

New beta version 0.2.0 of YAART. Most notable new feature: A (semi-)hidden manual address entry (expert) mode in YAARTTT.TOS that allows you to test memory that is not registered with GEMDOS, e.g. on an add-on video card. See the included documentation for more info.

You do not have the required permissions to view the files attached to this post.

Last edited by czietz on Fri Dec 09, 2016 8:01 pm, edited 2 times in total.

czietz wrote:New beta version 0.2.0 of YAART. Most notable new feature: A (semi-)hidden manual address entry (expert) mode in YAARTTT.TOS that allows you to test memory that is not registered with GEMDOS, e.g. on an add-on video card. See the included documentation for more info.

Hi.I've a problem with a 1040 STF.The 1Mb is composed of 32 chip.It is possible to scan only the first 512Kb, and after the last 512kb ?The banks are named like this in my computer :U3 U4 U5 U6U10 U11U12 U13U18 U19U20 U21U22 U23U24 U25U27 U28U29 U30U34 U35 U36 U37U39 U40U41 U42U44 U45 U46 U47

There are no logic with the numbers written on the motherboard. The blue Chip are for the first 512Kb, and the red, the second bank of 512kb.Is a way to test each chip (i think not), or a software to do ?Is my stf could boot with a missed chip on the motherboard ?

To fix my problem, i bought on ebay 32 capacitors of 220nF to replace all next the chips. (waiting to receive it).I've a 520STF working all the tests, i can remove a memory chip, solder an header, desolder one by one, each chip, and testing on the 520stf to find if one is dead... So if i'm not luncky, i can dessolder 32 chip to find the last dead :/

Or, better way, is the 1040stf should boot, if i remove R71 / R72 / R73 and let all the chip on the motherboard (like this i think my 1040 become a 520) and test only fist 512kb ?If yes, if the 1040 boot with 512k, and test are ok, if i resolder R71/R72 / R73 and dessolder R62 / R63 / R64 will my atari boot could boot with 512kb, on the second bank ???

If i ask some technical question like this, it's because it's not an STE with a SIMM module :/ and evitate to desolder 32 chips who had 16 pads ... so 512 pins :/ with the capacitor... 32 * 2 (64 pins too), the resistances 6 * 2 (12 too). In fact i have to desolder 512 + 64 + 12 = 588 pads !!!

There will definitely be no GEM app! Dal is totally right: the amount of memory used by YAART needs to be kept as small as possible.Also I don't see the point: what would be the benefit of a GUI in this case?

As you have already pointed out, it's always the same bit that is affected, more specifically the most significant bit, i.e. data bit 15 (D15).

The ST (usually) has an individual RAM chip for each bit of data, so the one for D15 would be my first suspect. In the schematic you posted this is U45. Note, however, that there were many revisions of the ST mainboard, so maybe this chip has another number on your board. The next suspects indeed would be the latches U22 and U26, as they are also needed for D15.

czietz wrote:As you have already pointed out, it's always the same bit that is affected, more specifically the most significant bit, i.e. data bit 15 (D15).

The ST (usually) has an individual RAM chip for each bit of data, so the one for D15 would be my first suspect. In the schematic you posted this is U45. Note, however, that there were many revisions of the ST mainboard, so maybe this chip has another number on your board. The next suspects indeed would be the latches U22 and U26, as they are also needed for D15.

Thank you very much for the quick response.I will check the U45 with oscilloscope the U45 RAM chip and the U22 and U26 to see if there is any unexpected behavior.

Apologies for not being able to update the status since my last message.I've replaced the U45 ram IC, however the problem remains, so I will try to replace the U22 74LS373 as it's the only latch I have.Hope this time will fix it.

Cheers!

[EDIT 28/02/18: FINALLY FIXED!!]

Checked both 74LS373 and 74LS244, but according to my motherboard (rev. 070789) those were marked as U57 and U60, so I assumed that the IC I replaced did not correspond to databit 15 and find out other schematics for STFM.

This time I found those: http://atari-schematics.angelfire.com/1040stf1.zip which do correspond to C70787 (1040 STFM)After reviewing page 5 where the memory is detailed I looked for the corresponding IC for D15 and those were U5 (which my Atari lacks being just 512K) or U3...

So, after replacing U3 the results were as expected: tests passed!!

Big thanks to all for helping diagnosing this failure and keep the good work with this excelent testing tool.

I have just piggy-back upgraded a 520ST using memory chips I've carelessly hot-aired out from other ST machines, and predictably some of the chips have faults. During the hunt to find out which, I realized it would be nice to be able to force a RAM test program like this to test a specific memory size/range even though TOS hasn't detected it