Tux

Yeah the soft dips, I forgot the soft dips are stored there too, but not all the neogeo games have soft dips.

... and I disagree ! But, if you want, you can update the brazilian translation and put that in CAPITALS then (for the brazilian language only) !

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.

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. Well if you can use a mouse reliably in your living room you are more lucky than me, on my side keyboard only !

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 !

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... !

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... !

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...

Don't worry, that makes it interesting ! 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 : 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.

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 !!! http://raine.1emulation.com/download/latest.html

Ok, you convinced me, but it's not one of these basic clones we had lately, this one adds a new mapping for the rom, it's not mapped as the others, so I'll need to look into it in more detail... Congratulations for the motivation though ! Ok, it was not so complex finally, the neogeo system is full of hacks, the mapping of the code rom is : from 0 to 0xfffff normal basic mapping for 0x100000 bytes then if the size is > 0x100000 you get something more 0x200000 to 0x2fffff rom bank and then if there is a write in the 16 last bytes of this region (which is rom so the writes are supposed to be ignored), then it's supposed to be a bankswitch based on the byte written to be able to access any address > 0x200000 This one uses the mapping at 0x200000 but not the bankswitch and its size is > 0x200000 it adds a new area which was unused so far : 0x900000 - 0x9fffff code rom starting at 0x200000 ! I tested it, it seems to work, assuming the code doesn't try to access any address beyond the end of its rom it should be ok, it seems good for the small test I did. I'll post a binary later, you won it. You should take a look at the git log for adding this rom, it's not so hard to do, except here I added the mapping for 0x900000 plus a new define rom ROM_END instead of copying lines all the time... So that you'll be able to add your own clones later !

Err I disagree here, I think the previous workaround was enough. The reason why it was fast this time was simply because I was finally able to reproduce it, previously I had to make a fix blindly. And also I found that you deserved to know all about it considering the time you spent on it ! Of course Any use of a colored line in the gui would make it to go away, as any key using the overlay gui (f2, f3, f4 and the layer keys if they are used by the current driver). Remember ? I am retired ! Plus you are dreaming here, the last commit you show in fbneo is from december 2023, but internet archive is notoriously slow to update its romsets, the dates of the files you are linking to are from april 2023 (click "show all"). If you find where this romset is coming from and how we can get reliable updates, I will consider it. It's actually the other way around, I just forgot to add a test to check that we don't try to load the same game when accessing these lists of games, and this test is already present for the main list of games. I should add it yeah... ! And so you'll just have to either press f1 or load another game 1st, or quit and reload.

... and some last words about this bug : actually the reason why I couldn't reproduce it is simply because in my saved settings the profiler display is almost always enabled (the 3rd one, the one with % numbers), that's the f11 key, and this key would have fixed the green screen bug too if you had used it because by default it uses opengl text, and so it calls glColor to set the color of the text to white, this time it's normal behavior since the text is monochrome, the non standard behavior is for color pixels of the game bitmap. It works also for the f1 key (reset) because you get some texts at the bottom of the screen to tell about the cpu(s) being reseted, and so it calls glColor too... So if you had had a simple profile display enabled in your settings you would probably never have seen this bug, but yeah most of the time you install to a new dir so it's back to default settings all the time... Everything is solved !

And finally went to the bottom of it, there is a weird difference between the opengl implementation in windows and in linux, I don't know why, this thing is supposed to be standard, not made by microsoft normally... anyway what happens is that the draw color, set by a super standard function, glColor affects the pixel operations in windows, but not in linux ! When you know it, it's very easy to work around it, just set the drawing color to white when the opengl drawing starts, which means just 1 more function called when the "play game" option is selected, almost nothing. With this I can finally remove the 2 workarounds there were for this very stupid bug. It's committed, but it isn't worth a new binary just for that !

I got curious and did some more inquiry about this : finally the draw color & blend mode don't seem to matter, because they are not directly used. These functions are queued and executed directly by the video driver, so there is really some difference between what windows does and what linux does here, but not sure what. Linux also uses the opengl driver by default. So it's just a mystery, probably related to some low level driver stuff here. The good news though is that the behavior is correctly emulated by wine, I get the green screen when running the windows binary in linux through wine, it makes things easier to test at least ! So the only workaround which seems to work is the one which I used so far : finish the drawing with a white line so that the color is reseted and does not affect opengl blit operations. This was a really crazy bug for something which shouldn't have created any problem (it's just a basic drawing primitive, nothing should go wrong with that !). Anyway I stop here.

