Previous Thread
Next Thread
Print Thread
Page 112 of 120 1 2 110 111 112 113 114 119 120
Re: Fixed software lists [Re: R. Belmont] #68102
03/24/11 06:36 AM
03/24/11 06:36 AM
Joined: Jan 2006
Posts: 3,687
Trondheim, Norway
etabeta78 Offline
Very Senior Member
etabeta78  Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,687
Trondheim, Norway
I cannot ensure all of them are supposed to work on a real system, but the Datel ones should work on a real Game Boy

Also, according to this guy
http://fuji.drillspirits.net/?post=87
most chinese carts should show a custom logo at boot (after having provided a copy of the Nintendo one to the system check to bypass the TMSS-like protection routine), and then start. MESS currently does not show it properly.

Some chinese pirates have copy protection systems too (I guess similar to the MD ones that you emulated), but I have had no time to look at what they do read/write since I'm still busy sorting out the GoodGBx naming mess... a lot of games got titled based on the header string which is often reused from one game to another. e.g. Bokujou Monogatari 2 (Unl) has *nothing* to do with Harvest Moon, or Shawu Story (Unl) is used for two completely different games!

Finally, there are also a couple of SNES pirates (Pikachu something, and SFEX) which might need some protection work to finally boot in emulators...

Re: Fixed software lists [Re: R. Belmont] #68118
03/24/11 10:58 AM
03/24/11 10:58 AM
Joined: Apr 2004
Posts: 1,554
J
judge Offline
Very Senior Member
judge  Offline
Very Senior Member
J
Joined: Apr 2004
Posts: 1,554
Actually, the nintendo logo is provided after the logo data has been copied to vram.

Re: Fixed software lists [Re: R. Belmont] #68121
03/24/11 11:03 AM
03/24/11 11:03 AM
Joined: Jan 2006
Posts: 3,687
Trondheim, Norway
etabeta78 Offline
Very Senior Member
etabeta78  Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,687
Trondheim, Norway
This proves how much I dug into the code wink

EDIT:
BTW, we should eventually support the gameboy sewing machine connection too! 3 Japanese dumps are already in the list (thanks to nointro guys who bought and dumped them)...

Re: Fixed software lists [Re: R. Belmont] #68130
03/24/11 08:39 PM
03/24/11 08:39 PM
Joined: Jan 2009
Posts: 13
B
BigFred Offline
Member
BigFred  Offline
Member
B
Joined: Jan 2009
Posts: 13
Quote:
any info on The Muppet dumps currently labeled as AX9P and AP9P? where do they come from? is that the serial for the game?


Sure - there is a transparent GBC only version as well as a black hybrid cart (I think AP9P) with different serial codes used for the naming.

I will look for that Sachen cart.

Re: Fixed software lists [Re: BigFred] #68132
03/24/11 08:59 PM
03/24/11 08:59 PM
Joined: Jan 2006
Posts: 3,687
Trondheim, Norway
etabeta78 Offline
Very Senior Member
etabeta78  Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,687
Trondheim, Norway
Originally Posted By BigFred
Sure - there is a transparent GBC only version as well as a black hybrid cart (I think AP9P) with different serial codes used for the naming.


do you have any picture of these Muppet carts?

and of Raku x Raku - Mishin (I got pictures of the other two sewing machine carts)?

anyway thanks for the info smile

Re: Fixed software lists [Re: R. Belmont] #68137
03/24/11 09:50 PM
03/24/11 09:50 PM
Joined: Jan 2009
Posts: 13
B
BigFred Offline
Member
BigFred  Offline
Member
B
Joined: Jan 2009
Posts: 13
They are on ebay - just small pictures but better than nothing smile

http://cgi.ebay.de/GB-COLOR-Spiel-MUPPET...=item35b0dd2efd

http://cgi.ebay.de/Muppets-Game-Boy-Colo...=item56363ea76b

A pic of Raku Raku should be on Dat-o-Matic. At least if you log in.

I have aquired several Sachen carts lately. Maybe we can improve emulation of these pretty soon.

Re: Fixed software lists [Re: R. Belmont] #68142
03/24/11 11:24 PM
03/24/11 11:24 PM
Joined: Jan 2006
Posts: 3,687
Trondheim, Norway
etabeta78 Offline
Very Senior Member
etabeta78  Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,687
Trondheim, Norway
Thanks for the pictures BigFred!

BTW, I can finally announce that with rev. 10922, all the original lists (created when lists were still in .c files and their usage in MESS just a faraway dream) have finally been filled with the fundamental info about publishers and release year (+ basic parent/clone relations and correct descriptions)

I'm pretty sure some typos are still present, of course, but e.g. all the Game Boy lists now contain valuable info instead of a series of 19?? - Unknown fields smile

Having fulfilled my duties with the original lists I created, I can shift back my focus on the creation of new lists, like a pc8801 one... stay tuned!

Re: Fixed software lists [Re: R. Belmont] #68171
03/26/11 11:53 PM
03/26/11 11:53 PM
Joined: Jan 2006
Posts: 3,687
Trondheim, Norway
etabeta78 Offline
Very Senior Member
etabeta78  Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,687
Trondheim, Norway
A bunch of comments about the change in svn 10936: with the latest code, each software entry can store three different kind of 'extrainfo' strings. They are thought to be used in specific cases, so let me briefly explain the big picture behind them.

