Previous Thread
Next Thread
Print Thread
Page 6 of 7 1 2 3 4 5 6 7
Re: Chip dumps + XML [Re: ICEknight] #87122 03/22/13 04:31 PM
Joined: May 2004
Posts: 1,611
H
Haze Offline
Very Senior Member
Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,611
yeah, not saying we should swap the MAME roms, I'm saying it's a bit messy because for the load_swap is inverted between internal/lists for the exact same file due to the lack of any endian awareness in the lists.

it's annoyed me for a while but I'm not sure what the cleanest solution would be, nor if it would cause issues on machines natively of a different endianess right now.


Re: Chip dumps + XML [Re: ICEknight] #87193 03/25/13 02:58 PM
Joined: May 2011
Posts: 25
S
Sunbeam Offline
Member
Offline
Member
S
Joined: May 2011
Posts: 25
I know the ROMs are byte-swapped to conform with MAME but this is far from reality, isn't it? Why they are prepared for ROM programmers? It's reasonable for MAME. Many arcade boards use socketed PROMs that are easy to replace. But console games that use soldered mask ROMs? I know, consistency ^^

The advantages supporting 'em in the natural format are prevail. First they remain compatible with all other known emulators, second the confusion about the "right and wrong format" ends and they are ready for flash-based carts. AFAIK no flash cart supports pre-swapped files. So in most cases the user have to byte-swap the image again to get it working (on the real hardware) and about 0.5% of the users are happy they don't need to pre-swap the files in the hex editor ^^

A note to programmers in the XML header "Perform byte-swap before programming" or "Configure programmer to use Motorola/MSB-fist/Big Endian/what ever format" would do just fine smile

Just a memory aid.

Re: Chip dumps + XML [Re: ICEknight] #87198 03/25/13 04:08 PM
Joined: Jul 2008
Posts: 73
E
ElBarto Offline
Member
Offline
Member
E
Joined: Jul 2008
Posts: 73
I agree that we should have all roms in the "correct" byte-order just to reflect the reality.
MAME (and so MESS) have always been a documentation of how the hardware is, so why roms have to be treated otherwise ?

Let take point per point the "cons" :

- byte-swapped roms aren't compatible with others emulators.
Do we care ? It is the MESS softlist we are talking about. Other emu aren't compatible with splited roms too, should we concat them ?

- byte-swapped roms aren't compatible with flash cart.
Do we care ? roms are available elsewhere on a correct format and if someone want to uses MESS softlist roms with a flashcart I'm sure that at some point someone will make a script which unzip, swap each roms.

- You have to swap them before opening them in a Hex Editor.
If someone have to hack a rom on a hexeditor or a disassembler you can assume that he knows that he have to swap it before.
(I just thought of something writing this, does unidasm have a switch to swap the roms before disasming it ?)

Re: Chip dumps + XML [Re: ICEknight] #87200 03/25/13 04:28 PM
Joined: May 2004
Posts: 1,611
H
Haze Offline
Very Senior Member
Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,611
plenty of (the majority produced in the 90s and later) arcade boards mask roms too, often soldered.

we've been over such arguments before with the NeoGeo in MAME, and the console copier formats there, in the end MAME sets the current standards simply by doing things right and documenting what is correct to a set standard.

With split dumps, proper byte order etc. MESS is doing the same thing for consoles and such, obviously the transition will take a long time, but it's the 'time to grow up and take things *seriously*' moment for consoles and the like which has always been sorely lacking IMHO because existing methods just favoured playability over all else.

Same reason we emulate the proper protected pirate dumps from protected carts as the primary sets, even if said dumps are useless in other emulators and cart copiers due to the protection. This is MESS, we aim for a more MAME-like approach.




Re: Chip dumps + XML [Re: Sunbeam] #87203 03/25/13 06:20 PM
Joined: Jan 2006
Posts: 3,687
etabeta78 Offline
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,687
Originally Posted By Sunbeam
A note to programmers in the XML header "Perform byte-swap before programming" or "Configure programmer to use Motorola/MSB-fist/Big Endian/what ever format" would do just fine smile

Just a memory aid.


This will be added, as soon as I'm done with all the info you fed me with wink

Re: Chip dumps + XML [Re: ICEknight] #87204 03/25/13 06:21 PM
Joined: Mar 2001
Posts: 16,499
R
R. Belmont Online Content
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,499
eta: What? We're using MAME-standard ROMs, period. No such note is necessary because those ROMs are natively compatible with EPROM programmers.

Re: Chip dumps + XML [Re: ICEknight] #87205 03/25/13 06:25 PM
Joined: May 2011
Posts: 25
S
Sunbeam Offline
Member
Offline
Member
S
Joined: May 2011
Posts: 25
Yey, that's exactly my intention too. I even started dumping that way before MESS came up and supporting it wink

But for the byte-order it should be clarified, that the ROM programmer dumps are just "pre-swapped" and ready to get reprogrammed. This is just due they work with little endian words on default. This is only correct if you're going to reprogram them to EEPROMs but not for the natural data order. This point isn't going to accuracy preservation.

I know, this behaviour/format is kept for compatibility reasons for easy repairs using MAME romsets. And that's just I wanted to point to. It's very unlikely for a console and preparing data exclusivley for ROM programmers. It's something like ... well preparing floppy images together with a specified trace duplicator script ^^

Re: Chip dumps + XML [Re: ICEknight] #87667 04/17/13 04:00 PM
Joined: May 2011
Posts: 25
S
Sunbeam Offline
Member
Offline
Member
S
Joined: May 2011
Posts: 25
For the interested parties:

I coded a converter to produce MESS softlist compatible output: http://retroshock.bplaced.net/mdg.html#download

Seems MESSUI have some serious problems with longer setnames. I haven't included them and used (for the first instance) traditional filenames. Not all are working or the wrong set get started confused

The background: PCBs will be identified by the converter and the feature-tags can be filled automatically including proper position markings for ROM names.

Re: Chip dumps + XML [Re: Sunbeam] #87668 04/17/13 04:36 PM
Joined: Jan 2006
Posts: 3,687
etabeta78 Offline
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,687
Originally Posted By Sunbeam
Seems MESSUI have some serious problems with longer setnames. I haven't included them and used (for the first instance) traditional filenames. Not all are working or the wrong set get started confused


you are mixing xml loading with fullpath loading and that's why it does not work. the former has to stick with shortnames, even if of course you are free to create your own; the latter cannot work in conjunction with xml and it cannot exploit xml features to select the proper on-cart hardware.

ETA: such kind of generated xmls could be of use if we ever get RPK support in drivers which are not TI99/A (RPK=zipfile containing the dump, in whatever form the user wants, + a basic xml specifying the pcb type and the loading addresses)

Re: Chip dumps + XML [Re: ICEknight] #87672 04/17/13 08:29 PM
Joined: Feb 2008
Posts: 42
G
gigadeath Offline
Member
Offline
Member
G
Joined: Feb 2008
Posts: 42
Speaking of Accolade weirdness, Star Control should be checked too, like Turrican. I wasn't able to get consistent readings at all back in the day.

Also, Centurion had the same stuff going on as F22. Maybe that's been taken care of already.

Phelios, and a few other carts I don't remember at all, have some epoxy shit on the PCBs. Weird Namco.

Page 6 of 7 1 2 3 4 5 6 7

Who's Online Now
2 registered members (Dorando, Stiletto), 56 guests, and 2 spiders.
Key: Admin, Global Mod, Mod
ShoutChat Box
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,775
Posts115,470
Members4,899
Most Online890
Jan 17th, 2020
Powered by UBB.threads™ PHP Forum Software 7.7.3