Enhanced OS independent CPU and FPU detection by 0xecc0-devices · Pull Request #18 · larsonmars/sysvars

0xecc0-devices · 2026-03-14T20:29:32Z

Rewrote CPU and FPU detection which now should be OS independent. Veryfied working on OS3.1 and WinUAE only though.

Support for FPU version added, not exposed yet.
Support for EC/LC variants of MC68040/MC68060 added, though not exposed yet. Reason is really that the MMU detection code is not yet implemented.
FPU get's set to "none" if no FPU is found

… of Kickstart 1.2 and later. Based on code by Chris Hooper: https://github.com/cdhooper/amigapci_stm32/blob/main/amiga/cpu_control.c Photon: http://coppershade.org/asmskool/PhotonsMiniStartup/PhotonsMiniWrapper1.04!.S M. Wandel: https://wandel.ca/homepage/execdis/exec_disassembly.txt

- added 68080 ID to global constants - enforced 60 columns limit

Verified working on Kickstart 37.350 and 40.63 with various cpu and fpu combinations in WinUAE

0xecc0-devices · 2026-03-15T18:51:10Z

fpu detection crash fixed on plain 68000 machines.

0xecc0-devices · 2026-03-22T11:37:05Z

@larsonmars finally verified working with Kickstart 1.3..my vasm DOS script needed fixing, so it now produces Kickstart 1.x compatible hunks ;D

Signed-off-by: 0xecc0-devices <retromachines@vodafonemail.de>

…on of emulation environment Signed-off-by: 0xecc0-devices <retromachines@vodafonemail.de>

