-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Conversation
There was a problem hiding this 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.
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. |
Almost all C64 software was released on 1541 ( 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 |
Lines 90 to 104 in dc94201
Some of the disks moved to |
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. |
We don't have a
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 |
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 |
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. |
This table is 5.25" only:
In the case of C64, the image will almost always be 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 ( |
On 06/12/2019 08:22, Vas Crabb wrote:
So is software for the different 5.25" drives incompatible? If so,
they should possibly each have their own software list.
Single sided 5.25" software was released for the 1541, some of the
clones had compatibility issues with some protection routines and fast
loaders.
The 1571 supported double sided 5.25" disks as well as being mostly 1541
compatible, but I don't know of any c64 software released on double
sided disk.
The 1581 3.5" disks was slightly more used on the c64, but they were
pretty rare back in the 1980's. Someone was selling NOS "kits" (no power
supply or disk drive) about 20 years ago & a lot of the drives out there
now are from that batch. I think the drives got used by commodore in
a500's and the power supplies used for 1541 mk2's. The remains must have
sat in a warehouse just in case.
There was also the TIB Ultimate drive which was a 3.5" drive hooked up
to the cartridge port with a standard floppy disk controller and DMA, I
think the only software for that currently is the demo disk that came
with it. However someone has reverse engineered it and has been talking
about making clones, so someone might end up writing some software for
it. I think it's the fastest c64 disk drive, but it came out in december
1991. I don't think the disk format is compatible with the 1581
http://www.zzap64.co.uk/cgi-bin/displaypage.pl?issue=079&page=054&thumbstart=0&magazine=zzap&check=1
<http://www.zzap64.co.uk/cgi-bin/displaypage.pl?issue=079&page=054&thumbstart=0&magazine=zzap&check=1>
|
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. |
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? |
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 |
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. |
…er mnaberez information. (nw)
@mnaberez is this OK with you now? |
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. |
There have been others in the past and they are annoying as empty placeholders. |
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. |
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.