False alarm! Was: 68HC000 not perfectly 68000 compatible

[troed]

edit: This turned out to be a hardware problem on the datalines on this particular STE. Once corrected the HC worked perfectly in Closure again. We're back to there sometimes being reports of incompatibilities but on investigation it turns out to not be the CPU. Post as it was follows:

***

I've just received a video showing {Closure} not running perfectly on an ST with a 68HC000 fitted. I'll post screenshots etc once the person who shot the video has said it's fine. This does fit with there having been a few posts every now and then claiming the HCs aren't perfectly compatible with all demos - but until now I've never seen an example of what that meant.

My own hypothesis from looking at the video, and knowing how Closure works, is that there is some condition where the code takes four cycles more or less (don't know right now which) than on the 68000. The likely culprit is where I match, on purpose, two instructions to be able to poke the GLUE at 2 cycle intervals instead of the regular 4. Thus this would seem to indicate that there's something in the HC that makes this instruction pairing fail.

Now, I don't think this is true for all HCs, so while the topic of the thread just states "HC", I think we need to figure out if it's a certain manufacturer or if there have been different respins where on of them wasn't fully compatible. So, knowing that a lot of people run HCs in your systems, let's document the ones we know are good. I suggest using {Closure} as the test bench, since we know it provokes the issue. The symptom is easy to spot - the very first dist (both the small and big) will simply bug out very visibly. "Sometimes it looks like crap" for the non-democoders, and "one or two of the border openings fail for the whole screen" for the others ;) And for the experts - "the whole screen after the top border is shifted 0 to X cycles".

Please post all the info printed on top of the CPU please - and a photo is of course best.

/Troed

[mrbombermillzy]

Hey always meant to ask you, (on a hopefully relevant close topic); does Closure work properly on the Mega ST?

I believe my Mega 4 runs ok, but it doesnt like the demo (various screen corruption issues).

It's either the demo, or I need to look at the PSU/caps! :)

[exxos]

The HC isn't stable on a ST unless you change the bus pullups. So it's not a fair test unless some "background work" is done first. So if you just "drop in" a HC and expect it to work, it won't.

In fact it was discovered years ago.

Capture.JPG

This is why all my boosters (The ones which use the HC CPU) either have, or are required, to have the pullups changed. Then later I recommended this be done as a mandatory fix because the pullups were just simply inadequate anyway.

[derkom]

All Stacys use the 68HC000 from the factory. I don't recall if I ever tested {Closure} before starting my colour screen project, but it definitely runs fine after the project, when the Stacy running in 68000 mode of course. Pullups were changed to 2.2K during the project.

[mikro]

I have a (otherwise unmodified) MegaSTE with the HC variant, I can try it but not sure if Closure is supposed to work on MegaSTE?

[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...)

[mrbombermillzy]

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.

[troed]

Hey always meant to ask you, (on a hopefully relevant close topic); does Closure work properly on the Mega ST?
I believe my Mega 4 runs ok, but it doesnt like the demo (various screen corruption issues).

It does - but there are machines where the new kind of fullscreen lines I use show severe Shifter-corruption. This is different from the kind of corruption I see caused by (at least some) HC CPUs which is a change in execution time, causing GLUE timing problems. I'll try to post some example pictures, but in short, what you see I expect to be "graphics corruption" - but the effects still run as they should.

/Troed

[troed]

I have a (otherwise unmodified) MegaSTE with the HC variant, I can try it but not sure if Closure is supposed to work on MegaSTE?

v1.1 works fine - see https://sync.wtf for download.

[troed]

The HC isn't stable on a ST unless you change the bus pullups. So it's not a fair test unless some "background work" is done first. So if you just "drop in" a HC and expect it to work, it won't.

That's good info - but that kind of instability is not what I see in the video. The machine is running perfectly stable, and screens not using instruction pairing (my assumption) are displayed just fine. The screens that do, however, end up making changes to GLUE registers with the wrong timing, which causes border openings to fail, or even signal sync issues. I'm quite certain a test program would show that the instruction execution time differs on this CPU compared to normal.

/Troed