MSX2+ boot screen in fMSX?

By Cayce

Supporter (6)

Cayce's picture

12-12-2021, 18:14

Hi, anyone know what triggers the MSX2+ sliding boot screen to appear, or not appear?

Lately I've been sending some PRs to libretro-fmsx, to fix/improve a few features. I noticed the MSX2 bootscreen appears, but not the MSX2+ variant. This is also the case in fMSX itself. BlueMSX & openMSX both do show it.

Is there a simple explanation (&solution) for this, or would it require a lot of debugging/fiddling with the fMSX core?

Before you ask: no, of course this not very useful. But I'm just curious! Now that I've noticed it, I would really like to fix it..

Any hints to get me started would be appreciated. Thanks!

Login or register to post comments

By Pencioner

Scribe (1523)

Pencioner's picture

12-12-2021, 18:41

it might be port #F4 bit 7 is set which indicates that soft (not hard) reset is ongoing and makes a boot ROM skip the logo part. So for MSX2+ the #F4 port (which is actually a 8-bit register) should be implemented

By Cayce

Supporter (6)

Cayce's picture

13-12-2021, 20:14

Thanks for the tip! On blueMSX, I see F4 being read, boot screen appears & then F4 is written. fMSX default MSX2+ machine is based on Sony HB-F1XDJ, which is not inverted. I implemented that in fmsx-libretro, but to no avail. (Inverted: same result) - the F4 port _is_ read & written but the boot screen still isn't shown.

I noticed fMSX doesn't even switch to SCREEN 6, so it doesn't even prepare to show the boot screen.

There must be another piece of the puzzle. Any additional ideas?

By Manuel

Ascended (18794)

Manuel's picture

13-12-2021, 21:20

Is the correct value returned then when the F4 port is read?

By Cayce

Supporter (6)

Cayce's picture

13-12-2021, 21:44

Tried with both 0 and 0xff (regular and inverted). It's only about b7, according to Pencioner. Or are there more values I should attempt?

By Pencioner

Scribe (1523)

Pencioner's picture

13-12-2021, 22:29

I didn't say that would be sufficient (i just know that MSX2+ has this port and that you'll need either patched BIOS or some added hardware which implements it if you upgrade MSX2 to MSX2+) - i was rather directing you towards looking for more information because that's likely a thing that is causing the issue btw. No blame for me please Big smile

By Cayce

Supporter (6)

Cayce's picture

17-12-2021, 15:32

No blame was intended. A remark on youtube (!) hinted towards the 32KiB Kanji driver (not the 1MiB Kanji ROM) containing the logo. I mapped that in fMSX. And indeed: the boot screen starts to appear - and then the MSX hangs in an endless loop at 7A68... Memory range 6000-7fff on the Kanji driver is crucial; when that page is missing, the boot screen is simply skipped. I was unable to reproduce the same error in bluemsx-libretro by 'breaking down' the Machine config.ini. It just simply skips the boot screen when not loading the Kanji driver.

I don't have any experience debugging MSX ROMs (which is my next step), so any hints are still welcome!

The only thing I have so far is a comparison of call paths, which diverge already at step 19 after port F4 is read.

fmsx:
...
CALL to 0627
JR to 0658 (seems to be the wrong path, although the 'hang' occurs many thousands of jumps later)

bluemsx:
...
CALL to 0627 (still the same)
RET to 0619

I have no idea what code is present at those addresses, so I'll be busy for a while I guess Wink

By jr

Champion (377)

jr's picture

17-12-2021, 20:27

Hello Cayce, more than a decade ago I worked on an MSX emulator for mobile phones that was originally based on fMSX source code. If I remember correctly one key piece in making the MSX2+ boot logo working was rewriting the sprite emulation. Again, according to my somewhat hazy memory, MSX2+ boot logo uses collisions of invisible sprites at the edges of the screen to time the animation effect and the inaccuracy of the fMSX sprite emulation prevented the animation routine from working correctly. Of course I cannot say anything about the state of fMSX emulation nowadays; I would think it has probably evolved a lot since I took it as a base for my emulator so it is entirely possible this is not an issue anymore. Just my random two cents for this discussion.

By Cayce

Supporter (6)

Cayce's picture

18-12-2021, 14:48

That's good info! Alas, it might be a bit over my head to solve that. I don't think fMSX has evolved a lot in the past 10 years.

The inaccuracy that you refer to, is that related to the actual collision detection, or specificaly related to timing? If the latter, I'd probably better just give up..

Is the rewritten sprite emulation code possibly still available somewhere? (I'm assuming here you actually did get the MSX2+ boot screen to work, with the rest of the fMSX code still being mostly intact?)

By jr

Champion (377)

jr's picture

20-12-2021, 18:08

I'm not entirely sure anymore but I think the main issue was timing; the sprite emulation was only updating state once per frame while the boot screen needed at least once per scanline or something like that. I got the boot screen working but I actually ended up rewriting the entire emulator. Not just for the MSX2+ boot screen but I wanted to improve other things and also optimize everything for the platform/hardware the emulator was running on. I don't have the source code anymore or if I do I don't know where it is, I'm sorry. Also it might not be very useful for you since it didn't share anything with original fMSX anymore, the VDP emulation was written completely in ARM assembly for example.