sebdel / mra-tools-c

39 stars 13 forks source link

Support for default DIP switch value in ARC files #66

Closed jotego closed 4 years ago

jotego commented 4 years ago

Some arcade games will not boot up or will get halted after an initial screen if DIP switches are not correct. These are sometimes reserved configurations by developers or deliberate test conditions for the service operators.

For DIP switches to work conveniently in MiST we need to get the default value -already in the XML- to the ARC file, something like

DEFAULT=00ABCDEF

Could you add this feature, please?

gyurco commented 4 years ago

As I see, the switches tag can have default like this:

    <switches default="FF,FF,FF,D1">

This could be mapped to CONF_DEFAULT=0xffffffd1 However bit 0 couldn't be used, because it means ARM reset. So maybe it would be wise to limit this to 24 bits? Then it should be CONF_DEFAULT=0xffffd100 (leave the lower 8 bits 0)

sebdel commented 4 years ago

Sorry, I'm a bit slow these days due to the circumstances. I'll look into it this weekend.

sebdel commented 4 years ago

I merged @jotego patch and it doesn't really do that. From <switches default="FF,FF,C9"> I get DEFAULT=0xFFC9FFFF you're saying that will reset the ARM controller? should I change that? Also, all these FF are a bit confusing; what would be the output of that: <switches default="12,34,56,78"> -> Which one should be discarded (with a warning)? Bonus: do you want to rename DEFAULT to CONF_DEFAULT or it's fine like this.

gyurco commented 4 years ago

I've added to the firmware already as DEFAULT. FF,FF,C9 shouldn't be 0xFFFFC900? Or why the order is shuffled? Or simply reversed, like the Intel byte order? (it won't reset the ARM, because the firmware will ignore bit 0).

jotego commented 4 years ago

Let me try it with the firmware update and I'll change it if needed. It does look like they are swapped indeed. For unused bits, I'd rather have a default one as off DIP switches were usually high in hardware. Please @gyurco let me know when there is a binary for the firmware.

jotego commented 4 years ago

I am sorry I shuffled the byte order. That was a bug I created. I have corrected the MRA tool now. (Check out this PR)

I have added an attribute for the switches element: mist-base. This will add that number (in hex!) to all switches bit. This is useful in order to use zero-based bits in the MRA switch definition but then quickly shift the result to fit your OSD needs. You can shift by any number. The tool will tell you if you've gone over the 31 bit limit. Default values are shifted accordingly too.

Another element is mist-rbf. I need this because some file names won't work in MiST. I pressume it is because of their length. mist-rbf overrides the regular rbf element.

I'll send you a couple of files by e-mail so you can test them.

sebdel commented 4 years ago

I don't think it's a good idea to have things called "mist-*" in the mra format. We made a lot of effort to have the same file for mister and mist, why diverge now ? I understand that the mister doesn't need these, but still, they can ignore them. For mist-rbf, what about:

    <rbf alt="jstz">jtsectionz</rbf>

We would just take the alt if present.

And for mist-base, why not call it "base", since that's what it is. I also think that having it in hexa is confusing but that's up to you.

I'll merge your PR but I will do some refactor after that (to improve the separation of concerns between mra and arc modules) so please wait before moving further :)

jotego commented 4 years ago

I agree. I am going to correct it for alt and base. The thing is that I don't want MiSTer to rebase the DIP switches because there is no need in it. But well, MiSTer firmware will just ignore it. I'll commit again in a few minutes. I'll try to fix the hex too.

sebdel commented 4 years ago

This is merged and released.