How to detect 68LC060

[Keir]

I am looking to report 68060 submodels in Amiga Test Kit (MC, LC, EC).

I can pull the Revision/Mask out of the PCR. Also it is possible to distinguish LC/EC from MC (Full 68060).

But how do I distinguish LC from EC? 68060 manual gives no software method for detecting absence of MMU (at least no easy method!).

Here's my understanding of Revisions and Submodels by the way:
Rev1: MC, LC, EC
Rev2: MC, LC, EC
Rev3: EC only
Rev4: LC only (same mask as Rev3)
Rev5: MC
Rev6: MC

(ie. At some point LC/EC got their own mask and stayed on that, with their own Revision IDs to distinguish between them. But there are also Rev1/2 LC/EC models which seem harder to distinguish between.)

Any advice?

[Keir]

I'm coming to the conclusion this is a can of worms and will simply report LC/EC based on PCR bit 16.

[Toni Wilen]

At least 68EC040 reads TC register enable and page size bits always zeroed. I haven't tested if 68EC060 works identically because I don't have spare socketed 68060 accelerator.

[Hedeon]

I guess the not so easy method is to install an exception handler and see if it is jumped to when using 060 MMU/FPU specific opcodes?

[Toni Wilen]

Originally Posted by Hedeon

I guess the not so easy method is to install an exception handler and see if it is jumped to when using 060 MMU/FPU specific opcodes?

It would be really easy option but it won't work.

MMU opcodes won't generate any exceptions even if MMU is missing. 68EC030 also does the same. Probably because transparent translation (which is part of MMU instruction set) is still supported, even without MMU.

[Keir]

Originally Posted by Hedeon

I guess the not so easy method is to install an exception handler and see if it is jumped to when using 060 MMU/FPU specific opcodes?

Yes that's the easy option I originally had in mind. But the 68060 User Manual fairly explicitly states it won't work, and Toni confirms it.

Seems there's no magic dust to be sprinkled here. I will do something simple, and leave it to other more dedicated tools like Piru's WhichAmiga to dig a little deeper.

[meynaf]

Originally Posted by Toni Wilen

MMU opcodes won't generate any exceptions even if MMU is missing. 68EC030 also does the same. Probably because transparent translation (which is part of MMU instruction set) is still supported, even without MMU.

I would say it is because the MMU is there in all cases, even if disabled/not working.

The situation seems to be similar to that of 68EC030 so the method to detect it should be the same ?
It's easy : just attempt to setup a translation (a complete one). If you get an exception, or if translation doesn't work (logical address not correctly converted to physical address), cpu is EC (LC).
Be awared that some 68EC030 have a partly working MMU that will be able to do simple protection but not full translation. It's perhaps the same for 68LC060.

[Exodous]

Originally Posted by Keir

Seems there's no magic dust to be sprinkled here. I will do something simple, and leave it to other more dedicated tools like Piru's WhichAmiga to dig a little deeper.

You do realise the source code for WhichAmiga is in the archive on Aminet at:


http://aminet.net/package/util/moni/WhichAmiga

[Toni Wilen]

At least when I had 68EC030 back in the day, it hung when any MMU translation was attempted (probably had physical fault in MMU and it was labeled as EC). Enforcer worked fine.

