Tux

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.

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)

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 !

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 !

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 !