Can we trust BIOS routine registers usage?

بواسطة aoineko

Paladin (897)

18-01-2023, 21:47

Hi everyone,
The documentations that describe the BIOS functions often list the registers that each function modifies (and that the calling code must save if it doesn't want to lose the values).
C compilers like SDCC assume that all assembler functions modify all registers and spend size and time juggling with the stack to keep the values it needs.
SDCC allows to indicate on an assembler function the registers used to avoid this overhead.
For my own assembler functions in MSXgl I have already added these indications to optimize the VDP or Memory module for example, but I have not yet done it on the BIOS module.
The thing is that as the BIOS is a black box, if only 1 BIOS modifies a register which is not indicated, it will create a bug which can be very serious.
Hence my question: Can we 100% trust the registers usage in the BIOS docs?
Are there any known problems? Do the most recent BIOS (C-BIOS type) respect scrupulously the usage restrictions of the BIOS docs ?

بواسطة Grauw

Ascended (10707)

18-01-2023, 23:22

aoineko wrote:

Hence my question: Can we 100% trust the registers usage in the BIOS docs?

Not 100%. BIOS routines that call hooks can modify additional registers in the hook. It can happen on machines or extensions which adds BASIC extensions, like on the Yamaha CX5MII for 80 columns mode.

بواسطة aoineko

Paladin (897)

19-01-2023, 09:51

Thanks.
And what about routines that don't use hooks?
Is there known issues?

بواسطة gdx

Enlighted (6108)

19-01-2023, 10:29

Normally, to use a Hook we have to respect 2 things.

We must preserve the state of the registers used by the hook to restore them before returning.
When the Hook is already used we must make sure that the one already in place is called at the end of the Hook that we add just after restoring the state of the registers.

بواسطة aoineko

Paladin (897)

19-01-2023, 12:41

From my point of view, over time, the de facto standard has partly taken the place of the theoretical standard.
For example, if a new MSX does not use the commonly accepted I/O port numbers, I think there are plenty of games and applications that will not work on it (even old ones).
The same may be true for hooks. If some well-established software does not follow the original recommendations, this should be taken into account.
I'm not saying this is good or bad, but it's a fact that I want to take into account in my MSXgl library to offer maximum performance (with direct accesses) or maximum compatibility (with accesses through the BIOS).

Saying that, I conclude that the easiest way is maybe to let the MSXgl user choose if he wants to take the risk of BIOS incompatibility to gain performance.

بواسطة gdx

Enlighted (6108)

19-01-2023, 14:48

aoineko wrote:

For example, if a new MSX does not use the commonly accepted I/O port numbers, I think there are plenty of games and applications that will not work on it (even old ones).
The same may be true for hooks. If some well-established software does not follow the original recommendations, this should be taken into account.

It's not the same for hooks. If someone modifies registers and it works normally, it's because it doesn't interfere with his program. You will lose speed or it will complicate the compilation by putting options for nothing.

بواسطة aoineko

Paladin (897)

19-01-2023, 17:50

I was speaking about compile option.
I have a lot of them in MSXgl to allow a maximum of options to be resolved by the precompiler and not in real time.
The counterpart being that the library must be recompiled when you change those options (nothing is free ^^).

So, I'll take into account the registers usage indications given by the BIOS doc by default and I'll add an option to ignore them if needed.