Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split C64 disk softlist similarly to Apple II. #6018

Merged
merged 2 commits into from
Dec 9, 2019
Merged

Split C64 disk softlist similarly to Apple II. #6018

merged 2 commits into from
Dec 9, 2019

Conversation

Firehawke
Copy link
Contributor

This PR serves to make a case to split the C64 disk softlist the same way we currently have the Apple II softlists: into clean cracks, originals, and misc (homebrew and defaced cracks).

My rationale for this change is that if we continue to dig into the C64 library, we most certainly will run into all three types for the same software. Being able to clearly denote which is which and use the same .zip filenames where appropriate will serve to make the documentation easier to read for developers and users both.

While I have committed a sin by having two empty softlists for the moment, there has been some interest from a MW poster to work on these lists and if I can grease the wheels a bit by doing the initial prepwork for them, I'm absolutely in favor of doing just that.

Copy link
Member

@cuavas cuavas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you’re going to have the physical size of the disks in the software list descriptions, please include the unit (i.e. 5.25" – you should be able to escape it as "). But is the physical size of the disks important? Were other physical disk sizes common on C64? Would we separate them, or just use use interface attributes to make them select a suitable drive? Would we separate by DOS type as we do on Spectrum (if there are different DOS types for C64)?

The questions are genuine – I’m not a C64 expert, and I only ever saw 5.25" software for Commodore DOS.

@Firehawke
Copy link
Contributor Author

Firehawke commented Dec 6, 2019

It was a pedantic thing that I'd included from the Apple side of things. You're right that I could add the " to the Apple softlists and will do so in my next update therein (in fact, it's in my work branch right now ready to be passed in with the next batch of Apple II stuff)

https://en.wikipedia.org/wiki/Commodore_1581 says the 3.5" drive was only out for about three years so it's possible we may hit some software for that form factor-- I'm not sure if we actually have any right now, though.

Your choice-- I can either remove the form factor entirely or we can add the " and later add the 3.5" disks as those pop up.

@mnaberez
Copy link
Member

mnaberez commented Dec 6, 2019

Almost all C64 software was released on 1541 (.d64 extension). There were some others but not common, e.g. the LOADSTAR disk magazine had a 1581 disk version.

C64/128 use the IEC bus which can connect the 1541, 1571, 1581, and more. PET/CBM use the IEEE-488 bus and can connect 2031, 2040, 4040, 8050, 8250, SFD-1001, and more. A lot of combinations are possible and we emulate most of them.

We currently use just a flop_ prefix in the Commodore softlists. All the Commodore floppy drives are 5.25" except for a couple 8" drives (8280, 8061) and the 3.5" (1581). The physical size doesn't help much because if you have a 5.25" disk, it could be 1541, 1571, 8050, or 8250. The image file extensions (e.g. d64, d71, d80, d82) are used throughout the Commodore community to identify the disk format.

@mnaberez
Copy link
Member

mnaberez commented Dec 6, 2019

<software name="bbsb">
<description>Bounty Bob Strikes Back! (v1.2)</description>
<year>1985</year>
<publisher>Big Five</publisher>
<info name="protection" value="halftrack" />
<sharedfeat name="compatibility" value="NTSC,PAL"/>
<part name="flop1" interface="floppy_5_25">
<!-- will not load if disk is not write protected -->
<feature name="read_only" value="true"/>
<dataarea name="flop" size="208212">
<rom name="bbsb.g64" size="208212" crc="69456d8c" sha1="26801eda258f748aa6f6c45df8af7f7cbb2857d4"/>
</dataarea>
</part>
</software>

Some of the disks moved to c64_flop_misc.xml appear to be originals. For example, this one is a GCR dump (.g64) that has the copy protection intact and the softlist describes the protection.

@Firehawke
Copy link
Contributor Author

Yeah, as I noted this was primarily a CODE change to support the migration to the new softlists for someone who wants to do substantial work on the C64 softlists-- no disks were moved out of the misc package as a result.

@mnaberez
Copy link
Member

mnaberez commented Dec 6, 2019

no disks were moved out of the misc package as a result.

We don't have a misc softlist. It was created in this pull request:

  • renames: hash/c64_flop.xmlhash/c64_flop_misc.xml
  • creates: hash/c64_flop_orig.xml

I support more work on the softlists and I am in favor of clearly denoting the originals somehow, but it's a little weird to create a new orig softlist for originals and have existing originals in misc.

@cuavas
Copy link
Member

cuavas commented Dec 6, 2019

So is software for the different 5.25" drives incompatible? If so, they should possibly each have their own software list.

The Apple II software lists shouldn't have the disk size in the software list names – the 5.25" and 3.5" software should be in the same software lists using the interface to select the right drive.

