Got ioperm.sys working.

chocolate-doom.cfg:
snd_samplerate 44100
opl_io_port 0xe850

Output:
S_Init: Setting up sound.
IOperm_InstallDriver: ioperm driver already running.
OPL_Init: Using driver 'SDL'.

Although, according to README.OPL, I should be expecting:
OPL_Init: Using driver 'Win32'.

For all I know it could be working.
No biggie though, just thought it would be neat to try.

Share this post


Link to post

do you know for sure the base address is 0xe800? maybe look in device man? (its been over a decade since i used windows heh)

Share this post


Link to post

hmm, so the io port should 0xe850 (for a model 55, for 37 and below, use the standard 0x388)

Share this post


Link to post

can you play opl midi with the built in DirectMusic stuff in DirectX? (I could in wine lol)

Maybe the card needs activating in windows?

Its done on linux with options snd-cmicpi mpu_port=0x330 fm_port=0x388 in modprobe.conf

Maybe chocolate doom could be patched to send the init code to the card in windows?

Share this post


Link to post
Randy87 said:

Got ioperm.sys working.

chocolate-doom.cfg:
snd_samplerate 44100
opl_io_port 0xe850

Output:
S_Init: Setting up sound.
IOperm_InstallDriver: ioperm driver already running.
OPL_Init: Using driver 'SDL'.

Although, according to README.OPL, I should be expecting:
OPL_Init: Using driver 'Win32'.

This implies that it's probably trying to detect a hardware OPL device but failing to find anything.

What card do you have? CMI8738 like Lemonzest has? You may find that you have to do something with your driver to get it working.

For example, I have a Yamaha 724 card, which has hardware OPL on board, but there's a "Legacy OPL" flag in hardware that needs to be turned on by the driver for it to be enabled. The Linux driver has a setting to turn it on, but the Windows driver doesn't and I've never been able to get it to work on Windows. The CMI drivers might be similar.

Share this post


Link to post

