Tux
-
Posts
1,059 -
Joined
-
Last visited
-
Days Won
219
Content Type
Profiles
Events
Forums
Blogs
Downloads
Posts posted by Tux
-
-
I had a dosemu env which worked not too bad to run the dos version, but dosemu seems to have a lot of trouble to reach their 2.0 version and it's getting hard to make it work, plus it was running at the current speed of the cpu, not emulated, at least it was very fast !
I didn't know pcem, emulator for ibm pc and clones ? And it can even run the dos version ? Wow, I'll have to test it one day then !
-
1 & 2 fixed in git, I'll keep 3 for later... !
-
1
-
-
Didn't think of anything, it can read command.dat, but not display it !
So it's enough, updated the download page, it appears below the 2 other binaries, 2.4 Mb, including history.dat and hiscore.dat, these 2 are handled.
-
2
-
-
4 hours ago, pmc2 said:
for the history I'm willing to take this last final version
Well I had disabled ips support in the dos version yesterday, but after thinking about it I added it today : there is almost nothing to do to add it, but without gui of course, the dos gui is crazy to program. But anyway it recognizes the ips directory and any file it contains, which means if you load a rom whose short name is a, and you have a file ips/a.ini containing a list of files to load from ips/a directory, it will do so. I just tested it with an ips I got for bublbobl, and it works perfectly, it's primitive, but it works ! At least it will be a decent version... !
I'll keep it a little longer to see if I think about something else...
-
Yeah I did it for that too, still a ton of respect for it even if it's outdated now.
-
1) Yeah I didn't test it, it would be easier to just remove the option... ! Don't worry, I'll test it...
2) did you at least read what I wrote about editing the colors or reverting to the default themes for that ? Either edit your bg color or revert, or even better revert 1st, and if it's still not enough for you then edit the bg color manually.
3) Nope obviously, didn't do it (boring and uninteresting, but yeah should be done one day).
Just now, pmc2 said:I say Mercurious should be a beta tester ^^
Yeah that's what he is already, and he loves that, too bad he can't code to help to fix these things... !
-
1
-
-
And here is the conclusion :
If someone wants to test this, I'll release the binary... a very last dos version, that was the least I could do !
The not maintained anymore is not totally true, I improved the message box in the allegro gui for this version, I wanted galaga to be able to display a message on a few lines and it was not supported in dos, now it is. But I won't do any major change on it despite its problems, it would be too crazy now... !
-
And here's a screenshot of the result, gunbird2 running in a dosbox session :
It's extremely slow, 6 fps and non constant, it crashes in 8bpp for some unknown reason on the colour mapper, it requires more ram than I ever saw in a dos machine (287 Mb displayed here !), but it works !!! Well, it wouldn't work at all on an old machine because of the ram requirement anyway, but maybe it would be faster, this cpu emulation isn't really very efficient... But at least it's good to be able to optimize stuff ! (and it takes forever to load too !).
-
Yeah I check everything is working or at least can be compiled. This dos version is really hard to test nowdays. The good news is that it works quite well with dosbox-x, an extended version of dosbox, with cputype = ppro_slow, and memsize = 64 at least. The rdtsc emulation is broken, so you can't even access the rdtsc counter with the f11 key, but except that the rest seems to work alright.
I hope that nobody uses the dos version nowadays, except me because I am curious to see how it works now !
It would need a few improvements, like that sample support from the galaxian driver, for now all this is simply disabled. same thing for the galaga explosion... But oh well too much work, not enough use, I'll probably leave it as it is now, at least it works, even if not perfect.
The debug build of raine doesn't work in dosbox, it needs an optimized build otherwise it's just too slow !
That was fun seeing it running anyway !
-
Ok, just release 0.96.6, no new topic because it's exactly the same kind as the previous one, small things. The difference is that this time there is no new game :
- what I hope will be the curl final fix, see a few posts higher in this topic for more info, everything should finally work as expected, it will create html files for index in the raine directory when needed.
- a fix for savegames in the gui which showed by mistake the clones saves at the same time, this thing is never used, really.
- the neogeo saveram can be saved by game to preserver hiscores, or shared as the neogeo hardware did and as we did until now. Option in neogeo/neocd options.
- Fixed the colors selection in the gui (gui options / colors), they were broken since the switch to sdl2 ! and slightly improved the look of the green theme by the way.
- The old behavior of the sdl1 gui where menus appeared behind dialogs in transparency is restored, it's only for dialogs, those having a black title bar. You can update the blue theme either by going to gui options / colors / revert to... and choose green, then blue, then exit and the colors are updated. Or edit the bg color in this same menu, and set alpha to 0xc0, same result. Or you can do nothing to keep the old one, but then don't complain if the transparency makes things hard to read sometimes !The rest are super minor changes, not worth detailing here...
-
1
-
-
Well finally I got curious about that, why not unleash all the crazy transparency from opengl instead ? And I got this :
You have 2 menus and 1 dialog overlapping each other (you can see a very small part of the main menu at the very top, the top of the "Load game" line), plus some moving lines in the background, and the whole thing takes 0% cpu, because transparency was made in software mode in sdl1 but here it's in hardware mode and all this is natural for opengl... !
I had to make the dialogs more opaque to preserve some readability, so you'll have to go to gui options / colors / revert to, to reset the alpha channel to its new default value, either that or adjust the bg color manually (I fixed the color dialog, it was broken since the switch to sdl2, the colors are handled differently in sdl2 and nobody noticed, oh well...).
Maybe that's a little too much ? I'll wait a bit, but for now I think it's still very readable !
edit : finally I had to limit myself and revert to something more like what there was with the sdl1 gui, that is : draw the background menu only if the top most menu is a dialog (that is, it has black title bar attached to the menu, no top or bottom frame on screen). The reason is the game selection dialog, the main menu was hiding most of the background picture, which makes the feature useless. That's that, or remake completely differently this game selection dialog. Maybe one day, but not soon for sure... !
-
1
-
-
31 minutes ago, mer-curious said:
It seems it doesn't have the transparency that is applied to all the other menus in the GUI. But I'm not sure if this is intended...?
It's because with the sdl1 gui you saw the video options menu behind it and for more readability you needed to have this one non transparent. Now I hadn't even noticed that now that the desktop background is drawn (the lines), we don't see anymore the background menu ! Oh well, this gui is not really a multi window system, so I am not going to try to recover the disappeared menu in the background, it would be outside its scope, but maybe restore the transparency here now yeah... !
-
1
-
-
7 hours ago, mer-curious said:
Hello again! Thanks for the super fast reply.
I'm sorry, I didn't want to bother you with that. I know it's just a tiny detail in the text. However, I didn't mean you should write the whole word in capital letters, like "SHARED", but just the first letter, "Shared", as we have for "Yes", "No", "Enabled", "Disabled" and all the other settings in this menu.
It's a change just to follow the naming standardization we use in virtually all the GUI.
By the way, I forgot to mention in my previous post that there's a new SDL version in the SDL GitHub, but I don't know if it would bring any benefits to Raine...?
Finally, I noticed there's some information missing for the samsho2pe ROM when you expand the window, take a look:
As you see in the bottom, the ROM information ends in an open bracket. I'm not sure if this is correct or not...
That's my quick reply for now.
Thank you so much again for your time and for the fast response.
The Shared, yeah probably right, I'll see that eventually.
SDL2, it's the 2.28.3 in raine for now, 2.28.5 on the site, so these are just minor fixes. You have the list of changes displayed in the release page in github :
https://github.com/libsdl-org/SDL/releases
and they also list the changes in their whatsnew file inside the archive if you get it from somewhere else. Nothing major for us, these are just minor bugfix releases.
Apparently their main branch is switched to sdl3 so I guess they will probably release that in a not too far future... Hopefully the switch will be less painful for applications... !
For the way too long name of the game : yeah I thought about that when copying and pasting the info from fbneo, I am tempted to just cut some part from it, but I can also remove any restriction on the length in the gui, now that it's fully opengl there is no risk to display off limits... I'll see, minor problem anyway.
-
1
-
-
1 hour ago, mer-curious said:
By the way, it's not just the high score which is saved to the internal console memory. Some late Neo-Geo titles such as KOF'98, '99 and 2000 also save other information such as the game language and the difficulty level you set in the game options. This is how I noticed my personal data was lost for these games, I went to the options and saw the settings had been reset to default, then I let the game demo run to see that all my hardly achieved scores had been gone too. 😩 Hopefully this will never happen in Raine again. 🙏
Yeah the soft dips, I forgot the soft dips are stored there too, but not all the neogeo games have soft dips.
-
1
-
-
1 hour ago, mer-curious said:
Ah, I looked at the code and noticed you forgot to capitalize "shared" for this setting. I think this should be done to match the other naming standard used for the options in this menu.
... and I disagree !
But, if you want, you can update the brazilian translation and put that in CAPITALS then (for the brazilian language only) !
-
1
-
-
Well it's done, you can choose to have the Neo-Geo saveram shared or per game in the neogeo options now. The default remains shared because the original hardware works like that, and I never missed any neogeo hiscore so far, but I agree it's a design mistake, these scores should go to the memory card and not to the shared ram.
Too bad we don't get our hands on the source code of one of these games, but it's probably horrible to read, they probably had crazy delays to release stuff as fast as possible, but it's too bad to have lost all that anyway.
the design mistake is probably because at the time even if the games are on some big cartridges, they didn't change that often and when the owner changed a game usually it didn't go back to the previous one, it was just to make some money with a new game. But they missed the point that the saveram should get exploitation info only (how many games for how much time), the hiscores are more player related and should go to the memory card.
Oh yeah, for the transition if the file <game name>.saveram doesn't exist yet, the saveram is read from neogeo.saveram, it's just saved in the end into <game name>.saveram. The .nv files you found are probably compatible if their size is exactly 65536 bytes.
-
2 hours ago, mer-curious said:
Thanks a lot for considering this change. I hadn't thought about an option to choose between the current and a new per-game save RAM system, but that seems very interesting indeed! How would you call it? Maybe "Per-game save RAM file"? Would it go into the NG/NGCD options, I guess?
Anyway, any methods you approach for this feature would be welcome, be it a 1 or a 64kb file per game. I think an important feature of emulation is improving the limitations of the real hardware, in this case, the NeoGeo save RAM limitation, which occasionally erases old game information to save new one.
I had a quick look at what mame does, and they save this "nvram" (that's how they call the saveram) separately for each game, no option there, and since fbneo is based on mame, they do the same. Oh well, might do the same too, I'll think about it.
2 hours ago, mer-curious said:That's a very good suggestion! My dad has one in his setup and it works pretty well for that. These wireless keyboards are cheap nowadays (some of them, at least) and some also come with a wireless mouse, so I'll be looking for one eventually.
Thanks a lot again for your time and work. 👍
Well if you can use a mouse reliably in your living room you are more lucky than me, on my side keyboard only !
-
1
-
-
8 hours ago, mer-curious said:
Yes, I've been using it a lot when playing Raine in a TV and from a distance, especially with difficult games such as Samurai Shodown that makes me create some save states in order to win.
I would advise a cable-less keyboard for this kind of case ! I hate this kind of keyboard for normal use, but for this use specifically it turns the keyboard into a remote control ! If you also install some dvr program which can run without any mouse, it can become quite awesome !
-
1
-
-
It doesn't say anything like that ! The eeprom is saved by raine too but there is no eeprom in the neogeo. Its nv files are probably the contents of the memory card. The neogeo saveram is bigger, 64k, nowdays 64k is nothing, but at the time non volatile ram was very expensive, it was the same thing for the ps1 "card" where it stored its saves, it was a few kb also at the time.
Well I never understood why the games don't save their hiscores in their memory card, would seem more reasonable to avoid any overwrite. Plus it seems it has a memory card for both modes, aes/mvs here (for samsho2pe). Well I am not a super big fan of 64k files / neogeo game where only a tiny portion of the file would be used. Eventually an option by user, default being share everything.
-
And bam ! The curl system is a little broken again ! I was too fast to think the file sizes were correctly reported by internet archive, they are correctly reported only for the fbneo archive probably because it's the only one which is not inside a zip file ! It would be nice to take this one as the main archive except the neogeo games inside this one contain all the neogeo bioses, which makes them quite bigger !
So, ultimate solution in git : re-create the index html I had before, but this time on the fly, saved in the raine directory, 2 indexes now, one for the raine archive, the other for the finalburn archive, no need for fbneo since it reports correctly its sizes. Then use the html files to extract the sizes when they are needed.
It works, there won't be an update just for that because the current version seems usable anyway even with this. The progress dialog looks bad because the size returned for everything which is not in the fbneo archive is -1, but it works anyway. So it will stay like that for now, update next time for finally a solid curl solution for all this mess !
Notice there are obviously multiple servers serving internet archive requests, some are very fast, but some are very slow, the download speed can change hugely depending on the server you get... !
-
1
-
-
The glitch : most probably a hack problem, I agree, too bad you don't have the url for the original author, you could post there to be sure.
The savegames in the gui : probably the most underused function of raine, never used it myself, but you are right and I just fixed it in git, it just shows this thing is never used.
The neogeo saveram : To be totally sure there are 2 kinds of data here, the memory card, which is game specific, in neocd and AES systems if I am not wrong (the non arcade one), and the neogeo saveram. The saveram is shared by multiple games, that's how the neogeo system is made. Remember it's a cartridge system, even at the arcade level. Here it's a hack, so it's totally normal that it tries to access the data from samsho2. There are functions in the bios, particularly in the uni bios to explore what was saved in the saveram.
For raine internally, the memory card is saved under <game name>-neogeo.bin in savedata, so it's really game specific, and the saveram is saved in neogeo.saveram only, in savedata too.
Here it looks like the hiscore screen, some games are saving to a .hi file in raine, but most neogeo games save their scores to the saveram, and that's the case for these 2. Notice that the capacity of the saveram is far from infinite so if you play a lot of neogeo games, the oldest ones disappear from the saveram... !
-
1
-
-
Well I don't know any "Bear", it's probably the group name author of the hack, if you want to create a new company entry for Bear when you add a new one, go on. For now Hack will do...
-
4 hours ago, mer-curious said:
Thank you Tux for your work in adding this rom. I didn't expect it would need any especial programming rather than allowing Raine to see the new driver. Hopefully it didn't give you so much work. 🙏
I tried it here one turn until the final boss and it's working pretty normally. The sound associations also work for this clone, I just had to add a new entry in games.cfg with the same associations from the original samsho2.
Thank you again for this.
Don't worry, that makes it interesting !
4 hours ago, mer-curious said:Yes, I took a look at the code added and I guess I understood most of what you did, but perhaps I would still need a hand of yours if possibly adding a new "version 1.9" of this hack in the future...
By the way, in line 1265 there is a typo:
We have "samsho5pe" after the /, when it was supposed to be "samsho2pe", no?
Anyway, this probably won't affect the game emulation, right?
Thank you so much again for your time and work. 👍
Yeah it's a comment, it's harmless, but it just shows I had a quick look at samsho5pf just before adding this clone !
I fixed it here. At least it shows you had a look at the code, good, and thanks for that !
Except that, the main part is :
QuoteLOAD_SW16( CPU1, "063-p1pe.p1", 0, 0x100000, 0xf63e163d ),
LOAD_SW16( CPU1, "063-p2pe.sp2", 0x100000, 0x100000, 0xffc16c11 ),
LOAD_SW16( CPU1, "063-p3pe.p3", 0x200000, 0x020000, 0xedffbd8a ),LOAD_SW16 is the way to load the rom, it's often the case for a 68000 code rom, the bytes are swapped compared to an intel cpu, and you have to use LOAD_SW16 instead of LOAD, it shows in the console when using the dump command, but anyway. Then CPU1, it's the 68000. The name of the rom, then its offset, apparently fbneo doesn't have any offset, which must make some romsets a little awkward to write because there are all kinds of oddities in the arcade roms and everything is not always in 1 block. That's probably the hard part for you here, you have to count manually the offset, 0 for the 1st one, then add the sizes of what has been loaded so far : 0x100000, then 0x200000. Then the size, and finally the crc.
Then the CLNEI line which says it's a clone of samsho2 and gives the long name, the company (I left SNK here, but actually it's a hack, so I just replaced it with HACK instead), year and type of game.Then you need the DRV( smasho2pe ) line in drivers.h to declare the driver, and that's all, your driver can be accessed and played, assuming it doesn't do anything funny like this one which used a new rom mapping.
-
1
-
-
All the motivation of mer-curious brought this, it's mainly for samsho2pe, "samurai shodwon II perfect hack v1.8", thanks to the info found in final burn neo. This is a special hack this time since it adds a new memory rom mapping to the neogeo driver, never seen before in raine.
Except that I got rid of index_roms.html finally, this file was here as a quick way to get the roms sizes, but actually using the head http command is more efficient (!), and got a proper fix for this weird green screen bug that mer-curious had in windows for way too long... !
That's all folks !!!
-
2
-
Playing with the dos version in 2024... !!!
in Raine
Posted
I had a look at this PCem, it indeed looks interesting, but where is the documentation ? Since there is no interface, how do you want to use this without any documentation ?!!! Even in the forum there is no basic documentation, no default configuration file, nothing, it's quite extreme ! I found the github repository containing all the bioses but they are useless without a minimum set of documentation...
If you have a link on how to start using this thing, I am interested... !
Ok, understood, you need the windows version to get the interface, the guys who wrote this are heavily addicted to microsoft... ! But the good news is that it runs fine in wine, and so I can create the config file this way ! Crappy way to do things though... !
After testing on a pentium2-300 with pcem (splendid emulation of the machine this time, this emulator is really THE emulator for dos), gunbird2 runs perfectly with a solid 60 fps. I saw a zooming problem during the intro, specific to this dos version (the flying carpet man while he approaches), I don't know why, but at least it runs smoothly with a serious margin, even with sound (soundblaster 16, 22 Khz).
For reference, this sh2 runs at 57/2 MHz, but with almost all instructions taking only 1 cycle (risc), so I'd say it's equivalent to at least twice this frequency for a "normal" cpu. Which means good emulation, raine honor is safe ! I thought about trying some heavy optimizations on this one, I didn't want to do it first because the driver would loose in readability and I didn't think it would make a big difference. After this test I am sure I don't need to do it !
Thanks for the info on pcem though, not sure it will be useful soon because maintaining the dos version today would be crazy as I said, but it's good to know there is a way to test this properly.
For info the linux version sucks, no configuration manager which makes it useless alone, and when I try to run it with the config created in wine, it just crashes without any message. As I said these guys are heavily addicted to microsoft, but their program is good anyway (the windows version!)
The only advantage of dosbox is that you don't need to create a disk image, but the emulation is less precise for sure on this kind of thing, I could even select a mach 64 gx to have 2d acceleration and then run univbe on it using pcem, quite impressive, even if I was limited to 512x384 16bpp for this test, but it was enough (and the resolutions < 512x384 in 8bpp are all broken in vesa3 for some reason, it seems their emulation isn't totally perfect here). But all this is quite impressive compared to what we had so far !
edit : PCem being quite fascinating to use, I fixed the crash in 8bpp, and the black sprites in 16 bpp for the dos version, this was just that color depths other than 32bpp were badly handled, and 8bpp was crashing because of an overflow in the color map. It's likely that other 24bpp games have problems in 8bpp in dos then, maybe I'll check that later. About 60% cpu free during most the intro on a pentium2-300 in 8bpp, I'd say it runs quite well ! The colors look a little pale in 8bpp, it's normal, it's the effect of the color conversion to fit all this in a 256 colors palette, switch to 16 bpp if you want bright colors !
I didn't find a way to mount directly a vhd in linux yet, I found something on the net about that but it doesn't seem to work, so I work on the vdi used by virtualbox, and then convert it to vhd for PCem using some virtualbox tool, really sub-optimal, but even if that's quite a lot of steps, it's quick to do and manageable.
Oh well, I think I'll be able to stop here for now !
The proper way to mount a vhd in linux : https://devicetests.com/mount-virtual-hard-disk-ubuntu (method 1 works perfectly).