Previous Thread
Next Thread
Print Thread
Page 1 of 7 1 2 3 4 5 6 7
#86653 03/10/13 01:45 AM
Joined: Mar 2013
Posts: 332
Likes: 1
I
Senior Member
OP Offline
Senior Member
I
Joined: Mar 2013
Posts: 332
Likes: 1
Now and then, I've seen mentions of XML files being used to complement ROM formats, but the conversation usually gets ignored in favor of not getting off-topic, so I thought it would make for an interesting separate topic.

Please allow me to start with a (hopefully meaningful) wall of text.




Back when the many Mega-CD BIOSes were being dumped, I noticed that those which were being dumped through a special cable + program burned onto a CD (rather than directly reading the chips inside), resulted in dumps that differed from the chip's actual data in a few places.

Then, some time after that, I read about the F-22 Interceptor Mega Drive ROM (commonly known as a good dump) being found to give different dumps depending on the used device. It turned out that this cartridge has two chips of different sizes inside but they've always been dumped as being the same size, which made some random garbage appear where no more real data could actually be found.

So it would seem like there might be more "bad good dumps" out there that will never be found out unless somebody actually takes the chips out and dumps them. That makes the old way of dumping seem a bit unreliable for accurate preservation.



I know that, even nowadays, many people are still thinking "what for?" when others ask about getting individual chips dumped rather than just getting anything that could work with emulators, but I'm also seeing that the MESS project seems to be striving to follow the same direction as MAME, in regards to actual historical preservation of the media, so this topic might be worth some discussion.


As for the general public not being too interested, I've got to say that those who just want to play their free games have hardly ever showed a special interest in MAME's split-ROM system anyway, and wouldn't have minded just having big single .ACD files with all the ROMs combined. Thankfully, this has never stopped the MAME devs from enforcing this system, even if part of their user base just will never care enough to understand it.


