Acid2Test help

Pagina 1/2
| 2

Door santiontanon

Paladin (791)

afbeelding van santiontanon

18-04-2019, 07:33

Hi!!!

After reading the MSXDev results, I noticed that XRacing did not pass the Acid2Test. Of course, I want to fix that, so today I was trying to run it. I got the files from here ( http://frs.badcoffee.info/MSXAcidTests.html ), and after adding these files to openMSX (I just decompressed the zip file from the Acid2Test to the ".openMSX/share/machines" as explained in the website), when I try to run it, I am apparently missing "Generic_msxaudio.rom". I do see an "msxaudio.rom" file in the extensions folder of my openMSX installation, are these two different files?

I am running it from the commandline like this: ./openmsx -machine Acid2Test-hardware

Not sure if I am doing anything wrong :)

Thanks in advance!

Aangemeld of registreer om reacties te plaatsen

Van Manel46

Champion (403)

afbeelding van Manel46

18-04-2019, 11:57

With our game "Dreams Puzzle", the same thing happens.
Msx music does not sound with Acid2Test hardware.

sd-snatcher, any ideas? Thanks.

Van santiontanon

Paladin (791)

afbeelding van santiontanon

18-04-2019, 17:00

Oh, so you were able to run it? How did you run the Acid2Test, I was not even able to start openMSX with the Acid2Test machine configuration :'D

Van Manel46

Champion (403)

afbeelding van Manel46

18-04-2019, 22:21

Yes. The juice of puzzles with the V9990, works everything except FM sound.

Van Grauw

Enlighted (8084)

afbeelding van Grauw

18-04-2019, 22:40

Hi santiontanon, the acid tests are included with openMSX, no need to download them separately, and the necessary roms are included in this archive along with the rest. If you haven’t already in the past, extract that to .openMSX/share/systemroms, and remove those machines you extracted to .openMSX/share/machines so the built-in ones aren’t overridden by possibly outdated ones.

Now you should be able to run ./openmsx -machine Acid2Test-hardware.

Van santiontanon

Paladin (791)

afbeelding van santiontanon

18-04-2019, 23:14

Ah, got it! Thanks Grauw! I was able to run it and confirm that XRacing does not work with the Acid2Test, will work on it! Smile

thanks again!

Van sd_snatcher

Prophet (3014)

afbeelding van sd_snatcher

19-04-2019, 00:57

@santiontanon

I'm glad you already have an answer. And thank you for the help, Grauw!

@Manel46

Ok. First, a disclaimer is necessary here to try to keep the trolls at bay: I created the AcidTests as a tool to help those who really want to code according to the MSX guidelines. Because we all had headaches with software that didn't handle some aspect of the system properly, be it subslots, RAM location, resource location, MA-20 compatibility etc etc etc.

The tests try to be a superset of characteristics that exist in many "known troublemaker" machines/hardware combinations, and also take all the recommendations of the standard literally. This way it saves time of the developer that otherwise would have to test in a plethora of different machines, and many of them are not even emulated yet. It also saves time/scarce resources of hardware developers, since compliant software is less likely to give them headaches.

Inspired by the achievement-based reward theory and the fact that MSX software always used icons to represent certain compatibility features (MSX-Music, SCC etc), I even created some icons for people who took the AcidTest challenge to stamp on their software. But that was just for fun.

The tests were separated in different aspects, otherwise putting everything into a single test would be a nightmare to debug, wouldn't it? Smile
(Not to mention the fact that some of the aspects are controversial)

If you need more detail for what the aspects that each AcidTest helps to test, please check this page.

Please read that article and be sure that the test in question (Acid2Test, in your case) is one aspect of the MSX standard that you would like to master.

There were other planned machines that, sadly, I couldn't finish yet. Others, like the "Interchip", lost their reason to exist because openMSX provided some nifty scripts like the too_fast_vram_access script that achieve the same result.

Now to your question: The Acid2Test helps you to check if one specific rule of the MSX standard is being followed: user software cannot do direct I/O, except for the VDP on the ports pointed by the BIOS.

Since your software isn't being able to play FM sound on the Acid2Test, there's a high probability that its replayer does direct I/O to the OPLL soundchip. You're certainly using a custom replayer and not the MSX-Music built-in OPLDRV replayer.

In a nutshell, ASCII recommendation for a custom MSX-Music replayer was very straightforward:

1) Keep your custom replayer and music data out of the frame-1 (4000h to 7FFFh)

2) Once per frame your replayer routine will be run, triggered by the VDP interrupt. Then, just once switch the frame-1 to the MSX-Music BIOS slot by calling ENASLT, and write all the data you need with direct CALL instructions to the WRTOPL FM-BIOS routine.

