| ID | Category [?] | Severity [?] | Reproducibility | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 01671 | Interface | Minor | Always | Apr 4, 2008, 13:51 | May 21, 2008, 00:59 |
| Tester | etabeta | View Status | Public | Platform | SDLMAME |
| Assigned To | aaron | Resolution | Fixed | OS | MacOS X |
| Status [?] | Resolved | Driver | |||
| Version | 0.124u1 | Fixed in Version | 0.125u2 | Build | Normal |
| Fixed in Git Commit | Github Pull Request # | ||||
| Summary | 01671: every set with PORT_MODIFY used for DIPs (e.g. arknoidj): the modified dipswitches are always listed at the bottom of the list | ||||
| Description |
as per the summary, in the Dip Switches menu entry of the UI every dip defined in the driver using PORT_MODIFY macro is listed at the bottom, no matter which shall be its correct position. otoh, diplocation submenu puts them in the correct place, if this can help to find where the problem is |
||||
| Steps To Reproduce | launch arknoidj, enter the UI and the DipSwitches menu, check where Coinage and Lives are (at the bottom) versus their expected position (at the top) | ||||
| Additional Information | |||||
| Github Commit | |||||
| Flags | |||||
| Regression Version | |||||
| Affected Sets / Systems | every set with PORT_MODIFY used for DIPs (e.g. arknoidj) | ||||
|
Attached Files
|
 phoenix.png (68,094 bytes) Apr 4, 2008, 16:05 | ||||
| phoenixa.png (87,476 bytes) Apr 4, 2008, 16:05 | |||||
 No.00562
Tafoid Administrator
Apr 4, 2008, 15:50
|
I guess I don't understand the problem. Using 32-bit Self-Build Windows. I'm looking at your example set arknoidj and comparing to the DIP listing in the arkanoid.c - I don't see an error. The switches are being put in the order given by PORT DIPLOCATION which I believe is used for the visual depiction of the DIPS (based on which switch and what location from the right edge it toggles). Maybe if I'm mistaken someone else can support this bug assertion? |
|---|---|
 No.00563
etabeta Developer
Apr 4, 2008, 16:06
|
my bad, I made a mistake choosing arknoidj because it has dips ordered in reverse, so it works. anyway many other sets do not and the issue is present. compare anyway my screens from phoenix and phoenixa (cabinet remains at the bottom because it's in a separate PORT, but you can see that Coinage is shifted down by 2) and, if you can, change the summary/procedure accordingly. next time I'll double check the sets I choose as example ;) |
 No.00565
RansAckeR Tester
Apr 4, 2008, 16:15
|
I believe this is by design, and possibly should be marked as a feature request? |
|
No.00567
etabeta Developer
Apr 4, 2008, 18:33
|
I don't see why it shall be by design: it seems a list is created for each set containing the dips and then this list is used to visualize them in the menu. except that if PORT_MODIFY it's used, the modified port ends up at the end of the list instead of the place the original port occupied. otoh the list of location is filled correctly. at most it could be seen as a limitation in the current code, but I will look better tomorrow to the way the list of ports is created to find where the problem arises |
|
No.00568
Tafoid Administrator
Apr 4, 2008, 19:19
|
I don't believe the order in which the dip menu is listed on the screen is supposed to represent where it is on the actual dip switch. I think this is the main reason why PORT DIPLOCATION was created - in an effort to actually document the physical location of the individual switches. Snippet from whatsnew.txt for 0.105 (0.104u7): Added new PORT_DIPLOCATION() macro which allows you to specify the physical PCB location of a DIP switch and the switches that correspond to the bits in the DIPSETTING. [Aaron Giles] I don't think the original intent of the listing in whatever order in the menu was meant to represent the actual location of the DIP. I'm leaning towards feature request, as RansAckeR mentioned. |
|
No.00570
etabeta Developer
Apr 4, 2008, 19:36
|
I agree, but I was pointing out that it is inconsistent: in the parent phoenix the order of definitions of the port in the driver is Lives -> Bonus -> Coinage -> Unknown -> Unknown phoenixa, using PORT_MODIFY to modify coinage setting should have Lives -> Bonus -> Coinage -> Unknown -> Unknown (because PORT_MODIFY has been introduced to avoid rewriting the entire PORT entry to only modify a single value) but ends up having Lives -> Bonus -> Unknown -> Unknown -> Coinage due to the way inputs are read. if you prefer to call it a feature request I'm perfectly ok, but it sounds like a (admittedly very small) flaw in the current code (with all the respect for Aaron). Notice that the order is "inconsistent" in the xml output as well. I will anyway take a look to the source to understand which function translates the source driver to the input strings to see if there is an easy workaround |