Since MESS is not about slapping together your regular console and computer emulators for playing free games, it can actually improve over the standards that were originally created for quickly dumping through a copier, publishing and downloading games. It's also not about altering the games' code (or the emulator's core) until they "work fine", but more about preserving the contents of those groups of chips, understanding how they work and then replicating that behavior.



In my oppinion, arcade emulation has always been ahead of consoles in this regard, and it's something that could be improved upon by making dumps of the actual chips inside the plastic cases. The examples I posted show that it's always important not to assume that external devices or the systems themselves can always correctly read all the data from inside these chips, something that has already been addressed before

Sure getting all the individual ROMs would be a task of gargantuan proportions, but so is all the arcade ROM dumping that's still being done in a constant basis. ROM dumps pending an EEPROM reader are normally marked as "bad dumps", so perhaps this should also extend to the actual ROM-based games.



Let me note that, of course, this wouldn't completely ditch all of the old formats, since there's some official ROMs that were never burned into a chip to begin with (like prototypes that were just stored in discs, game collections for other systems, etc), so "casual" emu users would always still be able to play their million-ROM collection if they wanted to.






Now on to the other topic at hand:



Back when I found out about MAME a while ago, I was curious on why it only supported games from a "softlist" that required to be audited from beginning to end. To me, in contrast with other non-arcade emulators, this system seemed like a step back but, once I understood that the data contained in the ROM dumps of these games didn't include proper information specifying the original hardware configuration, etc, I just got used to it and stopped giving it too much thought.



Around that time, I also found out about NES ROMs really consisting on the actual contents of the original PRG and CHR chips pasted one after another, with an appended "iNES header" that wasn't really inside the original game's code, but was needed in order to trigger the required specific mapper from the many that existed. I understood that making gamelists for a system like the NES would be crazy, with all the bad dumps, hacks, trainers, etc, that were out there already in the late 90s (just hex editing a 0 to a 1 would create your own entry in GoodNES). If not impossible, making a full NES gamelist for use with the emulator could make it way too slow to boot and thus impractical to use, so once again I accepted this newly made format while many people just didn't even know or care about what it really was (even some of the original publishers have accepted it as a standard for their re-releases on PCs and newer systems).


Some time later, troubles arose with certain NES dumps and thus the UNIF system had to be made with a brand new header. Even though it was made as a replacement to the old format, it ended up being mainly relegated for those cartridges with tricky hardware inside, so it still coexists with the knowingly flawed iNES standard.



Meanwhile, an extra internal ROM found inside Sonic & Knuckles was finally dumped, something that allowed using the real unmodified ROMs for emulating this specific combination without just getting a blank screen. However, you still had to artificially combine all three ROMs into a big one in order to play it. Nowadays, emulators that support it just treat this cartridge as an exception that will allow for using the Lock-On system with other games, with similar cartridges that sport an additional slot like the Game Genie also having to be hardcoded in the emu in a case-by-case basis.



Then the SVP chip got fully documented and Virtua Racing MD was finally emulated. No ROM dump needed for emulating it, since the emulators mimic its behavior themselves like usually happens with all those special SNES chips. What felt a bit odd to me was seeing that MESS had separate hardware selectors for Mega Drive games with SVP, Super Nintendo games with SDP, etc.



So, after all this, I noticed that Byuu had been trying to push for a new system for storing SNES games, involving folders and an XML file with additional info, and that made me realize something.

Just having a small XML stored along with the ROMs would, for any system:
  • Allow to automatically activate any special chips present inside the cartridge (SVP, Super-FX, MSU1 or anything else that could be discovered/developed in the future), without having to choose a specific "hardware mode".
  • Allow to prompt for another game when loading any cartridge that has its own slots in it, be it Sonic & Knuckles, any Game Genie or Action Replay versions, Same Game or any future game, without having to hardcode it into the emulator or having to join many ROMs into a big one.
  • Allow to automatically append a specific ROM from its ZIP/folder when the secondary ROM has a certain checksum (for example, adding the extra ROM when any version of Sonic 2 is being connected to Sonic & Knuckles).
  • Allow for the real ROM dumps to be preserved without added headers or having to change file standards when incompatibilities arise, since only the XMLs would have to be edited as long as the dumps are good.
  • Allow to just audit the games you have stored rather than waiting for a whole gamelist to be parsed.




What could that XML include? I personally think the less the better, with just enough info to identify the ROMS (names of CHR and PRG chips in the case of NES games) as well as whatever makes the specific game "special", when it absolutely needs to be specified.

I feel that some special emphasis should be made in trying to avoid absolutely everything that's external to the actual cartridge/device (no country, release date, label, cover, instructions, trivia, cheats, etc), which could bloat its size to unlimited extents and could always be handled by external applications when/if they wanted to (as is the case of MAME).

In any case, there's a lot of knowledgeable people involved in MESS who would surely be able to come up with an XML formatting standard for MESS that would cover these possible special cases, specially with all the progress that has been made in documenting and successfully emulating old hardware over the years. If the devs think it shouldn't be such a simple file and it should include a diagram of the whole physical circuitry that the emulator would just need to interpret on the fly... well, so be it.






So, in a nutshell, this system would be just like MAME's, having the individual chip dumps stored in either a compressed file or uncompressed folder, only with an XML file inside that identifies any peculiarity the current physical device might have.


What's your oppinion on this subject? I'd really like to know what you guys think of it, and the possible flaws you might foresee with using such a system.


LCD artwork scans and cleanups: https://mega.nz/#F!uFYSzK7S!U-lJon9jsqyoCX_3y7_KLA
Joined: Sep 2008
Posts: 105
W
Senior Member
Offline
Senior Member
W
Joined: Sep 2008
Posts: 105
MESS already uses "Software Lists" (aka softlists) for many of the emulated systems. There is a discussion of them here.

Joined: Mar 2013
Posts: 332
Likes: 1
I
Senior Member
OP Offline
Senior Member
I
Joined: Mar 2013
Posts: 332
Likes: 1
I'm already aware of that, but thank you in any case.


I hope the length of the opening post hasn't thrown some people off... I just thought using examples I've seen happen in the past years would help illustrate those points better.


LCD artwork scans and cleanups: https://mega.nz/#F!uFYSzK7S!U-lJon9jsqyoCX_3y7_KLA
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
For MegaCD the problem was already noticed, especially because it has a ROM overlay system for the interrupt vector, so one word of the ROM will always read as whatever your register is set to if you read it via the machine. That's kinda obvious if you look at how the system works.

Although I guess that's what you're trying to say anyway?

Dumps are replaced when better ones come along, the problem with marking the *entire* database as bad is that people will think the MESS listings are inferior to the ones simply due to that marking, and it makes distinguishing which ones are REALLY bad much more difficult.

Like has been mentioned, MESS has the software lists, that's our database of what we know, where all the documentation goes. You can try inventing 'Yet Another File Format' with all your ideals in it, but in all honesty it's unlikely to fly, simply wanting to use the proper dumps of things in MESS (and HazeMD before it) caused a lot of bad feeling and friction.

Obviously having some kind of per-game XML would help with homebrew cases, but people would still have to support it, and the majority just want to hang on to whatever old version of Fusion they have forever.

I'm all for getting proper dumps, but I think people need to work together, not further fragment things. Right now if you do a proper dump you can submit it to the Software Lists, they will be updated to reflect that. Obviously things like the Game Genie will still need to be special cases, because the carts contained extra logic, just like S+K. Even with an XML system you couldn't possibly describe *every* piece of extra logic any cart has in XML beyond a 'mapper number' for the complex cases so you're always going to have some dependency on the emulator.

The MESS lists are basically considered free for anybody to use AFAIK.

You've said the arcade stuff is handled better than the consoles, and part of that is the integrity a project like MAME offers rather than everything depending on trying to run any old files with random headers and voodoo hacks in order identify features. With MAME you know if you have the correct (best known) ROMs because if you have the latest version they'll be the expected ones. If you shift that responsibility to an XML file distributed with the ROMs it becomes less obvious, something could be found out to be bad, and you have no place to mark it.

All you have in the end with your proposal is just another form of header albeit a human readable one, in a separate files, even more likely to become disconnected from the ROMs or hacked.

Some would however argue the MAME approach is not as good, because we don't have flags to say how many times something has been verified etc. and it forces a certain file naming scheme, but the latter helps with things like bug tracking.

Either way the MESS lists attempt to do the same for the home stuff, providing an always updatable database, where the details of exactly what is inside each cartridge can be listed with great detail and hopefully (eventually) acting as a definitive reference for what is right, just as MAME does. If people focus on that there is no need for yet another standard IMHO. I think keeping the knowledge separate from the actual ROMs like this makes sense because it allows the facts to be updated and be widely distributed with no legal issues, then simply requires people to have the right files to match the current level of knowledge if they want to run something. It might be slightly less convenient for people if they have a rom we deem bad / incomplete and it no longer gets recognized, but as I've said, it gives a higher level of integrity because you can always get the *knowledge* of what's right from a trusted source rather than it coming from some seedy romsite.

If MAME had gone down the route of allowing individual ROM files to contain their own XML descriptions people would still be trying to run 0.3x era NeoGeo roms in 0.148 (and vice versa) then wondering why they fail rather than MAME explicitly letting them know the files they have aren't going to cut it because they don't reflect current levels of knowledge / correctness. (of course MESS will always be more open, but you know better where you stand)

The advantage here is of course because the SL comes with the emulator you're not going to have people mixing+matching lists and emulator versions. That means if a cart comes along where we NEED to add features to the emulator in order to support it then the lists referencing those features will also be the one found with the version of the emulator supporting them, and when you're dealing with unknown carts (especially pirates) that can happen, often, because many of them have their own (unique) protections. Again that's your 'integrity' thing.

Header XML files don't really give that, if you dump a new cart with an unknown protection, what do you do? assign it a name, an identity? What if it then turns out to be the same as something else? You can't take away the name you assigned it, and every emulator has to acknowledge the duplicate name to ensure the files still work. When the list is more closely tied to the emulator it doesn't matter, the list gets updated, there are no roms out there with buggy / incorrect XML headers due to the initial lack of knowledge, there is one valid list of such details, the current one, and everybody knows where to get it.

The MESS hardware selector thing for SVP etc and the SNES DSPs. is temporary, and existed due to limitations in the core (at the time you couldn't add a CPU to the emulation based on the content of a cart, it had to be a different machine type) The end goal is that the SL XML specifies the cart type, and the CPUs get added, just as the S+K emulation now gives you an extra slot to play with, and you can insert any other cart on that.

I do hope the SLs get expanded to support cartridge profiles at some point too, allowing for easier use of homebrew software with more advanced configurations, but that's still one for the future.


Joined: Mar 2013
Posts: 332
Likes: 1
I
Senior Member
OP Offline
Senior Member
I
Joined: Mar 2013
Posts: 332
Likes: 1
Wow, thank you for your insightful reply.

Those are some very good points regarding the XMLs; the way you've explained it, it does indeed seem to be a much better choice to have the updated info always available on the emulator side.

Of course homebrew games would seem to be a different story, with unlimited test versions being constantly released on message boards, which would unnecessarily bloat the gamelists if taken into consideration.

For these, perhaps, it could be made that, when the emu can't find an entry in the gamelist, it could look for a single gamelist entry inside the games zip/folder? This might eliminate the homebrew problem forever, without having to change the way things currently work.


What I'm not sure is where the line between original pirate games and homebrew games could be drawn, when having to choose wether to make or not a new entry for the softlists... Nowadays, any homebrew games can be burned into a flash ROM, as seems to be the case with that Super Mario Bros port by Mairtrus, which can already be seen being sold as a bootleg.




About dumping the separate ROMs whenever possible, marking all the ROMs that haven't been individually dumped as "bad" does indeed sound a bit radical, I guess I just misread this post, because I thought that's what was currently being done.


I've just checked the Mega Drive and NES softlists and I see there's some instances of individual chip dumps having been done at least with those systems, albeit not many in the case of the Mega Drive. Being a feature that actually makes dumps consistent between all systems including MAME's arcade dumps, I'd say it's very surprising to see it being left as such an obscure feature that few people may be aware of.


One of the things that make this feature so obscure is the fact that there's no simple way for being able to tell the real verified dumps apart from the bulk of the old format or the pseudo-good dumps that have been made by splitting old existant ROMs.

I just think it's a shame that people won't even suspect their help might be needed for getting the remaining games dumped, unlike with MAME, where you can instantly see if a specific redump is needed. Some people might actually be willing to help and just may not know that they actually can.



...But perhaps I've missed something, so I need to ask, is there currently any place where these verified ROMs are being announced and kept track of, and where people can lend their cartridges so they can be added to a documented list of existant "proper" dumps?


LCD artwork scans and cleanups: https://mega.nz/#F!uFYSzK7S!U-lJon9jsqyoCX_3y7_KLA
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
The Super Mario Bros port is already in the softlists, along with a bunch of other Russian pirates. They're commercial now, so would quality by default even under a stricter policy than the one we have.

You end up with a lot of stuff, but if you're documenting the home systems you have a sizeable home 'scene' to document too, and yes, sometimes that means a bunch of test versions, but we have that for some regular games too (look at all the 32X / Genesis protos released a few years back, some of them don't even boot on original systems because they were just buggy daily builds)

Like I've said, I hope the softlist gets a 'profile' feature one day, then you could launch your homebrew with a direct cart path and a 'profile' so that it picked the content of the cart (other than the ROM) from the softlist. Nothing has been decided for that yet tho.

It would be 'easier' if people doing homebrew had the ability to make an XML and have emulators recognize it, like you say, but quite a bit of the homebrew you see involves custom cartridges anyway, with extended banking and other nonsense to get around limits of the original system (at least on the 8-bits where you have modern stuff accessing amounts of flash ROM that would have been absurd back in the day) For cases like that you're always going to need the emulator support, or constantly revise what your individual XMLs support anyway so it doesn't IMHO actually make it much easier if you want to do something complex.

Like you say, not much has been done on the MD front when it comes to 'proper' dumps in the softlists, and that should give you some idea of the level of interest in doing such with the scene in general. While we do greatly appreciate it being done most people couldn't care less, they don't WANT to crack open the carts just to dump a chip and write down a proper label for what is already available. Arcades are more often bare PCBs so it's easier. Furthermore you need somebody aware and willing to put the information in, SNES has that probably to a greater degree than MD at present, but again that comes back down to interest. There are people who have opened up MD carts and noted down the part numbers, but then not dumped the ROMs so you don't really know if what they list corresponds to the existing dumps anyway!

The other thing to keep in mind with the Softlists is that they're meant to represent best available, the idea is that if any dump of a pieces of software exists it should be listed, that can be replaced by a better dump when one comes available. The general philosophy is that what we document is what we're leaving for the generations to come, and it would be irresponsible to NOT list something just because it isn't in a perfect format, we just have to hope people will replace them with better, so we can document better if better becomes available. The final point is that they exist to support the emulator, so any test software which can help validate the emulation, or provide solid edge case tests is infinitely useful to us (it avoids people making bad changes) even if a project like No Intro might ignore it.

What I hope is that eventually everything will converge and people can work together to document things properly and different people can concentrate on different areas of interest. It would be nice if MESS can provide a place for people to do that, just like MAME does for the arcades, they're all part of the same project anyway. The problem is right now with all the different groups, and standards, each one wanting to exclude certain things etc. it can as you rightly say be very difficult for somebody to know what to contribute and where, unlike with MAME where for better or worse you have something more authoritative and basically know that if something isn't supported, it isn't dumped. With enough work the Softlists in MESS can provide the same authoritative reference, and of course improving out emulation will help with that too (right now MESS isn't quite good enough for some of the key systems for people to treat the information as such)

