Atari 8-bit Software Preservation Initiative

[Keatah]

Love the work being done here.

 

I had fought against plenty of disks with shedding oxide on the Apple II. I found that grabbing the information in one or two rotations is effective, before the oxide sheds. It can be done with the Disk II drive, don't know about the stuff and kryoflux you guys are working with.

 

Another time I bathed a few "beyond delicate" disks, with visible cracks when flexed, in silicon spray. Non petrol based. And it worked.

 

I still have a few rarities that I'd like to try vapor depositing a new coating. And other disks had fold creases in them, but yet were durable enough to be unfolded and flattened in a book under a car tire. Go figure..

[tschak909]

I'm telling you, that it may very well be the substrate taking on ambient moisture. Anybody with a Fisher Scientific oven should be able to do it (or something similar)

 

-Thom

[Mclaneinc]

Yes mine works, same cas from the project, turn off any fast patches, set to XL any mem and most importantly the video MUST be set to NTSC, at the 8:50 mark you get the burping sio noise and then it starts the game, you wait a sec and you get the press start for game and I played a short match after the national anthem..

 

The only thing I do differently is that I don't want to sit and wait 8:50 so I use the F1 key to speed up the emulated time..

 

And just in case, I test stuff as it would be on a vanilla machine, no extra boards or add ons..

Edited November 20, 2016 by Mclaneinc

[Shannon]

The only thing I do differently is that I don't want to sit and wait 8:50 so I use the F1 key to speed up the emulated time..

 

 

You're not kidding... no one wants to wait for a long cassette load. It woulda helped if you mentioned what you did earlier since most people have fast cassette IO turned on. I confirmed what Mclaneinc said.

 

Another one for you all..

 

Super Boulder Dash (1986)(Electronic Arts)(US)

 

Atarimania says it includes Boulder Dash I and Boulder Dash II. The disk only appears to load Boulder Dash I. I'm guessing we are missing a 2nd disk with Boulder Dash II? Hard to verify based on the data available at atarimania.

[+remowilliams]

Atarimania says it includes Boulder Dash I and Boulder Dash II. The disk only appears to load Boulder Dash I. I'm guessing we are missing a 2nd disk with Boulder Dash II? Hard to verify based on the data available at atarimania.

 

Looks like I didn't dump this title earlier but I do have it and it's a double sided disk, so here's side 2 Super BoulderDash.Side 2.ATX.rar

[+kheller2]

 

 

To clarify: That's published by Alpha Systems; not an alpha version of the software.

 

IMG_5563.JPG

 

Wow. That's a bit impressive. How about Techniques 2? Pretty sure I have the master laying around.. I just can't remember if both came with a disk or only one.

Edited November 20, 2016 by kheller2

[Mclaneinc]

 

You're not kidding... no one wants to wait for a long cassette load. It woulda helped if you mentioned what you did earlier since most people have fast cassette IO turned on. I confirmed what Mclaneinc said.

 

 

First rule of thumb when testing software, always test it as close to the source RETAIL machine

 

I don't know what Avery would say is the percentage of reports that fail not through emulation fail but because its on a souped up model, I'd say at least 50%

 

I've been throwing software at Atari800win, Atari800winplus and altirra for too many years to remember checking for bugs, you get in to the habit real early of having a set of profiles that match out of the box Atari's so people like Avery etc don't bite me for not testing it correctly

 

Glad its going now, be aware that I've had very rare cases where speeding the emulated time up caused fails but in general it works flawlessly.

 

10 - 15 min tape loads are too painful to sit through...

Edited November 20, 2016 by Mclaneinc

[Shannon]

 

Looks like I didn't dump this title earlier but I do have it and it's a double sided disk, so here's side 2 Super BoulderDash.Side 2.ATX.rar

 

Thanks remowilliams... it works just great!

 

It's really weird seing the ECA logo on Boulder Dash..

[Clay Cowgill]

