Tux
-
Posts
1,060 -
Joined
-
Last visited
-
Days Won
219
Content Type
Profiles
Events
Forums
Blogs
Downloads
Posts posted by Tux
-
-
del key by default, but it's very primitive, it's a kind of mega turbo mode, it works as long as you keep the key pressed, but warning if you have a fast computer it can go really really fast !
-
Sorry I stopped !
I'll reply to 1 anyway : just don't do that ! Without kidding, I have played quite a lot this game since I tested this translation long ago and I never called the gui while on the main menu. It's interesting to know there is a bug here and it's probably something very stupid, but I don't want to spend time on it for now, sorry !
And I didn't even read past that ! (maybe I'll do later though)
-
38 minutes ago, petran79 said:
Because of other emulators like Retroarch cores and Duckstation supporting chd, converting the cue/bin files to chd for Neo Geo CD, Saturn, PC Engine and PS1 games, almost saved me 50 GB of storage.
But this emulator is more user friendly than Retroarch's Neo Geo CD mednaffen core.
And if you use zip+mp3 or zip+ogg for your neocd games it will be much smaller than any chd anyway !
-
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 ! -
18 minutes ago, Robert said:
This machine only has 2 memory slots, so I added a 128MB simm, which the bios recognised (total of 192MB).
But trying to run wakuwak7 still blew up halfway through loading (file 000-lo.lo)
First attempt caused the computer to reboot, 2nd attempt did the same as earlier (screen goes weird and computer froze).
Seriously though, I doubt I'll ever use the DOS version for anything apart from doing tests for you.
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 !
-
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 !
-
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 !
-
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... !
-
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... !
-
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... !
-
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-0.96.7.7z
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 !
-
2 hours ago, Robert said:
You'll need to physically identify the card, download the dos drivers for it and install them. The install will add some lines to your autoexec.bat file.
If it's Creative Soundblaster compatible, then you could probably just get the SB 2.0 driver and give that a go. It will tell you if the card is suitable.
After all that, the BLASTER variable is still needed, but the install will set that in autoexec.bat as well. My default settings are IRQ 5, DMA 1, High DMA 5.
I have a DOS machine that I use for testing things, and it also has various versions of windows 3.x as well. Obviously the sound card is different to yours, being in a ISA slot, and being a real Creative card.
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.
-
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...
-
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 !
-
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 4.2.3.1).
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.
-
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 !
-
45 minutes ago, theelf01 said:
Hi! thanks, i will give some feedback about dos version. At least in my 4 Pentium DOS computers sound is broken, i have
Pentium 1 mmx + CMI8330 (SB16 compatible)
Cyrix MII 366 + SB16
Pentium Pro 200 + AWE32
Pentium 3 1ghz + AWE64
Sound blaster 16 sound ir garbled, and make emulation slow. SB 1-Pro is not working, silent
this is last version with working sound
https://raine.1emulation.com/archive/rained-0.91.9.7z
this one have broken sound and is like the last one
https://raine.1emulation.com/archive/rainead-0.91.9.7z
thanks for your great work!
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... !
-
1 hour ago, theelf01 said:
Thanks for reply! sorry not feedback on the momment
I tested tripple buffer with S3, nvidia 128, geforce, voodoo 3, cirrus logic cards and nothing work
do you have latest DOS source code? or 0.6x? to compile and try to fix myself if i can, if yes, do you use djgpp?
thanks
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").
-
Out of luck here, I remember cleaning up old files not too long ago and deleting a rained.7z file which I didn't recognize... ! Well if I remember correctly I didn't get much feedback from this build, so I don't know if the changes inside were merged into the main version or not, but I'd say it's likely.
Anyway, even with PCem and in 16bpp with univbe, I still can't enable triple buffer, and it doesn't say why, it just says it can't, so I can't test that at all.
-
Hum, looong post... !
Well no need for an update since the update can be loaded with the crc warning. Let's wait and see... !
Your return key is just the gui way of working at its base : no button, then the only key handled is ESC to close the dialog, or button 2 of the mouse etc...
If there is at least 1 button, then either Return or the 1st letter of the string inside the button selects it. And yeah sorry I don't think about adding a button all the time, this gui accepts dialogs without any button so I use this sometimes, but sometimes it just feel right to have a single ok button below the message. Just accept it that's all !
Double line in the crc message : after looking at the code it's actually inherited from the dos version, which explicitly added the double line feed, so I did the same without wondering anything. Oh well you are the only one reacting to this kind of detail... More interesting is the fact that this particular last line escaped from the translations, I'll have to try to update them then... Ok, updated for the french translations, a few new strings to translate eventually for the others too... I'll update the others with empty strings for now. Also there is only 1 line feed now, although you are probably the only one interested by that !
For the crc error : it's very rare to actually need the 2 crcs at this point. Those who need it can check the zip archive. The crc displayed is the expected one, and for zip at least, when the message is added the actual crc of the file is not even known, it just knows it's different ! So I will leave it like that.
-
4 minutes ago, Neville said:
Glad you figured it out, unfortunately I didn't have the time to test it myself. PCem seems to have been abandoned, which is a pity, but there are forks of it that are still active, such as 86Box.
I actually wrote a guide on PCem back in the day. You can read it here.
Well for emulating raine in dos I wouldn't need anything more, everything works perfectly, sound rdtsc, even some vesa modes using univbe, eventually some svga chip supporting more vesa modes but even with the few I had it was enough to test. And even with the windows version I used, which works perfectly in wine.
it was abandoned, but then taken again by someone else, I don't remember the details, but yeah there seems to be quite some chaos in the x86 emulation world currently (even dosemu & dosbox seem to have a hard time creating their next stable release).
Anyway thanks for the info, it was useful and allowed me to fix a few bugs related to the sh2 emulation, even if there are still some problems with this dos version, it's better, and a working version in 2024 is already quite a feat !
-
Most of the changes in this one are for the dos version and were released as 0.96.6 for dos anyway, but :
- fixed an amazing bug for pengo which was here since 0.43.2, that was in september 2005 !!! See the thread in the forum if you want details.
- galaga will now display a message when loaded if it can't find anything for the explosion sample, you can ignore it, it's for info.
- gui fixes : games states, transparency, length of game title + size at bottom of screen.
- a new "color theme", it was just because I noticed the dos version had actually 3 color themes, but it was done simply by rotating the colors rgb values, here it's a little more involved. Anyway the red theme had been forgotten in the sdl versions...
http://raine.1emulation.com/download/latest.html-
2
-
-
And finally fixed the text truncation, for info the string was cut at 99 characters long because we still need finite buffers to store strings, it seemed to me that 99 characters was way enough for name (size), but some crazy games like samshope seem to need more... I think this name should be shortened, but I enlarged the buffer to 200 characters to avoid this kind of problem in the future anyway.
-
1
-
-
Didn't know it neither, might be very old, it's not amongst the most played games... ! Reproducible with the asm version too...
It was extremely old indeed, from between 0.43.1 & 0.43.2 ! But it was a stupid mistake, related to how regions with more than 1 gfx layout are handled, the big target here was cps2, and it got most of the work, and pengo stayed with some not totally finished code, which produced this effect. The fix is 2 lines only actually, but it took me quite a while to find out what happened !
Thanks for the report !
-
1
-
memory allocation debuging in raine...
in Raine
Posted
In the old days (!), I used something very convenient for that, electric fence, it just created a crash as soon as a read or write was done outside a normal area, then you just used a debuger to find what line triggered this exactly.
But the problem is that multi threaded programs are not supported by electric fence and these days everything is multi threaded (quite normal with all the cores in the cpus now). And so I was left with sub optimal ways to try to debug memory stuff in raine for years.
I tried some, like memwatch which can have its uses, but doesn't track everything so it's a lot less useful than what I had before. Then with clang came -fsanitize=address, a compiler command line argument, which is now handled by gcc too. And this thing works amazingly well ! Most of the asm code is even supported (except the 68020 stuff mostly). I should probably have spent more time playing with this when I added clang support, but I had a lot of stuff to finish at the time. Anyway I finally tried this thoroughly and it produced quite a few fixes in git already :
- for the okim6295, this stuff is very old but there was a clear buffer overflow for old_bank, I suppose since it was a small array it had some limited effect and didn't create any crash but it could have. That's the most serious one i got so far.
- all the others are mostly read overflows and since it didn't crash it had no effect, but it's better to have them fixed anyway.
These fixes are in git, and they replace memwatch in debug builds for now.