2956 static int __devinit snd_cmipci_create_fm(struct cmipci *cm, long fm_port)
2957{
2958        long iosynth;
2959        unsigned int val;
2960        struct snd_opl3 *opl3;
2961        int err;
2962
2963        if (!fm_port)
2964                goto disable_fm;
2965
2966        if (cm->chip_version >= 39) {
2967                /* first try FM regs in PCI port range */
2968                iosynth = cm->iobase + CM_REG_FM_PCI;
2969                err = snd_opl3_create(cm->card, iosynth, iosynth + 2,
2970                                      OPL3_HW_OPL3, 1, &opl3);
2971        } else {
2972                err = -EIO;
2973        }
2974        if (err < 0) {
2975                /* then try legacy ports */
2976                val = snd_cmipci_read(cm, CM_REG_LEGACY_CTRL) & ~CM_FMSEL_MASK;
2977                iosynth = fm_port;
2978                switch (iosynth) {
2979                case 0x3E8: val |= CM_FMSEL_3E8; break;
2980                case 0x3E0: val |= CM_FMSEL_3E0; break;
2981                case 0x3C8: val |= CM_FMSEL_3C8; break;
2982                case 0x388: val |= CM_FMSEL_388; break;
2983                default:
2984                        goto disable_fm;
2985                }
2986                snd_cmipci_write(cm, CM_REG_LEGACY_CTRL, val);
2987                /* enable FM */
2988                snd_cmipci_set_bit(cm, CM_REG_MISC_CTRL, CM_FM_EN);
2989
2990                if (snd_opl3_create(cm->card, iosynth, iosynth + 2,
2991                                    OPL3_HW_OPL3, 0, &opl3) < 0) {
2992                        printk(KERN_ERR "cmipci: no OPL device at %#lx, "
2993                               "skipping...\n", iosynth);
2994                        goto disable_fm;
2995                }
2996        }
2997        if ((err = snd_opl3_hwdep_new(opl3, 0, 1, NULL)) < 0) {
2998                printk(KERN_ERR "cmipci: cannot create OPL3 hwdep\n");
2999                return err;
3000        }
3001        return 0;
Thats the init code from cmicpi.c in linux (I assume its the init code)

and the YM724 code looks like this (ymfpci.c)
 207        if (pci_id->device >= 0x0010) { /* YMF 744/754 */
 208                if (fm_port[dev] == 1) {
 209                        /* auto-detect */
 210                        fm_port[dev] = pci_resource_start(pci, 1);
 211                }
 212                if (fm_port[dev] > 0 &&
 213                    (fm_res = request_region(fm_port[dev], 4, "YMFPCI OPL3")) != NULL) {
 214                        legacy_ctrl |= YMFPCI_LEGACY_FMEN;
 215                        pci_write_config_word(pci, PCIR_DSXG_FMBASE, fm_port[dev]);
 216                }
 217                if (mpu_port[dev] == 1) {
 218                        /* auto-detect */
 219                        mpu_port[dev] = pci_resource_start(pci, 1) + 0x20;
 220                }
 221                if (mpu_port[dev] > 0 &&
 222                    (mpu_res = request_region(mpu_port[dev], 2, "YMFPCI MPU401")) != NULL) {
 223                        legacy_ctrl |= YMFPCI_LEGACY_MEN;
 224                        pci_write_config_word(pci, PCIR_DSXG_MPU401BASE, mpu_port[dev]);
 225                }
 226        } else {
 227                switch (fm_port[dev]) {
 228                case 0x388: legacy_ctrl2 |= 0; break;
 229                case 0x398: legacy_ctrl2 |= 1; break;
 230                case 0x3a0: legacy_ctrl2 |= 2; break;
 231                case 0x3a8: legacy_ctrl2 |= 3; break;
 232                default: fm_port[dev] = 0; break;
 233                }
 234                if (fm_port[dev] > 0 &&
 235                    (fm_res = request_region(fm_port[dev], 4, "YMFPCI OPL3")) != NULL) {
 236                        legacy_ctrl |= YMFPCI_LEGACY_FMEN;
 237                } else {
 238                        legacy_ctrl2 &= ~YMFPCI_LEGACY2_FMIO;
 239                        fm_port[dev] = 0;
 240                }
 241                switch (mpu_port[dev]) {
 242                case 0x330: legacy_ctrl2 |= 0 << 4; break;
 243                case 0x300: legacy_ctrl2 |= 1 << 4; break;
 244                case 0x332: legacy_ctrl2 |= 2 << 4; break;
 245                case 0x334: legacy_ctrl2 |= 3 << 4; break;
 246                default: mpu_port[dev] = 0; break;
 247                }
 248                if (mpu_port[dev] > 0 &&
 249                    (mpu_res = request_region(mpu_port[dev], 2, "YMFPCI MPU401")) != NULL) {
 250                        legacy_ctrl |= YMFPCI_LEGACY_MEN;
 251                } else {
 252                        legacy_ctrl2 &= ~YMFPCI_LEGACY2_MPUIO;
 253                        mpu_port[dev] = 0;
 254                }
 255        }
looks like as with cmipci, you can have ports in pci space (fm_port=1) or legacy (fm_port=0x388)

Maybe in windows you could send the init sequence to the cards because the driver does not? as mentioned this is no problem in linux usually.

Share this post


Link to post
Lemonzest said:

Maybe in windows you could send the init sequence to the cards because the driver does not? as mentioned this is no problem in linux usually.

It wouldn't be appropriate or technically feasible to do so. It's the job of the driver to do it; if it doesn't provide a setting for it then there isn't really any other practical option.

Share this post


Link to post

The driver control panel's got nothin.
Device manager doesn't have a single changeable option... anywhere.
I may fire up linux and give it a try sometime.

As a note, there are open source windows drivers for this card.

Share this post


Link to post
Randy87 said:

As a note, there are open source windows drivers for this card.

Hard coding the driver to enable OPL shouldn't be too hard.

Share this post


Link to post
fraggle said:

It wouldn't be appropriate or technically feasible to do so. It's the job of the driver to do it; if it doesn't provide a setting for it then there isn't really any other practical option.


Well I was more thinking along the lines of an "Enabler" for the windows users not in chocolate-doom itself.

Share this post


Link to post
Lemonzest said:

Well I was more thinking along the lines of an "Enabler" for the windows users not in chocolate-doom itself.

Well, as I said, I don't see how it would even be technically feasible in any easy sense. Because of memory protection you'd basically have to do something like install another driver that would somehow find the appropriate memory address and set it.

If there are open source drivers (as Randy87 says) then that might be a viable option. If you can link to the source I can take a quick look; there might even be an option there already.

Share this post


Link to post
Randy87 said:

Thanks. I had a look through the code and foudn this in cmireg.hpp:

#define REG_LEGACY    0x14       // Legacy Control Register (32bit)
#define CENTER2LINE   0x00002000 // route center channel to line-in jack
#define BASS2LINE     0x00004000 // route bass channel to line-in jack
#define EN_6CH_CH1    0x00008000 // enable 6 channel mode on channel 1
#define DAC2SPDO      0x00200000 // enable PCM+FM to S/PDIF out
#define EN_SPDCOPYRHT 0x00400000 // enable S/PDIF out copyright bit
#define EN_SPDIF_OUT  0x00800000 // enable S/PDIF out
#define UART_330      0x00000000 // i/o addresses for UART
#define UART_320      0x20000000
#define UART_310      0x40000000
#define UART_300      0x60000000
#define DWORD_MAPPING 0x80000000 // enable DWORD-based position in base register
Compare this with the LEGACY register definition in the Linux kernel source. You'll see that the MPU401 definitions are there but the corresponding ones for 'FM' are missing. If you look further down at the REG_MISCCTRL definitions and compare with this you'll also find that the crucial 'CM_FM_EN' bit is missing as well. This all implies that the driver doesn't support it.

Theoretically it should be fairly trivial to implement, but I don't have a Windows machine, a development environment I could use to do it, or the appropriate card immediately available to me. Your best bet is probably to contact the author of the driver but it looks like there hasn't been a new release of this driver since 2009, so don't get your hopes up.

The author also mentioned disabling MPU-401 support if that means anything.

The MPU-401 was an interface for connecting to external MIDI devices - most SoundBlaster-type cards were compatible with it. Doom supported it as a music device: if you had a hardware MIDI synthesizer (like the Roland SC-55 used by Bobby Prince to compose Doom's music), you could configure Doom to send MIDI events to it, and get higher quality music than what you'd normally get out of an OPL chip.

It's worth pointing out that DOSbox supports the MPU-401 interface as well - if you run Doom in DOSbox configured to output to MPU-401, it will send the MIDI events to the OS's built-in MIDI output. If you do it on OS X (which has a pretty good MIDI synth) it sounds quite nice :)

Share this post


Link to post

Thanks for taking a look Fraggle.
Just thought it would be something interesting to try.

Unfortunately nothing plays through the MPU-401.
I might get around to trying it out in linux sometime.
See if I can get any OPL/MPU output.

Share this post


Link to post
fraggle said:

  • snd_channels is 8 instead of 3, which is a more sensible default nowadays


  • The way I see it (the anally-retentive vanilla freak kind of way), configs should (if technically possible and not that difficult) be identical, whether it's the one generated with the setup tool or the slightly different one generated after running the game executable itself (let me know if you want the confirmed CRC32's)

    I don't personally agree to the new "sensible" default values for this setting, specially when "screenblocks" still gets the original values even though PC's have been able to use at least 10 without any noticeable performance loss for centuries now.

    I say give all default.cfg settings vanilla values and save the "sensibility" for chocolate-doom.cfg :)

    Switching subjects. V2 is no longer able to use a high libsamplerate value with certain pwads, like Plutonia 2, it crashes like it used to a while ago. Just wanted to know if I should post this at the official bug tracker, since it looks like a regression.

    Share this post


    Link to post
    fraggle said:

    Theoretically it should be fairly trivial to implement, but I don't have a Windows machine, a development environment I could use to do it, or the appropriate card immediately available to me. Your best bet is probably to contact the author of the driver but it looks like there hasn't been a new release of this driver since 2009, so don't get your hopes up.


    Unfortunately we'd have to rule that out as well. Someone already asked for OPL-enabled drivers and dogbert basically said "OPL sucks, code it in yourself", or something like that.

    This is truly a waste of good OPL hardware.

    Share this post


    Link to post
    Porsche Monty said:

    Switching subjects. V2 is no longer able to use a high libsamplerate value with certain pwads, like Plutonia 2, it crashes like it used to a while ago. Just wanted to know if I should post this at the official bug tracker, since it looks like a regression.

    v2-branch is using an older version of the libsamplerate code. A while back I received some updates for the code from David Flater, which I applied to trunk. However, when I went to merge the changes onto v2-branch, the updated code conflicted with some other changes that I made for supporting the other games. The conflicts were taking too long for me to resolve so I abandoned it with the intention that I'd do the merge later. Unfortunately I never got round to doing it, so it's still using the old version for the time being.

    Share this post


    Link to post

    Thanks for the explanation.

    I know you're a busy man, but...any chance for a fix any time soon?

    Regards.

    Share this post


    Link to post

    I found some bugs while testing my level, could you help me to identify them and explain them to me? screenshots bellow

    [picture no longer working]

    [picture no longer working]

    these bugs do not appear in gzdoom and prboom+ so i assume that these are chocolate-doom's fault

    Share this post


    Link to post

    Screen 1: vanilla Doom can only tile vertically correctly textures that are 128-pixel tall. SKSPINE2 is 96-pixel tall.

    Screen 2: the ceiling flats on both sides of the mid texture are identical (same height, same texture, same light level) so they are merged into a single visplane with no "edge" with which to clip the midtexture. Introduce a difference (for example, increase light level by just one unit on one side, it will not be noticeable by the player) if you want to trick the rendering engine into forcing the midtexture to be clipped.

    Screen 3: no idea on the top of my head.


    In any case, given ChocoDoom's mission statement, none of them are Choco's fault unless vanilla Doom doesn't have the same bug. Since one goal of Chocolate Doom is that it can be used to test compatibility with the unmodified original game, it is supposed to bug, glitch and crash in the same ways and for the same reasons as the original.

    Share this post


    Link to post

    Hi there,

    I'm new at DoomWorld forums, and I came here so I could learn more about Doom sourcecode, since I'd like to hack my own "features" and adapt it to my needs.

    So, in the first place, I'd like to find out if it's possible to have "uncapped fps" in Chocolate-Doom, as it's the sourceport I find more interesting right now.
    Why uncapped FPS on Chocolate-Doom given it's goal is to emulate original Vanilla Doom, wich ran at 35 FPS? Well, Vanilla DOS Doom ran at 35 FPS on a 70Hz display, so it looked pretty smooth. However, setting a 7Hz display on most of current SDL backends can be tricky if not impossible: for example, I've just implemented a KMS backend for SDL 1.2.x and while it works great for most games, Chocolate-Doom looks ugly with it's 35 FPS on 60Hz display, as KMS doesn't offer 70Hz modes over any HDMI output I've seen in some ARM boards (Pandaboard, for example).

    So, in a nutshell, having 30FPs would be enough, but maybe I can eliminate some wait loop in the sources (ugly hack, I know) and get uncapped fps. Or you can point me to where in the sources is the FPS rate derived from other variables... :)

    thanks for your work in Chocolate Doom as it is, anyway!

    Share this post


    Link to post

    Abandon your hope for a quick hack: the playsim runs at fixed 35Hz and you'll either need to implement interpolation in the renderer (big project) or attempt to make playsim work with variable tics length (very likely to break in-game behavior in both obvious and subtle ways).
    Unless you are content with changing the game speed.

    Share this post


    Link to post
    vanfanel said:

    Hi there,

    I'm new at DoomWorld forums, and I came here so I could learn more about Doom sourcecode, since I'd like to hack my own "features" and adapt it to my needs.

    So, in the first place, I'd like to find out if it's possible to have "uncapped fps" in Chocolate-Doom, as it's the sourceport I find more interesting right now.

    Nope, sorry. It's not something the original did.

    If you're interested in hacking on your own source port, this is the kind of thing that would fit very nicely into a fork, though - along with various other features.

    Share this post


    Link to post

    Is it possible to bind inventory keys (i.e., "next item", "previous item", "use item") to the mouse wheel in Raven games?

    Share this post


    Link to post
    Janizdreg said:

    I'm curious, does this SourceForge change affect the Chocolate Doom wiki in any way?

    Saw this already about a month or so ago, and I don't believe it should, no.

    Is it possible to bind inventory keys (i.e., "next item", "previous item", "use item") to the mouse wheel in Raven games?

    I think there aren't mouse bindings for these actions at the moment, but there probably should be.

    Share this post


    Link to post
    twipley said:

    I have just gotten my hands on the 324 MB FLAC collection from LogicDeLuxe. It does not compare to the MIDI music (http://www.doomworld.com/classicdoom/info/music.php) as outputted by the "Microsoft GS Software Wavetable Synthesizer." For example, the birdsongs at the beginning of the d_bunny (end-of-game) music piece are almost inaudible as outputted through the software synthesizer, although full-blown as outputted through the intended hardware. It is a real shame for the software synthesizer to be that ineffective!

    kkaden said:

    I'd like to see support for audio packs, specifically so I can listen to the doom games' music as recorded from an SC-55.

    this is a great idea!

    fraggle: should a ticket be opened on the bug tracker to that effect?

    in other words, would such an implementation be a feasible undertaking?

    -- edit: one has been opened: http://sourceforge.net/tracker/?func=detail&aid=3560986&group_id=144368&atid=758618

    it is to be hoped the enhancement request is on a par with the objectives of the project. after all, it would have a hard time not being, as the main page notes "chocolate doom is a doom source port that accurately reproduces the experience of doom as it was played in the 1990s."

    Share this post


    Link to post

    I have noticed an odd issue. If you alt-tab in Chocolate Doom on Windows, and then navigate back to Choco by any means, the automap (or whatever you have bound to Tab) goes haywire. For some reason, Odamex exhibits the same behavior, but Eternity and pr+ do not.

    Share this post


    Link to post
    This topic is now closed to further replies.