3) Once finished, manually switch back the frame-1 to where it was by using ENASLT of the MainBIOS.

By doing this, it will ensure that your music replayer will play FM sound correcly regardless of the CPU speed (Z80, R800, Z80 turbo etc) and even on the MSX-Audio BIOS v1.3.

Last, but not least, I must say that I really liked your game! The screens are so beautiful, and it's so rare to see MSX2+ games! Please keep them coming!

Van santiontanon

Paladin (791)

afbeelding van santiontanon

19-04-2019, 07:44

Actually, I just noticed one thing, the Acid2Test website notes that this test cannot be used to test " Software that do illegal direct sub-slot switching by accessing the FFFFh register", I notice that XRacing crashes in the Acid2Test machine shortly after I kick the BIOS out of page 0 temporarily.

I use page 0 just to store data. So, from time to time, XRacing kicks the BIOS out, calls Pletter to decompress something from the game page 0 into RAM, and then puts the BIOS back. I guess this is the part of XRacing that is not dealing well with the Acid2Test. So, I have two routines, one that sets the pages as: ROM-ROM-ROM-XXX (where "XXX" is whatever was there before), and then another one that sets pages as BIOS-ROM-XXX-ZZZ (where XXX, ZZZ is whatever was there before). The first one uses the BIOS, but the second one does not (since the BIOS isn't there to help, of course Smile). I think after I call the ROM-ROM-ROM-XXX routine, the Acid2Test machine starts behaving weirdly, and the game ends up crashing.

Do you guys know of a safe way to perform such operations? or kicking the BIOS out (even if it's just temporarily, and always with the interrupts disabled) is directly a no-no, when it comes to compatibility?

Van Manel46

Champion (403)

afbeelding van Manel46

19-04-2019, 10:29

Thank you very much sd_snatcher, for your detailed explanations, of the operation of Acid2, and of what is the possible problem of my rom. I will try to follow your instructions.
On the other hand, based on what santiontanon says, I have tried the rom (V9990/OPL4):
https://www.msx.org/downloads/merry-christmas-2018-by-mapax-0
Nor does the test pass. In it I do not use the bios. On page 0, I have the opl4 player, with its tables. Of course also the particular routine, of treatment of interruptions in # 38

Van sd_snatcher

Prophet (3014)

afbeelding van sd_snatcher

19-04-2019, 16:32

@santiontanon

I'm a bit confused, and OMG I really hope to not cause anyone any trouble here, but: Didn't the "MSX classic" category rules restrict the main-RAM of the machine to 16KB? If that's the case, there shouldn't be any RAM available on 0000h~3FFFh. So the problem isn't how to make it pass on the Acid2Test, but rather that the game is trying to use more main-RAM than the MSXdev machine would have. The fail to pass the Acid2Test is just a hint about that other issue.

I was under the impression that the 16KB rule was there exactly because the MSXdev organisers knew that handling more than 16KB of RAM on cartridges is cumbersome (worst yet for the frame-0).

IOW, given the system restrictions, cartridges can access 16KB without hassle, and up 32KB to 48KB if they perform RAM searching on their own. But as a corollary of the rules, switching the frame-0 is a no-go zone for well-behaved user software. (*1)

Only software for MSX-DOS can access more than 48KB of RAM safely.

Another corollary is that accessing more than 48KB of plain-ROM is also a no-go zone. MegaROMs are very simple/cheap circuits that were created to get around this limitation.

*1: Again, I'm just explaining how things work if you want to "drive your car according to the traffic rules". Yes, you can find shorter/quicker routes if you don't drive according to the rules, but then somewhere there will be a collision sooner or later.

Van sd_snatcher

Prophet (3014)

afbeelding van sd_snatcher

19-04-2019, 16:53

Manel46 wrote:

Nor does the test pass. In it I do not use the bios. On page 0, I have the opl4 player, with its tables. Of course also the particular routine, of treatment of interruptions in # 38

Humm. The Acid2Test was created exactly to test if the BIOS is being used. Yes, in the MC2018.ROM you won't be using the BIOS for the VDP or the music, but it should still be used for everything else.

Probably the MC2018.ROM is doing direct I/O to the PPI. You can easily check this yourself this way:

1) Pause the Acid2Test on the boot logo
2) Type the following commands on the openMSX-console:

debug set_watchpoint write_io 0xa8 0xab
debug set_watchpoint read_io 0xa8 0xab

3) Release the pause. The emulator will break if any user direct I/O is done to the PPI.

Pagina 1/2
| 2