(Seems like these emulators could benefit from a little XML 'settings' file that goes along with each media image to automagically flip all the right emu setup bits... I assume there's no provision for carrying that sort of info internally in the old .at_ formats?)

[Shannon]

(Seems like these emulators could benefit from a little XML 'settings' file that goes along with each media image to automagically flip all the right emu setup bits... I assume there's no provision for carrying that sort of info internally in the old .at_ formats?)

 

Phaeron partially added some options in regard to this in the latest build of altirra. Although it needs some work and tweaking. In the meantime he has been adding support for a bunch of chipped drives like the happy, us doubler and indus GT.

[Mclaneinc]

I thought he meant for each atr etc?

 

That would be an incredible amount of work...

 

If its just the types of disks it could be done but my ideology if I was an emulator author would be the same as the real world, I'd make the sure the host machine emulation was right and that any emulated devices added on bar interfacing them would be down to the user to configure, just as I said, in the real world.

 

Maybe I'm reading Clays post wrongly?

Edited November 21, 2016 by Mclaneinc

[Shannon]

Tail of Beta Lyrae, The (1983)(Datamost)(US)

 

The image that is part of this archive 486b026e seems to have issues. I don't know if it is protection or not. But if you play the game for a little while 1 of two things will happen.

 

The screen colors will change such that you cannot see what is going on.

The controls go all wacky and you can't control the ship.

 

The atx image from atarimania (I think) works just fine and has no issues. CRC 161464ef

[Mclaneinc]

That game has all sorts of issues, some meant, some not, I remember the author talking about it on here, I have no idea if there is a 100% known working one, I do hope so, I also seem to remember a thing where writing to the disk from within itself actually altered the way the game played.

 

May have even had more widespread complications..

 

Shame as its a cracking shooter...I do hope there is a fully working one about...

 

I'll try the one from Atarimania, I imagine I already have it but just to be sure...The colours going wrong sounds like attract has kicked in and not been adjusted to not to..

 

Just checked, seems ok, ....The Databyte tape one must be set to 64K to load (and all the usual things turned off...)

Edited November 21, 2016 by Mclaneinc

[Farb]

(Seems like these emulators could benefit from a little XML 'settings' file that goes along with each media image to automagically flip all the right emu setup bits... I assume there's no provision for carrying that sort of info internally in the old .at_ formats?)

 

 

No, there is no provision for it in the current ATR and ATX formats.

 

I do have all that information for every dump in the preservation database so it wouldn't be difficult to write a script to generate metadata that can be consumed by an emulator. We would just need to agree on what the format looks like.

[Farb]

Tail of Beta Lyrae, The (1983)(Datamost)(US)

 

The image that is part of this archive 486b026e seems to have issues. I don't know if it is protection or not. But if you play the game for a little while 1 of two things will happen.

 

The screen colors will change such that you cannot see what is going on.

The controls go all wacky and you can't control the ship.

 

The atx image from atarimania (I think) works just fine and has no issues. CRC 161464ef

 

Thanks for pointing it out. That ATX file has not been verified so we'll have to look at how it's different from the Atarimania one.

[Keatah]

There shouldn't have to be fussing over setting bits and stuff. In a properly written emulator, all you should need to do is select the machine type and go. It should resemble retail hardware as close as possible.

[Clay Cowgill]

I thought he meant for each atr etc?

 

That would be an incredible amount of work...

 

For 'user convenience' carrying the 'magic settings' around in the .atr (or whatever) would be the cleanest, but I could also see having a database file that just lives with the emulator. Use the MD5 (or whatever) signature for any particular media image as the hash value in to the 'database' (could just be XML) and then each entry would have the necessary settings for the title. (So the emulator would 'load' the image, calculate the hash based on the image, look in the database for a match and if found-- load up the proper settings.)

 

Watching this thread where most of us presumably "know some stuff" about the system and we still have issues getting things to run makes me suspect that a lot of users just get "it didn't work" and have no clue what to do about it...

[Farb]

There shouldn't have to be fussing over setting bits and stuff. In a properly written emulator, all you should need to do is select the machine type and go. It should resemble retail hardware as close as possible.

 

Altirra in particular does resemble retail hardware quite closely. The problems that we're describing pertain to both emulated and physical hardware. For example:

• Some titles only work with 64K of memory or higher so they won't work on stock Atari 400 or 800.
• Some titles require BASIC and some of those even require BASIC Rev. A and don't work on B or C.
• Some titles that run on Atari 400 or 800 require OS Rev. B and don't work with other OS versions.
• Some titles only work in NTSC and break with PAL (and vice-versa).

So knowing the details of each title is useful for both real hardware and emulators. Obviously with emulation, we can go a step further and make sure the correct hardware, memory, OS version and presence of BASIC is automatically selected based on the title being loaded.

[ijor]

 

Altirra in particular does resemble retail hardware quite closely. The problems that we're describing pertain to both emulated and physical hardware. For example:

 

And for copy protections reasons, it can be even worse ...

 

Some titles (or at least, some versions of some titles), run only on certain drives (say, 810 only).

Some titles run on 64K, but not on 128K.

 

Of course, these are extreme cases.

[+remowilliams]

Continuing to go through some 'sort of lost, but found again' disk boxes. I'll add things if I don't see them listed already.

 

Like this Bible Baseball.ATX.rar (OSB, Basic)

[Mclaneinc]

We have been down the hashing software etc lane before and at the end its an incredible amount of work that would need to be verified, the point here is that Altirra offers a clean incredibly compatible interface that relies just like in the old days that the user looked at the box, followed the instructions and bingo. With the wealth of images out there that are of unreliable sources and cracks that may not be full it means that sort of idea just fades away because of the pain it would be.

 

This has been tried on the Emulator Higan for the Snes where the author created manifest files and dumps in a folder system that most found confusing leaving some people to reinvent the emulator without the system. Don't get me wrong, the idea you have is nice and the not so in the know users would benefit from the auto configuring of the emulator but its simply not practical and it would be a huge task to implement and police.

 

Sometimes the old way is best and easiest all around..

 

As I keep saying, setup the emulator as the closet to the retail machine and make profiles for them, you can always have a profile for the machine of your dreams but expect stuff to not be happy

[Clay Cowgill]

[...]

Sometimes the old way is best and easiest all around..

 

As I keep saying, setup the emulator as the closet to the retail machine and make profiles for them, you can always have a profile for the machine of your dreams but expect stuff to not be happy

 

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).

 

The problem is one of "who do you want to be your audience". We OG Atari 8-bit people are getting in to our late 40's and above, so statistically we're already far below 50% of internet users and will only get smaller over time. If we want to have this stuff be 'accessible' and not just 'preserved' for the larger audience that's online, the best way to do that is make it 'just work' automagically.

(Case in point-- archive.org's MAME/MESS based online Apple ][ collection. Click on the game and you can play it in-browser with no fussing with how to setup the peculiarities of a computer that may have been sold before you were born and that you've only ever seen pictures of online...)

 

https://archive.org/details/Frogger4amCrack

 

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

[Shannon]

Watching this thread where most of us presumably "know some stuff" about the system and we still have issues getting things to run makes me suspect that a lot of users just get "it didn't work" and have no clue what to do about it...

 

Farb's response covered most of what I would have saiid. But me bringing up issues with any particular image is to determine whether the actual image itself is a correctly dumped image. This is actually an 8-bit software preservation thread.

 

In some cases something goes wrong in the process and the disk or tape needs to be re-imaged. In other cases I just overlooked a setting in the emulator.

 

Sure I could just stick to a plain vanilla emulator setting. But even that won't always work (read Farb's response). Also I'm not interested in waiting 20 plus minutes for a tape image to load because I have high speed cassette I/O turned off.

[+DjayBee]

 

For 'user convenience' carrying the 'magic settings' around in the .atr (or whatever) would be the cleanest, but I could also see having a database file that just lives with the emulator. Use the MD5 (or whatever) signature for any particular media image as the hash value in to the 'database' (could just be XML) and then each entry would have the necessary settings for the title. (So the emulator would 'load' the image, calculate the hash based on the image, look in the database for a match and if found-- load up the proper settings.)

 

Look there for phaeron's thoughts about this: http://atariage.com/forums/topic/256683-altirra-280-released/?p=3587479

[Keatah]

We have been down the hashing software etc lane before and at the end its an incredible amount of work that would need to be verified, the point here is that Altirra offers a clean incredibly compatible interface that relies just like in the old days that the user looked at the box, followed the instructions and bingo. With the wealth of images out there that are of unreliable sources and cracks that may not be full it means that sort of idea just fades away because of the pain it would be.

 

This has been tried on the Emulator Higan for the Snes where the author created manifest files and dumps in a folder system that most found confusing leaving some people to reinvent the emulator without the system. Don't get me wrong, the idea you have is nice and the not so in the know users would benefit from the auto configuring of the emulator but its simply not practical and it would be a huge task to implement and police.

 

Sometimes the old way is best and easiest all around..

 

As I keep saying, setup the emulator as the closet to the retail machine and make profiles for them, you can always have a profile for the machine of your dreams but expect stuff to not be happy

 

All that and the boldface type especially. I've been working this way for a long long time. And it's the best. I truly hate software lists because names or checksums don't always match, especially on disks that write back a config file or record progress or hi-scores. And keeping lists updated and policed never really happens. It turns out to be a lot of wasted busywork. Furthermore, lists don't always have that one special title you're looking to run so you have to set it up manually anyway.

 

I keep a folder with some 8 or 10 common retail machine configurations that seems to cover a lot of stuff. And the stuff it doesn't cover is going to make you fuss with exotic options - much like you would have had to do in real life back in the day.

 

I also do the same thing with the Amiga.

Edited November 21, 2016 by Keatah