- added emulation environment variable $Emulation which detects UAE, Emu68 or Musashi emulations - added CPU revision environment variable $CPURev for MC68060/MC68LC060/MC68EC060 and AC68080 - fixed and simplified AC68080 detection (note: AC68080 doesn't support CACR.NAI) - added detection of MC68LC060/MC68EC060 which will be shown for now as '68LC060' in $CPU - added detection of MC68LC040/MC68EC040 which will be shown for now as '68LC040' in $CPU - added detection of MC68EC020 which will be shown as '68EC020' in $CPU - refactored CPU string output to use a table based approach instead of digit replacement - optimized various assembler instructions as of VASM's suggestion - updated and corrected function header documentation for various functions

larsonmars

Thank you very much for the detection improvements! This will make many people happy.
I made some comments for your consideration.

Unfortunately, I cannot just approve as is, because the tests fail due to breaking change with $CPU and $FPU. I also made some comments there. If we want to keep it the way it is now, we would have to adapt the test (the startup-sequence).

Also, we must not forget to create the Aminet release, where we mention your contribution in the .readme (I can do that in an extra commit when the PR is complete).

larsonmars · 2026-04-27T23:30:59Z

 ************************************************************
 *                                                          *
-*                      SYSVARS V.0.18                      *
+*                      SYSVARS V.0.23                      *


Could we use v.0.19?

EDIT: I understand that you did some versions in your fork. I suggest we use a versioning scheme, such as 0.20a1 or 0.20b1 for the next changes if you intent to merge it, so we keep one branch with the major versions.

Sure, no problem. I reverted the version back to 0.19
For further versions, I'll follow your suggestion using current version +a1/b1

larsonmars · 2026-04-27T23:31:39Z


 PROGVER: macro
-    dc.b "$VER: SYSVARS 0.18",0
+    dc.b "$VER: SYSVARS 0.23",0


see above, would be good to have 0.19

Sure, no problem. I reverted the version back to 0.19
For further versions, I'll follow your suggested naming scheme

larsonmars · 2026-04-27T23:34:45Z

+MC68060_ID EQU $0430
+
+; constants for detection of 24bit addressing
+KICK_VER equ $00F8000C


equ => EQU (for consistency)

Fixed that, too.

larsonmars · 2026-04-27T23:43:43Z

    endc

-    movea.l EXEC_BASE,a6         ; get exec base in A6
+    movea.l EXEC_BASE.w,a6         ; get exec base in A6


Could you elaborate the benefit of using EXEC_BASE.w instead of just EXEC_BASE? I would expect assemblers to do it right either way, but the added .w is noisier.

Because vasm will complain with optimization abs.l -> abs.w

How about a simple macro?

;----------------------------------------------------------- ; get's exec.library base address to passed address register ;----------------------------------------------------------- ; Macro Arguments: ; 1: address register to store the exec.library address in ;----------------------------------------------------------- EXECBASE macro movea.l EXEC_BASE.w,\1 endm

larsonmars · 2026-04-28T00:13:57Z

+.cpuName:
+    dc.b "68000",0,0,0
+    dc.b "68010",0,0,0
+    dc.b "68EC020",0


I very much appreciate that we can now distinguish EC versions of a CPU. However, putting it into the name like this we loose the ability to use inequality operators (less/greater than) in scripts, which is quite common to enable certain tools only for certain CPU generations or newer (see also the test that must we must adapt so it works again).

Maybe we can split the EC/LC as separate $CPUVariant variable, or we could create variables for the actual CPU feature (or the lack thereof), such as $MMU. As we already have $FPU, which can be 68881, 68882 and internal, the information in $CPU, $FPU, $MMU would be sufficient to determine whether it is an LC/EC CPU.

What would you prefer?

I didn't think much about that. But you're right..for a script tool the $CPU variable denotes the integer compatibility, which doesn't differ between the XC/EC/LC variants.
I'd go with your suggestion to keep $CPU, $FPU and $MMU separated and clean from variants. I'm not even convinced that the $CPUVariant variable would be necessary.

larsonmars · 2026-04-28T00:42:16Z

-| **``$CPU``** | always | installed CPU, for example ``68030`` (68080 is supported, but see [limitations](#Kickstart-13-and-below))
-| **``$FPU``** | if&nbsp;CPU&nbsp;≥&nbsp;68020 | installed FPU, one of ``68881``, ``68882``, ``internal``, or empty for LC/EC 040 and 060 CPUs where no FPU is available (see [limitations](#Kickstart-13-and-below))
+| **``$CPU``** | always | installed CPU, for example ``68030``
+| **``$FPU``** | always | installed FPU, one of ``68881``, ``68882``, ``internal``, or ``none`` for LC/EC 040 and 060 CPUs where no FPU is available


Like with the CPU, this is a breaking change. Is there a reason why you changed the FPU to be always available again? The inital sysvars version also had this defined always. I had this later changed to be not defined for CPUs below MC68020 so it is consistent with other properties that are only defined when they can technically be available. AFAIK, there can never be any FPU with anything below MC68020, but maybe I'm wrong. Also, why is 'none' better then just empty?

It's possible to have an FPU with the 68000 as a peripheral (see Motorola AN947). But it's rather impractical.
In Amiga DOS scripts you would probably go for IF EXISTS checking for the availability of the environment variable and then compare the value with IF $FPU EQ or something similar.
I think script-wise there's no real difference between checking for existance of the variable or getting it's value evaluated.

I'll just revoke the change that sets the variable when there's no FPU detected.

- removed detection of MC68EC020/MC68LC040/MC68EC040/MC68LC060/MC68EC060 which makes $CPU showing the integer unit's capabilities - refactored CPU string output to use digit replacement again - added macro for getting exec.library base pointer to improve readability avoiding assembler optimization output

0xecc0-devices · 2026-05-27T18:06:45Z

Any thoughts on the changes?

0xecc0-devices added 6 commits February 8, 2026 20:06

- added credits into the source code

d149a45

- added 68080 ID to global constants - enforced 60 columns limit

Merge branch 'larsonmars:main' into main

be71bcc

Enhanced OS independent CPU and FPU detection

1a2422a

Merge branch 'main' of https://github.com/0xecc0-devices/sysvars

1b7e064

Fixed fpu detection crash on plain 68000 machines

689bc30

Verified working on Kickstart 37.350 and 40.63 with various cpu and fpu combinations in WinUAE

0xecc0-devices added 3 commits March 17, 2026 18:45

Update README.md

1cdd6e4

Update README.md

2e16499

Update README.md

8191ea3

larsonmars self-assigned this Mar 31, 2026

larsonmars added the enhancement New feature or request label Mar 31, 2026

0xecc0-devices added 4 commits April 16, 2026 22:14

Added UAE/Musashi/Emu68 detection

b727963

Signed-off-by: 0xecc0-devices <retromachines@vodafonemail.de>

Merge branch 'main' of https://github.com/0xecc0-devices/sysvars

37a7925

updated README.md

d92dff9

Fix: Added code to properly close the expansion.library after detecti…

f375f86

…on of emulation environment Signed-off-by: 0xecc0-devices <retromachines@vodafonemail.de>

larsonmars self-requested a review April 20, 2026 00:15

0xecc0-devices added 2 commits April 26, 2026 15:04

Update README.md

01c599d

larsonmars reviewed Apr 28, 2026

View reviewed changes

0xecc0-devices added 3 commits April 29, 2026 17:58

Update README.md

82a9345

Merge branch 'main' of https://github.com/0xecc0-devices/sysvars

030fb32

Uh oh!

Conversation

0xecc0-devices commented Mar 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

0xecc0-devices commented Mar 15, 2026

Uh oh!

0xecc0-devices commented Mar 22, 2026

Uh oh!

larsonmars left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

larsonmars Apr 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

larsonmars Apr 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xecc0-devices Apr 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xecc0-devices Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xecc0-devices commented May 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

0xecc0-devices commented Mar 14, 2026 •

edited

Loading

larsonmars left a comment •

edited

Loading

larsonmars Apr 27, 2026 •

edited

Loading

larsonmars Apr 27, 2026 •

edited

Loading

0xecc0-devices Apr 29, 2026 •

edited

Loading

0xecc0-devices Apr 28, 2026 •

edited

Loading