I expect 68EC060 to follow 68EC040 and force TC=0. Easy test: try to set only page size=8k bit (much easier than trying to test if MMU enable bit sticks, it requires MMU tables if you don't want instant double fault) and read it back. If page size bit is zero: there is no MMU.

Or there are physically non-MMU 68040/68060 variants that return TC=0 and MMU faulty (or just marked as EC anyway) models that work like 68EC030.

Having optional TC register test and MMU translation test would be one way to find out

[Keir]

Originally Posted by Exodous

You do realise the source code for WhichAmiga is in the archive on Aminet at:


http://aminet.net/package/util/moni/WhichAmiga

I didn't know that. I'll have to take a look!

[Thomas Richter]

Originally Posted by Toni Wilen

Having optional TC register test and MMU translation test would be one way to find out

What the mmulib does is that it runs a pre-test in which the MMU is shortly enabled and kickstart is remapped to 0, with interrupts disabled. If that works, and no exceptions happen, a post-test is run that goes through the entire mmulib logic, including exception processing.


But, as Toni mentioned, this is not bullet-proof either. There are cases, at least for the 68EC030, where both pre- and post-tests pass, yet the MMU has hick-ups later on. Thus, I would also suspect that Mot made a full MMU test at the factory, and labeled those CPUs with defects in the MMU as 68EC030.


Thus, if someone is aware of any better or more reliable test, I would be keen to know, but I am not aware of one. The above is the best I could come up with, but it isn't waterproof.

[alexh]

The problem with XC68LC060 and XC68EC060 (that I came across in PGA package) is they are identical to full 060 except the writing on the top of the chip. The FPU/MMU may or may not be faulty but the only way to tell is the writing on the chip and to test it functionally. I think there was no bond out option, no package change, no register change, nothing. Just a lower price and no guarantee the FPU/MMU will work. Thus no predictable way to test in software

[emiespo]

Originally Posted by alexh

The problem with XC68LC060 and XC68EC060 (that I came across in PGA package) is they are identical to full 060 except the writing on the top of the chip. The FPU/MMU may or may not be faulty but the only way to tell is the writing on the chip and to test it functionally. I think there was no bond out option, no package change, no register change, nothing. Just a lower price and no guarantee the FPU/MMU will work. Thus no predictable way to test in software

This kills my hopes. I got a lent CS-MKI with an XC68EC060 on it, that apparently is fully working (AWinQuake worked for 40 minutes with no issues).

CPU060 detects it with a full mask, the only issue I have is with my ZZ9000, it seems I get gfx errors unless I turn the data cache off entirely.

Despite the MMU table saying that ram where the board lives is not cacheable...

Hey Alexh just noticed you’re in Oxford too? First Amigan I heard of in my town!

[AmigaHope]

Originally Posted by emiespo

CPU060 detects it with a full mask, the only issue I have is with my ZZ9000, it seems I get gfx errors unless I turn the data cache off entirely.

Despite the MMU table saying that ram where the board lives is not cacheable...

This is probably the MMU not behaving as it should because it's an EC part. =P The registers seem to work but it's not doing anything. The rest of the system works OK because the card is probably setting cache inhibit pin on the 24-bit address space.

What happens with the ZZ9000 if you just disable copyback?

Have you tried setting the MB BURST jumper on the Cyberstorm to position 2-3?

[alexh]

Originally Posted by emiespo

Hey Alexh just noticed you’re in Oxford too? First Amigan I heard of in my town!

There are lots of us. BuZz of http://exotica.org.uk is a big name who lives here too.

Originally Posted by Keir

Here's my understanding of Revisions and Submodels by the way:
Rev1: MC, LC, EC
Rev2: MC, LC, EC
Rev3: EC only
Rev4: LC only (same mask as Rev3)
Rev5: MC
Rev6: MC

Technically only Rev6 is MC. Before Rev6 full versions were prefixed XC

https://www.nxp.com/docs/en/product-...ollateral.html

[Thomas Richter]

Originally Posted by AmigaHope

This is probably the MMU not behaving as it should because it's an EC part. =P The registers seem to work but it's not doing anything. The rest of the system works OK because the card is probably setting cache inhibit pin on the 24-bit address space.

That would be a bizarre design then because some components in Z-II space are cachable, for example memory expansions.


It is more likely that you observe that the CPU just continues to run with the TTx registers (transparent translation) enabled and configured as by the kickstart. They leave the lowest 16MB non-cachable, and the rest is cacheable. Unfortunately, there are only two of them (well, actually, four, two for data, two for code), and they have a granuarilty of 16MB, much too coarse to change the configuration of a single card.

[emiespo]

Originally Posted by AmigaHope

This is probably the MMU not behaving as it should because it's an EC part. =P The registers seem to work but it's not doing anything. The rest of the system works OK because the card is probably setting cache inhibit pin on the 24-bit address space.

What happens with the ZZ9000 if you just disable copyback?

Have you tried setting the MB BURST jumper on the Cyberstorm to position 2-3?

Uh it was already in position 2-3. I can try to disable copyback as a next step, thanks!

[emiespo]

Originally Posted by Thomas Richter

That would be a bizarre design then because some components in Z-II space are cachable, for example memory expansions.


It is more likely that you observe that the CPU just continues to run with the TTx registers (transparent translation) enabled and configured as by the kickstart. They leave the lowest 16MB non-cachable, and the rest is cacheable. Unfortunately, there are only two of them (well, actually, four, two for data, two for code), and they have a granuarilty of 16MB, much too coarse to change the configuration of a single card.

For the record, I didn't get any of these issues with a Cyberstorm 3D. I was told this is because the ZZ9000 is pushing the limits of the Z3 bus and there are some known incompatibilities with the CS-MKI

EDIT: oh I just remembered that the board works just fine in Z2 mode. This might explain then? Lowest 16mb non cacheable and the rest cacheable, despite me trying hard with the mmu.library + config + every single 68060.library out there...

[emiespo]

Originally Posted by emiespo

Uh it was already in position 2-3. I can try to disable copyback as a next step, thanks!

That didn’t help.

This is a quick album I’ve just created to share my issue: https://photos.app.goo.gl/Rv13huLDYanXDCys5

[AmigaHope]

Originally Posted by emiespo

That didn’t help.

This is a quick album I’ve just created to share my issue: https://photos.app.goo.gl/Rv13huLDYanXDCys5

Might need to just get a real 060 then. =/

One cheap hack that would almost certainly work is to solder a wire between TBI and TCI pin and then disabling copyback. You'd be losing copyback, but still get to keep main memory caching.

(also that link does not work)