|
The state of C64 support
#384419 - 11/27/19 11:36 PM
|
|
|
I'm curious about the state and direction of Commodore 64 support in MAME.
I was looking over the files and noticed that there's only around 900 files for the C64, while Gamebase64 has over 25,000 and other sites have much more than MAME as well.
While it's easy enough to add more files for the C64, I was curious if there was a discussion on criteria for inclusion in MAME? I know a lot of the files out there are cracks for example, I'm curious if that disqualifies them from official consideration and only original images are desired?
I'm also curious on the file formats, does MAME prefer the disk container formats or the formats that unify multiple disks to a single container to minimize disk swapping?
Thanks for any information on this subject!
|
|
|
Tafoid |
|
I keep on testing.. testing.. testing... into the future!
|
|
|
|
|
Reged: 04/19/06
|
|
Posts: 3135
|
|
Loc: USA
|
|
|
|
Send PM
|
|
|
Re: The state of C64 support
[Re: Rygar9]
#384420 - 11/28/19 01:35 AM
|
|
|
> I'm curious about the state and direction of Commodore 64 support in MAME.
>
> I was looking over the files and noticed that there's only around 900 files for the
> C64, while Gamebase64 has over 25,000 and other sites have much more than MAME as
> well.
>
> While it's easy enough to add more files for the C64, I was curious if there was a
> discussion on criteria for inclusion in MAME? I know a lot of the files out there are
> cracks for example, I'm curious if that disqualifies them from official consideration
> and only original images are desired?
>
> I'm also curious on the file formats, does MAME prefer the disk container formats or
> the formats that unify multiple disks to a single container to minimize disk
> swapping?
>
> Thanks for any information on this subject!
Time, effort and a whole lot of testing. C64 machines in MAME are not at a state where going all in on a large and complete software list isn't fully practical. As of now, I presume they consist of only images which got hands-on testing or were freshly dumped/confirmed and serve as good test cases for the emulation.
While we try to push software list use if for nothing else than consistency - people sometime forget they can use virtually any image available for the machine via the UI (File Manager) mounting or using command-line interaction.
c64 cassette (cass) .wav .tap
floppydisk (flop) .d64 .g64 .g41 .g71 .d77 .d88 .1dd .dfi .hfe .imd .ipf .mfi .mfm .td0 .cqm .cqi .dsk
cartridge (cart) .80 .a0 .e0 .crt
quickload (quik) .p00 .prg .t64
A number of types of media/data are supported. I'm unsure if any of those are the "all in one merged disk" format you mention above.
|
|
|
|
Re: The state of C64 support
[Re: Tafoid]
#384442 - 11/28/19 09:11 PM
|
|
|
One more project I should be looking at. There's a ton of softlists in need of additional care and nowhere enough time and health to spend on them all.
At the very least maybe I can see about splitting C64 between originals, clean cracks, and other.
|
---
Try checking the MAME manual at http://docs.mamedev.org
|
|
| Tafoid |
|
I keep on testing.. testing.. testing... into the future!
|
|
|
|
|
|
Reged: 04/19/06
|
|
Posts: 3135
|
|
Loc: USA
|
|
|
|
Send PM
|
|
|
Re: The state of C64 support
[Re: Firehawke]
#384443 - 11/28/19 09:52 PM
|
|
|
> One more project I should be looking at. There's a ton of softlists in need of
> additional care and nowhere enough time and health to spend on them all.
>
> At the very least maybe I can see about splitting C64 between originals, clean
> cracks, and other.
It's a lot of work no matter how you look at it.
Even seemingly smaller softlists I've started locally I wanted to update and top off for earlier consoles to include homebrew which was developed to use on original hardware - it can be very unorganized and there doesn't seem to be a centralized data collection for them as there are for other console and computer collections so I get discouraged fast when time already is limited to spend on MAME that isn't day-to-day maintaining and testing.
Whacha going to do..
|
|
|
|
Re: The state of C64 support
[Re: Tafoid]
#384455 - 11/29/19 03:35 AM
|
|
|
I agree, and C64/C128 is probably one of the hardest platforms to tackle. Second only to PC.
Gamebase64 has more than 25,000 known distinct games, including edutainment but not even touching other types of software.
Going through that list is a herculean effort, and I would imagine impossible for one person. IMO, this would take a dedicated team to handle.
I'd propose the starting point be defining a plan for tackling this effort, recruiting team members here and on other dedicated sites, and splitting the work.
And yes, I'm willing and happy to participate!
To my mind, I think a very small dedicated group would have to start with answering and gaining consensus in MameDev on the following questions...
- What file formats are to be supported? C64 has a lot of file formats that may or may not be necessary. I think it's unique in having a significant number of file format types.
- Should the original disk images be kept separate as they originally were and flipped during use, or should an auto-flipping method be introduced and the separate images kept?
- Should cracks count? Should they count as variants of a parent original that is the pristine version?
- Should MAME support new titles? (People are still making new games for the C64)
Thoughts?
|
|
|
|
Re: The state of C64 support
[Re: Rygar9]
#384464 - 11/29/19 02:53 PM
|
|
|
If you're volunteering on this side of things, I'll be glad to help-- I'm the guy doing the Apple II softlists right now.
Cracks are fine; in a lot of cases, it's all we actually have.
What I'd want to do before you start your project is to split up the C64 softlist like the Apple softlist is-- one list for cleanly cracked (meaning no crack screens, no ripped content-- as pure of a crack as possible), original disks (where possible to image and run those; I'm not sure if C64's in a state where that's possible), and miscellaneous (basically everything else-- rips, cracks with loader screens and modifications to the title screen, etc, and some legitimately important homebrew)
Take a look at how the A2 softlists are set up:
https://github.com/mamedev/mame/blob/master/hash/apple2_flop_clcracked.xml
https://github.com/mamedev/mame/blob/master/hash/apple2_flop_misc.xml
https://github.com/mamedev/mame/blob/master/hash/apple2_flop_orig.xml
That's how I'd want to approach it. Why? Because you're likely to end up with canonical copies of a game or other software package that goes into multiple categories (e.g. on Apple we have cleanly cracked MECC educational disks alongside the original images) and you'll want to separate them while keeping the filename the same so it's clearly identifiable as the same package.
If you have questions, I can be contacted here or on the MAMEdev IRC channels.
|
---
Try checking the MAME manual at http://docs.mamedev.org
|
|
|
Re: The state of C64 support
[Re: Firehawke]
#384465 - 11/29/19 03:40 PM
|
|
|
> Cracks are fine; in a lot of cases, it's all we actually have.
>
I'd go one further and say they're desirable, although recent policy seems to be to store them in separate lists (which does make sense)
MAME documents culture, these were part of it, sometimes they fixed bugs in games, or made them easier to use (compatibility with more models / hw configurations that protection was blocking) other times they introduced bugs
sometimes cracked versions are unfinished versions of the games, stolen from magazine review copies, so play different to the final for reasons other than being a bad crack
also the cracktro / demoscene stuff associated with the cracked games is just as important, and can show interesting use cases for the hardware outside of the emulated games, often pushing things to do fancy tricks; many of the people who worked on such things then went on to work in the industry, so they're part of that story too. I actually feel groups that have gone out of their way to wipe said material off the internet in favor of only clean material have done the scene a disservice.
likewise with some systems the majority of software was only released on cassette, so you'll only find cracked disk versions (or clean transfers) and in some cases those solve problems of the original media (especially true of multi-load games and such)
originals are good
recent clean cracks (just protection stripped) are good
cracks from back in the day are good
bugfixed versions are fine too (sometimes bugfixes were magazine type-ins back in the day, other times people have gone out their way to fix games today)
even enhanced versions (cases where people have added music to games that originally only supported sfx for example) are interesting.
just make sure they're probably labelled so there can be no confusion.
as a footnote, the modern development scene is a BIG part of many of these systems, and actually some of the most at-risk work as Internet sites hosting old or even current versions of it can vanish overnight, and even for ones that were sold on cassette distribution levels are much lower than they were back in the day, so that stuff absolutely needs listing with all released versions documented.
|
|
|
|
Re: The state of C64 support
[Re: Haze]
#384468 - 11/29/19 08:00 PM
|
|
|
Getting clean dumps of some of this stuff is a slightly higher priority in my book because we actually don't have clean cracks or originals for large chunks of what's out there-- and finding them is a lot harder than the scene cracks with the defaced titles, etc.
That said, I do agree that it's important we document what the scene did back in the day as much as possible and optimally I'd like to see all dumps of note get in there somewhere.
If I could clone myself, I'd volunteer to triple my workload...
|
---
Try checking the MAME manual at http://docs.mamedev.org
|
|
|
Re: The state of C64 support
[Re: Haze]
#384530 - 12/04/19 02:08 AM
|
|
|
Firehawke, Haze
I've been looking at this closer, and I'm concluding it'll be both easier and harder than I was initially thinking.
On the easier side, I have a source for the full names of a lot of the material out there. So I'm thinking I can use that as a starting point, and build a tree out of it. Or more specifically, use Neo4j to build a graph database out of it.
Main nodes would be names as a parent, children would be details of each "Rom", edges would be filesizes/crcs to differentiate between variants.
Then I take a directory full of those roms, and write a utility to scrape their details, traverse the graph, insert if it's not been seen before, and move it to an appropriate directory.
Once done, I can dump the graph to a softlist and have most of the detail.
But the hard part...there's a phenomenal amount of variants. every time I touch a collection of material I'm finding variants. I think it's going to take me longer to collect the C64 content than it is to generate the softlist.
Further compounding this is - I can't tell what's a crack and what isn't without exploring every single file. At least not in a way that I know of yet, but I wanted to run something past you.
The one thing I could think of, cracks have common intro screens, which means they should have common binary. I could find those binary patterns, log them, and search each file for that pattern, then classify them as cracks.
Thoughts? Does that seem feasible?
|
|
|
|
Re: The state of C64 support
[Re: Rygar9]
#384534 - 12/05/19 01:27 PM
|
|
|
A little too tired to parse through most of this right now, but I'll add one thought-- you can generally tell normal cracks by the defacing of titles or intros or even the addition of a trainer.
Cleanly cracked won't be obvious. I'm not even sure there's anyone in the C64 community looking into revisiting those old disks like 4AM is for Apple stuff, so I guess that's not really something to worry about yet.
I plan to look into modifying the C64 softlist files soon (probably in the morning, in fact)-- the general plan is to start by moving everything in the existing disk softlist (c64_flop.xml) into c64_flop_misc.xml and add support for other softlists similar to how I did the Apple split. That'll open things up for you to start work.
|
---
Try checking the MAME manual at http://docs.mamedev.org
|
|
|
Put in a PR for softlist splitting.
[Re: Firehawke]
#384539 - 12/06/19 02:31 AM
|
|
|
You'll want to keep an eye on this pull request as this is what I was saying I'd try to get into MAME for you.
It would split things up into three softlists (see the apple2_flop_*.xml files for details on how that works) and that should make things a little simpler for you.
Hopefully this will be acceptable to Vas et al. as I think it's a good foundation starter for your work.
|
---
Try checking the MAME manual at http://docs.mamedev.org
|
|
|
The state of C64 cassette dumps
[Re: Rygar9]
#384541 - 12/06/19 03:25 PM
|
|
|
Floppy dumps aside, I think it's also worth noting that the current Commodore cassette format is actually not faithful to the tape's contents (lacking basic things such as pause length), so right now the only properly preserved cassettes for this system are those with WAV dumps.
The same thing was happening with MSX cassettes until, just a couple of years ago, somebody started dumping those in a TZX-based format and successfully asked emulator authors to support it. So, in case that anyone wants to give it a try on figuring out a similar "proper" cassette format, know that it's not too late for that.
|
|
|
|
Re: The state of C64 cassette dumps
[Re: ICEknight]
#384542 - 12/06/19 04:24 PM
|
|
|
> Floppy dumps aside, I think it's also worth noting that the current Commodore
> cassette format is actually not faithful to the tape's contents (lacking basic things
> such as pause length), so right now the only properly preserved cassettes for this
> system are those with WAV dumps.
>
> The same thing was happening with MSX cassettes until, just a couple of years ago,
> somebody started dumping those in a TZX-based format and successfully asked emulator
> authors to support it. So, in case that anyone wants to give it a try on figuring out
> a similar "proper" cassette format, know that it's not too late for that.
Not that TZX is really much better... or at least the tools that work with it aren't, and there are so many undefined edge cases + things that don't belong in a cassette format at all making it a bit of a nightmare.
massive oversights like not having a checksum of what the raw data should decode to with a correct decoder make TZX a poor archival choice.
we've very much been left to deal with what people chose to leave tho, guess we should at least be glad to movement of trying to convert everything to snapshot memory dump files instead was quashed fairly early (although some dumps still only exist in that form)
|
|
|
|
Re: The state of C64 cassette dumps
[Re: Haze]
#384543 - 12/06/19 05:51 PM
|
|
|
> Not that TZX is really much better... or at least the tools that work with it aren't,
> and there are so many undefined edge cases + things that don't belong in a cassette
> format at all making it a bit of a nightmare.
Still, a vast improvement over the (current) C64 and (previous) MSX cassette formats which, just like snapshots, cannot be converted back to an accurate WAV representation of how the game's code was stored.
|
|
|
Index 
Threaded 
The state of C64 support
Reply
[Re: 