I've stated before I'd like to see both MAME and MESS fully under one roof, to emphasize the point that the MESS stuff *is* the MAME equivalent for consoles, and we're already seeing strides in that direction. The current source SVNs are shared, so the MESS Software Lists sit alongside the MAME stuff in all the distributions even if the binaries of the official distribution are still separate at this point. One of the motivating factors for me promoting this idea has been that I hope it makes people realise that the MESS lists *are* our attempt to do the same for the consoles as we do for MAME, and it's all part and parcel of our ongoing documentation / preservation efforts people have come to understand.

You've already mentioned that almost nobody bothered with the new NES formats and you still end up with mostly iNES roms, and that's simply momentum, and unless you're going to give regular users a tangible reason (other than OUR FORMAT IS BETTER!) you're not going to persuade them to adopt a new format, there is simply too much history. The MESS approach just avoids that by not caring, we list what we list, if new things come along we replace the old ones. It's again a philosophy inherited from MAME, and because a lot of MESS users have a background in MAME it tends to be understood (even if people do have some teething problems with it and it can seem quite alien / obtuse for people coming from other console emulators)

Like I've said, the MESS emulation isn't really that great for a number of systems, so you're always going to have that to contend with, and that will put some people off the 'MESS standard' roms, especially when nothing else currently even parses the Softlists, but I've also noticed that there are a fair number of people who are quite willing to accept a lower quality of emulation and less features for the convenience of a common platform which therefore becomes one of the 'user benefits' with MESS. What would your user benefit be for a new XML format? How are you going to convince people it's really better, rather than just have the majority ignore it?

