Skip to content
Open
Show file tree
Hide file tree
Changes from 15 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 5 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,8 +10,9 @@ Currently, the following variables are supported:
<a name="overview_table"></a>
|Variable|Availability|Description
|--------------|------------------------------------------|------------------------------------------
| **``$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

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@0xecc0-devices 0xecc0-devices Apr 28, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

| **``$CPURev``** | always | Revision of installed CPU for MC68060/MC68LC060/MC68EC060 and AC68080, for example ``6``
| **``$Chipset``** | always | installed graphics chipset, one of ``OCS``, ``ECS``, ``AGA``, ``SAGA``
| **``$VFreq``** | always | vertical frequency of the native display, can be either ``50`` (PAL 50Hz) or ``60`` (NTSC 60Hz)
| **``$TotalChipRam``** | always | total amount of Chip RAM installed (in KB)
Expand All @@ -21,6 +22,7 @@ Currently, the following variables are supported:
| **``$SlowRamFirst``** | see&nbsp;description | The variable is set to ``1`` if Slow RAM is first to be allocated as non-Chip RAM[^2], otherwise this variable is unavailable
| **``$KickVer``** & **``$KickRev``** | always | Kickstart version and revision (see [limitations](#Kickstart-12-and-below))
| **``$BSDSockLib``**, **``$BSDSockLibVer``**, **``$BSDSockLibRev``** | if&nbsp;present | ID, version and revision of bsdsocket.library
| **``$Emulation``**| if&nbsp;detected | emulation, one of ``UAE``, ``Musashi``, ``Emu68``
| **``$UAEMajor``**, **``$UAEMinor``**, **``$UAERev``** | if&nbsp;detected | major, minor version and revision of UAE detected (see [limitations](#UAE-detection))
| **``$VampireType``** | if&nbsp;CPU&nbsp;=&nbsp;68080 | type of vampire installed, for example "V2_600", or "V4_Standalone"
| **``$VampireCoreRev``** | if&nbsp;CPU&nbsp;=&nbsp;68080 | core revision of the currently flashed firmware .jic file[^3]
Expand Down Expand Up @@ -84,7 +86,6 @@ The tool is also available in the [Aminet](https://aminet.net) and there is a [s
As sysvars is optimized for speed, being compact and system friendly, it is not an elaborate H/W detection tool, such as WhichAmiga. This means that there might be system combinations, where sysvars gets it wrong. Some known limititaions are listed below. Anyway, you can always file a bug report, if you think that sysvars can be optimized.

## Kickstart 1.3 and below
- Sysvars currently detects CPUs above 68020 as 68020 and any FPUs as 68881.
- Environment variables can only have global scope (i.e., they reside in ENV:). This means you must have ENV: mounted (e.g., to some folder on RAM:). This is not required for OS 2.0 and above.
- Environment variables can only be used with the IF command (things like
``ECHO $CPU`` do not work. You must use ``IF $CPU GE 68010``).
Expand Down Expand Up @@ -132,7 +133,7 @@ IF NOT WARN
The tool is already quite useable, but there are still some things missing, which I want to fix in future versions (no particular order):

- Add ``$RTG`` variable to enable/disable stuff like FBlit or swap screen mode configurations
- For Os 1.3: add detection for CPUs > 68020 and at least the 68882
- ~~For Os 1.3: add detection for CPUs > 68020 and at least the 68882~~
- Make use of boards.library and identify.library if available for even more expansions.
- Make a WinUAE/FS-UAE-based test suite for automated tests (CI/CD-like)

Expand Down
Loading