Previous Thread
Next Thread
Print Thread
Page 15 of 30 1 2 13 14 15 16 17 29 30
Joined: Jan 2013
Posts: 73
A
Member
Offline
Member
A
Joined: Jan 2013
Posts: 73
It's on your box!

Joined: Mar 2001
Posts: 16,834
Likes: 43
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,834
Likes: 43
Thanks!

Joined: Oct 2007
Posts: 300
F
Senior Member
Offline
Senior Member
F
Joined: Oct 2007
Posts: 300
Originally Posted By Haze
In single .bin file mode the pregap information (except the first 2 seconds) is usually stored.

CloneCD .img usually has all the data (with offset garbage, of course), .bin usually has all the data track pregaps and post-data audio track pregaps cut and replaced with PREGAP (since it's a CDRWin standard).

Originally Posted By A. Viloria
If it helps, I have found a "Dark Matrix (J)" (Saturn) BIN/CUE with this CUE:

Code:
FILE "C:\SATURN\170 BLACK MATRIX (J).BIN" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
  TRACK 02 MODE2/2352
    PREGAP 00:03:00
    INDEX 01 33:03:00
  TRACK 03 AUDIO
    PREGAP 00:04:00
    INDEX 01 58:04:71


The image is about 418MB. And its easy to find/download googling.


As for the data track pregaps, they usually have the first minute in the previous track's mode and the rest of pregap is in the next track's mode. In this case it should be 75 sectors of Mode1+150 in Mode2. If the pregap is of xx:xx:74 type (common for PCE), then it goes 74+the rest. But if you're going to make a list of good dumps, you should avoid any image with PREGAP, since these are incomplete images with the data stripped out. And if it's known, that the image was done with CDRWin - it should be especially avoided, since Darkwater set is full of dumps with random errors in audio tracks, CDRWin ignores them, linlhutz dumps also have these problems + no gaps at all in most of cues.

Joined: Aug 2009
Posts: 1,142
Likes: 3
Very Senior Member
Offline
Very Senior Member
Joined: Aug 2009
Posts: 1,142
Likes: 3
Originally Posted By R. Belmont
Bump/reminder: if anyone can supply the original bin/cue rips that generated the images Kale had problems with, please PM me. (Kale apparently does not know where he got his own images. True fact). It is not possible to add any more images to CD-based softlists until this problem is resolved.


Never said such a thing.

Joined: May 2011
Posts: 25
S
Member
Offline
Member
S
Joined: May 2011
Posts: 25
btw, why do we have to specify the size in dataarea?

The size-sum of the rom entrys should do well, shouldn't it?

Joined: Mar 2001
Posts: 16,834
Likes: 43
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,834
Likes: 43
Same reason MAME doesn't auto-size ROM regions when it could - we frequently need the flexibility of extra space.

I wouldn't mind an "auto" size option, both in softlists and in REGION_START() though.

Joined: Jan 2006
Posts: 3,690
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,690
two games from megadriv.xml come easily to mind as good examples of how useful this flexibility is

- there is a quackshot revision which contains 0x80000 bytes of data loaded in non-contiguous areas of a 0x140000 region. Having a dataarea larger than the rom allows to 'emulate' the pcb line connections very easily (much more than having to redirect the upper 0x40000 at loading time)

- the other example is super sf2, where I haven't managed to implement the bankswitch when using 5MB of dataarea only, without breaking the ingame checksum check at start. so I currently mimic'ed original HazeMD trick to allocate 9MB of dataarea, with the real rom moved to the upper 5MB and the banks getting copied at request on the lower 4MB of accessible memory
eventually, I'll get bored enough to give another look to the code to fix this, but in the meanwhile this is a very clean workaround

Joined: Jan 2013
Posts: 73
A
Member
Offline
Member
A
Joined: Jan 2013
Posts: 73
In latest SVN submision (r22515) there was an error in 'gbcolor.xml': line 929 is duplicated making the XML invalid.

CMP breaks down importing the file.

This is the problematic entry:
Code:
	<software name="ejim">
		<!-- Notes: GBC only -->
		<description>Earthworm Jim - Menace 2 the Galaxy (Euro, USA)</description><!-- only Euro confirmed -->
		<year>1999</year>
		<publisher>Crave Entertainment</publisher>
		<info name="serial" value="DMG-AEBE-USA, DMG-AEBP-EUR"/>
		<part name="cart" interface="gameboy_cart">
		<part name="cart" interface="gameboy_cart">
			<feature name="pcb" value="DMG-A07-01" />
			<feature name="u1" value="U1 2M/4M/8M MROM" />
			<feature name="u2" value="U2 MBC5" />
			<feature name="slot" value="rom_mbc5" />
			<dataarea name="rom" size="1048576">
				<rom name="dmg-aebp-0 f1.u1" size="1048576" crc="2e65daaf" sha1="78f9bd7f8c40274cf7282892a45e814103944060" offset="000000" />
			</dataarea>
		</part>
	</software>


Sure you have seen it too.

Last edited by A. Viloria; 04/24/13 07:56 AM.
Joined: Feb 2008
Posts: 326
M
Senior Member
Offline
Senior Member
M
Joined: Feb 2008
Posts: 326
Fixed, thanks for reporting

Joined: Dec 2012
Posts: 245
L
Senior Member
Offline
Senior Member
L
Joined: Dec 2012
Posts: 245
Hopefully the last mistake, but in n64.xml,
Code:
<softwarelist name="n64" description="Nintendo 64 cartridges">

is at line 1607. It should be at line 56, otherwise it renders quite a few roms as invalid.

Page 15 of 30 1 2 13 14 15 16 17 29 30

Link Copied to Clipboard
Who's Online Now
2 members (dormml, belegdol), 22 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
Topics8,990
Posts118,128
Members5,005
Most Online890
Jan 17th, 2020
Forum Host
These forums are hosted by www.retrogamesformac.com
Forum hosted by www.retrogamesformac.com