Building an STe536

[exxos]

1. System doesn't start unless I press reset
- The motherboard is already fully recapped, using a re-capped SR-98 PSU, the C100 reset cap is 53uf. I may just experiment with different C100 values to see if I can fix this, unless anyone has another idea.

My board has a 330uF across C100, but that was just what I grabbed randomly at the time.

2. System randomly reboots
- Might be related to ACSI hard disk access

Looking back I had that problem and seemed to be ROM access speed. But if you can boot with MAPROM it doesn't use ROM after that anyway.
viewtopic.php?f=94&t=5826&p=116990&hili ... ng#p116990

Though I did have resetting issue as well, which is why the small cap was added onto the CPU clock. It might be worth scoping it out (hence my white wire) and maybe adding a bit more capacitance (think I sent 47pf) to see if that helps. There is a lot of bad ringing on the clock for some reason. It's almost impossible to add a series resistor, hence the cap addon instead.

4. After managing to get MAPROM and BLITFIX inside C:\AUTO (I put the old 68k cpu back in to copy from floppy to ACSI) the system will crash / hard lock when loading MAPROM.PRG out of AUTO (on the ACSI drive) I then tried loading MAPROM from within TOS, this also caused a hard lock (no bombs, just pure lock-up)

I doubt they have much error checking and they likely assume TTram is available on a 030 CPU.

My thoughts so far: Firstly I just want to point out, this STe motherboard is 100% re-capped with all mandatory fixes, including bus resistor changes done.

That is a bit of a unknown at the moment because I haven't tested with the bus pullups changed yet. Unfortunately while I have a lot of motherboards, there are all in various states of disrepair. Not something I have time to do at the moment.

So I should probably point out that the 2.2K pullups on the bus hasn't been tested yet. I cannot really say at this point if the 2.2K makes things better or worse with the 030 as they were tested with the 68000 CPU and 32MHz booster (also 68000) . The 030 doesn't run the bus at higher than stock speeds as MAPROM is used to speed up ROM access. So the bus remains at 8MHz, it somewhat negates the issue of stability running at 32MHz.

This particular motherboard also has the fabled 'good dma'.

That has not been tested either. You should probably try a -38 in there. In fact I only have 1 "good DMA" and the pins are about to break off it. I only ever test the -38 as its whats in most machines. Though in some cases the "good DMA", as I found, can actually work worse than the "bad dma" -38 chip. So I tend not to bother with it anyway. I could probably go as far to say that the "good DMA" won't be supported full stop.

I will next do testing on IDE only, to completely rule out ACSI access as being the cause for many of these problems.

Probably a good idea to try IDE yes.

Also don't forget the 2.2K pullups change the DMA timings and with the "good DMA" having slightly different timings again it could be enough to break things.

My only other thought is that EMUTOS hasn't been extensively tried either yet.

[Steve]

Thank you for all the pointers. I will proceed as follows:

1. Take ACSI out of the equation (for now, re-introduce later)
2. Check out the CPU clock & experiment with different value caps.
3. Replace my C100 with a higher value cap.
4. Get IDE going so I can run tests reliably.
5. Change my SIL's back to stock values, they're socketed so it's easy to do. I might do this last if required.

I don't actually have a -38 DMA to play with. So hopefully I can get ACSI going reliably after everything else has been investigated.

[exxos]

I slowed the ROM access down in this one so you can try that helps..

main_top.zip

Also while I did not see any problems as such in my tests, there's a huge voltage drop from the power supply to the CPU. I got 5.00 to 4.85V. There are some header pins with 5V and 0V on the STE536 where you can wire link them direct to the PSU to get a bit more power to the board.

I also assume you ran YAARTTT to test the TTram etc ..

[Badwolf]

Thank you for all the pointers. I will proceed as follows:

1. Take ACSI out of the equation (for now, re-introduce later)
2. Check out the CPU clock & experiment with different value caps.

ACSI may be my least favourite thing in the world. After Tottenham. Oh, and those air freshner things with sticks coming out the top.

Anyway, I've been investigating very similar sounding issues with DSTB1.

So far I've discovered that modern logic sampling the 8MHz clock can go utterly haywire. Probably reacting to the ringing. The Schmitt trigger on Exxos' STE to DIP adapter board has really helped out there. I presume any edge detection employed against other signals may have the same problem too, incidentally.