For the newer platforms like N64 it does become a problem, the emulation is simply so slow that nobody in their right mind is even going to consider using it, but simply due to the size of MAME / MESS the list can survive within the same project much as drivers for several systems with absurdly high requirements can survive in MAME.

CD systems are more of a problem, and if you thought it was difficult getting people to agree on dumping standards for carts you've seen nothing, and on top of that MESS expects things in a different format to everything else, as CHDs. I'm actually surprised by the number of people who have followed the MESS CHDs so far, but scout around, and you'll find that most people would have much preferred it if we'd just used the original formats there too instead of reinventing the wheel even if what we do have is a CD format which is both compact, streamable, and contains the information needed to verify the file integrity. Merely having good ideas in a new format isn't enough because the thing people hate most of all is change, especially when they can't *see* any benefit.

As for marking things as bad, maybe other devs have different policies, I certainly wouldn't consider it in the MD list ;-)

btw, I do fully support your ideas of getting these things better documented, don't get me wrong, part of the reason I created HazeMD was so that proper dumps could be represented in a MAME way, even if basically nobody cared about dumping them. (The other part was so that I had my own tool to explore the pirate carts and emulate the protection, which at the time nobody else had bothered doing, and of course build better code for the MAME systems using the Genesis VDPs) The problem is HazeMD was rather insignificant, a drop in the ocean compared to what was already out there, and a bit of a departure from everything else. It did go down well with MAME users and cab owners tho. because it was instantly familiar.

