exxos blog - random goings on

[dml]

One more tip - ramscan can only safely scan STRam from the end of its own storage towards ramtop. So if you want max coverage, you'll need to run it with minimum stuff loaded from AUTO and disable desk ACCs etc.

[exxos]

Yeah if you use the keys 0-9/a-f it will hop to each MB (16 keys, 16MB).

The first one (0) will take you to the initial TOS state which looks like garbage. The last two (e,f) will take you to the HW regs and cartridge area.

OK.. using Using rampan0..

0 = garbage
1 = white
2 = white
3 = white
4 = white
5 = white
6 = white
7 = white
8 = white
9 = white
a = white
b = white
c = white
d = white
e = corrupted white and 2 black blocks
f = corrupted white and 2 black blocks

So I would assume on 1MB boundaries that the test is actually working.

[exxos]

Actually ramscan is reporting bit #12 as faulty 0x1000 on 16bit transfers, at least in that area of RAM. It doesn't complete all other tests if it runs into lots of data faults so there could be more after that. But anyway its bit 12, not 11 (bit 12 counting from 0, so the 13th actual bit). In case you get your logic probes out and attach on the wrong pin

*confused*

Counting from right to left, counting from zero, its bit 11 ?!

IMG_0228.JPG (334.27 KiB) Viewed 1072 times

[dml]

Counting from right to left, counting from zero, its bit 11 ?!

0000:0000:0000:0000 : 0001:0000:0000:0000

Counting from right to left, thats 3x hex 0's, which uses up 3x4 or 12 bits. So the 13th bit from the right (bit 12, counting from 0) is the first set bit, which seems to be the damaged bit.

[dml]

c = white
d = white
e = corrupted white and 2 black blocks
f = corrupted white and 2 black blocks

So I would assume on 1MB boundaries that the test is actually working.

It looks like 1MB boundaries are ok, from what you've described - but only near the boundaries. The whole MB doesn't fit on the screen. The keys just take you to the start of each MB, you need to use the right arrowkey to step + 256k at a time, 4 times in a row, to see the rest of that MB.

The screen only shows 640x480 = 307,200 bytes at a time (or less than 1/3rd of that MB)

[exxos]

Counting from right to left, counting from zero, its bit 11 ?!

0000:0000:0000:0000 : 0001:0000:0000:0000

Counting from right to left, thats 3x hex 0's, which uses up 3x4 or 12 bits. So the 13th bit from the right (bit 12, counting from 0) is the first set bit, which seems to be the damaged bit.

Right, Thought it was a binary dump...

So bit 12.. So why does the Atari cart think bit 11 is faulty..

But bit 12 being bad should show up as a vertical line thought your program though ? Thinking it must only be a bad bit in one of the banks.. , it's very confusing

[exxos]

It looks like 1MB boundaries are ok, from what you've described - but only near the boundaries. The whole MB doesn't fit on the screen. The keys just take you to the start of each MB, you need to use the right arrowkey to step + 256k at a time, 4 times in a row, to see the rest of that MB.

The screen only shows 640x480 = 307,200 bytes at a time (or less than 1/3rd of that MB)

That the thing as well, I was using up and down arrow and other than some garbage at the start and the end, I don't really see anything amiss.

[dml]

That the thing as well, I was using up and down arrow and other than some garbage at the start and the end, I don't really see anything amiss.

So if it looks clear between the first and last two pages, the Videl is reading RAM ok. Or at least, it is not seeing any bogus set bits. It's all reading as zeroes.

But ramscan says there are data read faults on at least one bit, in some areas.

So either those bits are stuck at 0, or the Videl and CPU don't agree. Hopefully that's a clue.

[dml]

Right, Thought it was a binary dump...

LOL you're right, I'm the idiot here can't read output from my own program.

It's a binary dump, two bytes separated by a colon. So it's bit 11

[exxos]

So if it looks clear between the first and last two pages, the Videl is reading RAM ok. Or at least, it is not seeing any bogus set bits. It's all reading as zeroes.

But ramscan says there are data read faults on at least one bit, in some areas.

So either those bits are stuck at 0, or the Videl and CPU don't agree. Hopefully that's a clue.

I plugged in the working RAM board and did not see any difference between that one and the faulty board. It would seem the Videl is reading the RAM OK then ?

So I am basically back to their being a "CPU side" bus fault ? this would tally with the fact that when @Badwolf's DFB1 is inserted the problem seem a lot less.. At least according to the Atari diagnostic cartridge which I think cannot be trusted at this point anyway.

But that in itself does not make sense because if the bus was unstable, why would there be a working RAM board. surely the problem would be there with multiple boards not just one..

When I was testing with YAART (as in the video) it would throw up a load of faults then pause them for upload of thoughts again.. For arguments sake it would be like alternate 1MB chunks of ram were working and not working.. But if that was the case, why would this not show up with rampan...