 No.05638
Tafoid Administrator
Feb 6, 2010, 14:13
edited on: Feb 6, 2010, 14:13
|
Though it doesn't have any confirmation warning that it's missing or it's created (due to the black text, I assume), it appears you need to create the eeprom with the F2+F3 like you do for other Konami games to get this running. When you first start, hold F2 then hit F3 and hold both F2 for a couple of seconds to make sure it takes, the game boots as expected. I'll get it added to the FAQ. Closing. |
|---|---|
 No.05639
Haze Senior Tester
Feb 6, 2010, 14:55
edited on: Feb 6, 2010, 14:55
|
I think you should add default eeproms to the roms. Forcing this procedure is just annoying because it has to be done for every set, every time you have a new tree / folder and is the source of many needless bug reports. |
|
No.05640
Tafoid Administrator
Feb 6, 2010, 15:10
|
For 0.135u4, as the eeprom device was being reimplemented, the decision was made to take the auto-init hacks out in favor of this. I personally took a lot of time to try to catch all instances of needing to F2+F3 in the first time run so they could be included in the MAME FAQ. One only has to do the procedure once and it takes very little time to do. As for reporting, there is an informational sticky note at the top of each page here and I've been trying to drum up some positive press about the MAME FAQ when it's mentioned or asked about in forums. Heck, I've gotten more personal/MAMETESTERS email about this eeprom thing than actual bug reports filed... and it's not bugging me all that much yet. Creating default eeproms? I suppose that would take an effort to do so that no one is caring to do right now. Besides, it's my opinion that people will complain more that the ROMS no longer work because of the missing eeprom file. I think that "my roms suddenly don't work" posts on the boards would annoy more people than the current solution. |
|
No.05641
Haze Senior Tester
Feb 6, 2010, 16:15
|
well, the 'roms don't work' is a temporary problem until the new sets filter through people expect that, and Aaron moved an awful lot of the internal ones to external anyway, so it goes with the flow (that's what the auto init was imitating anyway).. This f2+f3 thing is gong to keep coming up again and again until you want to start killing people who report it. |
|
No.05642
etabeta Developer
Feb 7, 2010, 12:38
edited on: Feb 7, 2010, 12:39
|
the main difference is that most of the games whose eeprom were added to the romsets, had the eeprom hardcoded in the driver. this means that those games *absolutely* needed that eeprom content to work and that probably they had no way to initialize it at start (in some cases I guess the hardcoded content was the one that came as default content from factory). for konami ones, you *can* initialize them and it's pretty easy. I see no reason to add default eeproms. notice that if it was for me, I would delete as well the eeprom for amcoe gambling games but it's not my driver, and at least in that driver the eeprom simplifies development (since the init procedure is definitely more involved than konami's one) |
|
No.05644
Haze Senior Tester
Feb 7, 2010, 13:11
edited on: Feb 7, 2010, 13:16
|
actually a lot of them don't *absolutely* need the eeprom data, they'll just boot with weird / invalid settings, or require non-obvious startup procedures without them. (that's why in a lot of cases where I moved them to external I used ROM_LOAD_OPTIONAL, but people don't seem to like that.. so ..) For example the Naomi ones can be initialized, but you can waste 10 minutes doing that because it's so slow, so the defaults REALLY help there. The only reason the Konami ones had the auto-init instead of default eeproms in the driver is probably because it was found that it could be done that way, and it only required a few lines of code, not a default eeprom in the code per revision. Having to initialize the games all the time is a pain, the Amcoe ones are much easier to work with and check things on with the default settings, and there are still some issues that need looking at in the driver. I'm not a big fan of making MAME inaccessible, and startup procedures like this also caused unneccessary problems for people trying to record .inp files, as internal MAME keypresses such as Reset (F3) aren't recorded, and eeprom data can change from defaults when the game is running. This leaves the replays unplayable which isn't good in cases where I want to see a run through of a game to check for bugs; this is another reason I put default eeproms in a lot of the drivers I worked on. Having the game be bootable and running in a 'normal' state without an existing .nv file is essential in these cases. I don't like to see things ripped out without consideration for why they exist in the first place, and without adequate alternatives being put in place. |
|
No.05650
etabeta Developer
Feb 7, 2010, 16:10
|
the old nvram init was a *hack* and indeed all more recent konami additions were added *without* any auto-init procedure (check e.g. gticlub or hornet, or simpsons bowling) since that auto-init procedure was also making the nvram code a mess, it has been ripped out with no second thought (and notice that I was not even the one suggesting to remove them, Arbee and Aaron were). However, as I have already said above, I admit that in *some cases* these pre-defined nvram can help development (e.g. amcoe and naomi) and that's why I never suggested to remove them completely, even if I still consider them a hack and I would personally remove them. |
|
No.05651
Haze Senior Tester
Feb 7, 2010, 16:43
edited on: Feb 7, 2010, 18:06
|
That's fine, but it doesn't solve the issue that it's now impossible to record a replay that can be reliably replayed without creating some kind of read-only nvram file first to ensure that the start state is always the same which is an even uglier solution. The rules of places like MARP also (fairly, as it can change how the game runs) stipulate that you can't have any NVRAM when recording, and such places are the primary source of high quality replay files which properly demonstrate a game for testing purposes. |