Everything I did there is now in MESS, which is slightly more significant, and slowly starting to gain the same recognition as MAME with us making the ties clearer. What we need is a) for more people to recognize this + our ongoing efforts, and b) contributors to further things along, both in terms of the hardware emulation AND the software documentation, although finding people, especially to improve emulation is becoming increasingly difficult.

If we can get that further in motion then all this 'ROM format' and 'ROM header' stuff slowly becomes irrelevant as people adapt and get used to the MAME way of handling things. Also MAME has a lot of weight behind it, and by keeping MESS close we it benefits from people realising that if they port MAME to new platforms they also get a lot of other emulation for free via MESS. I think in the long term that makes more sense than trying to come up with another new format people aren't going to see any real benefit to even if it is a good idea / good format.

Obviously these views are going to be slightly biased (but hopefully seen as honest) because my roots are in MAME / MESS, but my primary interest is in creating one good reference, for everything, so that future generations have something they can trust, not fragmenting standards further and making it harder for people in the future.

None of this would be complete without a plug for 'my' current project, UME, which is just MAME with all the MESS bits enabled (I say 'my' because I don't change anything these days, it's just an alt target in the official source) If nothing else makes it clear that MESS is the MAME ideals and code used for a console emulator that should because it shows just how close the bonds are and I'm hoping it slowly wins people round to the idea that the MAME way of thinking can be successfully applied to documenting non-arcade material by making that clear in unequivocal terms. It's not some libretro thing glueing together multiple emulators of different architectures and codebases, it's the complete form of one emulator with the same architecture and codebase and same ideas from the same developers with the same long term attitudes and goals and it works. You can flip between Thunderforce AC (MD Arcade hardware hw) and Toe Jam + Earl (regular MD) or Puckman Pockimon (bootleg Arcade MD hw) barely lifting a finger, knowing you're running exactly the same code behind it all and that the same thought process has gone into it. By doing that, I hope the MESS lists can become more established and better understood with people seeing them as an extension of the MAME ideal(s).

