Tux

Yeah you could do it on git, but since you don't compile of course it wouldn't be super convenient... Ok, it reminded me that the finalburn roms are on internet archive too, so I got my update from there, crcs updated and tested, finally... !

For the kof94 hack, it's a very well done one with ips patches, so you can add it by using the ips patches... yeah I know, you need to create the .dat files not to become crazy, but they are not that hard to do, it's pretty straightforward... Now there is still a question : there are 2 directories in the ipsPatches directory : a94, and a95, and both seem to contain very similar file names, so what's the difference between them ? I guess a95 is not just more recent than a94, it would be too easy... ! Well for the a94, you can create a94.dat by copy and pasting this in the a94.dat (and put it in the ips/kof94 directory, with the contents for the a94 directory from the ipsPatch folder in their github site) : 055-c1.bin kof94_a94.055-c1.c1.ips CRC(b96ef460) 055-c2.bin kof94_a94.055-c2.c2.ips CRC(15e096a7) 055-c7.bin kof94_a94.055-c7.c7.ips CRC(62f66888) 055-c8.bin kof94_a94.055-c8.c8.ips CRC(fe0a235d) 055-p1.bin kof94_a94.055-p1.p1.ips CRC(f10a2042) 055-s1.bin kof94_a94.055-s1.s1.ips CRC(825976c1) [en_US] a94 from https://github.com/city41/kof94te I tested with this one alone and you can already make your custom team, so I really wonder what a95 is about... Someone courageous to go to their discord server to ask what it's for ?

Well I had a look at sfz3mix, a hack from Brazil ! You should try to organize a tournament there... ! Yeah I know, Brazil is very big, but you never know... ! Anyway, never seen such a cps2 game, the regions are huge, and that's the only cps2 game using some dipswitches ! So for now the support is very preliminary, the rom loads, but half of the sprites are broken, and there is no sound ! I guess I'll have to spend more time on it if I want to understand how all this works... A really crazy hack indeed, it wins the prize of the craziest hack I have seen so far for an arcade rom ! Because it took me more time than anticipated I didn't look at your kof94 hack, but it should be easier normally, at least this one should be a lot like its parent rom, which is not the case at all for sfz3mix, it's supposed to be based of the phoenix version of sfa3 (sfa3ud), but in fact everything is totally different for all the regions !

Yeah well I don't know where the 2.0 rom is, and I don't even want to look for it anyway for now, it's very late after the party here. About the author's name it would probably have been better to have strings but we have int constants here, I guess antiriad chose this to optimize space thinking that since raine started mainly as a taito emulator there wouldn't be much change in the company name... it made sense at the time, raine grew a lot since then !

Er, no sorry, this is called backporting, there is absolutely no reason for me to do that. But so far the changes have been only to try to compile with sdl 2.0.10, you can try to start over with 0.92.1 to see how it works, it should at least get rid of these sdl compilation errors, but don't come crying because of all the other bugs which are inside... ! 0.92.1 is there in git : https://github.com/zelurker/raine/releases/tag/0.92.1 The part about fixing the asm bits can probably be put to a patch which you should be able to apply to this source too, hopefully !

Well I'll make this reply the shortest : it's obviously yet another problem because of sdl 2.0.10 which is clearly outdated here. So decide where you want to go from here. By the way you can view the changes in sdl since 2.0.10 there : https://github.com/libsdl-org/SDL/releases?page=4, 2.0.10 is towards the bottom of this page 4, at the top of page 1 you have the latest release.

Well, you should think about it twice before deciding, arch is not about dev only it has a huge package repository, I publish the arch packages here too but for x86 and x86_64 only so far. Just go to https://archlinux.org/packages/ and search the package you want, I doubt you wouldn't find it. Maybe take a look first to the site about the arm version in case it hasn't got 100% of the packages from the normal arch distrib. And you should take a look at the changes in raine since 0.92.1, it's *HUGE*, there were lots of fixes for the sdl2 port too and you would loose most of them by going back to 0.92.1. For the changes to git I talked about, it's because the NO_ASM version actually still uses some inline asm code, and it shouldn't, so it would be useful to all versions to clean this up, but no I don't plan to buy a pi, at least not for now... Notice that everyone seems crazy about arm these days though, after apple, microsoft just released their surface laptop based on an arm too, so maybe I'll have some arm computer in the future but it's not planned for now... ! (but I don't plan to ever try to port raine to osx again, the way apple develops osx is crazy from my point of view, willingly making old versions incompatible to force people to update, but it's crazy for the binary package with a maintainer who doesn't want to make new versions all the time just to please apple... !).