@ghost
Copy link

ghost commented Dec 6, 2019

The Apple II software lists shouldn't have the disk size in the software list names – the 5.25" and 3.5" software should be in the same software lists using the interface to select the right drive.

I have to disagree here. Entirely different media should be in a different list.

Beyond that, you have further splits into additional lists to help with organization where applicable, not throwing it all in one list.

@mnaberez
Copy link
Member

mnaberez commented Dec 6, 2019

So is software for the different 5.25" drives incompatible?

This table is 5.25" only:

Sector Image Drives that can read it
.d64 2031, 2040, 4040, 1541, 1571, 1551
.d71 1571 only
.d80 8050, 8250, SFD-1001
.d82 8250, SFD-1001

In the case of C64, the image will almost always be .d64 (or the GCR image .g64). Drive-based copy protection was common. Protected software targets the 1541 but it usually runs on the 1571 also (the C128's drive, which can be connected to a C64 too). Other drives will not work. Non-protected C64 software can run on any drive that reads the disk.

In PET/CBM, drive-based copy protection was uncommon. Identical software was often distributed on 4040 and 8050 format disks. PET software will usually run on any drive that can read the disk.

Currently, we have a softlist for each Commodore computer. The softlists contain software that runs on that particular computer but has a mix of disk types. In the PET softlist, you'll see several image formats (.d64, d80, d82). That software will usually run as long as the drive can read the disk. A variety of configurations are possible under MAME. For example, software for an 8032 in .d80 could run on pet8032 with either c8050 or c8250 as the drive. Software for a 4032 in .d64 could run on pet4032 with c2031, c2040, or c4040 as the drive.

@smf-
Copy link
Member

smf- commented Dec 6, 2019 via email

@Firehawke
Copy link
Contributor Author

Thanks, smf and mnaberez, you saved me having to look up and format that.

Look, I'm open to whatever you decide to do but I figured that what I had was at least a step in the right direction. Make an executive decision on how you want these formatted, and I'll make adjustments as needed, but based on everything I've read...

...I feel like we should definitely keep 3.5" on its own SL, though it's going to be rare to run into any. My reasoning is that the form factor here does matter enough to keep its own list.

5.25" disks are debatable on whether they should be split by drive or not. I'd lean towards 'no' because of a combination of the lack of disks for most of the formats and the relative compatibility across them.

@cuavas
Copy link
Member

cuavas commented Dec 7, 2019

We already keep 3.5" and 5.25" disks for IBM 5170 in a single list and filter on interface. It makes sense when it's logically compatible and you have releases with both types of media included. Apple II software lists should follow that example.

I guess the C64 software list can be done with clever use of compatibility filters?

@mnaberez
Copy link
Member

mnaberez commented Dec 7, 2019

I am in favor of splitting the C64 softlist to clearly indicate which disks are known originals because there is preservation value in that.

I'd prefer not to further separate the Commodore softlists by disk type. It doesn't seem to cause issues now. I would not want to see pet_flop.xml fragmented into 4 softlists unless there was a compelling reason.

@Firehawke
Copy link
Contributor Author

Okay, then I motion we go with a three-way split for C64-- originals, cleanly cracked, and everything else, while removing the 5.25" description from the file.

It makes a lot of sense on Apple II to split them because there's multiple formats of 3.5" disks (UniDisk VS SuperDrive) and compatibility at the controller level matters for some software that pulls C64-style "run code on the drive" stunts.

@cuavas
Copy link
Member

cuavas commented Dec 8, 2019

@mnaberez is this OK with you now?

@mnaberez
Copy link
Member

mnaberez commented Dec 8, 2019

Yes, I think this is fine and I'm happy to see others working on the Commodore softlists. Thanks @Firehawke and contributors.

This PR introduces an empty softlist file. This is fine with me but I haven't seen this before in MAME so I am a little hesitant to merge the PR myself. This is probably not a big deal and @Firehawke states above they will be working on filling it in. Please feel free to merge this PR. I'll merge it in a day or two if it's still open and there are no objections to the empty softlist.

@Tafoid
Copy link
Contributor

Tafoid commented Dec 8, 2019

There have been others in the past and they are annoying as empty placeholders.
My desire is to see at least ONE valid set for each softlist created. Can that be done?

@Firehawke
Copy link
Contributor Author

Look, I don't know what's in the C64 softlist. If you can find even a single "cleanly cracked" entry in the existing set OR downloaded somewhere, that can be migrated in.

Cleanly cracked means no protection and ALSO no defacement or cut material. Only the protection removed.

@cuavas cuavas merged commit 3cf5653 into mamedev:master Dec 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants