False alarm! Was: 68HC000 not perfectly 68000 compatible

[troed]

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.

If you can, please post a photo of the CPU I do believe we will find that there's a certain manufacturer, or a certain respin, that's not perfectly compatible.

[exxos]

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.

The GLUE can malfunction if it has something like 2ns skew on the clock, it's that sensitive. So changing the CPU loads the clock differently which can still cause issues. The CPU needs to be tried in a known working machine which runs with a HC already (and has the bus resistors changed like a H4 H5 board).

It's also possible it could be a bad CPU. I've seen some from China do crazy things. But it's why I test the ones I sell in my store. If this person bought it from China directly then its iffy ground right from the start.

EDIT:

Also exactly what ST is it in and how is it fitted ? recapped PSU etc ? All this needs to be taken into consideration as well.

[derkom]

If you can, please post a photo of the CPU I do believe we will find that there's a certain manufacturer, or a certain respin, that's not perfectly compatible.

There are quite a few pictures in my Stacy thread. For instance, this post has a pretty good shot.

I don't think that's the original HC I pulled out of the Stacy. I've got a tube of NOS HCs and I think I used a new one.

[exxos]

If you can, please post a photo of the CPU I do believe we will find that there's a certain manufacturer, or a certain respin, that's not perfectly compatible.

While I am not dismissing the notion of faulty CPUs (I have had them myself) . I think the direct jump to there *are* incompatible CPUs at this point is a bit of a leap. As most of these chips come from China they are likely or reprinted from God knows where anyway. So documenting them may be somewhat problematic.

If anyone thinks there are incompatible CPUs then just send them to me personally and I will test them in my H5. But even doing that could result in a simply faulty CPU rather than incompatible. Other than the manufacturing process (HMOS \ CMOS etc) they should be otherwise totally compatible.

[troed]

they should be otherwise totally compatible.

I absolutely agree. My hypothesis to what could cause what I see in this video (and remembering the few - https://www.atari-forum.com/viewtopic.p ... 92#p351992 - comments from others regarding HC CPUs) is something that I don't think any program ever but a synclocked demo would trip however. So, the CPUs would likely pass 100% of all tests ever created.

The person who made the video is now going over the machine to see if the problem can be affected in any way by something external to the CPU.

/Troed

[troed]

... and poof, just like that, we're back to there being no proof whatsoever that the HC isn't 100% compatible. Exxos is right, as usual This time I really thought there was something to the report. The person who sent me the video managed to find a fault with the data lines and once corrected everything's now perfectly stable.

(Thread title and top post will now get edited)

/Troed

[exxos]

The person who sent me the video managed to find a fault with the data lines and once corrected everything's now perfectly stable.

What exactly did he find and fix though ?

[mrbombermillzy]

While we are here...

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.

/Troed

Not expecting you to tell all your coding secrets, but is this due to using the interleaved R/W instructions overlap 'trick' for less cycle usage?

[mikro]

Perhaps not a proof that the HC is not compatible but more like there are different MegaSTE timings... my experience:

- MegaSTE #1: MonSTer, Lightning, 68HC00016: Closure works flawlessly

- MegaSTE #2: ATonce 386SX (HW emulator board sitting in the CPU socket), 68HC00016: Closure works with vertical bars and a couple of screens partially corrupted, see below

PXL_20220103_213056790.jpg (111.13 KiB) Viewed 2731 times

PXL_20220103_212805651.jpg (90.52 KiB) Viewed 2731 times

PXL_20220103_211128615.jpg (97.78 KiB) Viewed 2731 times

The last one also exhibited a slight jumping up and down of the text line in the middle.

All hw mods are disabled, both CPUs ran at 8 MHz. Used the same disk image.

[exxos]

Have not done much with the MSTE, but I assume it suffers the same ill fate and needs to bus pullups changing.