There are benefits to MAME too, but this isn't about that, it's about why I think the MESS Software List approach at least has the long-term potential to be better than another new format, and how we're trying to help with that and how in the long run I hope it's the one that makes a real difference. You're free to disagree :-) At this point emulation is an important piece of historical work and larger scale things like MAME and MESS are your encyclopaedias and most likely to be carried forward IMHO.

Joined: Mar 2011
Posts: 54
F
Member
Offline
Member
F
Joined: Mar 2011
Posts: 54
While it might not have an overly large impact, I think one step needed to get more proper, documentation-grade dumps is a simple how-to guide.

While I don't really have many games nor much software I'd gladly dump and document them all for preservation/emulation purposes. The problem starts at the very first step, though: I don't really know how.

If we take the SNES for example, what's the standard operation for dumping those carts? Opening up the cart to document what's inside is a gimme, but can the cart be accurately dumped in some kind of copier or a Retrode? Do I desolder the chips and dump them in a programmer? What kind of programmer would I need for that? Will a Willem make do? What settings do I use for those ROMs?

Not every little thing can be explained of course, as the carts may have innards containing anything from epoxy blobs to god-knows-what, but some general guidelines on the Wiki of how to do it the proper way would at least give a starting point where ignoramuses like me can get going. And perhaps be a good landing place to send others who wish to help out all the same.

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
That's beyond my field.

I know some SNES carts use funky chips with weird sizes, I guess that could cause problems for some programmers, so you'd probably need a specific guide for those.

For anything with only a single chip the cart copier approach isn't unreasonable, likewise if you already know the profile of the cart and exactly how a proper dump should get split for that cart.

For the epoxy blob carts you're going to have no choice, unfortunately some of those also implement custom banking within said blobs so a cart copier will struggle too and you might need custom hardware, the blobs were after all done as a form of protection.

SMS carts also use funky rom chips with built-in banking and many programmers will only give you a bad read.

For a lot of platforms you're just dealing with fairly regular roms or chips compatible with such, although some might be unmarked masks, but cases like that have caused problems with arcade games too (an absurd number of Sega / Kaneko MASK roms ended up dumped as half size, and it still happens sometimes)

So yeah, a blend of experience and knowledge is needed so finding somebody knowledgeable about the platform can be important if you're presented with something odd upon opening up the cart.

Joined: Mar 2013
Posts: 332
Likes: 1
I
Senior Member
OP Offline
Senior Member
I
Joined: Mar 2013
Posts: 332
Likes: 1
If I knew of a trustworthy person I could send some of my cartridges to, and was given the warranty of receiving them back in working condition after the dumps took place, I'd send a bunch of them right away...


I originally bought a Retrode in hopes that it would allow to make perfect dumps, but it can't do them chip-by-chip. Kind of a bummer. =\


LCD artwork scans and cleanups: https://mega.nz/#F!uFYSzK7S!U-lJon9jsqyoCX_3y7_KLA
Joined: May 2011
Posts: 25
S
Member
Offline
Member
S
Joined: May 2011
Posts: 25
Yeah, the die-shrinked ROMs are always a problem. You can only guess the capacity by counting the address/data lines but this is no guarantee they contain the supposed memory cells. If you try to access the non-existing cells you may get a unspecified result. Some will mirror the last data (= ignores selected address line). Those are easy to detect.

A Retrode might work for single ROM carts. At least you have to ensure the PCB uses a common/1:1 edge connector <=> ROM wiring.

The MD softlist is in work - I hope. I did already lots of redumps and provide a DAT for true raw-dumps on my website. I didn't added the redumps to the softlist due some "endianness-war" and I don't want to maintain two kind of dumps. But etabeta is working on a "conversion" to adapt my stuff to the softlist. As speaking for the MD the future looks probably more promising than other systems. I'm not the only one whos dumping that way.

Page 1 of 7 1 2 3 4 5 6 7

Link Copied to Clipboard
Who's Online Now
2 members (DarthMarino, Vas Crabb), 32 guests, and 2 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