exxos wrote: 03 Jun 2025 14:36
Did @agranlund or anyone test DOTT in anything but EMUTOS though ? I tend to be the only one using TOS. So I question if DOTT works in TOS, has ever worked, or has ever been tested in any other configurations ? I think those questions should be answered before chasing hardware faults which may or may not even be there.
These are reasonable questions as to avoid chasing ghosts.
I can confirm DOTT works under TOS2.06 and a plain 8MHz 68k with 4MB ST-RAM. This is in my STE board. I've just taken the STE536 out to double check for dry joints so put in the original chip and booted of ASCI.
BW
You do not have the required permissions to view the files attached to this post.
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2 FrontBench The Frontier: Elite 2 intro as a benchmark
Badwolf wrote: 03 Jun 2025 22:08
I can confirm DOTT works under TOS2.06 and a plain 8MHz 68k with 4MB ST-RAM. This is in my STE board. I've just taken the STE536 out to double check for dry joints so put in the original chip and booted of ASCI.
Is this generic 206 or my patched 206 your testing ?
Badwolf wrote: 03 Jun 2025 22:08
I can confirm DOTT works under TOS2.06 and a plain 8MHz 68k with 4MB ST-RAM. This is in my STE board. I've just taken the STE536 out to double check for dry joints so put in the original chip and booted of ASCI.
Is this generic 206 or my patched 206 your testing ?
Generic. Tried your TOS but won't boot on a 68k.
BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2 FrontBench The Frontier: Elite 2 intro as a benchmark
I took my board out and gave it a good inspection. I could find no dry joints, but there was some evidence of flux residue between pins. A bit of a poke and a scrub later and things are much improved.
I've not encountered a freeze on DMA yet (the previous symptom) and both ExxTOS and EmuTOS are able to boot up nicely.
Running DOTT under ET leads to reboots on heavy IDE access, however. No problem running from ASCI.
I did try under TOS, but I don't have a partition scheme on my IDE drive that HDDriver can work with and for some reason ICD refuses to load under ExxTOS & STE536 with 'ICDBOOT NOT LOADED' error. This is both from autoboot and run from floppy. Again, they're not HDDriver compatible, so that recognises nothing. EmuTOS can pick them up and use them, so the drive is working.
So back to EmuTOS and the reboots on IDE access again. I posted a copy of EMUTOS256 PRG version above modified to NOT reboot when the mono detect interrupt is issued. Running that solves the reboot problem with DOTT for me. I see the screen flicker (as the resolution is changed and changed back again quickly when the mono detect routine still runs -- just no reboot remember) occasionally so, to me, this pretty close to a smoking gun.
No mono adapter involved this time. Purely a SCART lead.
I suspect the autoboot logic again.
BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2 FrontBench The Frontier: Elite 2 intro as a benchmark
@Badwolf I've sent you a new firmware (untested) with the whole patch module ripped out. Tough I've not been able to replicate that problem myself here yet.
@PhilC There seems to be 2 problems with those external blitter boards. 3 if you count my board doesn't access floppy anymore.. Even with the stock cpu :roll:
There is something up with that BR signal. I've made it a latched condition and now floppy behaves.
I'm still puzzled why only those boards need a delayed clock... You can't delay the clock on the internal blitter boards. It goes nuts. Plus delaying the clock tends to result in DMA issues :lol: :pullhair: :crazy: :headbang:
I've been trying to think why the cpu needs to be delayed and at 8mhz nothing should really care. Unless anyone has any ideas.. My guess is it might be GND bounce. The system runs at 8mhz so maybe there's to much bounce in that clock domain and shifting the CPU clock skews the bounce to it working again.
Doubt I will have time today. But I'll probably hardwire the bottom of the CPU rails directly to the PSU and see if that helps. Probably won't be that simple.. It never is...
I've mentioned this in passing before, but the guys who created the TwiSTer booster have a whole section describing improvements to be made on an STe motherboard to make the booster stable. It would not surprise me if these modifications were beneficial for the STe536. It involves improving the 5v / ground by running wires on the rear of the motherboard, adding some polymer caps around the glue chip, and adding a capacitor on the blitter to stop blitter related crashes.
Pages 12-15.
STE-Kombi-manual-engl.pdf
You do not have the required permissions to view the files attached to this post.
HigashiJun wrote: 04 Jun 2025 11:35
I have only performed the blitter fix, but even this is not mandatory anymore since firmware version S007.
Hmm yes this is interesting... so of course, almost everything can be fixed in the firmware - tolerances can be introduced to overcome the short-comings of the motherboard design / age-related degredation. I suppose these motherboard mods are just generally beneficial and good to have either way.
