ST536 STE EDITION

[Badwolf]

You really need to use a thermal camera to figure out whats going on there - even then you can get reflections which give false positives so it needs to be done in the dark. Not sure if those laser thermometers get fooled by reflections - maybe not - but it's not specific enough to see what the source is.

Could be a reflection, could be something on the mainboard, could be components on the underside - or even the PCB tracks if something is sinking current to a short.

Yeah, don't disappear down a rabbit hole.

a) how precise is that dot to where the measurement is taken?
b) how accurate is the measurement anyway?
c) different specular surfaces could give different readings at the best of times.
d) temperature is not heat. The board will certainly have a lower specific heat capacity than the chips.
e) conductivity. The board will probably be a poorer thermal conductor than the chips. combined with d) means a little bit of localised heat can have a disproportionate effect on temperature.

Also - if the PLD is uncomfortably hot to the touch and the thermometer says its only around 50'c maybe it's not a correct reading on those surfaces?

Quite. You should be able to keep your finger on at 60C and it only start to become a bit ouchy north of 70C.

My CPU after thrashing away for hours tends to fall between those two points, FWIW.

I wouldn't worry about heat unless you're seeing north of 85C anywhere.

BW

[exxos]

I need to look into the address bus issue more. Every time something is decoded things get worse. Like I said before, it's like the internal PLD address is still transitioning long after AS goes low and more address decoding makes it worse.

Currently the internal register at DF0000 can only be triggered by my STOS program. And yet, with DTACK in the mix, it screws up. If I remove DTACK it works fine. So DTACK has to be going randomly low corrupting ST and TTram. But the only trigger for DTACK is when DF0000 is decoded... Which shouldn't happen... Similarly with IDE and SDRAM. It's all the same problem.

Its like AS goes low and the address still isn't stable 20ns later. My only thought is to solder a wire on A5 on the CPU, and use a spare PLD IO to output A5 to see what the real-world delay is.

If it's not that, then no idea. If it is adresses slowing things down, then the new register will have to be removed and maybe the IDE AB. That removes 2 lots of address lines internally. Hopefully enough to solve the issues.

The compiler moans a lot as well these days. I think 30 address lines multiple times internally is breaking things. I could try just using higher address bits only. But if it's like a internal "fan out" issue, then it's not going to help.

Aside from that, moving to a 5V FPGA might be the only solid fix. But that would essentially mean starting the project again. Which I just don't have time for.

EDIT

The max10 series is likely the closest match..

https://jlcpcb.com/partdetail/intelalte ... C8G/C78764

[Badwolf]

I need to look into the address bus issue more. Every time something is decoded things get worse. Like I said before, it's like the internal PLD address is still transitioning long after AS goes low and more address decoding makes it worse.

It sounds to me like perhaps you ought to forget any new dev for now -- including my configuration register request -- and just concentrate on making sure the functionality of the base 536 is there. A known working configuration.

Currently the internal register at DF0000 can only be triggered by my STOS program. And yet, with DTACK in the mix, it screws up.

I may be misremembering, but I *think* STEs issue their own DTACK for the 0x00Dxxxxx range. Hence my suggsetion to use them. You wouldn't need to bother, just detect the AS, LDS and RW activations.

EDIT: Just tried this quickly on Hatari and it appears I'm mis-remembering. I thought there was a whacky memory range decoded by the STEs but, it seems it's not this. Apologies.


BW

[exxos]

@Badwolf I'll build you a cut down version later. I'll take out IDE AB and the new reg and see if that helps with your issues..

I'm not sure if the STE decodes that range. I don't think it does... I think last night I got bus error on that range because I forgot to put dtack back in but I'll double check tonight.

The problem always stems from "loading" the address bus with more decoding logic. Like removing the IDE AB code, and things start working ahwin, could suggest that code is faulty. But it almost does nothing. Removing the block then saying that's the problem... Easy to think that... But add in another address decoding problem elsewhere and it breaks again. So in that situation, it's not exactly the IDE AB code which is causing the issue...

Hopefully new tests will give some more solid clues. But like I said originally, the ROM decoding logic took something like 30+ns to decode and sent ROM CE low. That problem went away with the larger 288. But adding in more stuff is breaking things again. I just don't think these chips have the capabilities to do everything I am trying to to.

EDIT:
Maybe try current7 as that seemed fine and was before I started adding more stuff...

[exxos]

Been doing some more testing and it seems all my current thoughts are simply wrong :roll:

I had one of the spare IO pins as a debug output, I have checked for glitching on various registers and there is just simply nothing (which is expected) . Timings for the address is about 8ns delay. I already factored that in.

The only other thing I have found currently is when on the debug output pin, I have the CPU clock.. the debug pin shows rather low 50Mhz voltage. BUT the CPU itself (which goes via a 66R resistor) looks pretty good.

IMG_3279.JPG

So not sure what's going on there.. But I seem to be back to square 1 again now :pullhair:


EDIT:

I change the output slew rate to fast, and now its booting to desktop fine :WTF:(but may not be totally stable it seems)

IMG_3280.JPG

Its now running GB6 fine.. hmm...


I tried DEBUG output of CLK100 and its very slow like 1v p-p... I went back to CPUCLK and now it looks fine :WTF:

IMG_3281.JPG

OK I had BW limit on one channel now its turned it self off.. so no problems there then ...

[exxos]

I've uploaded current10 firmware. Nothing is removed (IIRC) but this one has FAST SLEW which seems to be working massively better.

A heatsink on the CPU is definitely needed...

[Badwolf]

CURRENT7, 9 and 10 all exhibiting IDE-related reboots in mono mode.

BW

[exxos]

CURRENT7, 9 and 10 all exhibiting IDE-related reboots in mono mode.

I haven't tested mono at all yet. I have to get my other monitor out for that.. Better to use colour modes for now.

[Badwolf]

Acting on my hunch that the IDE access is somehow messing with the mono detect interrupt (perhaps related to the autoboot interrupt fondling?) I built a 256PRG version of EmuTOS that doesn't reboot on a monitor change detection event.

Sure enough IDE access causes the resolution to be reset but because the reboot has been bypassed the system carries on after blanking the monitor for a bit.

Here it is should anyone wish to use to to debug a reboot loop going forward.

In short: I suspect the autoboot logic and I think this is the same problem we saw back with DOTT in the old days, albeit now oddly only manifesting when starting from mono.

BW

[exxos]

If I remember right the mono bit is in the same register as the harddrive bits...

But all bits but one should be pass though...

Code: Select all

 if (BUSEN_IRQ == 1'b1) begin
			  data[7:0] <= { D[7:6], 1'b0, D[4:0] };
        end  

Did any previous firmwares work fine in mono? I've messed with the clocks a lot in later firmwares.. Maybe try current6 or current7 and see if you can get to desktop.. But those firmwares might be unstable anyway..

I can't remember offhand if the INT line is even used past booting up? If there was register corruption it would happen on first IDE access, even before the driver loads.

I'll try accessing the register with and without IDE tomorrow.