exxos blog - random goings on

[exxos]

I can't think of many effects it could have on the actual DRAM side of things. That's all hidden behind COMBEL and VIDEL. Load on the power rail? It's not exactly nearby either.

I have no idea... This type of crazyass-faults is normally why I change the pullups on the motherboard. So I went round A1-A17 with a 2.2K pullup fly lead and made no odds.

Booster does indeed have a lot of caps on it now , 100uF jobbies. I will have to try and find some way of hacking some capacitors onto the expansion port headers next.

[Badwolf]

I can't think of many effects it could have on the actual DRAM side of things. That's all hidden behind COMBEL and VIDEL. Load on the power rail? It's not exactly nearby either.

I have no idea... This type of crazyass-faults is normally why I change the pullups on the motherboard. So I went round A1-A17 with a 2.2K pullup fly lead and made no odds.

Booster does indeed have a lot of caps on it now , 100uF jobbies. I will have to try and find some way of hacking some capacitors onto the expansion port headers next.

If the errors are occurring at consistent addresses, perhaps you can coax Videl into showing that area as the screen and writing a fixed pattern into it?

If the errors are 'real' DRAM-side errors, they'll appear on the screen. If they're bus-side artefacts, they won't.

BW

[exxos]

If the errors are occurring at consistent addresses, perhaps you can coax Videl into showing that area as the screen and writing a fixed pattern into it?
If the errors are 'real' DRAM-side errors, they'll appear on the screen. If they're bus-side artefacts, they won't.

A good thought.. More effort than hacking capacitors over the board though

But yeah, I don't really know where this problem is actually at. At one point adding a 100pF on MAD1 seemed to help as well.

[exxos]

I slapped a big 4,700uF on the RAM board, main motherboard capacitor, and on a inductor on the bottom left of the board. But this does not seem to make any difference. Oddly the keyboard seems to be behaving now though.

EDIT:

Not sure if this is part of the puzzle @Badwolf But with the DFB1 plugged in, my keyboard does not seem to respond correctly in the diagnostic cartridge. Like I keep pressing D to get into the diagnostic menu, and it just seems to refresh the main menu. I have to press D several times before it actually goes into the menu. It does not do this with the stock Falcon..

[Badwolf]

I slapped a big 4,700uF on the RAM board, main motherboard capacitor, and on a inductor on the bottom left of the board. But this does not seem to make any difference. Oddly the keyboard seems to be behaving now though.

EDIT:

Not sure if this is part of the puzzle @Badwolf But with the DFB1 plugged in, my keyboard does not seem to respond correctly in the diagnostic cartridge. Like I keep pressing D to get into the diagnostic menu, and it just seems to refresh the main menu. I have to press D several times before it actually goes into the menu. It does not do this with the stock Falcon..

The first key press for me never does anything (on stock or DFB1). Hold on, got a diag cart here...

...no difference between DFB1 and Stock here when entering the diag. First key press does nothing. Second 'D' takes me through to the menu.

The only difference I've seen before with DFB1 on the diag cart is that the initial bus error test will fail (red screen before the interrupt test passes). If your monitor takes time to sync, you'll never see it. This seems to be a difference in COMBEL behaviour between the expansion bus and the internal CPU. No bus error is raised writing to 0x00000000, for some reason.

Doesn't have any other effect.

BW

[exxos]

...no difference between DFB1 and Stock here when entering the diag. First key press does nothing. Second 'D' takes me through to the menu.

The only difference I've seen before with DFB1 on the diag cart is that the initial bus error test will fail (red screen before the interrupt test passes). If your monitor takes time to sync, you'll never see it. This seems to be a difference in COMBEL behaviour between the expansion bus and the internal CPU. No bus error is raised writing to 0x00000000, for some reason.

I do see the bus error not detected.. I assume you have put this in your code ? I think you help me fix that on the TF536 code a while back.

For me I can sit here (and have done just) and had to press D several times before it went into the menu.

This oddity does not happen with OPTION2 jumpered.

EDIT:

Oddly the RAM problems are back with OPTION2 jumpered

[exxos]

If the errors are occurring at consistent addresses, perhaps you can coax Videl into showing that area as the screen and writing a fixed pattern into it?

If the errors are 'real' DRAM-side errors, they'll appear on the screen. If they're bus-side artefacts, they won't.

Maybe if it is simple you or @dml Could write me a routine to do just that.. No worries of his too much hassle as just about had enough of this chaos anyway

This is really a problem because I don't know if the fault is "CPU side" or "RAM side" currently. Without something to narrow it down I am shooting in the dark all the time

Currently I would assume it is "CPU side" as things improve when the DFB1 is fitted.

[dml]

Let me think about this one.

One of the problems with this is making sure RAM is clear to begin with - because trying to clear it could write garbage, if either the bus or the RAM is sketchy, spoiling the test.

But I have a couple of ideas that might show something, will think it over.

[dml]

Just reading back through the messages...

So my first response would be that STRam reading issues would show as noise, on the display. The diagnostic software you are running must put the display in STRam and is refreshing from it constantly. If Videl fails to read (but the state is good on the RAM side) you will see noise, or columns of noisy pixels which don't persist.

If the issue limited to a specific address range then it would need the display to be scrolled to that address (which is doable, not difficult). So that's probably the simplest place to start. If that doesn't show any noise then its the transactions themselves which are failing (cpu/ram exchange).

[exxos]

Just reading back through the messages...

So my first response would be that STRam reading issues would show as noise, on the display. The diagnostic software you are running must put the display in STRam and is refreshing from it constantly. If Videl fails to read (but the state is good on the RAM side) you will see noise, or columns of noisy pixels which don't persist.

If the issue limited to a specific address range then it would need the display to be scrolled to that address (which is doable, not difficult). So that's probably the simplest place to start. If that doesn't show any noise then its the transactions themselves which are failing (cpu/ram exchange).

I think the problem is it always happens on the same few addresses... I think @Badwolf Was referring to reallocating video memory into that range. I don't know where the diagnostic cartridge would put video memory.

It is pretty much always these exact same addresses. Give or take a few. Ordinarily I would say it is bad DRAM.. but that does not make sense because the errors are a lot less ( generally only one or two bad addresses) when @Badwolf DFB1 is fitted.

I guess the idea would be to stick video memory somewhere around these bad parts.. And just write a set pattern to the screen memory and see what I actually get on screen... ? I'm not sure how that would differentiate between CPU or RAM problems..

It is always bit 11 which fails and always on those same addresses basically.

Problem is, is the CPU bus feeding bad data into the Video RAM.. or is the data always correct, and the VIDEL is reading bad data back from the RAM incorrectly. So it is basically "which side of the Videl" is acting up.

Again I am leaning towards some sort of CPU bus corruption because the problems are a lot less with the DFB1 fitted. But is just so weird that it is always (mostly) the exact the same addresses and bits at fault every time.

IMG_0215.JPG (131.68 KiB) Viewed 865 times