English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 12 June 2020, 11:27   #1
Keir
Registered User
 
Join Date: May 2011
Location: Cambridge
Posts: 608
How to detect 68LC060

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?

Last edited by Keir; 12 June 2020 at 11:32.
Keir is offline  
Old 12 June 2020, 12:15   #2
Keir
Registered User
 
Join Date: May 2011
Location: Cambridge
Posts: 608
I'm coming to the conclusion this is a can of worms and will simply report LC/EC based on PCR bit 16.
Keir is offline  
Old 12 June 2020, 12:18   #3
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,057
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.
Toni Wilen is offline  
Old 12 June 2020, 14:06   #4
Hedeon
PPC Hacker

 
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 1,299
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?
Hedeon is offline  
Old 12 June 2020, 15:18   #5
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,057
Quote:
Originally Posted by Hedeon View Post
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.
Toni Wilen is offline  
Old 12 June 2020, 19:22   #6
Keir
Registered User
 
Join Date: May 2011
Location: Cambridge
Posts: 608
Quote:
Originally Posted by Hedeon View Post
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.
Keir is offline  
Old 12 June 2020, 19:45   #7
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,925
Quote:
Originally Posted by Toni Wilen View Post
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.
meynaf is offline  
Old 12 June 2020, 20:02   #8
Exodous
Registered User

 
Join Date: Sep 2019
Location: Leicester / England
Posts: 77
Quote:
Originally Posted by Keir View Post
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
Exodous is online now  
Old 12 June 2020, 20:12   #9
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,057
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
Toni Wilen is offline  
Old 12 June 2020, 23:40   #10
Keir
Registered User
 
Join Date: May 2011
Location: Cambridge
Posts: 608
Quote:
Originally Posted by Exodous View Post
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!
Keir is offline  
Old 15 June 2020, 19:24   #11
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 576
Quote:
Originally Posted by Toni Wilen View Post
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.
Thomas Richter is offline  
Old 15 June 2020, 20:14   #12
alexh
Thalion Webshrine
alexh's Avatar
 
Join Date: Jan 2004
Location: Oxford
Posts: 12,410
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
alexh is offline  
Old 04 July 2020, 16:54   #13
emiespo
Registered User

 
Join Date: Jul 2017
Location: Oxford
Posts: 49
Quote:
Originally Posted by alexh View Post
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!
emiespo is offline  
Old 04 July 2020, 18:49   #14
AmigaHope
Registered User
 
Join Date: Sep 2006
Location: New Sandusky
Posts: 746
Quote:
Originally Posted by emiespo View Post
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?

Last edited by AmigaHope; 04 July 2020 at 19:05.
AmigaHope is offline  
Old 04 July 2020, 21:18   #15
alexh
Thalion Webshrine
alexh's Avatar
 
Join Date: Jan 2004
Location: Oxford
Posts: 12,410
Quote:
Originally Posted by emiespo View Post
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.

Quote:
Originally Posted by Keir View Post
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
alexh is offline  
Old 05 July 2020, 09:34   #16
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 576
Quote:
Originally Posted by AmigaHope View Post
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.
Thomas Richter is offline  
Old 05 July 2020, 22:44   #17
emiespo
Registered User

 
Join Date: Jul 2017
Location: Oxford
Posts: 49
Quote:
Originally Posted by AmigaHope View Post
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 is offline  
Old 05 July 2020, 22:47   #18
emiespo
Registered User

 
Join Date: Jul 2017
Location: Oxford
Posts: 49
Quote:
Originally Posted by Thomas Richter View Post
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...

Last edited by emiespo; 05 July 2020 at 23:22.
emiespo is offline  
Old 05 July 2020, 23:09   #19
emiespo
Registered User

 
Join Date: Jul 2017
Location: Oxford
Posts: 49
Quote:
Originally Posted by emiespo View Post
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
emiespo is offline  
Old 06 July 2020, 01:37   #20
AmigaHope
Registered User
 
Join Date: Sep 2006
Location: New Sandusky
Posts: 746
Quote:
Originally Posted by emiespo View Post
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)
AmigaHope is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
68LC060.library update SpeedGeek Coders. Asm / Hardware 13 16 September 2020 16:34
How to detect WHDLoad files? guidobartoli80 support.FS-UAE 15 31 May 2019 08:04
Detect RTG arcanist Coders. General 2 03 March 2019 19:37
Detect AGA Steffest Coders. C/C++ 2 22 October 2017 12:20
How to detect WinUAE demolition support.Apps 13 13 November 2012 11:21

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 18:03.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.12766 seconds with 15 queries