exxos blog - random goings on

[exxos]

You are scrolling through ram. the garbage is TOS's stuff in RAM.

Twinkling in the very first page of garbage is maybe ok (some interrupts changing variables).

If you scroll past that (downwards to the empty areas, free ram) and see twinkling == bad news.

It would probably have to start at the problem address because I have no way of knowing where it is.. But the problem is the fault is always seemingly bit11 stuck high.. It is not random so I'm not sure this test would show anything up...

[dml]

It would probably have to start at the problem address because I have no way of knowing where it is.. But the problem is the fault is always seemingly bit11 stuck high.. It is not random so I'm not sure this test would show anything up...

If you scroll through the whole lot, and don't see twinkly areas or coumns of noise - or anything changing/animating - before it loops back around (which it will at 00ffffff) then the RAM is ok for reading, at least.

The only area where stuff should animate, if at all, is the very first page where the vectors and sysvars are.

[exxos]

If you scroll through the whole lot, and don't see twinkly areas or coumns of noise - or anything changing/animating - before it loops back around (which it will at 00ffffff) then the RAM is ok for reading, at least.

The only area where stuff should animate, if at all, is the very first page where the vectors and sysvars are.

OK.. There is some twinkling on the second page.. All sorts of weird and wonderful garbage patterns basically.. Then into total blackness..

But like I say, the same few addresses always have exactly the same bit error it never changes. The only possible way would be to fill that ram range full of zeros because presumably bit11 would still be stuck high like in the diagnostic test.

[dml]

But like I say, the same few addresses always have exactly the same bit error it never changes. The only possible way would be to fill that ram range full of zeros because presumably bit11 would still be stuck high like in the diagnostic test.

Yes, filling with zeroes will help find stuck 1 bits.

If you clear the FASTLOAD bit, the program will clear all ram from its load pos (just after the first TOS page) upwards towards the end of ram (nearly but not quite). So if you see anything at all between the end of the TOS garbage and the end of ram (except one small strip near ramtop) then it's probably not good - animating or not.


The reason I thought this tool might be useful was in looking for flaky ram reads, which the Videl would also see (as noise, flashing pixels, columns etc). But stuck bits will also be visible, if the RAM is cleared or filled, because it won't fully clear (or fill) properly, and Videl will see that too.

[exxos]

Yes, filling with zeroes will help find stuck 1 bits.

If you clear the FASTLOAD bit, the program will clear all ram from its load pos (just after the first TOS page) upwards towards the end of ram (nearly but not quite). So if you see anything at all between the end of the TOS garbage and the end of ram (except one small strip near ramtop) then it's probably not good - animating or not.


The reason I thought this tool might be useful was in looking for flaky ram reads, which the Videl would also see (as noise, flashing pixels, columns etc). But stuck bits will also be visible, if the RAM is cleared or filled, because it won't fully clear (or fill) properly, and Videl will see that too.

I tried clearing the fast load bit, didn't seem to do anything...

I will have to video what I see there is allsorts...

[exxos]

@dml I left the falcon off for a bit.. Now bit less garbage.. takes about 2 mins to loop right the way though.





I put the working RAM board in and kinda looks the same.. but midway I think it remains black for the majority of the time this time..

I think the diagnostic cart is lying to me.. I ran YAARTT and its passing, then scrolling errors, then passing.. then scrolling errors.. so that may fit with the black/white scrolling blocks in the video...

[dml]

Assuming this is a 14mb config / 16mb ram board, it looks wrong to me.

The scrolling loops at 16mb and the last 2mb is HW registers / cartridge etc. so the final bit with the patterns etc. is probably normal.

But 4 times you see a block of white pixels which is a few pages in length. The rest is black. That's incorrect - it should be black all the way between the initial TOS garbage and near the start of the final 2MB (ramtop).

So something is up with the RAM.

The fact it happens 4 times suggests its something like the upper 1MB in each 4MB block.

Its late now but I'll try it on my Falcon tomorrow and confirm.

[exxos]

Assuming this is a 14mb config / 16mb ram board, it looks wrong to me.

The scrolling loops at 16mb and the last 2mb is HW registers / cartridge etc. so the final bit with the patterns etc. is probably normal.

But 4 times you see a block of white pixels which is a few pages in length. The rest is black. That's incorrect - it should be black all the way between the initial TOS garbage and near the start of the final 2MB (ramtop).

So something is up with the RAM.

The fact it happens 4 times suggests its something like the upper 1MB in each 4MB block.

Its late now but I'll try it on my Falcon tomorrow and confirm.

Yep 14MB board.. Those blocks of white don't show up on my working board.

This is a dump of YAART.. To tired to figure it out.. But what you say probably fits... Not sure what physical RAM chips that relates to. Maybe one of the RAS/CAS lines is malfunctioning :shrug: Its the only way I can think entire banks can be wiped out.





If anything, I think the diagnostic cart RAM test doesn't work. Clearly not just a couple of errors.

[dml]

This is a dump of YAART.. To tired to figure it out.. But what you say probably fits... Not sure what physical RAM chips that relates to. Maybe one of the RAS/CAS lines is malfunctioning :shrug: Its the only way I can think entire banks can be wiped out.
If anything, I think the diagnostic cart RAM test doesn't work. Clearly not just a couple of errors.

Yep it does look like there is a problem with the ram.


Tomorrow i'll rework the tool to be more sensitive to bad bits. The TC version was quick to do but it could hide something in darker colours.

So a better version will be:
- high res, 8bit instead of TC (more bits onscreen)
- any set or cleared bit becomes opposite colour so its obvious
- two versions, one that clears mem, one that fills mem. in both, the palette is set up to show any unwanted bit in opposite colour. this should catch any stuck 0 or 1 bits on any bitplane
- keys 0-9/a-f to hop straight to each megabyte
- keys left/right to hop 256k at a time in either direction

This should make diagnostics a bit easier than with the first version, the idea seems to work though - seems to agree with the other test failing.

[dml]

In a bunch of those error messages it shows bit 8 (of 16) being wrong. e.g. ($0800 != $0000) and ($f7ff != $ffff)

So at the very least a bad data bit or line?

Anyway I'm off to recharge :)