Wow, that's a long one this time ! 1) SDL2 is backward compatible, so you won't have any problem overwriting an old version with a more recent one, assuming it's still version 2.0.x. 2) For the distribution, there are lots of distributions on the pi, see there : https://linuxconfig.org/list-of-linux-distributions-available-for-raspberry-pi Personally, I prefer arch so I would advice the very last one in the page : linux arch on arm, but if you are still a beginner with linux you might have some hard time with it, if it's like the pc version, there is no install program, you must do most of the stuff manually, which is not a bad idea because it forces you to know your system well and it's not that hard if you follow carefully their guide. The advantage is that after that you get a rolling distribution which is always updated and the updates go very very fast on arch. For info sdl2 is at version 2.30.3 currently on pc, absolutely not comparable with your outdated thing... ! 3) the main problem here : it's even harder than the previous one obviously. This controllermap.c file is taken directly from the sdl source, with some light modifications, that's what you learn if you look at the git log about this file, and it explains why it crashes so hard when you try to compile it with an sdl version older that itself. The only sane way to fix that is just to remove the ability to edit the mappings of a controller ! For that : sdl/controls.cpp: delete line 1100 and then the whole do_mapping function from line 1102 to 1191. Then finally delete the gui call to do_mapping in line 1207, you should probably do this one 1st to keep the line numbers while going up, it's this line which should be removed : { _("Controller mapping"), &do_mapping }, makefile: delete line 1263. That's the safest option here. controllermap.c is taken directly from the sdl2 source, so you might also be able to take the one there was in sdl2 2.0.10, but then you must add the modifications I added to it, even if there is not a lot of things, it's a risky operation if you are not familiar with diffs so it's really much more reasonable to remove all this. I strongly advice that you loose more time but try to install another linux distribution on your pi, it will be a lot more beneficial in the long run. Also there are tutorials for doing cross compilations from a pc running arch, and it's quite easy to do actually now, preparing your pi programs on your pc would be much faster, although if it's a pi4 it goes at a reasonable speed I heard... If you continue along this path of changing the source for sdl2-2.0.10, you still have to clean up the bits of x86 asm here and there, which would be the hardest part for me, for that I'll probably have to make some git commits, but we'll see if you eventually reach this point. For info if you want to go back to a raine which was compatible with such an old sdl2, it would be version 0.92.1, which means almost the 1st raine version using sdl2, you can still get the source from git if you are curious.

You're doing a good job of finding the problem so far, 2.0.10 is quite old, I added this in december 2021 and it was already quite old, you could compile a more recent sdl2, it's quite easy to compile normally, I don't know what distribution you have on your pi but most distributions give instructions on how to compile a new package, usually it's mostly about passing the right --target argument to configure to tell where to install things (it's in /usr/local by default, and you want /usr if it's to replace the system version). Otherwise you can just remove the functionality of this, the idea is to detect what the audio device can do to adapt to this so you'll just have to do your configuration manually. For that : in sdl/dialogs/sound_options.cpp delete the lines 103-105. in sdl/sasound.c delete line 192 normally it should work, you'll just have to make all sound configurations manually, there are defaults which should work normally though.

Probably but you'll have to test that yourself, edit the makefile and be sure to uncomment the line NO_ASM = 1. There might be a few very small bits of asm left here and there in the source though nothing complex since it works in 32 & 64 bits for the same code but there might be some very simple inline asm at some places. You can always try and if you are stuck at how to deal with some specific code, send some details and I'll take a look. I hope you don't compile on the pi, it would be much faster to cross compile from a pc for that... but I have no pi, so I'll leave you test that.. !

For your problems with the gui and the savegames : well the function has been here for years, and nobody ever reported anything (or used it maybe, that's my case I never used it, it explains why it has some bugs !). So the obvious workaround is to use the good old method : the keyboard with f2/f3/f4 keys, it should do all you need.

Yeah and the heat became deadly in Brazil too, I guess you don't think about video games when it's getting so hot... How much was it already ? I think it was about 60° C felt, some good 40°C base + 20° C felt because of > 90% humidity, you could call that the suburb of hell... ! Anyway you are probably seeing the end of it for now for this year, and it's going to be our turn... for now we are lucky... !

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.