New game for MSX1 (Transball)

Page 20/20
13 | 14 | 15 | 16 | 17 | 18 | 19 |

Par santiontanon

Paragon (1810)

Portrait de santiontanon

30-09-2016, 20:23

Ok! thanks! then I think I found the problem! there was indeed a bug, and it was not related to the keyboard matrices nor joystick... but to how did I set the code for changing the ship rotation speed! there was some uninitialized memory in some MSX2 machines, which worked fine for most machines, but in some, it happened to contain values that messed up the code.

The good new is that even with the old unfixed version, you can make the game work fine by pressing "1" in the main menu before playing (that sets the rotation speed to 100%)

But in any case I updated the release: https://github.com/santiontanon/transballmsx/releases/tag/1.3.2

ps: nice gdx! my basic is too rusty these days, hahaha

Par ericb59

Paragon (1102)

Portrait de ericb59

01-10-2016, 08:27

Yes !
It works ! Big smile

The most strange thing is why this bug does not appear on all Turbo-r !

Par dioniso

Champion (479)

Portrait de dioniso

01-10-2016, 08:45

ericb59 wrote:

Yes !
It works ! Big smile

The most strange thing is why this bug does not appear on all Turbo-r !

An internal RAM expansion or anything like that, maybe?

Par Manuel

Ascended (19471)

Portrait de Manuel

01-10-2016, 10:13

Different RAM chips may have different initial values. It should be possible to reproduce this in openMSX, for some machines we know the initial values (at least for the ones we tried, it is of course possible different RAM chips were used in different series, like here with the turboR). There have been more bugs like this in the past (e.g. in Akin).

Par santiontanon

Paragon (1810)

Portrait de santiontanon

01-10-2016, 13:48

wohoo! nice! Big smile

Par Louthrax

Prophet (2465)

Portrait de Louthrax

01-10-2016, 17:24

Manuel wrote:

Different RAM chips may have different initial values. It should be possible to reproduce this in openMSX, for some machines we know the initial values (at least for the ones we tried, it is of course possible different RAM chips were used in different series, like here with the turboR). There have been more bugs like this in the past (e.g. in Akin).

That was a common issue on all machines in C & assembly coding (modern compilers are now issuing warnings when you access an uninitialized variable).

Maybe something useful for SQA purposes in openMSX would be the possibility to initialize RAM chips with random values (or with a predefined value ?). You never exactly now what's the content of the MSX RAM chips at boot (depending on the previous game / application you have launched...).

Par Manuel

Ascended (19471)

Portrait de Manuel

01-10-2016, 19:25

You can set the initial values in the config file that describes the MSX. Take a look at the Canon V-20 XML file for example.
There's also a script in openMSX that helps you find UMR's (Uninitialized Memory Reads). It's a bit similar to the 'too fast VDP access" script. In the console, try "about umr" for the relevant setting..

Par Imanok

Paragon (1200)

Portrait de Imanok

03-10-2016, 10:07

ericb59 wrote:

Yes !
It works ! Big smile

The most strange thing is why this bug does not appear on all Turbo-r !

Did you manage to update the cartridges with the last bugfixed version?

Page 20/20
13 | 14 | 15 | 16 | 17 | 18 | 19 |