ASM detect CPU type ?

[exxos]

Seems the first problem is I needed to use DATA and TEXT around the dataline, ironically :lol: :roll:

Code: Select all

exxoscpucheck:				
		move.l		$59e.w,d0
		cmpi.w    #$0,d0   /* #$0020,d0  */
        bhi.s     IsHigher

exxoswarn:
			move.w    #$0000,d0	
			move.l    #infoText,-(sp)
            move.w    #9,-(sp)
            trap      #1            /* Cconws()*/
            addq.w    #6,sp
				
IsHigher:		

DATA
infoText:  dc.b 'Hello World',0
TEXT

So it seems to be doing the opposite to what is intended :lol:

It outputs hello world on a 030 system, when should only do that on a 68000 system :roll:

EDIT:

Oh I think

Code: Select all

move.l		$59e.w,d0

should be

Code: Select all

move.w		$59e.w,d0

Now doesn't do anything on a 030, so good there, but just bombs on the 68k CPU now.. no logo even :roll:

[exxos]

It's very discombobulating. This code will print hello world perfectly well on a 030 CPU, but just bombs on a 68000.. Even before displaying the logo which is actually before my code :roll:

Code: Select all

exxoswarn:
			move.w    #$0000,d0	
			move.l    #infoText,-(sp)
            move.w    #9,-(sp)
            trap      #1            /* Cconws()*/
            addq.w    #6,sp
	
DATA
infoText:  dc.b 'Hello World',0
TEXT

030.PNG

00.PNG

EDIT:

I know what that crash is now.. It's because I enabled the instruction caches before the logo :headbang:

So next up, how do we gracefully crash TOS :lol: :lol:

[exxos]

That'll do pig that'll do :lol:

68000.PNG

68030.PNG

:girldance: :girldance: :girldance: :girldance:
:dizzy:

[stephen_usher]

I would never expect a 68030 targeted OS to work on a 68000. Different exception stack frame for a start.

[DiTBho]

hi
very interesting topic :o

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 version of the assembly program can run-time-detect the CPU type in the list?

[stephen_usher]

I guess that if the program has access to supervisor mode then it could try operations which cause exceptions on the different models, such as illegal instruction, or examine the stack to determine that stack frame etc.

You'd need a matrix of documented failure modes to test against.

[DiTBho]

You'd need a matrix of documented failure modes to test against.

is there anything? :o

[stephen_usher]

Well, we know that the exception stack frame on 68010 and above is different from the 68000 & 68008 for a start. The 68008 has an extended move.q that the 68000 doesn’t. So, there are two tests there. The 68020 will have instructions the 68000 doesn’t, as does the 030. Some instructions were removed from the 040 weren’t they and even more from the 060 from what I remember. So more tests there.

[mikro]

You'd need a matrix of documented failure modes to test against.

is there anything? :o

https://github.com/freemint/freemint/bl ... ect.S#L212

(but similar code can be found in all m68k kernels)

[DiTBho]

detect.S
but similar code can be found in all m68k kernels

Thanks for this example, it's exactly what I am looking for :D
Linux? I will look into!

Next week, I'll prepare some code for my CPU board modules: the firmware on the motherboard is the old "motorola dBUG" monitor, which is loaded in RAM after the start-up, so it's possible to easily reload the exception vectors as well as the supervisor code.

I also have an EVO board (1994) with a MC68332 chip and "dBUG32" in its ROM, very similar to "dBUG". As far as I understand, the instruction set of the CPU32 core is similar to the 68020 without bitfield instructions, and with a few instructions unique to the CPU32 core, such as table lookup and interpolate instructions, and a low-power stop mode.

So, in this case I have some hints to detect CPU32 ---> test if a "table lookup | interpolate" instruction doesn't cause an exception