1. <feature> fields: these are well established in current lists. they belong to a <part> element (i.e. a specific cart or cd disc or floppy disk) and they can be used to store hardware details that belongs to that specific <part>. typically, we have used these to describe the pcb_type of a cart (e.g. the board type in NES carts or in AES carts, to remove the need of specific mappers), so that at loading time they can be checked and the emulation can be setup accordingly. However, some lists (e.g. snes.xml and, in a few months, nes.xml as well) use these more creatively, to e.g. document the exact chip locations on the pcb

examples
<feature name="pcb_type" value="MMC3C"/>
<feature name="u3" value="SRAM-64M"/>

----------
2. <sharedfeat> fields: these are listed in the main <software> entry, but get stored together with the <feature> of each part of this software. E.g. if your software entry consists of 9 floppies, these shared features will be inherited by *all* the disks. The typical usage for this is to list the compatibility requirements of the software entry, e.g. a PAL system, or the presence of an expansion card, or the presence of additional RAM. These compatibility settings have to be manually parsed in the loading code by the driver author, but it makes more sense to define them only once for each software entry than to copy and paste it for each <part> (and believe me, it makes a difference both in terms of avoiding redundant lines and in terms of time necessary to create the xml list itself, when you deal with hundreds of multidisk entries like in the forthcoming pc8801 floppy list). consider this as a shortcut for 1. when you have multidisk software.

examples
<sharedfeat name="compatibility" value="EUR-JPN"/> (the value can be freely chosen by the driver author as long as he also add the correct values in the loading routine wink )
<sharedfeat name="addon" value="DVC"/> (this can be of use in cdi titles which won't work without the DigitalVideoCard expansion)

----------
3. <info> fields: these belongs directly to the main <software> entry, like the <sharedfeat>, but they do get stored in the main software entry, not with the <part>. They should be used to store additional info which might be of use for frontends, but that are not strictly necessary for emulation (if you have to describe some fundamental hardware characteristic that has to be checked during emulation, then you should use <sharedfeat> not <info>). Possible examples include the name of the development team, or the serial number of the cart, etc but it's up to the list creator to decide what to use this for and if to use it at all

examples
<info name="developer" value="Treasure"/>
<info name="serial" value="NUS-NSMJ-JPN"/>

As already said in the svn commit, imho the format can now be considered finalized. I cannot really think of anything else that we might want to include in the format, without getting redundant.

p.s. In fact, some small change is still required in the core to fully support the new fields (e.g. at the moment <info> are not loaded by the core), but the xml format won't be touched.

Re: Fixed software lists [Re: etabeta78] #68178
03/27/11 03:08 PM
03/27/11 03:08 PM
Joined: Apr 2005
Posts: 552
GERMANY
Darkstar Offline
Senior Member
Darkstar  Offline
Senior Member
Joined: Apr 2005
Posts: 552
GERMANY
Originally Posted By etabeta78
...
<feature name="u3" value="SRAM-64M"/>
...


Wouldn't this be saner with a more standardized "key=value" system? i.e. the above is really 2 features, a board location for the chip and a chip type. Why not make that 2 seperate entries?

<feature name="chip_location" value="u3"/>
<feature name="chip_type" value="SRAM-64M"/>

this way, all lists could use the same feature names and it would be easier to parse for external tools. the current format would require regexes or similar to completely parse.

-Darkstar

Re: Fixed software lists [Re: R. Belmont] #68180
03/27/11 03:35 PM
03/27/11 03:35 PM
Joined: Jan 2006
Posts: 3,687
Trondheim, Norway
etabeta78 Offline
Very Senior Member
etabeta78  Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,687
Trondheim, Norway
it seems that my examples were not really clear (probably I should have added more)

anyway, the location+chip features have been been added by MESSfan to document the precise content and layout of the carts.
they are not used by the emulator to determine the presence of each component (in this case, it's not used to check if SRAM is present in the cart nor its size)

in other words, current lists use <feature> in a twofold way: you have features that are used by the emulator at loading/running time (like "pcb_type" or "part_id") and features which only document the hardware (like this "u3").
for the former we already use what you suggest (and it's important since we need to parse them for proper emulation); for the latter I don't think it is important the way you include the info as long as it's included.
what I like in MESSfan's format is that in principle you could graphically represent the chip position by combining pcb_type (which tells you available locations) and the locations themselves: sort of
Code:
          SHVC-1A0N-20
 |----|
 | U1 | MASK ROM
 |----|

 |----|
 | U2 | CIC
 |----|


OTOH, the other solution you suggest would not work: the way we store/retrieve features requires each feature to have a unique 'name' in order to be searched for at a later stage. hence, we cannot have two chip_location entries.


Page 112 of 120 1 2 110 111 112 113 114 119 120

Who's Online Now
4 registered members (AJR, Edstrom, mixmaster, 1 invisible), 159 guests, and 3 spiders.
Key: Admin, Global Mod, Mod
Shout Box
Forum Statistics
Forums9
Topics8,625
Posts112,775
Members4,839
Most Online324
Dec 20th, 2018
Powered by UBB.threads™ PHP Forum Software 7.6.1.1
(Release build 20180111)
Page Time: 0.050s Queries: 15 (0.033s) Memory: 5.7415 MB (Peak: 5.9644 MB) Zlib enabled. Server Time: 2019-02-17 12:01:42 UTC