Jump to content
IGNORED

Atari 8-bit Software Preservation Initiative


Farb

Recommended Posts

Allow me to add this:

 

Software lists CAN be alright and real benefit for things like OS & firmware roms, or a fixed unchanging cartridge library. But to extend it to disks? I don't get that fuzzy feeling.

 

I also believe that software lists should be in a simple text-file block format and easily edited anywhere, any time. All you really need is a standard checksum, title, and notes - like:

 

..

..

Star Raiders

ff802df55af2db674000015906d2911e

#notes can go here on this third line

#and fourth line too. as much as you need

..

..

 

Such a file can be searched instantly with even basic notepad and edited all the same. Even by a noob layperson. I've been playing with emulators since way before the Activision ActionPacks, before the first version of mame. Complex XML or overly detailed and numerours information fields serve little purpose and are the result of busywork, wanting to do more for more's sake and all that.

Link to comment
Share on other sites

The idea here is to definitively preserve and verify from original disks, known good images-- so the opportunity for generating the 'master list' of known good, known original hashes/checksums is here.

Differences in media really don't matter, IMHO. An Atari 8-bit disk image is smaller than most SNES carts and once we know that an image is 'good' from a preservation standpoint it's not going to change. (The bits that were mastered are still the same whether the distribution media was ultimately ROM, EPROM, cassette, floppy, etc.)

Link to comment
Share on other sites

@Mclaneinc

 

I was discussing with the wife and some buddies what approach to take toward our future Atari activities and why.

 

1- real hardware with modern-day upgrades and add-ons

2- quality emulation (with simulation of modern-day hardware upgrades and augmented by host PC resources)

 

We settled upon #2 because of versatility and speed. Knowing full well we might only get 98% compatibility. But the advantages far outweighed the 2% loss.

 

It is easier to experiment around with the virtual hardware than it is the real stuff. The real stuff is not always available, needs maintenance, and can be costly. And sometimes just plain tedious to set up and tear down. Not only that but we benefit from modern display and storage technologies straight away. No back-end work like programming a flash cart or disabling certain add-on features to get certain software working again. And cartridge/disk images can be changed out lickety split too.

 

Case in point for modern displays:

There is a thread that talks about modern TVs doing something "wrong" and displaying all the overscan output from a real machine. It goes on to describe a hardware mod which changes the gating of the video signal so that excess overscan is chopped off. Well, yes of course. Modern displays and classic hardware don't play well all the time.

 

Point being is that by operating entirely in the digital domain via emulation all that needs to be done is choose from 1 of 4 levels of overscan (Altirra). Problem solved.

 

Another more down to earth example is flipping through a flip-n-file or scanning a wall of cartridges to locate something. That would drive me nuts no matter how cool a wall of carts looks. With emulation and an even basic/haphazard media collection you can rapidly find what you're looking for. Just the other day I was looking for Rear Guard. Something I hadn't played in years. Took all of but a few seconds to locate.

Link to comment
Share on other sites

The idea here is to definitively preserve and verify from original disks, known good images-- so the opportunity for generating the 'master list' of known good, known original hashes/checksums is here.

 

Differences in media really don't matter, IMHO. An Atari 8-bit disk image is smaller than most SNES carts and once we know that an image is 'good' from a preservation standpoint it's not going to change. (The bits that were mastered are still the same whether the distribution media was ultimately ROM, EPROM, cassette, floppy, etc.)

 

I'm not an expert in Atari container formats, but don't .atr .xex .bin .rom .com .xfd all have different layouts and what not? Different preludes and prologs?

Edited by Keatah
Link to comment
Share on other sites

No because this part of the discussion involves what additional bits are in a freshly dumped disk image and how those bits are used.

 

No actually it doesn't. As mentioned earlier the disk preservation formats have no accommodation for the additional metadata that has been brought up.

Link to comment
Share on other sites

 

