Jump to content

Tux

Ultra Members
  • Posts

    1,228
  • Joined

  • Last visited

  • Days Won

    264

Everything posted by Tux

  1. Well the most impressive rom hack I have seen so fa anyway ! I took a quick look at the qsound rom (sz3mx.11m) and indeed it looks like there are 2 $800000 bytes regions inside, but I have no way with the current qsound driver to declare 2 regions for a single chip. The problem is the qsound driver is a quite outdated, but mame now emulates the dsp from the original qsound hardware which seems quite overkill for me, so I'd love to find a workaround for this problem, but it doesn't look easy.
  2. Cool, thanks ! Well the increase of resolution was the easiest part, the sprites the hardest so far. I'll try to see about this 2nd bank for the qsound, thanks for that. And I have some other bugs to keep me busy, not directly related to sfz3mix... ! Yeah the work on this hack is impressive, biggest cps2 rom ever this info alone is impressive ! For the samples, usually we do that with "sound associations" in raine, cps2 is already supported, it allows to replace a chosen song by an mp3/ogg/flac, etc, so it's probably the easiest way to do that here, except usually it's configured by the user, here it would be by the driver, I'll see that later.
  3. Ok, finally fixed almost all of sfz3mix : - the aspect ratio dipswitch is a fake one. In Raine it's useless since the setting is already in video options. Ok in raine it's just about trying to keep the 4:3 aspect ratio or not, I could instead force to 4:3 or 16:9 like here (there is even an option for these ultra wide screens, I didn't know these could be useful for gaming !). Spent quite some time searching how it was read, didn't find anything... ! - there are quite some hacks for the sprites drawing explaining my bad sprites. It's a huge sprites bank, $4000000 bytes, never seen that in a cps2 game so far. Luckily there was also a modified mame source where it's easier to track the modifications and find everything needed. There was also a change in the output handling which helps a lot to center the screen ! - for the sound it was a blank area in the middle of the rom. At least the intro sound of the game seems broken which is strange since it's the only broken sound apparently. It's among the new sounds added to this... I checked their custom samples, they are about music only, so it's not the cause, so for now I don't know why it's not playing correctly... It's possible the driver uses some fancy recent feature of the qsound driver, the one in raine is actually very old now. The amazing thing about qsound is that their samples are 8 bits and they sound like 16 bits samples... ! - The inputs seem ok, tested only in service mode, can't be sure about the game, I am not an expert in this game but it should work normally. It's in git for now. ffman1985 has been adding quite a few of his hacks/cheats lately too to git...
  4. And ffman1985 understood these folders : That is the portrait in the character screen. https://github.com/city41/kof94te/blob/main/resources/avatars_a94_256.png https://github.com/city41/kof94te/blob/main/resources/avatars_a95.png So, the a94 is the one nearer to the original. So you must either apply a94, or a95, not both. Here is then the a95.dat file, on the same model, it's just a copy and paste of a94.dat with a94 replaced by a95 : 055-c1.bin kof94_a95.055-c1.c1.ips CRC(b96ef460) 055-c2.bin kof94_a95.055-c2.c2.ips CRC(15e096a7) 055-c7.bin kof94_a95.055-c7.c7.ips CRC(62f66888) 055-c8.bin kof94_a95.055-c8.c8.ips CRC(fe0a235d) 055-p1.bin kof94_a95.055-p1.p1.ips CRC(f10a2042) 055-s1.bin kof94_a95.055-s1.s1.ips CRC(825976c1) [en_US] a95 from https://github.com/city41/kof94te Notice that this method has only advantages, you can choose which version of the patch you use : at the top of their git tree is the 1.30 beta, but you can revert to any version to get the one you want, the .dat files will remain the same since the crcs are the crcs of the rom files, not the patches. In linux you can use symlinks for the a94 and a95 files to make them to point to their git directory, and then choose the version you want in this directory... !
  5. I have most of the sounds, it was because this romset was made for mame compatibility and so it includes the gap that mame has for its z80 memory map in the middle of the rom ! 0x8000 bytes wasted, and so I needed to make a memmove to compensate for this... Still a few sounds seem strange, I'll have to make more tests on that, and anyway for now no idea for the broken sprites and there are quite a few !
  6. 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... !
  7. 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 ?
  8. 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 !
  9. 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 !
  10. 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 !
  11. 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.
  12. 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... !).
  13. 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.
  14. 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.
  15. 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.. !
  16. 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.
  17. 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... !
  18. 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.
      • 1
      • Like
  19. 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 !
  20. 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)
  21. And if you use zip+mp3 or zip+ogg for your neocd games it will be much smaller than any chd anyway !
  22. 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 !
  23. 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 !
  24. 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 !
  25. 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 !
×
×
  • Create New...