exxos blog - random goings on

[dml]

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

I agree - if bit 11 is broken and ramscan is setting/clearing it (depending on which one you run) then you should be left with vertical columns.

Hmm.

Unless it is only affecting CPU reads. i.e. it always writes correctly but reads back faulty. But that's also hard to explain.

I'll try faking up broken bit 11 on the Falcon and see what the tool shows. :/

[exxos]

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]

I agree - if bit 11 is broken and ramscan is setting/clearing it (depending on which one you run) then you should be left with vertical columns.

Hmm.

Unless it is only affecting CPU reads. i.e. it always writes correctly but reads back faulty. But that's also hard to explain.

I'll try faking up broken bit 11 on the Falcon and see what the tool shows. :/

I am frankly confused. This is why I created a new motherboard because I got tired of all this BS on these original machines

[exxos]

I'll try faking up broken bit 11 on the Falcon and see what the tool shows. :/

Actually I have bit12 "cut" on the bad RAM board for doing tests.. but I would assume the Falcon wouldn't boot if bit 12 was faulty right the way through RAM.. It seems to be only faulty in certain places in ram.. But again, if it was a DRAM IC fault, why doesn't the Videl show the errors..

[dml]

Confirmed - if I invert bit 11 during the clear/fill operation for ramscan, it shows vertical columns every 16 pixels as you'd expect.

So CPU is disagreeing with Videl. somehow.

[exxos]

Confirmed - if I invert bit 11 during the clear/fill operation for ramscan, it shows vertical columns every 16 pixels as you'd expect.

So CPU is disagreeing with Videl. somehow.

This one has me beat because I don't know how that could happen since the Videl is basically the DRAM controller anyway . CPU RW's would be going via the Videl anyway

Is bit11 in the videl actually used for starters ? I think you said your program used true colour, so it would never register on those faulty bits ?

Capture.PNG (33.54 KiB) Viewed 894 times

At this point, I am back to thinking that probably half the bank in bit 11 in the DRAM IC itself is just simply bad. I would surmise if I just change that chip then things would be back to working again anyway.

EDIT:

There is something else which may have to be considered here.. That bit11 assuming testing in 16 bits.. Actually has a high and low word.. Assuming this will mean that bit11 could actually be bit 27 in a different RAM chip

Code: Select all

33222222 22221111 111111
10987654 32109876 54321098 76543210

00000000 00000000 00000000 00000000
    *                 * 

So maybe you could do a 32bit RAM test instead as this would rule out some confusion... ?

EDIT2:

Actually 32-bit isn't going to work on the Falcon is it

[exxos]

I write this down before I forget..This is the way I understand it, which may well be wrong..

MAD8 = 1MB RAM
MAD9 = 4MB RAM
MAD10 = 16MB RAM.

RAS0 = Bits 0-15
RAS1 = Bits 16-31

CAS0L = Bits 0-7
CAS0H = Bits 8-15

CAS1L = Bits 16-23
CAS1H = Bits 24 - 31

So I guess RAS selects a WORD bank and CAS selects BYTE bank.

So if RAS0 is low, we select bits 0-15. Then If CAS0L is selected, then we only enable bits 0-7.

I would then assume the memory map would be something like this..

ADDRESS 0 BYTE (EVEN 8 bits) RAS0=0, CAS0L=0
ADDRESS 1 BYTE (ODD 8bits) RAS0=0, CAS0H=0
ADDRESS 2 BYTE (EVEN 8bits) RAS1=0, CAS0L=0
ADDRESS 3 BYTE (ODD 8bits) RAS1=0, CAS0H=0

Or 16 bits access.

ADDRESS 0 BYTE (EVEN 16 bits) RAS0=0, CAS0L=0, CAS0H=0
ADDRESS 2 BYTE (EVEN 16 bits) RAS1=0, CAS0L=0, CAS0H=0


So I would surmise that my bit 11 fault in a single IC must have failed in such a way, that a whole address range only on bit 15 has died and only died on the upper half of the actual RAM in that chip. Possible MAD10 with bit 15 blew 5MB-14MB in that chip. But did bit15 kill it, or did MAD10 kill it.. Will have to scope those MADx lines out to see if they are spiky next...

[exxos]

I scoped out the RAS/CAS/MADx lines and they all look pretty much perfect overall.

IMG_0233.JPG (98.8 KiB) Viewed 854 times

All the spikes are still present on the DATAx signals.


I guess the only test I really need to do is work out exactly what address ranges bit11 fails on. Maybe I could impose on @dml For a ram test variation which just outputs good and bad blocks of RAM..

For example this almost gives indication but not a actual address range..

IMG_0212.JPG (129.28 KiB) Viewed 854 times

IMG_0234.JPG (51.09 KiB) Viewed 854 times

Looks like there would be 32 dashes. So 14336 / 32 = 448KB per dash.

So first fail is dash 7, so 448 * 7 = 3136KB, to dash 10, 448*10 = 4480KB. So basically 3.0625MB - 4.375MB or thereabouts has failed. At least in the the first block of failures.

Basically what I want to do is confirm that it has not failed on any address boundaries...EG...

(Assuming I work this out right ?)

MAD4 = 4KB
MAD5 = 16KB
MAD6 = 64KB
MAD7 = 256KB
MAD8 = 1MB RAM
MAD9 = 4MB RAM
MAD10 = 16MB RAM.

But if my guesstimate is correct that it is failing around the 3MB to 4.3MB area, and I would assume the failure is not aligned to any sort of MADx boundary...

Basically I am assuming that for whatever reason, bit 11 spiked low enough and long enough to basically end up in some "random" address ranges in ram. But that in itself would seem a little strange because of the past fail pass fail type nature across the RAM range.

[dml]

Is bit11 in the videl actually used for starters ? I think you said your program used true colour, so it would never register on those faulty bits ?

Yes I thought about that, so all versions after the first one I posted are now using 8bit mode, with a palette.

Either colour 0=white, 1-255=black ...or... 0-254=black, 255=white, depending on whether you run ramscan0 or ramscan1.

Each will show up a single bad bit on any bitplane.

At this point, I am back to thinking that probably half the bank in bit 11 in the DRAM IC itself is just simply bad. I would surmise if I just change that chip then things would be back to working again anyway.

Could be.

There is something else which may have to be considered here.. That bit11 assuming testing in 16 bits.. Actually has a high and low word.. Assuming this will mean that bit11 could actually be bit 27 in a different RAM chip

If it were mapped as 32bit wide databus then yes.

But I thought it was organised as 16bit ram, not 32. (In fact its organised as 8bit in terms of addressing but anyway....)

[dml]

I guess the only test I really need to do is work out exactly what address ranges bit11 fails on. Maybe I could impose on @dml For a ram test variation which just outputs good and bad blocks of RAM..

I can try that approach next - but it won't be tonight :-p might get some time in the morning for it.