how to runtime-detect the CPU type?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

how to runtime-detect the CPU type?

2,795 Views
DiTBho
Contributor I

hi

m68k doesn't have a "CPUID" instruction.

I need to operate with an evaluation motherboard that accepts different CPU modules:

  • 68000
  • 68008
  • 68010
  • 68020
  • 68030
  • 68060
  • CPU32 (68332)
  • Coldfire-v1

Is there a library/hack to run-time-detect the CPU type?

 

0 Kudos
Reply
4 Replies

2,717 Views
DiTBho
Contributor I

I do personally find a bit annoying when people reply "have you Googled".

Anyway, that link points to a semi-working solution. Ok, it gives hints, but ...

0 Kudos
Reply

2,700 Views
TomE
Specialist II

It is unlikely anyone reading this forum has what you want. Unless a debugger (68KBUG/16XBUG?) is written to detect the CPU, but it is more likely it would be built for a specific CPU.

http://www.bitsavers.org/pdf/motorola/VME/68KBUGD1_Debugging_Package_for_68K_CPUs_Part_1_Jun97.pdf

Maybe the 68k version of GDB has some code in it? Good luck understanding that though.

https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=opcodes/m68k-opc.c;h=3bd1bc431e95bcbefa07a0d...

> Ok, it gives hints, but ...

But ... hasn't done the work for you in a form where you don't have to do much.

So who does this sort of thing? Who still worries about "which 68k"? Amiga people, that's who. The easiest was to find them and their code is to search for it.

Here's a whole web page full of debug packages and source code, with references to 68040 and 68060 libraries and so on. No, I don't know how to open an "lha" archive.

https://aminet.net/dev/debug/

https://aminet.net/dev/debug/enforcer.readme

https://aminet.net/package/dev/debug/COP

AFAIK, the only way to tell the difference between these chips is to do something that is "illegal" on one chip, but not on others. Like reading 16 or 32 bits from an odd address. For which you need good working TRAP code that can take a trap, recover the stack, or write (that the trap happened) to a variable, clean up and return. Handling traps is specific to your code base. Unless it has been written exactly for what you have, you've got some work to do.

The above "enforcer" readme says that detecting the MMU is really difficult (68030 vs 68EC030). There's no difference between the 68000 and 68008 apart from execution speed. So you'll need some external "real time source" to measure the instruction timing against. Then there's the 68EC000, which can be strapped to be 8 or 16 bits. Other differences (68000 vs 68010) are that some traps generate different stack frames, so you need to be able to tell the difference between them. Or try to access the VBR and SFR and have it go wrong on the 68000.

The best reference I've found is "Table A-1" in int document usually called "M68000PRM.pdf". That lists which CPUs have which instructions, so you can check for differences. Or that above GDB source file that lists all the instructions and which apply to which CPU.

Tom

 

 

0 Kudos
Reply

2,694 Views
DiTBho
Contributor I

I wrote thinking that someone had already faced the problem, which in fact was pointed out in the other forum you linked, where then I asked, and It was enough to point out a piece of real code to understand how to deal with the matter.

0 Kudos
Reply

2,745 Views
TomE
Specialist II

Have you tried typing that question into Google? Or into Bard or ChatGPT?

https://exxosforum.co.uk/forum/viewtopic.php?p=95215

Tom

 

0 Kudos
Reply