Jump to content

Farb

Members
  • Posts

    859
  • Joined

  • Last visited

3 Followers

Profile Information

  • Gender
    Male
  • Location
    Munich, Germany

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Farb's Achievements

Dragonstomper

Dragonstomper (6/9)

640

Reputation

  1. Thanks for the offer to the community. If they are truly rare and undumped, please don't use them in an Atari 1050. There are folks here that have Kryoflux, SuperCard Pro and/or Greaseweazle (and experience using them) which are much safer options. But you've probably already seen this mentioned many times in this thread 😁 Perhaps @Bill Lange or @Pheonix could assist? If I'm not mistaken, they are not terribly far from you.
  2. I'm not sure, I've not used ROMVault. I tested with ClrMamePro which didn't appear to have any problems with custom tags in a DAT file. I did a quick check and I wasn't able to find anything that indicated custom tags were disallowed in a DAT.
  3. I'm not sure who "you" refers to in this context? It is probably helpful to differentiate between people posting their flux dumps to this (or other) forum topics and the people doing the actual preservation work for the project. As I see it, the former are providing contributions to the latter. One should never assume that any one dump is 100% good without further information 🙂 My frustration with this was the very reason I started working on this project. It is extremely difficult to fully put every title "through its paces" as it requires both a lot of time and detailed knowledge of how the title should perform. You can imagine the time investment needed to fully test an Alternate Reality or Ultima IV release for example. And if you do encounter bugs or problems -- were they there originally or was it the result of a bad dump? Or maybe even emulator settings? Even on real hardware, OS revision, memory, video standard, BASIC revision, etc. can all affect how a program behaves. Any official ATX files that the preservation project releases will have a [!] in its filename if it's considered "verified". This means we have at least two examples (often more) of independently dumped media with completely identical data, media structure, media anomalies (e.g. protection), etc. These are often created on different disk drives and using different hardware (e.g. Kryoflux, SuperCard Pro, Greaseweazle, etc.) You can see full provenance for every dump we release on our website. Also note that ATX files preserve much more of the original disk information than an ATR does so it is our preferred distribution format for disks. At the end of the day, however, we are making a pretty fundamental assumption -- if multiple dumps of a title are identical in every practical way, then they are "good" regardless of how they behave. We've processed several thousand dumps and have seen no evidence that this is a bad approach. Using this process, for example, we have found releases of software that clearly had mastering errors in an early release that were fixed in a later one -- or later releases of titles that subtly altered the type of copy protection employed. Anyway, I hope this helps in understanding what we are doing and how we are trying to tackle the concerns you've expressed.
  4. Thanks for your detailed analysis, @NewRisingSun. I know this is a full retail release because it was a disk my father bought from a local computer store in 1982. I'm not sure what problem you are seeing, but I just tested and if you hit a trapped apple repeatedly over the head with your shovel, it will fall through the hole and disappear. You need to let the shovel bashing happen "automatically" via a single button press. MACE Newsletter v2n4 (April 1982) mentions that the version they tested occasionally doesn't play sound when digging. I saw this same phenomenon with our e76f1e59 ATX so that supports your theory that it is likely the first release. Based on your analysis, I have swapped [a] and [a2] in our database and noted how they differ [a keyboard crash bug] and [a2 no bad sector check].
  5. Thanks for the contribution! As a general rule, when having problems loading one of the dumps we publish, you can first check the page on our website for that dump. In this case: http://www.a8preservation.com/#/software/dump/345 Thanks for pointing this out. I have corrected BASIC -> machine language in the database (which automatically updates the loading instructions).
  6. We don't track changes in the preservation database currently so it would take effort to do so. As you said, since the Atari files are pretty small, Internet connections are so fast these days and our release cadence is low, it doesn't really seem like a problem worth solving at the moment vs. us focusing on other priorities. Besides, the stream of new contributions has slowed down considerably, so I don't expect our current release cadence to continue once our pending backlog is processed which will likely happen over the next release or two. The DAT files that are included in every release could be diff'ed and a list of changed files created. So it should be possible for an entreprenurial community member to create update packs if they really wanted to.
  7. May I kindly ask you to move this conversation to its own thread? I don't want there to be any confusion that this is associated with the preservation project. Thanks!
  8. Thanks to everyone mirroring the latest release!
  9. No worries at all. Thanks to everyone for their distribution efforts!
  10. Every release is a complete replacement for prior ones. Things get added, modified and removed as we learn new things.
  11. We aren't tracking individual changes at the DB level. Easiest thing is to do a text diff between the new DAT file and the previous one to see what has changed.
×
×
  • Create New...