exxos's Atari, Amiga & retro forum

I read most of the US topic and can confirm that you can also see damage to the PCB itself from excess US cleaning. Especially around fine pitched chips like the 95288s

I use the same flux removing fluid that you go but use it at 40-50C and max 15 mins.

PhilC wrote: 17 Mar 2026 21:15 I use the same flux removing fluid that you go but use it at 40-50C and max 15 mins.

This that's where I got 70c from, the bottle I think.

I wonder if there's a bubble tank for cleaning PCBs rather than ultrasonic..

I also think JLC PCB quality has gone downhill. The copper seems more fragile than I like. Used to have big problems before with some low cost PCB suppliers. You couldn't resolder anything as the copper would rip off every time. Low quality FR4.

EDIT
Can't find any sort of hobbyist air bubble tanks because they just come back as bubble edge tanks in searches.

I may get a aquarium air stone and a cheap air pump and just drop that in the bottom of the tank.

exxos wrote: 16 Mar 2026 14:48 Currently the STERM is pulsing like a slow clock signal. 200ns low, 300ns high.

When I have things like that it normally means the state machine is breaking down. Probably the mix of async and synchronous signals Ijor always cautions about. Had it with my bus arb logic recently.

Options are try to reduce the async inputs (delay the AS/DS/similar signals by three high speed clocks), change your optimisation settings or identify and correct any cross clock domain dependencies in the module.

OTOH if you're seeing it only on one CPLD, it *could* be a hardware fault. Of course it could be something is very marginal and you only see it on a subset of chips. The changes above may be worth doing anyway.

BW

Badwolf wrote: 18 Mar 2026 13:36 OTOH if you're seeing it only on one CPLD, it *could* be a hardware fault. Of course it could be something is very marginal and you only see it on a subset of chips. The changes above may be worth doing anyway.

Its had loads of extra sync stuff added already. That issue is only on one board. PLD, SDRAM, CPU & SOCKET changed. Continuity checked. It seems to have been dying a slow death.

Similar with a second board. Was working fine all night. Then started acting up, now won't boot.

I've heated up various boards a lot and didn't fail. So doesn't suggest tolerance issues.

Gregs board seemed to die for no reason. I changed PLD, SDRAM, CPU & SOCKET. US cleaned it. It's still dead. So either the pcbs is bad somehow, or something has failed again. Or the bus buffers have failed.

Either way, When something fails, even a barebones 8MHz setup is unstable or won't boot. I've been around the firmware thousands of times. It's not even that complicated. It's why I moved to hardware in fixing any signals which look bad. But now I have seen 2 boards this past week which are doing crazy things and I can't find anything wrong.

The only change I really did from the TF536 is add ROM. Point being TF536 don't have similar reports. So it can't be hardware as such. It only leaves me with PCB defects, which is proven. Or Ultrasonic cleaning which has killed 3 oscs so far.

I need to build up another rev 5.50 board for a new control test and not use the UScleaner on it. Then just leave it on constantly for like a week. If that one fails, then it only leaves the PCB. I'd have to get some made elsewhere and retest again. Rather expensive experiments :(

The only other odd thing, is the PLD which is getting hot, it had TTram disabled and ROM shadow disabled, it ran GB6 fine. I enabled ROM shadow and it wouldn't boot. Tried the previous one, no boot. Went back to my last good firmware, won't boot. It's like flashing the PLD killed it.

I have witnessed iffy jtag connections causing a working board to crash a few times so far. No idea why yet. But maybe it's a gnd issue between the H5 and PC. I need to measure. But if the gnd levels are at different potentials, mix in iffy connections, the PLD could be seeing 100s of volts which would kill it.

That's the reason I disconnect the gnd wire from my soldering iron as I can end up with sparks coming from the end of the tip otherwise. Had same issues with my scope ground. I'll try and measure it when I get chance. Easy thing to rule out.

EDIT:

Could not detect any voltage between the H5 and PC. So all good !

Built another rev 5.50 last night. It been now running 24hours straight.

Left on all right and all morning again and still going just fine..


It will be left on all day and all night again.


Yesterday it was in a warm room and the ST536 was even in sunlight for most of the day as well..


EDIT:

So it just seemed to reset about a hour later. Just went back to the Atari logo, nothing more. But I mean its been running for like 40 or so hours none stop. I rebooted and its running fine again. I still have a couple mods to do on it yet. So will do those next.

Being redoing the SDRAM timings again.. In hardware and firmware.. Managed to give the timings a little bit more "headroom" ,so hopefully that will fix most problems now . I also found a "bug" in the SDRAM settings which seemed to be causing those odd "high byte" random errors I was seeing before. Overall there is been a ton of changes this past week.. The most annoying thing is the first memory access to SDRAM is "expensive". The CPU is actually stalled little bit waiting for SDRAM, but that's just unavoidable :(

I've also managed coax a tiny bit more speed out of TTRam :D


Looking at my old front bench scores it looks like I posted 2930 frames originally. Now I am getting 3013 frames on my H5. Not massive, but still a "free boost" so I took it :P

In theory thing should be stable enough to experiment with overclocking in the future. The SDRAM itself can run at twice the speed, but things will undoubtedly be slowed down because of the PLD anyway. I am hoping ultimately to push it to 60MHz CPU. They will likely be a while before I get to testing that out. Got enough headaches to deal with currently :lol: :roll:

Now to see what I broke :lol: :hide:


EDIT:

With STRAM cache allowed..

oops :)


TTram speed now over 1,000% ! :D

BUT there is a small caveat.. Single accesses now take a fraction longer. That's the speed penalty for sequential accesses . It does not seem to have impacted performance, at least with frontbench. It gained a massive six frames extra ! :lol: but obviously on sequential access like GB6 does on TTram access, There is a speed bump there. It won't have much impact in the real world I guess, but anything which is optimised or does a lot of sequential access should get a speed bump.

@agranlund do you know / still have a older copy of MAPROM which compiles in Devpac 3 still ? I've found 1.8 and that won't compile :(

Congratulations Chris - 1000% !

That's impressive... :)