Jump to content


Ultra Members
  • Posts

  • Joined

  • Last visited

  • Days Won


Tux last won the day on January 24

Tux had the most liked content!

1 Follower

About Tux

Profile Information

  • Gender
  • Location
    Nantes, France

Recent Profile Visitors

6,397 profile views

Tux's Achievements


Experienced (11/14)

  • Posting Machine Rare
  • Dedicated Rare
  • Very Popular Rare
  • Conversation Starter Rare
  • First Post Rare

Recent Badges



  1. Tux

    Worth mentioning...

    Some company released some old toaplan games as new games on steam lately : vimana : https://store.steampowered.com/app/2023170/Vimana/ batsugun : https://store.steampowered.com/app/2023000/Batsugun/ fixeight : https://store.steampowered.com/app/2023180/Fixeight/ they are cheap, but they look awfully like the original game running in an emulator... ! Also there is king of fighters 15 : https://store.steampowered.com/app/1498570/THE_KING_OF_FIGHTERS_XV/ this one is really an original game at least, I don't know if it's any good though !
  2. You might have a hardware problem then, I just tested with 128 Mb and 192 Mb on pcem (virtual pentium2-300 gigabyte motherboard), and the game runs fine in both configurations (slight cracking of sound during neogeo intro though, sound sync is a lot worse in dos than in windows or linux, and it's even worse if using seal). Yeah you need a fast cpu to handle that much ram otherwise it becomes a real pain. What dos lacked : hardware accelerated drivers, maybe it could have been done but microsoft preferred to kill it. It's better to leave it dead now, unless being obliged to use it, there are much better alternatives now... But thanks again for the tests !
  3. 76 Mb for wakuwak7 (+ the emulator). Theoretically there is a message when you run out of memory, but sometimes the dos prefers to just crash like that, tss.... ! Thanks for the test anyway, it's enough to say the normal version should work in most reasonable setups, with the seal version as a last resort in case of problem. And if both don't, well give up the dos ! Actually you can have any amount of ram in dpmi in dos, but it becomes a little special to configure if it's more than 256 Mb of ram. It's probably limited to 4 Gb for the 32 bits limit, but you'll never need that much. I have tested with 512 Mb using PCem, and it works !
  4. I finally understood the problem, at least for my setup : it's just some crappy sb16 emulation software by creative which eats the interrupts when in protected mode (the program itself is not in protected mode, so any protected mode handler is very likely just ignored). I lost 2 days because of seal, but seal doesn't use its interrupt handler at all in fact, it's here just to be sure sound is updated that's all, it just acknowledges the interrupts without doing anything else. That also explains why it worked in pcem and not on some real hardware : on pcem the sb16 is directly emulated and not by some crappy software by creative which doesn't know a thing about protected mode ! So to sum up : this card is just badly supported in dos, that's all. Now I don't know the details of all the configurations out there, if someone can test this on an isa soundcard later, he is welcome to, but normally it should work ! Sorry to have doubted of allegro, it wasn't their fault this time !
  5. Apparently it's the irq handler which is never called ! Which is totally insane because djgpp doesn't evolve a lot, I mean the way to install an irq handler has probably not changed at all in the 20 last years, so you can wonder if this code ever worked with djgpp actually ? It's a total nonsense... The problem is that it's a critical place of the code of course, so it's not an easy fix... !
  6. I don't know, maybe ? I mean, I never knew the mcu was used for any game logic in this game, it handles inputs and protection, it mainly makes life harder to emulate it, but it doesn't do magic. But never been a big fan of this one myself, so I can't say I know much about it. It was mainly the work from Kayamon, the crazy guy who made the 68705 mcu code in raine... ! One of his last comments in the driver is : changes/kayamon: 30/8/99: - added Knight Boy, dunno if it was worth it though. - NOTE: MCU is tested for KKK, seems to be 100%, so any problems are most likely due to the rest of the hardware instead. So emulation of the mcu was considered complete, and that's what I thought too... !
  7. Well in my case this pc doesn't have any isa port, so this was not an option ! What is sure is that it was the end of creative, at this point soundcards started to be merged in the motherboards, except for some very specific uses. No problem for the delay, this thing has probably been here for years before being noticed... ! I made a few more tests on my end because we still have seal sources to compare, I thought it was just a simple timeout problem with the dsp, but no luck, it doesn't fix anything for now. It's extremely hard to debug some low level stuff on dos, especially when you are used to work with higher level stuff as we are today... ! An interesting problem anyway, I'll probably try again later... !
  8. Well anyway here is a link to the latest dos version but using seal this time, it's the only known workaround for now when getting no sound : http://raine.1emulation.com/archive/raine-seal- Seal is supposed to be more primitive, its awe32 driver doesn't seem to work, I just tested on bubble bobble and it seems to sound ok at least on this game, but anyway it's the only solution for now !
  9. If you could test the latest dos version on one of your isa sound cards... I think the driver creates a virtual port to handle requests, and it just doesn't work with the allegro driver, but it might work with a normal isa card. The problem is the same when using one of their test program to play a sample so at least the error is not from me.
  10. Yeah I know that, but thanks for making me curious enough to have a last look at it, it's an old compaq computer, so I don't like messing with the internals, but I have seen worst configurations. Finally it's a "Creative CT4750", which seems to be a sbpci. I found a very good page to configure these old cards in dos there : https://retronn.de/imports/soundblaster_config_guide.html and then their ftp site with all the drivers you might want : ftp://retronn.de/driver/Creative/ In short : the pci cards use the blaster variable just for compatibility with the old dos applications, they don't need it anymore, they work totally differently, and so they require a program to be loaded to handle them, it can either be the windows driver (I am sure it's the 1st time I do this configuration for dos !), or like here the right dos program to load, the environment variable alone can't do anything. And with all this I was finally able to make it work ! And to my dismay, I confirm the bug, as incredible as it may sound, nothing can be heard with the allegro sound drivers when seal drivers work perfectly ! Allegro is really a big pile of bugs, it was part of the reason for switching to sdl, I would never have thought they would manage to still annoy me after all this time !!! The problem is what to do with that ? Most sites keep this allegro version as the last stable allegro version for dos... ! The short solution is to have seal, even though seal is sub optimal, at least it works ! Oh well, I'll make a few tests maybe and update this later...
  11. I tried to resurrect a very old pc I had around here, 128 Mb of ram, 1 GHz cpu, setting up a pure dos boot was already hard for it, but I finally found something. But I failed miserably at the sound card configuration. There is a sounblaster compatible pci card in it, but I don't remember which card it is exactly. Maybe there was a windows driver with the card, it's very old stuff. I assumed it would work with just a blaster environment variable in dos, clearly it doesn't ! Oh well, I'd say all this is just a big waste of time, I would never have thought it could be that hard to just setup a sound card in dos... ! So for now I give up, unless I find what this card is precisely and how to configure it in dos, there is no way, and for now I don't have the faintest idea !
  12. Yeah that's strange, even though allegro had some astounding bugs I can't believe its sound system doesn't work correctly with the vanilla hardware, there's something off... Maybe they are still on the web too, a place to send some message ? Also be sure to test from the other thread : go to mode-x 320x240 (8 bpp, all mode-x are 8bpp), and then try to enable triple buffer, the advantage is that it can be tested on any vga card, no need for vesa3 for this. I get a black screen in pcem when doing this, but it might do something more on a normal pc. Maybe you should try some test programs from allegro4 to test sound... Quite a lot of people used this lib so I can't believe it couldn't work on the original hardware... edit : I found a related thread on their site there : https://www.allegro.cc/forums/thread/596505/0 it's not exactly your problem, it seems related to the sbpro 8 bits samples and doesn't affect sb16, but it's still a very buggy sound driver in allegro 4.2.2 (by the way the allegro in raine here is Well, I'd say if you really want to go to the bottom of this, you'll have to test directly some allegro versions then, there is a sample program to play samples, hopefully it will be enough to check the quality of the sound, build some version and see what you get. The thread tracked the bug appearing in 4.1.15 apparently... ! Luckily allegro is quite fast to build, at least on a modern machine. I remember that at that time I had already some sb compatible card and it worked well for me at the time with raine... Each time I find such a big bug in allegro I am amazed, their documentation feels like it's an almost professional project, and then you find astounding bugs in it... an alternative would be to find another sound library, but testing a new sound driver in raine would take ages, so no thanks. Well I can also post the seal binary if you want it.
  13. After testing : yeah I confirm, this ad version is for allegro sound, that's the same thing used in the latest 0.97.6 binary, both use correctly the sb16 in pcem for me. and when clearing the blaster environment variable (set blaster=), I still get sound with the allegro version, so it uses some autodetection if there is no blaster environment variable after all, but only silence with the seal version, which is the last one which worked for you. I can post the seal binary for the latest version if you want, I still have seal around here, but it has only SB and awe32 driver, nothing for sb16, plus no autodetection, seal is officially dead since the end of 1999, so it would be better if you managed to fix your sound with the allegro version !
  14. You pointed both time to 0.91.9 to be the last dos version with working sound, and then having broken sound. (ah ok, the 2nd link is for the ad version, sorry my bad). Well if I am not wrong this a was for allegro, if that's right then the last released binary (0.97.6) also uses allegro sound. Anyway this 0.91.9 is from 2020, you could have posted earlier... ! Well I had sb16 emulation working in pcem but it doesn't do any autodetection, it relies entirely on the BLASTER environment variable, if you set it badly, you don't hear a thing. It's a little strange you don't get any sound on a sb16, it's the base card for a lot of things, but if you double checked this blaster environment variable, there is not a lot more things I'll be able to do... !
  15. Yeah the sources are available of course. Some sources archives are on this site, up until 0.51.11 I think. If you want something more recent, use the github icon to go to the github page, click on the tags to select the version you want, then it will give you links to download the sources for this version in zip, or tar.gz. The problem is allegro, you need to find some sources for allegro4, then there are some patches, I use these, some from arch linux which probably come from somewhere else, some from the old days of Antiriad with the dos version : patch -p0 < ${startdir}/makefile.all.djgpp.patch patch -p0 < ${startdir}/makefile.dj.djgpp.patch patch -p0 < ${startdir}/misc_mdhelper_sh.djgpp.patch patch -p0 < ${startdir}/src_misc_vbeafex_c.djgpp.patch patch -p1 < ${startdir}/diff-inline patch -p1 < ${startdir}/raine_hacks.patch patch -p1 < ${startdir}/vesa.patch Of course all this is for djgpp. I compiled the whole thing for version 0.96.6, and it worked quite well with PCem, which is quite a serious emulator for old x86 hardware... The best I could do with triple buffer is trying to enable it from a 320x240 mode-x -> black screen (instead of the usual error message "Can't enable triple buffer").
  • Create New...