exxos's Atari, Amiga & retro forum

Hi guys, a few days ago I had a friend of mine come to my house and he left me an Atari 1040 Stf because, according to him, it doesn't work well, but not always.

Often, at a certain point after using it with Cubase, the computer freezes, showing random pixels on the screen (see photo).

With all the other programs I have, however, it works well.

At first I thought about the TOS ROMs, but I replaced them with two that were definitely working and it didn't solve the problem.

The Cubase program (version 2.01) works well with the other Atari STs I own, but not with the Atari Stf that my friend left me; so it's out of the question that the program is the culprit.

I thought that the Cubase program is one of the few programs that uses a large part of the 1040's memory, while almost all the other programs I have use half of it; so my attention immediately went to RAM problems.

I have an Exxos diagnostic cartridge but unfortunately it doesn't work anymore, so, doing a search on the internet, I found a nice program that allows you to scan the RAM of the Atari ST; the program is called YAART.TOS by czietz.

So I launched the program directly from the floppy without any other driver and/or program in memory and it found a lot of RAM errors. So many that I'm a bit disconcerted.

What would be the next step I could take?

On that Atari I have already changed all the capacitors and replaced the floppy drive, so I'm pretty sure that it is indeed a RAM problem, also because YAART.TOS seems to speak clearly to me.

Could be an aliasing problem -- difficult to tell without seeing one of the early YAART errors, but would fit your symptoms.

Eg. Let's say every data write in the bottom 512k also happens to be written to the top 512k too. If the screen's at 0x0F8000 -- right at the top of the second bank -- the writes right at he top of the first bank might end up there too.

So if you don't ever get close to the top of the first 512k, you won't see screen corruption.

Things that could cause this that I can immediately see are an address decoding problem (one address line stuck low, forexample) , or an upper/lower RAS/CAS strobe is shorted, perhaps?

So the first thing I'd do is to remove, clean and reseat the MMU. It not only could be the source of either of those problems, but it's also notorious for having bad contacts.

See this thread. It's so frequently an issue we've built tools for it! viewtopic.php?f=17&t=1484

BW

I can't remember if YAART does a full walk test of the RAM.

If it does then it should spot addressing errors and aliasing with a bad address line would generate thousands of errors as soon as it touched the high RAM.

If it's a relatively few (hundreds) of errors and they all have a certain bit in error then it's more likely to be a single RAM chip.

The image of the YAART run showed bit 16 in the upper bank being set high when it was supposed to be zero. (Top nibble has both bit one and bit four set when only bit one should be)

So, I went over the MMU, GLUE and SHIFT solder joints with the soldering iron on the back of the motherboard, I also moved each socket pin a little bit on each of them, cleaning each contact carefully.
No improvement.

The thing is, my problem is very similar to this:

viewtopic.php?f=23&t=1228

my card version is exactly like that too, and out of curiosity I tried that game from that thread (Metrocross) and my computer also has pixels below:
I found out that depending on how my Atari wakes up, it can see 512K, or 1024K (I see this via SYSINFO.PRG), and that if it wakes up seeing only 512K and I scan the RAM, it gives me a bunch of errors.

While if my computer wakes up with 1024K, then the program does not give any error but I notice some pixels in the lower part of the screen, corresponding to the scan status: I also attach a screenshot of gembench: These are the first errors if the Atari turns on seeing only 512K: The only thing I have seen now, is that the user who had this problem in that thread, also reviewed the 4 buffer chips, which I will have to do tomorrow.
It seems that it is a problem of selecting the second RAM bank, which sometimes works and other times does not and when it works there is something that makes those pixels appear (which are not seen when my Atari only sees 512K).

If anyone has any other advice I am here ready to listen.

Roberto wrote: 14 Nov 2024 22:48 It seems that it is a problem of selecting the second RAM bank, which sometimes works and other times does not and when it works there is something that makes those pixels appear (which are not seen when my Atari only sees 512K).

It does sound like a failing chip (or a few!), then.

Presumably if it fails during the initial RAM scan, the OS allocates only 512k and your screen (which is always very near the end of memory) is fine. But when 1M is allocated your screen moves into the failing bank.

I suspect with a bit of judicious reading of the schematic and a look at the failing bits in YAARTT you'll be able to work out which chip to replace. The two errors we can see in your pictures point to different chips, though. Could be more than one.

