Game working in emulators --not on physical machine :-(

Master (246)

15-11-2020, 15:21

It's only now and then I test my game on a real machine. Now, I did (A1-WSX and a "new" SVI-738/MSX2), and it does not work (black/gray screen. frozen somehow). It seems to me that finding out exactly what is wrong on a physical machine is way harder than with an emulator. And not to mention the "Plug in SD-card in PC. Code on PC. Transfer files to SD-card. Move the SD-card to MSX. Boot. Test. Repeat."

The game runs fine in openmsx using a whole bunch of configurations. It works in BlueMSX and it works in WebMSX.

Before I start dismantling the game (an orchestration of 7 binaries run toghether - no rom), I thought I'd just ask here: are there any known and especially "picky" areas of the hardware, where the emulators are known to be a bit more "lenient" or forgiving?

If so, I'd start to look there.

Maybe some of you have some cool war-stories doing exactly this?

!login ou Inscrivez-vous pour poster

Par Grauw

Ascended (9498)

15-11-2020, 16:11

It would help to give more context on what kind of system features your project uses. Do you use screen splits, FM music, memory mappers, is it a ROM or a disk file, does it run in DOS(2) or Basic, etc? Do you have custom interrupt and / or slot selection routines?

The timing limitations for the FM chips are generally not emulated, this usually results in corrupt music on real machines though, not freezes. The V9990 emulation is also relatively immature. One pitfall is polling the TMS9918 / V99x8 status register, this is not reliable on real hardware. Other than that things are generally well-emulated especially in openMSX.

I would suggest to reproduce the exact hardware set-up in openMSX. So this includes using a MegaFlashROM SCC+ SD extension just like on the real MSX. It could for example be incorrect slot or memory handling which is only exposed in that specific configuration.

Additionally when debugging such a problem on real hardware I often add a bunch of visible markers, e.g. changing the background colour in different parts of the initialisation to drill down on where it freezes.

Par MsxKun

Paladin (954)

15-11-2020, 16:17

Also. When using emulator usually the memory is clear. Zeroes, of $FF. If you using a real machine, specially when loading from SD, memory can be... whatever. So don't expect the RAM having 0 or $FF or any value at all. Can be random.
So what Grauw said, use the same SD extension on openMSX, could help. Depends. Usually these things are due to something really simple and silly but takes lots to find

Par Bengalack

Master (246)

15-11-2020, 18:24

Thanks guys.

Yes, I know this post was pretty wage. It's just that I thought it would be hard to give all the details (would be page up and page down). So, I thought I'd just look for other people's experiences - in general.

But you have probably helped me find the culprit already?! Maybe I face a problem with DOS1 (no mapper support) vs DOS2 (mapper support with dos grabbing a bunch of the segments by itself).

"I develop for MSX-DOS v1.03". I thought I could use that as a target. Now, for both my physical machines I use this 512kb ram with Nextor as the ram-extension. But, this thing actually boots up in dos2 (well: nextor)... -that will not work of course. -I thought I could target v1.03 and be the sole owner of the memory mapper and be able to claim whichever segment I wanted. Dang!

To verify this I would need to be able to start up without nextor starting up, so I could boot from dos1 and just benefit from the 512kb ram. As is what happens when using the emulator "-ext ram512k". That is probably not even possible, as it is nextor that initializes the ram, the segments and boots up with the right slots (I believe).

Soo... I should probably cater for *any* version of dos, already at this point in development. Making the mapper-routines compliant with dos2. -I've just been lazy so far, thought I'd do those things later.

Anyone knows if "Fractal2000_SD_Mapper" and nextor is supported as extension for openmsx somehow?

Par thegeps

Hero (640)

15-11-2020, 21:01

Well I have something like on Freedom Fighter... I had to set the "No drives" option to "yes" on sofarun. I think it is because the SD Mapper. It has 2 SD slots and msx view them as drives. I tried to free as much as RAM as I could but it continue to freeze if that option isn't set to "yes". Obviously no problem on openMSX, blueMSX and webMSX...

Par Manuel

Ascended (17313)

15-11-2020, 21:06

Trying a ROM on an emulator directly is quite not the same as trying a ROM on an emulator like you do on your real MSX with Sofarun. So, please do not compare apples and oranges here.
The former is as if you are running a ROM cartridge with the proper mapper circuitry in the MSX cartridgeslot of your MSX. And the latter is using tricks to simulate that ROM cartridge mapper hardware on the available hardware (e.g. just an MSX memory mapper).

@Bengalack: I don't think that specific thing is emulated, but you could try emulating the MFR SCC+SD, which also runs Nextor. That's a lot closer already. You could try that already.

Par Grauw

Ascended (9498)

15-11-2020, 21:47

Running a DOS program that directly accesses the mapper on DOS2 without supporting DOS2 mappers is very likely to crash. DOS2 will change the mapper banks and not be able to restore it to the original mapper page that you were using. You can also accidentally overwrite the DOS2 system segments. So that seems very probably the cause of the problem.

You should be able to reproduce this on the emulator no problem. The easiest is to select a turboR which has DOS2 built-in, and on other machines you can plug the ASCII DOS2 cartridge, or the Sunrise IDE (DOS2) or MegaFlashROM SCC+ SD (Nextor) extensions.

All my DOS software that uses a memory mapper requires DOS2. Most people who have larger amounts of memory will already have it as part of a SD/CF cartridge (and if not they can get one). I also think it’s less effort to support just DOS2 mapper routines rather than having two backends. If DOS1 support is really important then MU.COM can provide mapper support routines.

p.s. You can boot Nextor with the 1 key pressed to force it to run in DOS1 mode on your machines. Then there’s no support for FAT16 and subdirectories though, so you may need to prepare an SD card for DOS1. Alternatively you could copy the files to a disk and then boot from there.

Par thegeps

Hero (640)

15-11-2020, 21:49

@Manuel, it is what I was trying to say too: he is using a SD device (like me), so things aren't exactly as they are on plain hardware...
Anyway I've decided to buy a cartridge to flash Freedom Fighter from carmeloco so I'll be able to try the "real thing"

Par Bengalack

Master (246)

15-11-2020, 22:43

Thanks all, for helping out!

Manuel wrote:

but you could try emulating the MFR SCC+SD, which also runs Nextor. That's a lot closer already.

Sounds good. Thanks!

Grauw wrote:

I also think it’s less effort to support just DOS2 mapper routines rather than having two backends.

Not sure at this point what I will do. Currently things run on disk (so I need some kind of mapper handling during development), but if this game becomes something really cool, I will likely have to look into rom-development, and if so, msxdos2 goes away, and there might not be need for ram mapping at all. I guess it is this uncertainty that has led me into these problems in the first place...

Grauw wrote:

As of your tips today I looked into this, and yes, it seems like I have to partition the SD-card, and make startup-disks and such. Yet another thing to get into. Holding that one off until I really need it

So: pretty confident that this will work out nicely now