False alarm! Was: 68HC000 not perfectly 68000 compatible

[DoG]

I have the same exact "glitches" as micros have in his screen dumps above. But this is on a C070859 rev2.1 board with MC68000P10. Glue and MMU is SMT.

I can't really pinpoint where the fault is. It seems to correct it self when I flex the board. I have tried pressing on various chip without any luck. All the main chip has been solder of this board at one point in time. So much stuff is in sockets now.

So check datalines perhaps or check soldering on Glue? Otherwise there is some bad soldering somewhere or just micro crack in the board?

2022-01-04 17.07.25.jpg

2022-01-04 17.06.15.jpg

2022-01-04 17.05.41.jpg

2022-01-04 17.04.29.jpg

[exxos]

Some months ago I had to re-solder literally half motherboard because it was is so bad. The machine had never been opened either. That had all kinds of strange faults.

So indeed start by re-soldering the main chips.

[troed]

everybody: While the new fullscreen lines I invented for Closure worked perfectly on the 11 machines I tested on, they are _not_ as compatible as the tried and proven Level 16 ones. "Every other 16 pixels blank" is unfortunately a known issue due to a Shifter wakeup mode. I have a code path that would work in that mode as well, however, it's impossible to detect which mode the Shifter is in from software. So, the demo contains one of the paths and hopes that not too many people end up getting the "every other ..." mode :/

It's not due to a problem in your ST at all. In theory it _could_ be affected by delays between MMU and Shifter - but again - don't go modifying hardware just because my fullscreen lines aren't good enough ;)

/Troed

[exxos]

@troed I cannot remember if the original shifter chip had odd faults relating to all this as well ? though I think these were only ever in the very very early STM machines.

In case of @DoG He says flexing the board solves the problem. So sounds like he has a bad connection somewhere which ordinarily does not cause problems with his machine :shrug:

This actually opens up the door to rather a interesting topic in itself.. As if ordinarily the machine can pass RAM tests etc.. But cannot run Closure.. It could actually be a really good indication that the machine is indeed malfunctioning..

[DoG]

Interesting. Before I started flexing the board I pressed reset or did a cold boot a couple of times until I got Closure to run correctly. I could check by switching shifters with a board that runs Closure as well.

[mrbombermillzy]

This actually opens up the door to rather a interesting topic in itself.. As if ordinarily the machine can pass RAM tests etc.. But cannot run Closure.. It could actually be a really good indication that the machine is indeed malfunctioning..

Maybe Closure should be the new Atari system diagnostic test suite? :lol:

Seriously though, that sort of thing even happens on the C64 when hitting it hard enough (VICII VSP bug), and thats a bit more standardised with parts than the Atari ST family as a whole. Just one of those things where if the tolerances are all in the wrong way and you are scraping the metal to the bleeding edge software wise, will crop up IMHO. Hence the recommendation to go through the OS being the 'proper' way to use the machine by C=/Atari in the day.

[exxos]

Maybe Closure should be the new Atari system diagnostic test suite? :lol:

Yeah that was pretty much what I was thinking!

Seriously though, that sort of thing even happens on the C64 when hitting it hard enough (VICII VSP bug), and thats a bit more standardised with parts than the Atari ST family as a whole. Just one of those things where if the tolerances are all in the wrong way and you are scraping the metal to the bleeding edge software wise, will crop up IMHO. Hence the recommendation to go through the OS being the 'proper' way to use the machine by C=/Atari in the day.

Interesting.

There can be all sorts of weird hardware faults and the machine could otherwise appear to function perfectly well. I documented slow DTACK *somewhere* in my booster work years ago ( among a million other things), Problem being that software ( other than probably GB6) would be totally unaware of the CPU taking longer to complete instructions than it should do otherwise. It was part of the reason why GB6 show a very small variation speeds, like 1% or 2%, simply because the CPU was not terminating the cycle fast enough causing instructions to take twice as long as they would do normally.

In every run-of-the-mill software, it really would not care. But when you are literally down to cycle precision stuff like Closure, a couple instructions wrong here or there timewise and the whole thing screws up kinda thing.

One of those odd things is if you have a SR98 PSU, where you can alter the voltage up or down slightly, just doing that could make or break Closure from working. Changing any chip on the motherboard from one brand to another could even be enough make or break things. This is why I gave up with original machines as there are just inherently way too many things wrong with them to solve in one's lifetime :lol:

[mrbombermillzy]

VSP Bug:

"Finally, this phenomenon hinges on the exact timing of the RAS signal at the nanosecond level, and on many machines the critical situation simply doesn't occur. The timing (and thus the probability of a crash) depends on factors such as temperature, VIC revision, parasitic capacitance and resistance of the traces on the motherboard, power supply ripple and interference with other parts of the machine such as the phase of the colour carrier with respect to the dotclock. The latter is assigned randomly at power-on, by the way, which could be the reason why a power-cycle sometimes helps."

Does that bold text sound fairly familiar? ;)

[exxos]

Does that bold text sound fairly familiar? ;)

:lol: :thumbup:

[HigashiJun]

My Mega ST also works fine with the 68HC000 fitted and 2.2 K pull-ups on the motherboard.

(But did not try Closure...)

Please give it a go if you can.

It would be interesting to see if the *slightly* different clock of the MegaST is one of the factors causing the problem if your HC variant.

No worries, but do you know if there is a .PRG version of this demo ?

I only have a .MSA file and I do not really feel like converting it to .PRG.

By the way, my Mega ST is NTSC, and I heard NTSC versions had some problems with Closure...