exxos's Atari, Amiga & retro forum

Wietze, I forced the i-cache off in our JOY demo and it then behaves exactly like the video you sent me of your computer running it. The problems starts on the same frame, so it seems like your i-cache is disabled (by hardware) or malfunctioning. It's not due to software control as in the released version of JOY I enable the i-cache by setting cacr.

Just some quick info:
That's exactly the reason for the test/test2.tos thingies - to make sure that there is no Ram access I and D cache are frozen, and SMC was used (now removed) to check for complete cache coverage of the loop in question (an illegal is written into the code after freeze, which the cpu won't see due to frozeen caches). The SMC check produces an illegal on wietzes machine, but not on mine. Also his timing is like non-cached code.
This let me to believe the cache isn't enabled. This can happen if the trace to pin 71 is broken or sth like that. To double check I did a 2nd version test2 with cache off, and both behave the same on wietzes machine and as intended on mine.

Ok, today we ran some more tests.

Benchmark results are the same results when testing with icache on/off. This confirms the story of Daniel.

I've checked the cpu speed; in both 8mhz and 16mhz modes, and indeed the results are different from each mode; this in order to validate that I ran my initial benchmarks in 16mhz, which I have (lower results obtained when running at 8mhz).

So this concludes that it must be an icache issue.

We have checked the CDIS (pin 71 of cpu), and if it is connected to pin 20 of j20, which it was. We checked the nearby pins (pin 70 and 72) for short circuits; which there werent.

Im kind of running out of options in order to verify if its something related to the board; or if its actually the CPU thats borked.

I can obtain a replacement 030, which Im of course willing to risk; Im just wondering if we can do more to narrow down the cause, and determine if its IN the CPU or at the board level.

Input welcome.

What voltage do you get on pin 122 ?

wietze wrote: ↑Wed Jul 10, 2019 9:06 pm Ok, today we ran some more tests.

Im kind of running out of options in order to verify if its something related to the board; or if its actually the CPU thats borked.

I can obtain a replacement 030, which Im of course willing to risk; Im just wondering if we can do more to narrow down the cause, and determine if its IN the CPU or at the board level.

Hi wietze, did you resolve this?

Sorry for not following up on this!

Yes, this issue is resolved. After visual inspection, we realized that at the back of the board, some components were moved (probably due to board rework in the past). As such at, we expect that one of the components caused a short, that affected the cache behaviour.

The actual fix was to heat up the board, and move all the components that were off in place and cleaning up the board. Once this was done, the falcon purred like a little bird again.

Thanks to beetle for actually taking the time out of his day off to come over and service this Falcon during the summer!

This means I got a spare 030 CPU replacement if anyone is interested

Kind regards,
Wietze

That is quite interesting, do you have any photos to share in case someone has a similar issue in the future? Would be interesting to see what components you're talking about. Are you saying that you moved them back to their factory positions, or just removed a short and re-soldered them?

We just moved the components back to their factory position. While doing this, we cleared at least one short.

Having this done a few months ago, I didnt keep pictures :/

Good work to resolve that and a mega demo to find the fault