This is where that capacitor tuning could probably help you out.

The second thing I've been running into is our friend ACSI. Now I think the hardware hanging off the back of this can make a difference too -- one of my hard disc emulators is worse than the other at this -- but in my board, which has onboard RAM and does clock switching (like yours to a certain extent), using both at the same time is problematic.

Below is an as-yet unreleased video of me demonstrating this.

I've had a little bit of joy switching down to 8MHz as soon as BR is asserted. If you get everything bar DMA working, perhaps this is something that can be added into the ST536 firmware, if it's not already?


BW

[exxos]

I've had a little bit of joy switching down to 8MHz as soon as BR is asserted. If you get everything bar DMA working, perhaps this is something that can be added into the ST536 firmware, if it's not already?

Like I mentioned wayyyyyy back, I switch back to 8MHz on BR,BG,BGACK and stay way clear of DMA access. It's been standard across all my boosters for a long time. You have to switch on all 3, just doing one doesn't work.

So far I've discovered that modern logic sampling the 8MHz clock can go utterly haywire. Probably reacting to the ringing. The Schmitt trigger on Exxos' STE to DIP adapter board has really helped out there.

Yep, Its why I had so many mods to the STE boosters over the years. Mostly because internal and external blitter machines have different levels of "bad clock". Half the time I had to add 33pF on it to solve the issues, but then it wouldn't work on the other motherboards. So I ended up with 2 approaches. Later I used the schmitt buffer which mostly solves that(**), but now adds to much delay, so I had to do the STE DMA FIX boards after :lol: :roll:

(**) Though some blitters can go nuts if it doesn't have a particular loading on the clock.. The whole thing drives me nuts :(

[Badwolf]

Like I mentioned wayyyyyy back, I switch back to 8MHz on BR,BG,BGACK and stay way clear of DMA access. It's been standard across all my boosters for a long time. You have to switch on all 3, just doing one doesn't work.

:thumbup:

Although I can't think of a case where BG is low and both BR and BGK are high, so I'd hope two would be sufficient.

BW

[exxos]

Although I can't think of a case where BG is low and both BR and BGK are high, so I'd hope two would be sufficient.

Its depends how your clock switching works, as /AS (off the top off my head) if used as a switch to 16Mhz, may fall in the middle of busgrant cycle and could speed up the CPU and then cause issues. Of course it's been years since I looked at it and I don't remember much about it anymore. But that's what my results showed from all the tests I did years ago, that , if any of those signals are low, you must run in 8MHz.

[Badwolf]

Although I can't think of a case where BG is low and both BR and BGK are high, so I'd hope two would be sufficient.

Its depends how your clock switching works, as /AS (off the top off my head) if used as a switch to 16Mhz, may fall in the middle of busgrant cycle and could speed up the CPU and then cause issues. Of course it's been years since I looked at it and I don't remember much about it anymore. But that's what my results showed from all the tests I did years ago, that , if any of those signals are low, you must run in 8MHz.

BR can occur anywhere in a cycle, obviously. BG will only happen between cycles as it's issued by the CPU. BGK is the last thing to be released before you take over again.

I'm still fiddling, but what was happening with me was that 8MHz + AltRAM was fine, 16MHz no altram was fine, combining the two was a problem. Because I was only using BGK (BR isn't connected to the CPLD on mine) and I tried delaying coming out of 8MHz mode after a BGK, that implies to me that any problem must have been at the *start* of the bus arb cycle. Which is odd.

Asserting BG too rapidly? Seems unlikely, doesn't it?

Anyway, never mind. But ACSI smells.

BW

[exxos]

Asserting BG too rapidly? Seems unlikely, doesn't it?

Not really, I don't issue BG until /AS and /DTACK is high on the ST side. Your fighting against 8MHz screwy GLUE timings with a lot of this stuff. GLUE can become unhappy very easily..

[Badwolf]

Asserting BG too rapidly? Seems unlikely, doesn't it?

Not really, I don't issue BG until /AS and /DTACK is high on the ST side.

Oh, you do your own bus arb?

Anyway, I meant what I was demo'ing in that video. There's evidence the problem isn't coming *out* of bus relinquishment as stacking delays on the end of a cycle don't have any effect, whereas putting the brakes on the second BR asserts (could be mid-cycle) does improve things.

To me that says the mystery lies at the *start* of the bus arb cycle. But got knows what it could be.

BW