exxos blog - random goings on

[exxos]

We don't know what particular row and column xAE6 in the lower bank corresponds to, but that particular data line will be used for all other lower addresses too, so it's not going to be on the data pin side.

But that was what I was trying to diagnose and prove somehow. Only the data bits have spikes on. All the other lines including power all seem relatively fine. So something has killed the chip, it has to be related to those spikes.

Is also possible that maybe the failure was down to a unseen spike on RAS0 for example.. But would that have killed more than just one chip..

Of course my last RAM boards only address the data bit noise. I did not see any reason of putting suppressors on any other pins.. But in hindsight maybe I should have done even though they are seemingly okay in my machine..

I'm still struggling to get any other boards to fail.. (I still have about nine others to test yet though) And yet I bet if I sent out this one board that has been on 20+ hours.. It would probably fail straightaway in someone else's machine. As that has seemingly happened 4 times now.

The one board I had which did fail, I documented it was on for 11 hours I think.. And it died when I turned it on in the morning. So perhaps the spikes only happen on power up. But currently I did look into that briefly and did not see anything out of the ordinary. But I did not check the address lines or other control lines then. I may do that later.

Looks like that particular row and column is returning high no matter what you write to it. The little charge bucket in that part of the chip is zonko, I reckon.

Yep, that's why I was diagnosing RAS/CAS earlier. The failed bits may only happen if RAS is low or something. Again I was trying to figure out is possible to work out what actual addresses in ram correlate to which chip and address exactly. It seems to be going down the rabbit hole more than anything. You would really need a huge logic analyser on the entire lot to figure it all out.

Overall point being what could cause almost alternate banks to fail in a chip to start with.. That is what I've been trying to work out the past few days.

[Badwolf]

But that was what I was trying to diagnose and prove somehow. Only the data bits have spikes on. All the other lines including power all seem relatively fine. So something has killed the chip, it has to be related to those spikes.

Well the chances are if you've blown a particular row/column in the chip it will be because of zapping the data line.

RAS+MADD and then CAS+MADD open up the little capacitor and then you 'fill the bucket'. What if you fill the bucket with a fire hose? You probably lose the bucket.

Yep, thats why I was diagnosing RAS/CAS earlier. The failed bits may only happen if RAS is low or something.

RAS shouldn't be low during data access. That's the first half of the cycle, but IKWYM.

Again I was trying to figure out is possible to work out what actual addresses in ram correlate to which chip and address exactly. It seems to be going down the rabbit hole more than anything. You would really need a huge logic analyser on the entire lot to figure it all out.

I suspect the data lines are pretty obvious 8 chips, 4 bits per chip. 32 bits. probably one of the end chips will be 0-3 and at the other end that chip will be 28-31.

Mapping bus addresses to rows and columns? Harder.

Overall point being what could cause almost alternate banks to fail in a chip to start with.. That is what I've been trying to work out the past few days.

When you say alternate banks, what do you mean?

Also -- sorry, you probably missed the edit of my last post -- was DFB1 on or off when reduced errors were seen?

BW

[exxos]

@Badwolf


If you have chances some point can you tried taking samples of the power rail starting up.. As I see this...

IMG_0239.JPG (281.43 KiB) Viewed 835 times

I thought it was interference because the scope is on top of the power supply.. But putting it on the floor did not change anything.

I do have a transient suppressor on the top power pins of the RAM board which so almost 0 spiking.. But this was taken towards the bottom left of the board on VCC.. the same seems to be present on RAS/CAS etc as well.

So could do with a second diagnosis on this in case my scope is lying to me again...

But note the timebase as if you look at the ramp up over a second it looks perfect...

[Badwolf]

@Badwolf


If you have chances some point can you tried taking samples of the power rail starting up.. As I see this...

OK, will try to put some time aside & get the scope out again tonight.

BW

[exxos]

When you say alternate banks, what do you mean?

I'm just referring to the pattern like in this post...

viewtopic.php?p=93749#p93749

Where it goes.. Good bad good bad good bad.... This is also confirmed with all the RAM test side been doing.. It looks like only part of the chip hosting bit 11 as blown...

Also -- sorry, you probably missed the edit of my last post -- was DFB1 on or off when reduced errors were seen?

Originally I was using the Atari diagnostic cartridge. With the DFB1 Plugged in I was only getting 1-3 errors. Without it I would get a whole page full of errors. I don't think the Atari cartridge works properly somehow.

That is what myself and @dml Were trying to diagnose if the problem was relating to the CPU bus or Videl databus.

I guess I could try again some of the programs with and without your booster. But with it scrolling up hundreds of various I think it would be difficult to figure out if there is any difference having it fitted or not.


EDIT:

Just tried with and without the booster with dmls test program. Stalls in exactly the same place and the graphic is exactly the same.

So I think for whatever reason, the Atari diagnostic ram test is seriously FUBAR somehow. It is probably one of those things it has to be seen to be believed...

[exxos]

@Badwolf

With your booster in and the Atari diagnostic cartridge...



Seriously you could not make this sh*t up

IMG_0242.JPG (253.43 KiB) Viewed 821 times

Will test without the booster next....

IMG_0243.JPG (193.31 KiB) Viewed 817 times

The diagnostic cartridge does not find hundreds of errors.. And when you're booster is in, it goes even more bonkers

[ijor]

Without specific knowledge of VIDEL (which @ijor may have?) ...

I'm afraid I don't have any internal information for VIDEL. I was meaning to decap VIDEL, COMBEL and SDMA, even when I'm not an expert on the Falcon at all. But a few months ago somebody at atari-forum claimed he was going to do it and even purchased a whole Falcon chipset from Best. I think we didn't hear anything from him since then.

So may be I should consider again the idea of a Falcon decap project ... But I don't want to hijack the thread ...

[Badwolf]

When you say alternate banks, what do you mean?

I'm just referring to the pattern like in this post...
viewtopic.php?p=93749#p93749
Where it goes.. Good bad good bad good bad.... This is also confirmed with all the RAM test side been doing.. It looks like only part of the chip hosting bit 11 as blown...

Well two chips host bit 11, so that's not really that surprising.

Also -- sorry, you probably missed the edit of my last post -- was DFB1 on or off when reduced errors were seen?

Originally I was using the Atari diagnostic cartridge. With the DFB1 Plugged in I was only getting 1-3 errors. Without it I would get a whole page full of errors. I don't think the Atari cartridge works properly somehow.

What I meant was: was it plugged in but disabled (right hand jumper set) or plugged in and running?

I was just wondering which CPU was actually reading this data.

BW

[exxos]

What I meant was: was it plugged in but disabled (right hand jumper set) or plugged in and running?

I was just wondering which CPU was actually reading this data.

The OPTION2 jumper is set.. and the jumper I think you sent it with... Did not know you could disable it... I do now..


These tests I just did was with the OPTION2 jumper on.. I guess I could try without it as well.. See if things look any different

viewtopic.php?p=93781#p93781

[Badwolf]

I'm afraid I don't have any internal information for VIDEL.

Cheers, Ijor. I've seen someone talking about the interleaved nature of the Falcon's memory & thought it may have been you.

I suspect it would only need an afternoon with a scope and some assembly to infer the details of the address bus to MADD mulitplex, but if someone knew off the top of their head... no need.

BW