You could just have left this all bug to rest, you know ? Anyway to take a last look at it : the line is actually drawn by SDL2_gfx which was merged into raine, but they never fixed this part of the code anyway. Their line code uses this to set the color : result |= SDL_SetRenderDrawBlendMode(renderer, (a == 255) ? SDL_BLENDMODE_NONE : SDL_BLENDMODE_BLEND); result |= SDL_SetRenderDrawColor(renderer, r, g, b, a); the doc from sdl says that this function affects only lines/rects (and FillRects) and points. Well it also clearly affects the opengl function to blit some pixels to the screen which is used by raine. The reason why it's only in windows is probably because in windows we are forced to use the opengl driver for video where in linux I leave the generic one. Anyway a proper fix would simply be to get the current BlendMode and the current draw color before drawing the line, and restoring it when it's done, it should be done at the SDL2_gfx level normally, but I just checked and this function was never updated ! (it would take only 2 lines to do that !). On the other hand it would probably make programs using lots of lines slower, so it might be better do do otherwise like us here. Oh well at least the current workaround works well... No idea why I wasn't able to do it in my previous install, might have gone too fast, actually I think you need to have the current selection of the dialog over something containing one of these green boxes when you close the dialog so that the BlendMode stays.

Yeah with 0.95.5d I can reproduce it, but there is no point, that's the reason why I took back this workaround. From memory it happens only in windows...

Oh well since your video is so short I took the trouble to reproduce this here. Well in the meantime I updated my windose to win11, I was starting to get frustrated with mine, plus it was filling its partition because windows has a stupid way of handling its boot disk, so I bought a new ssd and installed a new windows on it, this was better. It's still a windows though so I still use it as little as possible, but it's better this way. Anyway I didn't have raine in the windows disk anymore because of this, so fresh install, I just grabbed the games.cfg containing your associations from the linux disk before rebooting in windows, I installed the latest version from the site, in 64 bits and latest version, didn't touch any setting, and no green screen here (I even downloaded the aof3 rom from raine, using internet archive, I noticed I wrote intrnet archive in the french translations, oh well...). Sorry ! But I don't think it's related to the cpu anyway, but I don't know what it's related to then.

Yeah but the hw of the ps1 & neocd were actually comparable, both had a cd drive, and the ps1 didn't have any real 3d hardware since it had no z-buffer, it was more of a hack than anything, 3d games on the ps1 really had to be motivated to get some good result, and also they were at the same time on the market, so like it or not, they were in competition... You liked ssrpg a lot because you are a die hard fan, but really it's too simplistic compared to what sony had to offer at the time. Good news for retroarch, I don't have any of these fancy android devices so I am not interested in this stuff on my side.

Just a notice about the talk of the other day about android : raine would work almost out of the box on the steam deck, it's an amd cpu, running linux arch, and this is what is supported here by default ! Ok, it's not like using a phone which is already useful for some other uses, but for those interested, it just works. I don't own one so I can't give some step by step instructions on how to install, but it's probably quite easy. It's probably worth mentioning this !

Yeah well the pure C version of raine would probably work on android now, but android is not exactly a standard platform, you need to use custom tools to build for it, I tried once long ago and gave up, but it was before the sdl2 version, and it should be easier with sdl2 since it supports android officially. But I'd prefer that someone who knows android building applications better than me does it, I can't say I liked very much my previous attempt... You were a really big fan on this to play it in japenese without understanding a word ! That translation had been released 10 years ago unofficially though and it made a terrible scandal which made the original author to stop his work for a while, that's why it required 10 more years to be finished. So I did it 10 years ago, but gave up before the end, it's supposed to compare to ff7 / ff8, err no unless you really love the game franchise. Glad you loved the whole thing though ! No advice for a neocd emulator sorry, I never had the need to try to play on android, even for arcade, playing by taping on screen, I can't say I love the idea...

Eh, feedback after all ! Ok well I won't discuss this, if somebody finds it useful it stays, just be careful at your settings, and if you have a doubt erase the config file to return to default settings.

Maybe you have set the option in sound options "always stop neocd music while loading" to No ? Actually I should have removed this option long ago, I added it out of curiosity to see if it could be useful sometimes, but for the original hardware it's totally impossible not to stop the music while loading because both require reading from the cd. This option is always to "yes" by default, just make sure yours is. After checking this option is from before 2009, which means before the start of the git log, I expected to get some feedback from it but since the feedback never came, I just forgot it. You are the 1st one who might have used it by mistake !

It does not happen for me neither in raine... ! For info the voice is one of the cd tracks, it stops playing when you press 1 which sends you to the game's menu. It's always been like that, no idea how you got this.