#216 Support for offsets on ROM files

SD Snatcher

I recently dumped the ROM of my Sony HB-F1XDJ using an EPROM burner. The HB-F1XDJ contains a single 128KB PROM for nearly all it's needs (*1). This single ROM is then split by the hardware to be shown on the required slots.

*1: The KanjiFont-ROM and the Wapuro ROM are kept on a separate ROM.

This single-ROM splitting seems to be the used on most of the MSX2+ designs: Either Sony's, Sanyo's, Panasonic's or CIEL.

Unfortunately, I can't use the original dump of the F1XDJ ROM on openMSX. The only way to use it is to manually split the file in smaller files.

An easy way to support a single ROM split across multiple slots would add support for optional offsets under the <filename> and <sha1> tags of the xml file. Taking the HB-F1XDJ SubROM and MSX-Music BIOS as examples, it would become like this:

<secondary slot="1">
<ROM id="MSX Sub ROM">
<filename offset="0x8000">roms/Sony_HB-F1XDJ_main.rom</filename>
<sha1 offset="0x8000">f2a1d326d72d4c70ea214d7883838de8847a82b7</sha1>
<mem base="0x0000" size="0x4000"/>
<ROM id="MSX Kanji Driver with BASIC">

<secondary slot="3">
<MSX-MUSIC id="MSX Music">
<filename offset="0x18000">roms/Sony_HB-F1XDJ_main.rom</filename>
<sha1 offset="0x18000">f2a1d326d72d4c70ea214d7883838de8847a82b7</sha1>
<io base="0x7C" num="2" type="O"/>
<mem base="0x4000" size="0x4000"/>


  • I would turn this around. In stead of specifying fragments, the whole ROM should be used just like the hardware does.
    Someone that has separate ROMs can join them together.

  • ROM image offsetting is already implemented. See the ASCII MSX-DOS2 extension.

  • FRS, can you confirm that using the <window> tag helps for your case? (As bifimsx pointed out.)

  • SD Snatcher
    SD Snatcher

    Yes, this new <window> tag is just what was needed! :)

    As thanks gift, I'll attach an updated version of the HB-F1XDJ hardwareconfig.xml file here.

  • SD Snatcher
    SD Snatcher

    Updated HB-F1XDJ file, to use the dump of the original ROM

  • SD Snatcher
    SD Snatcher

    Updated CIEL Expert-Turbo xml file, to use the dump of the original ROM. Audio mixing also fixed.

  • SD Snatcher
    SD Snatcher

    I also attached an updated xml file for the CIEL ExpertTurbo. It has the following enhancements:

    1) Updated to use the <window> tag, that allows the original EPROM dump to be used.
    2) Fixed the audio mixing and stereo balance. Just test it with MicroCabin games, Starship Rendezvouz and Valis-II to check the results.

  • I've checked it, and I'll talk with Wouter if we still want to change this now.
    The problem is that everyone will need new ROM files (the 'single' dumps are not available anywhere at the moment) and there is no way (I think) to specifiy the separate alternatives still, as a temporary measure.

    I think you did make a mistake with the channels on the CIEL. 1-9 refers to the channels you hear when rhythm mode is off and 10-14 refers to the 5 rhythm channels. This does (by design) not correspond to the actual channel numbers of the FM chip. Otherwise you would get the 3 channels of the non-rhythm mode ('melody mode'?) on the wrong side.

    You boosted the volume of the FM to 21000, which is A LOT compared to 9000. Are you sure this is correct?
    Also, if you don't use FM, the PSG is now always on the right side. Is that also on the real thing? It sounds a bit annoying to me if you run PSG only games.

  • SD Snatcher
    SD Snatcher

    [split files vs single file]
    Yes, you're right. That's why I believe that the <window> parameter should be related to the file being referenced (<file> and <sha1> tags), and not to the <rom> tag. This would allow to have both fragmented or single files and would be a good transition path.

    [channel separation of the YM2413]
    But that's the way the real YM2413 outputs sound: The channels 1-6 go to the MO output and the channels 7-9 go to the RO output. This always happens regardless if the chip is with the Rhythm mode activated or not. Of course the consequence is that when the Rhythm mode is activated, the right channel will only produce rhythm sounds because their generated by the combination of the las 3 channels.

    You can test Starship Rendezvouz on any real YM2413 stereo hardware and see that the melody of the channels 7-9 will be heard on the right channel.

    Also, it's right: On the stereo output of the ExpertTurbo the PSG will be output only on the right channel. It was designed like this to try to balance the audio as 6 channels on the left and 6 channels on the right. I do agree that for PSG musics this results in a mono output on the right side (*1), but it does produce a very good result for games that use both PSG and FM, like MicroCabin does.

    *1: On a mono MSX, isn't exactly that what happens when you connect it to a stereo receiver? At least at my setup, when I connect my Turbo-R to my stereo all the sound is output only to the right channel. Then I have then to manually select "mono output" on a switch of the stereo receiver to force it to output the sound on both sides. When playing PSG games on the ExpertTurbo, its the same: the user just select "mono" on the switch of the receiver. The machine was designed in a way that FM(+PSG) games are stereo, but PSG-only games are mono on the right channel like any other MSX.

    About the OPLL volume: The sound have the volumes perfectly leveled between the PSG and the OPLL, otherwise the PSG will sound too louder. If you test MicroCabin games (quick tip: use the Disk-2 of Xak ToG to test it, and also try FF1), you see that the chords are now very well balanced between the PSG and the OPLL, forming beautiful harmonics just like the PC88 versions of the same musics. The PSG was used only to add more crispness and remove the sense of dullness from the FM chip notes. On Fray, the PSG is used to complement the high-hat and cymbal sounds, you'll get a much more realistic sound with this volume setting. Starship Rendezvous and Valis-2 Musics also get a much more pleasant result, as you can notice.

    If the OPLL volume is left at 9000, this equilibrium is broken and the PSG notes will sound too loud, shadowing the OPLL chords and completely destroying the smoothness of the harmonics. The musics then sound a lot different from this very same games on other computers/consoles. Specifically for Fray, the high-hat/cymbal sound will get noisy and will lose the realistic achievement MicroCabin got. Starship Rendezvouz and Valis-2 musics result in a nearly unbearably loud PSG drumkit.

  • About the YM2413: it has 2 outputs MO and RO (Melody Output and Rhythm Output) and according to the application manual (Figure III-3 on page 19), MO only has the melody output and RO only the rhythm output. Also, someone like Meits just confirmed this behaviour: the 9 FM channels are always at one side and the rhythm sounds on the other, 6 or 9 channel melody mode doesn't make a difference for that.

    So, I think the channel distribution we have now is correct.

  • SD Snatcher
    SD Snatcher

    Humm. Maybe it's the compatible U3567 chip used on many of those ExpertTurbo/Expert3 and on the Tecnobytes FM Sound Stereo.

    There's a picture of the U3567 OPLL here:

    The chip is described on details on this article by Sturaro (in portuguese):

    As a measure to confirm the real sound, I asked for people to send me recordings of the Stereo output of the ExpertTurbo using the YM2413 and after that using the U3567 to compare the results.

    That would confirm the correct channel separation for each chip. I didn't checked if the ExpertTurbo I tested long ago (the one that had the 1-6/7-9 channel separation as I mentioned) had an YM2413 or an U3567 inside.

    Let's then keep the current channel separation (MO/RO only) on the xml file until someone send the recordings.

  • I implemented something in revision 12078. I'll repeat the commit message below. Please verify if it's enough for this RFE (and then close this RFE).

    Support different <window> specifications for a <rom>

    We already have support for multiple <sha1> tags inside a <rom> tag in a
    hardwareconfig.xml file. This way you can specify alternative files (e.g.
    different revisions of a rom, or different dumps of a diskrom with different
    values for the memory mapped registers). We also support a <window> tag inside
    <rom> to specify that only a part of the (bigger) file is to be used.

    But before this patch it was not possible to specify different <window> tags
    for the different <sha1> alternatives. This can be useful if you want to model
    the hardwareconfig.xml more like a real MSX machine: one big ROM file of which
    each MSX ROM device uses a smaller portion (this can be already be modeled).
    But in addition, for convenience and backwards compatibility, you ALSO want to
    specify 'split roms' in your config file.

    We now support multiple <rom> tags inside MSX device configs. Each <rom> is an
    alternative. Each with it's own (optional) <window> tag and (list of) <sha1>
    tags. The <rom> tags inside a device config are tried in order when trying to
    load the rom file.

    Note that some devices (like 'Bunsetsu') already have two <rom> tags. Though
    each of these must have a different 'id' attribute. Now you can specify
    alternative <rom> tags for each of these two by specifying multiple <rom> tags
    with the same 'id' attribute.

  • In the mean time I updated the config file of the CIEL and XDJ to use the EPROM dumps with the new mechanism and provide fallbacks for split ROMs. The PSG balance has also been fixed for the CIEL.

    Still to do is the volume balance and the sound recordings to confirm the weird channel split you mentioned :)

    • status: open --> closed
    • Group: --> Next_Release
  • I guess we can close this one, as the original problem has been solved. It's now possible to use EPROM dumps.

    See also:
    commit 1cb0af4064baa79013ba25c7d14fe185a4b206db
    Author: Wouter Vermaelen m9710797@users.sourceforge.net
    Date: Wed Mar 30 20:22:09 2011 +0000

    Support different <window> specifications for a <rom>


    commit a9524f26948b2e0c2503a1972490fb6e3f751e19
    Author: Manuel Bilderbeek Manuel.Bilderbeek@gmail.com
    Date: Fri Apr 1 20:31:07 2011 +0000

    Also make use of the single available EPROM dump for the CIEL Expert-Turbo.

    commit d50199858e1ef9ca6be195cec2f30517788cc89a
    Author: Manuel Bilderbeek Manuel.Bilderbeek@gmail.com
    Date: Fri Apr 1 19:52:07 2011 +0000

    Make use of new feature to use multiple ROMs and added the EPROM dump FRS ma