No actually it doesn't. As mentioned earlier the disk preservation formats have no accommodation for the additional metadata that has been brought up.

 

That's not exact. It is possible to put metadata in an ATX image. I considered the possibility of including metadata since the beginning. But currently there is no convention on how to label that kind of metadata.

 

Just pointing the technical fact. If it is the right way to do it, or if that debates belongs here or not, that's another story. :)

 

  • Like 2
Link to comment
Share on other sites

METADATA! That's the word I was looking for.

 

Anyways, what metadata goes into a container should probably be determined by what's going to be reading it. And here you have to have agreement between utility writers, emulator authors, and the folks creating the original image.

 

If this hasn't been done by now at this point, it's gonna be hella bitch because everything dumped to date needs to be re-done then.

 

A work around proposition would be to include a companion file of a sort. An additional text file. And that comes with it's own disadvantages. Mainly a 2nd file to keep track of. But a .zip file would help keep it all together. Just more work a of a different nature. IDK.

Edited by Keatah
Link to comment
Share on other sites

My main point here is that if this is going to be the definitive 'preservation' of these disk (and other) images and if we need to collect the "how to use them" data *anyway* (as Farb is already doing) it would seem to make sense to generate unique hashes (to identify file contents in the case of file name changes) and make the meta-data available for use in emulators (present or future).

 

Since we don't have control over any of the file container formats (other than which one(s) to use), some sort of auto-generated output from Farb's database would seem to make good sense to me. (Then if an emulation author wants to pull access for that in to their application to make it easier for novices to use, all the better.)

Link to comment
Share on other sites

 

That's not exact. It is possible to put metadata in an ATX image. I considered the possibility of including metadata since the beginning. But currently there is no convention on how to label that kind of metadata.

 

Just pointing the technical fact. If it is the right way to do it, or if that debates belongs here or not, that's another story. :)

 

 

Ijor, I agree its possible to add data to a disk, it was a system I offered to a a friends software distribution company as he was worried about returns just being items pirated and the like and I offered to make a list of stuff he sold Atariiwise and to locate a clean sector and use it for details (yes, data protection would cut me a new backside these days) and keep a list and check if copies were doing the rounds. Obviously I could not tell if the disk had been copied by a Happy but it was something offered.

 

The side effect is accidental destruction unless people are willing to clone their collections, its also means that a person with some skill needs to do the metadata creation, know what is actually free space etc and as said, the problem then falls on the shoulders of the emulator author to implement that system which I feel would put most authors off actually doing it due to complexity, time and simply the drive to do all that.

 

We know its technically possible, there's no denying that, its all the extra around it that is the real problem.

Link to comment
Share on other sites

@Keatah.

 

Re your choice of hard vs emualtion, I agree with you..

 

I have some real hardware and its pulled out as and when I can to test issues with images so I can make a more informed bug report for the emulator author but its becoming harder to do that because of my pain level, moving boxes here there and everywhere is beyond hell for me and because of my grip I've dropped my beloved Atari 800 and cracked the case by the space key, I'm terrified it won't work. But that in itself proves the case for emulation, as Phaeron once said in a post "thankfully I don't emulate the smoke and burning of when things go wrong". In truth I use a small amount of what is available in Altirra but I can see by forum posts that what is emulated is either 99-100% or well on the way with possible exceptions. I'd suspect that is more than enough for most and the only folks it may affect would be the staunch hardware only folks who I perfectly understand their reasons, hell, that's why I like my 800, you can't emulate that feel BUT you can emulate its workings which is exactly what emulation is there to offer.

 

Like yourself I can locate pretty much anything in my collection in seconds and its up and running, try that with real boxes and storage :)

 

Where I love emulation is the ability to use the same machine I surf, print play PC stuff on etc is to also boot up a game from my time in the start of the Atari, arcade and the like and play it pretty much perfectly with a better screen and have taken up zero extra space and almost no setting up.

 

