Previous Thread
Next Thread
Print Thread
Page 5 of 7 1 2 3 4 5 6 7
Joined: Jan 2006
Posts: 3,690
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,690
well, in a lot of cases the chips have a single manufacturer even across regions, so it's not so out of place to have it in the filename itself...

Joined: Mar 2013
Posts: 332
Likes: 1
I
Senior Member
OP Offline
Senior Member
I
Joined: Mar 2013
Posts: 332
Likes: 1
Well... yeah, in some cases there's just one, but isn't that just guesswork? Whenever somebody finds a new bunch of cartridges that happen to come from another manufacturer, would the file name change if there's now more of these?

I'm just saying, this code only appears within this specific set of Mega Drive games, which seems to add some inconsistency to the system's software list and even with MAME's romsets. It could potentially even make things confusing for somebody who is looking for a certain chip and sees a "W57" that's not inside his cartridge.



I feel that leaving the manufacturer code out seems to be simpler, safer, more accurate and more consistent, in my humble oppinion... I hope you see what I mean. =|


LCD artwork scans and cleanups: https://mega.nz/#F!uFYSzK7S!U-lJon9jsqyoCX_3y7_KLA
Joined: Jan 2006
Posts: 3,690
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,690
I perfectly understand your point and I thought about it a lot, before adding the manufacturer to the filenames

point is that there is just no solution to make everyone happy: the manufacturer letter/string *is* scripted on the chip markings, right at the end of the MPR-xxxx code, so one could as well say "why there is no manufacturer code on the filename when there is one on my pcb"? if you can see the reason of the difference in one case, you can probably see it in the other case as well

we document the meaning of the manufacturer codes at the top of the xml, specifying that they can vary, and we list the known variants as a <feature> in the list, so that it is clearly present both if you open the xml in an editor and if you look at the entry through ProjectMESS (see e.g. http://www.progettoemma.net/mess/gioco.php?game=aladdin&list=megadriv when you press on "Show detailed info about 'parts' of this software" )
I don't really know what we could do to make it more clear...

Joined: Mar 2013
Posts: 332
Likes: 1
I
Senior Member
OP Offline
Senior Member
I
Joined: Mar 2013
Posts: 332
Likes: 1
Has that been done for the MAME ROMs as well, or is including that code a new thing, anyway?



Regarding the verified chip dumps already in the gamelist, many of them seem to have the string "SEGA MEGA DRIVE " or "SEGA GENESIS " in the header.

Shouldn't these strings read "ESAGM GE ARDVI E" and "ESAGG NESESI " respectively, in this kind of dumps? Or does it depend on the PCB type?




LCD artwork scans and cleanups: https://mega.nz/#F!uFYSzK7S!U-lJon9jsqyoCX_3y7_KLA
Joined: Jan 2006
Posts: 3,690
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,690
the confirmed dumps which still use loadflag="load16_word_swap" haven't still byteswapped yet

they will be, eventually, don't worry. it's just that I have only 24hrs per day, a real work and some emulation progress to attempt as well, in addition to the documentation ones, so that things are in progress but not all done yet wink

Joined: May 2004
Posts: 1,716
Likes: 3
H
Very Senior Member
Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,716
Likes: 3
and yeah, the list endian stuff is confusing vs. MAME because in MAME terms load16_word_swap would be CORRECT for a byteswapped rom...

I think some of the Megatech Genesis ones are wrong actually and are preswapped (I added comments in the source about such a long time ago)


Joined: Jan 2006
Posts: 3,690
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,690
erm... no, the problem is that 99% of the dumps available on the net *are* byteswapped so we use load16_word_swap wink
the list endian coincides with MAME one, now (IIRC ElBarto fixed that more than one year ago)


it's again the fact that the PINs on the board make the CPU read ROM bytes in an order, but reading the ROMS in a reader with default settings gives you the opposite order...
since we use byte order which makes simpler the life to dumpers willing to re-burn data into their boards ( http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=86765#Post86765 ), common dumps have to be swapped and will be at some point (at least the ones verified having correct data)

Joined: May 2004
Posts: 1,716
Likes: 3
H
Very Senior Member
Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,716
Likes: 3
nope...

pga tour golf pgt04.u1 is a correctly byteswapped rom (non-human readable)

to load it in mess you use

<dataarea name="rom" size="1048576">
<rom name="pga tour golf pgt04.u1" size="1048576" crc="8d980bb4" sha1="89b50dae5c88f633458a6faeb4ee288fcc94c1b1" offset="000000" />
</dataarea>

to load such a rom in MAME (in a 68k CPU region) you'd use load16_word_swap

(I think it's because in MAME it swaps stuff based on the CPU type, but with lists you don't have that, for data regions on a 68k you'd get similar behaviour to MESS if you forgot to use the correct BE/LE stuff on the ROM_REGION)

it's still inconsistent between the internal/softlist because the softlist regions have no concept of endianess.


Joined: Mar 2001
Posts: 16,943
Likes: 69
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,943
Likes: 69
Right, non-human-readable is EPROM-burnable. The only difference is softlist regions don't have endianness.

Joined: Jan 2006
Posts: 3,690
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,690
yup, Kold666, ElBarto and TheGuru all confirmed that only non-human readable roms can be burned to a megadrive cart with default reader settings (same as Amiga bios mentioned by Guru many times)

Of course, you can always modify endianness in the dumping software, but if we want to make a standard out of our lists, I think it's better to swap md dumps to match MAME conventions about arcade pcbs, rather than swapping MAME dumps to work as available genesis dumps


A note on MD endianness will be put in the xml, once I'm done adding sunbeam's info, though, to clarify the subject
As for swapping available dumps, I don't want to do any massive swap of unconfirmed dumps because quite often the pcb had 8bit roms which got load as 'interleaved' and those don't need to be swapped but separated properly
Hence, only the confirmed ones will be changed.

Page 5 of 7 1 2 3 4 5 6 7

Link Copied to Clipboard
Who's Online Now
3 members (nerd4gw, Dorando, DarthMarino), 26 guests, and 3 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,132
Posts119,651
Members5,029
Most Online890
Jan 17th, 2020
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com