ST536 STE EDITION

[PhilC]

Which cap was removed? I've just fitted the patch and built the board but only have 1mb ram on this STe until my delivery from Mr Exxos arrives next week, so haven't tried it.

@exxos re 288 and 144. It works fine on the H5 and now even on my Mega ST, which is a complete b*Stard of a machine, so doubt the 288 will make a difference.

Is there any difference with reliability between PAL & NTSC and the external nlitter versions. My Mega won't work with the nlitter in as well as an ST536.

[coonsgm]

Which cap was removed? I've just fitted the patch and built the board but only have 1mb ram on this STe until my delivery from Mr Exxos arrives next week, so haven't tried it.

@exxos re 288 and 144. It works fine on the H5 and now even on my Mega ST, which is a complete b*Stard of a machine, so doubt the 288 will make a difference.

Is there any difference with reliability between PAL & NTSC and the external nlitter versions. My Mega won't work with the nlitter in as well as an ST536.

@PhilC My STE536 (NTSC) seemed to have fewer stability issues with the original firmware and build...but that could simply be my specific computer and have nothing to do with the region.

I have not been able to get my ST536 to run stably on my Mega ST with our without the blitter for more than an hour or so. I switched to running an Atari flashed TF536 with EmuTOS which is rock solid on the Mega.

[exxos]

Which cap was removed?

Yours wont have it.

@exxos re 288 and 144. It works fine on the H5 and now even on my Mega ST, which is a complete b*Stard of a machine, so doubt the 288 will make a difference.

Problem is , I had to mess with the TTram timings to get it to work at all on the Atari. The STE536 is the same. That mystery was never solved. As shifting to the STE536 seems to show the problems now more, I fear, technically, so will the ST536. Its jut a fluke of tolerances if it works or not.

I don't think Anders had the problems when he was messing with the TF536, but he used a 288XL... We are using the same code base, so it doesn't make sense why I get the troubles.. Unless its the PLD... I suspect the tipping point was probably when I added the TOS206 decoding.. It pushed the PLD over the edge, even though it was maybe only 90% full at the time. I've added more in since then.

The only way to prove that, is for me to build a couple up with the 288, and see if something monumentally changes or not. Currently the PLD is 99% or 100% full.. The compiler is really struggling. SDRAM seems very sulky about timings.. So even a couple of ns is enough to make or break it.. mix in tolerances across batches of boards or chips.. Its like fighting a loosing battle at this point...

Is there any difference with reliability between PAL & NTSC and the external nlitter versions. My Mega won't work with the nlitter in as well as an ST536.

:shrug:

[Steve]

@Steve Which cap did you remove? I assume the oscillator is the one closest to the patch board.

We had a cap underneath the 030, I think it was connected to the clock signal. If you didn't put one there, you might not have one. And yeah I removed the old oscillator, same as exxos.

[coonsgm]

Ah got it. I have removed both the oscillator and that cap now. No change. Issues still with modified TOS 206, but working just fine with EmuTOS.

[PhilC]

@exxos well it does sound timing related as I had to change to the H5 oscillator in the Mega for it to work? And there are three oscillators on the STe IIRC

[exxos]

@exxos well it does sound timing related as I had to change to the H5 oscillator in the Mega for it to work? And there are three oscillators on the STe IIRC

It's something off with the sdram timing. Hard to diagnose without a LA. ST bus side access still happens at 8mhz. I think the CPU might be out of sync with the SDRAM clock. Well it likely is, just not sure on the skew.

But I need to measure it really.. unless one of you guys can scope the CPU clock and SDRAM clock. SDRAM is always 100mhz, max CPU will be 50mhz. They should be in sync but I'm thinking there's less than 5ns skew between them. 50mhz is down clocked from the 100mhz... BUT because of clock switching logic thats likely introducing a bit of skew by itself. I guess if someone could measure a Amiga TF536 it would likely help.

It's only a guess at this point. But there must be some logic block sharing or something causing timing errors which the original TF536 didn't have.. I had problems right from the start but I had to add 206 decoding as the 030 CPU needs it... Which I'm guessing was enough to force the compiler to take drastic action to get it all to fit leading something to break...

So trying a 288 is going to be my next step... I need to rule out the compiler next, otherwise I'm chasing problems which don't really exist...

[exxos]

Ah got it. I have removed both the oscillator and that cap now. No change. Issues still with modified TOS 206, but working just fine with EmuTOS.

I think EMUTOS is a red herring. Maybe different code isn't triggering whatever the fault is , but TOS206 does. Both should be reliable.

[Steve]

Could it be that HD Driver could be a problem itself? @mikro recently found a bug where it basically works 'by accident' on certain hardware. There was a big thread about it on Atari forum. I'm just thinking that since Uwe hasn't tested his driver on these new boosters, it could have something to do with that.

Perhaps try tos 206 with a different hard disk driver?

[exxos]

Could it be that HD Driver could be a problem itself? @mikro recently found a bug where it basically works 'by accident' on certain hardware. There was a big thread about it on Atari forum. I'm just thinking that since Uwe hasn't tested his driver on these new boosters, it could have something to do with that.

It's a possibility I guess. I think my last version was 11.12 or thereabouts. I've not tested any later versions yet.

I mostly used EMUTOS to run tentical as I needed the PC compatible boot... Was just to lazy to look for and boot from floppy..

But I do know something is off as the CPU clock seems way to sensitive... I've got 33R on the next PCB revision, but they could make things worse...