Mame. Altirra, WinUAE and other various emulators, I love you...If I win the lottery then I'll treat myself to some of the real hardware but in truth apart from wishing to support our wonderful people who make stunningly wonderful boards and software I in truth actually don't need the hardware but as I said I'd do it to give something back...

 

Lets hope I win the lottery :)

Link to comment
Share on other sites

Ijor, I agree its possible to add data to a disk ... locate a clean sector and use it for details

...

The side effect is accidental destruction unless people are willing to clone their collections

 

We are talking about adding metadata to a file image, not to a physical disk. Or I misunderstanding what you mean?

Link to comment
Share on other sites

 

Technically speaking, I don't see it as being any worse that something like the various 'cheat' database systems (for MAME and the like). It's a solve-able technical problem and generating the data is pretty easily crowd-sourced (just like these disk images are).

 

Having said that... Not my emulator! Easy to make suggestions when you don't have to do the work! ;-)

 

Yes to the last bit...Most important..

 

As for the cheat analogy, I think you very over simplify it, the process requires incredible man hours and depending on how its done makes it (for me) over complicated. Databases have always been one of the most ignored parts of collections, people simply get tired of doing it, look at TOSEC, its got HUGE flaws and glaring inaccuracies but its update over time has slowed to a crawl. Ok there's probably as many images out there as there will be bar rare finds and people scanning their collections but there in also adds issue's, is it only going to be originals or all images, what about multiboots with several games or even more, how will that work. If originals which ones do you DB / metadata.

 

I'm NOT NOT NOT attacking the idea, I'm all for ease of use but so much of this rests very heavily on the emulator writers shoulders and as seen with the Higan project, it gets complex real quick and puts people off stuff.

 

I just think after all this time it could have already happened but it didn't and there's a reason for that...People simply did not want to do the work just to load a game.

 

Any way, creative thinking is always appreciated and who knows what will happen with the idea, its merely my 2p worth..

Edited by Mclaneinc
Link to comment
Share on other sites

@remowilliams: Great work, thanks :thumbsup:

 

Results of dump comparisons for the above dumps by remowilliams for Farb's database:

 

The following are identical to the Atarimania dumps I submitted some time ago. The ATXs differ, so keep either of them:

Bible Baseball

Elektraglide.Atari Smash Hits Volume 6.Disk 1 Side 1

Timeslip.Atari Smash Hits Volume 6.Disk 1 Side 2

Tink! Tonk! - Tinka's Mazes.Side 1

Tink! Tonk! - Tinka's Mazes.Side 2

Tink! Tonk! - Tuk Goes to Town

 

This dump is the same version as the Frankendisk I submitted (so kill my submission which is probably named as APX version):

MECC Instructional Computing Demo

@remowilliams: Is this a disk with an original MECC-label?

 

I suspect this to be a gone-bad disk:

Joe and the Nuclear Caverns

It has five bad sectors scattered over the disk and none is accessed while loading the game. Two of these are inside an unsed DUP.SYS file.

@remowilliams: Can you dump it a second time please?

 

 

 

Link to comment
Share on other sites

MECC Instructional Computing Demo

@remowilliams: Is this a disk with an original MECC-label?

 

I suspect this to be a gone-bad disk:

Joe and the Nuclear Caverns

It has five bad sectors scattered over the disk and none is accessed while loading the game. Two of these are inside an unsed DUP.SYS file.

@remowilliams: Can you dump it a second time please?

 

 

It is an Atari Learning Systems branded disk - Instructional Computing Demo (AED80047)

 

I can try dumping it again but I think the errors were rather persistent.

Link to comment
Share on other sites

MECC Instructional Computing Demo

...

It is an Atari Learning Systems branded disk - Instructional Computing Demo (AED80047)

I can try dumping it again but I think the errors were rather persistent.

 

Did you provide the raw dump? Sometimes it is possible to recover errors with a flux dump.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...