You can fit a USB serial adapter to the ST's serial port and log all the errors YAART generates, BTW. Easier to see patterns.

...or just fit a 4M upgrade board and disable the onboard RAM entirely.

BW

Badwolf wrote: 15 Nov 2024 12:41
You can fit a USB serial adapter to the ST's serial port and log all the errors YAART generates, BTW. Easier to see patterns.

I took a serial cable and connected it to a terminal where it shows me these two RAM test extracts (the test was stopped): Now the computer always sees 1024 K when turned on (before it could see 512K or 1024K randomly), so maybe now it's easier to identify the cause of the problem.

I know that the memory of the Atari ST is organized in 16-bit words and that the addresses with even numbers refer to the other 8 bits while the odd ones refer to the 8 low bits of the word.

I also know that the 1024K are divided into 2 benches and that the lower one goes from 0x000000 to 0x07FFFF while the upper one goes from 0x080000 to 0xFFFFFF.

Based on what I read in the two log files, is the fault in the lower bench? How can I locate the incriminated chip?

For this motherboard model there is no exactly corresponding scheme but the closest I found is this:
I also used another program to test the RAM (XTRA_RAM), after about an hour of testing it gives me this (the test has been stopped):

Confusingly YAARTT consistently reports bit 8 as failing stuck high whereas your other program (which I'd not seen before and has a nice interface) suggests bit 2.

From the pattern of the dots on the screen, bit 2 does look more likely than bit 8 to me, but very difficult to tell.

If you were following that schematic you'd be looking at U35 or U37 for bit 2 and U44 or U46 for bit 8. I don't know if the banks are stacked (like you alluded to) or interleaved.

But you also say that schematic might not be exactly the right one, so the best course of action would be to buzz out the chips to the appropriate pin on the shifter.

BW

Badwolf wrote: 21 Nov 2024 13:59
If you were following that schematic you'd be looking at U35 or U37 for bit 2 and U44 or U46 for bit 8. I don't know if the banks are stacked (like you alluded to) or interleaved.

I keep having random problems at startup: that is, it can see 512K or 1024K, it can give problems or not. It could also not give any problems to the RAM! But one thing is for sure: looking at the various RAM chips I discovered that two of them have already been replaced (see photo), and exactly U35 and U47 (you can see not only from the soldering but also from the different label). I did nothing but go over the soldering but without any significant change. I remind you that GLUE, MMU and SHIFTER are in place (already replaced) and welds reworked in the hooves.

I have an oscilloscope; is it possible to identify some errors in the RAM using this tool?
I would like to replace some RAM chips but the problem is that I do not have chips of this type. Where can I find them? Does anyone have some to sell me?
I guess it is not possible to insert a socket...

Badwolf wrote: 21 Nov 2024 13:59 Confusingly YAARTT consistently reports bit 8 as failing stuck high whereas your other program (which I'd not seen before and has a nice interface) suggests bit 2.

From the pattern of the dots on the screen, bit 2 does look more likely than bit 8 to me, but very difficult to tell.

If you were following that schematic you'd be looking at U35 or U37 for bit 2 and U44 or U46 for bit 8. I don't know if the banks are stacked (like you alluded to) or interleaved.

But you also say that schematic might not be exactly the right one, so the best course of action would be to buzz out the chips to the appropriate pin on the shifter.

BW

Hi Badwolf, I found the time to follow your advice and somehow understood the pinout of the RAM and SHIFTER chips.
I understood that:

- the d0 (pin 3, which corresponds to BIT 0 on the SHIFTER), must go to the two RAM chips that manage bit 0, namely U47 and U45
- the d1 (pin 4, which corresponds to BIT 1 on the SHIFTER), must go to the two RAM chips that manage bit 1, namely U42 and U40.

I did a test with the multimeter and it's actually like you said. So: U35 or U37 for bit 2 and U44 or U46 for bit 8.
The fact is that I can have some random problems, as you can see from my photos above. For example also an error at Bit 15, but only sometimes.
This thing of this randomness disconcerts me and I don't know if I actually change those 4 RAM chips. As long as I can find them because they seem untraceable.

As its random, have you checked the pull up resistors on the data and address lines?

I once had a SIL resistor on a Mega ST that had a crack in it, gave me weird issues. Might be worth doing the mandatory fixes, at least the pull ups.