Viewing Issue Advanced Details
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
Regression Version
Affected Sets / Systems every set with PORT_MODIFY used for DIPs (e.g. arknoidj)
Attached Files
png file icon phoenix.png (68,094 bytes) Apr 4, 2008, 16:05
png file icon phoenixa.png (87,476 bytes) Apr 4, 2008, 16:05
There are no relationship linked to this issue.
User avatar
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?
User avatar
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 ;)
User avatar
Apr 4, 2008, 16:15
I believe this is by design, and possibly should be marked as a feature request?
User avatar
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
User avatar
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.
User avatar
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