REV 3 - REV 5 - The beginning (ST536)

[exxos]

I'm sure I read that an 80mhz oscillator will work fine as is with the original firmware, so good chance it'll work with yours.

Yeah, but the original downclocks to 8mhz anyway, so 50Mhz doesn't seem to be a problem for people so far. You wold think with my int-div test program it would screw up as the CPU gets red hot with that running... It's really odd. It's not like I even have a blitter in the machine, so nothing else can even use the bus to corrupt it. Well other than the ROM... I will have to get a socket on the TF536 and try the ROM there instead.. then I can isolate the ST bus more often..

But in reality, I have had the SEC running at 75MHz without anything tripping up.. So 50MHz should be pretty simple.. But with using a different PLD maybe it screws up some timings which I am otherwise unaware of. One odd thing I did notice is DTACK on the ST seems to "float" and switch between like 3V and 5V.. I never seen that happen before either. DTACK is only a input on the PLD, so it shouldn't affect it anyway.

There are no pullups on the 030 SDRAM bus which I thought could be a problem, though checking a few lines they seem fast and sharp so it doesn't seem to need them oddly. It could just be the internal logic routing in the PLD is just to slow.. a 5ns part might solve the problem.

I don't think I have slowed down TTRAM decoding yet.. maybe it's accessing the bus to fast after a ST cycle.. The motherboard buffers might be taking too long to isolate ST-RAM or something.

I wonder if anyone out there has a breakout board for the 030 CPU ? At least I could get the scope on every pin easier..

Then try those 68ec030 40mhz cpus perhaps?

I don't think it was as good as the ceramic on the original TF536 ?

[terriblefire]

@terriblefire Is this normal for STERM ? I mean its hardly low for 20ns...


IMG_6368.JPG

Your probes are awful lol

[exxos]

Your probes are awful lol

Why ? I was deliberately using x1 to add capacitance to various pins to see if I could make things worse or not. If a signal was borderline then the loading of the probe would be enough to kill it completely. I find it a very useful debugging tool.

[derkom]

I wonder if anyone out there has a breakout board for the 030 CPU ? At least I could get the scope on every pin easier..

I looked for one back when I was working on trying to nurse one of the Sparrow boards back to health (should really get back to that someday, because I know a lot more now), and I did find one, but it was absurdly expensive, like in the hundred-plus euro range. Seems like something that could be homemade for not too much...

[PhilC]

@exxos use the smt cpu and adaptor board? At least the pins are probeable then?

[exxos]

@exxos use the smt cpu and adaptor board? At least the pins are probeable then?

Ohh yep.. Finding said board could be a problem :lol: :roll: I'm kinda hoping slowing TTRAM decoding will solve the problem , can't try it until tonight :(

Looking back on previous ram tests, the start address is odd at 7A20 which is a 16 bit figure. So must be something holding the bus longer than it should be, the problem might go away if the ROM was actually on the TF536 anyway.

[exxos]

Just got home and made some changes, it looks like delaying ram access has solved the problem... I think the problem is the ST bus isolators can take up to 20ns to disable and that is just too long..TTRAM has dropped from about 900% to 820% because of it.. but hopefully I can close that gap down a bit..

The RAM Being identified is still wrong.. But this could just be how MAPROM is checking for RAM.. I think it just checks the end of certain block lengths to see if there is ram there or not, and I think my ram is bad is failing the tests getting on ram amounts back.

[exxos]

@PhilC Doesn't get past the FUJI at all.. not even to RAM test :( Gets "burn'ya finger hot" after a short time as well.

IMG_6370.JPG

[PhilC]

@exxos you need a fluffing big heat sink :lol:

[Badwolf]

The RAM Being identified is still wrong.. But this could just be how MAPROM is checking for RAM.. I think it just checks the end of certain block lengths to see if there is ram there or not, and I think my ram is bad is failing the tests getting on ram amounts back.

Is the amount it detects always consistent? Again, getting EmuTOS involved here might be useful.
BW