exxos's Atari, Amiga & retro forum

Hi all,

I am trying to get my TT sorted. It has an underlaying problem which means I need to drop all the data and address bus SIPS to 2.2k to get any kind of stability. While I was generally happy, I lately found I was getting bus errors on SCSI access. After lengthy testing I decided to socket my address and data SIL resistors to investigate. I found that default 10k is unusable, crashes on hard disk detection (HD driver) 4.7k sometimes passes but then crashes later. 2.2k passes and the system works, but then has some low level bus errors cropping up here and there - so I want to find the cause.

I put 10k SILS back in and started scoping. I found that removing the STRAM board (the TT still has 2mb on the motherboard so can still operate) drive detection passes with 10k SILS installed. But loading the FreeMint OS (my daily driver OS) freezes on boot during 'setting up fstab' (which is where the drives are detected and mounted in the OS) This is an interesting development.

EDIT: Also noting that removing the TT RAM board (but leaving ST-RAM board installed) works too. So this does not seem to be an issue with either RAM board. Bus loading? As I heard Exxos speak about before. And I know we generally fix this by lowering SIL values, but I just want to understand why as people in the TT domain are always telling me 2.2k might damage components in the system, so if possible I want to find the root cause.

Here are some scopes, blue is 5v direct from the PSU and yellow is connected to 5v on the STRAM board.

I am not so great at reading the results, I took photos at various different zooms/scales and at 20mv for both channels.

Ps - I have two PSUs and tested them both, behaviour is the same. The main PSU is recapped and tests 5.1v and 11.9v, negative rails pass fine too.

I think that you're hitting the resolution of your scope and seeing individual samples for a start.

Variations of +-20mV aren't unusual for power rails in a digital system... they'll also be picking up RF such as mobile phone signals etc.

I think you're currently chasing ghosts.

Have a look at the actual signals on the data and address lines and forget the power rail for the time being.

Your scope appears to be set to 10x, try it at 1x, see if it's clearer.

@stephen_usher in order for me to look at the signals on the data and address lines, would you suggest I attach my scope to individual lines on the SIP resistors themselves?

Would you suggest scoping two different SILs at once? One data, one address or vice versa?

rubber_jonnie wrote: 01 Mar 2022 21:43 Your scope appears to be set to 10x, try it at 1x, see if it's clearer.

Thank you. Will do.

Steve wrote: 01 Mar 2022 22:05 @stephen_usher in order for me to look at the signals on the data and address lines, would you suggest I attach my scope to individual lines on the SIP resistors themselves?

Would you suggest scoping two different SILs at once? One data, one address or vice versa?

Just hold the tip of the probe on a chip data or address line and look at the shape of the signals. They should be sharp boxes with minimal rise time and fall time and little in the way of overshooting.

@stephen_usher one last Q I promise! When you say 'a chip' does it matter where? Shall I focus on a ram chip on the st ram board and perhaps the SCSI chip?

I'd check as many places as possible. However, starting at the most accessible is probably a good idea, just to look at the the signal shapes.

@stephen_usher

I am just thinking of some logical testing methodology - since the unstable behavior shows itself when TTram/STram cards are installed, then perhaps I need to scope some readings without them, then with them and see how the data changes.

I am still unsure (sorry) as to the best place to gather this data (which chip to scope) I don't want to just pick randomly, so that my tests are consistent. Perhaps a chip related to balancing VME bus usage would be logical, if such a chip exists?

Steve wrote: 02 Mar 2022 12:38 I am still unsure (sorry) as to the best place to gather this data (which chip to scope) I don't want to just pick randomly, so that my tests are consistent. Perhaps a chip related to balancing VME bus usage would be logical, if such a chip exists?

On this point, you may try to compare, for given trace, what you get by scoping on two chips (e.g. it trace 't' is linking A and B, put the first probe at A and the second probe on B). This way you would know if you have to take care of the location of the probe, or not ?