Do we need a new standard for disk/cart images?

[phaeron]

Simple things like "requires OS/A" or "needs at least 64k RAM" are easy, but after you go beyond that things get _very_ tricky.

 

Requires/doesn't require BASIC is a very common one that is difficult to tell for newbies... mainly because some games require BASIC for completely nonsensical reasons, and because of Atari's annoying decision to require you to press Option to disable it instead of the other way around. A couple of Microprose games require it solely to display the splash screen during disk loading. Add to that modified OS ROMs that have the Hold Option behavior reversed, and it gets even more confusing. I remember struggling with this stuff even 20 years ago on the real hardware when I sometimes had to think whether a particular game required the Translator disk or not, whether it needed BASIC, etc.

 

Even the apparently simple cases get tricky when you throw in different emulators or emulator versions, though. SIO patch enabled/disabled is one such option -- Altirra can boot some disks in SIO patch enabled mode that Atari800WinPLus can't, because it has additional checks for unusual behavior. Conversely, there's at least one demo game that can only be booted in Atari800WinPLus with SIO patch enabled, because it calls into SIO after copying it to RAM and trashing part of it, and relies on A8WP's hook mechanism details to still work.

 

That having been said, it isn't necessary to cover all possible cases with a configuration mechanism. Just being able to cover the common options would go a long way toward usability.

 

You guys ever hear of something called file streams? That's what I use. I write metadata into a separate stream. Software that calls the filename directly calls the default stream by default (Disk Data). I read the metadata from the second stream as needed to provide runtime configuration information.

Do you mean streams as in alternate data streams (ADS) on NTFS? They're problematic for a few reasons: they can't be placed on removable drives that use FAT32 or exFAT, they don't go well in compressed archives, they're not very visible to the user, and my personal favorite reason, the .NET Framework actively blocks access to them by rejecting them during path validation.

 

I think changing any longstanding file format because some people can't figure out how to use an application is ridiculous. Either make the application simpler / more user friendly, or write a simple tutorial of how to set it up, use it, and what settings to try changing when something isn't working. If Avery was so inclined, I suppose he could make a simple mode for Altirra or something. But I certainly wouldn't expect him to do something like that -- He's already over-extended himself in helping the community in my opinion. With complex/capable programs comes a learning curve, as FJC said, whether or not you're an IT person, a programmer, or rocket scientist. Sure, an emulator for an Atari 8-Bit (and I include them all) can often be more difficult than the simple machines that they emulate. But that's because they do much more than any single machine does.

 

Can't deny that Altirra could always be made easier to use, but trying to make things simple/easy is one of the hardest tasks in programming -- it requires a lot of insight into how your UI is being used and the problems that users are running into, and creative solutions to the hairy problem that users don't read help text. It's not an area of program design to be underestimated effort-wise.

 

I'm afraid there is another reason that emulators aren't as play-and-go as they should, which is the need to avoid legal issues -- including making sure it isn't too ostensibly geared to playing mass-pirated game software, and not including copyrighted software that would otherwise be handy. The most glaring specific problem is the inability to bundle the XL/XE OS, thus requiring users to go out and get it, and then hook it up to the emulator. At this point, I've done the most I can by including versions of all four main ROMs that have been rewritten from scratch (OS-B, XL/XE OS, BASIC, 5200 OS). However, even this is foiled by the annoying tendency of people to still write new software that fails on anything other than the ver.2 XL/XE OS.

[+MrFish]

Can't deny that Altirra could always be made easier to use, but trying to make things simple/easy is one of the hardest tasks in programming -- it requires a lot of insight into how your UI is being used and the problems that users are running into, and creative solutions to the hairy problem that users don't read help text. It's not an area of program design to be underestimated effort-wise.

 

I'm afraid there is another reason that emulators aren't as play-and-go as they should, which is the need to avoid legal issues -- including making sure it isn't too ostensibly geared to playing mass-pirated game software, and not including copyrighted software that would otherwise be handy. The most glaring specific problem is the inability to bundle the XL/XE OS, thus requiring users to go out and get it, and then hook it up to the emulator. At this point, I've done the most I can by including versions of all four main ROMs that have been rewritten from scratch (OS-B, XL/XE OS, BASIC, 5200 OS). However, even this is foiled by the annoying tendency of people to still write new software that fails on anything other than the ver.2 XL/XE OS.

 

Don't get me wrong. My point is that monkeying with a well established file-format is not the solution to user's difficulties with a program that has some necessary complexities. I would suggest the tutorial path be followed above anything, and in no way am I suggesting that you should have any part in that. Altirra is well documented, but unfortunately it seems that most people would rather get pissed at a program than read documentation. If somebody is inclined to help people who may not have much of a clue about Ataris, emulators, or both, then the missing information needs to be added to the user's, not ATR files. The suggestion about emulators was just in general -- although I talked about Altirra because it's the most popular -- and I'm just stating that it's another alternative, and preferable hypothetically to changing ATR's.

Edited March 27, 2014 by MrFish

[+JAC!]

Note for BASIC/Option victims: I offer patching your favorite program :-)

[Irgendwer]

Since you mention ID3 tags, keep in mind what problems they caused back then to software and hardware that was not aware of them - they played noise for a fraction of a second or even crashed. I had a hardware MP3 decoder chip (Micronas 3507 or something like that, can't remember) that not really liked them.

 

So what does that imply? You would like an untagged MP3 format more, just because some players have problems with the tags or interpret them wrong? Really?

 

 

I absolutely don't like the idea to add such a thing to an ATR, we already have enough problems detecting all of the broken ATRs and trying to handle them...

 

It should not be the solution to ADD information to an ATR but to define a new format. This should enable you to detect data integrity and help identifying the 'geometry'. So you actually argue for a better format.

 

 

I think changing any longstanding file format because some people can't figure out how to use an application is ridiculous.

 

My point is that monkeying with a well established file-format is not the solution to user's difficulties with a program that has some necessary complexities.

 

I fully disagree and find your position quite arrogant. You blame easy access to technology and introduce the "I'm not worthy!"-scheme. If someone just likes to try out some of 'these old games' for outdated machines, you abstain from giving him a chance to do so and maybe suppress further interest. I think arousing interest and ease access it the way to keep a platform alive. (Still the "I don't prefer the LOAD"*",8,1" thing...)

 

 

Actually I do the same with files that require more memory, PAL video mode, OS-B, or SIO patch to be turned off, i.e.: [256K], [PAL], [OS-B], [sIO].

 

So you have already your solution (like I mentioned in the other thread "tags on disk labels") - others have theirs. Wouldn't you find it practical if there is a common sense what these tags should cover and have a standard access to them? Imagine you like to try out a 65C02 in your machine, would a tag 'program makes use of undocumented opcodes' be helpful? (Which you may have not covered now, since there wasn't the necessity - for you.)

 

I also have my 'tagging' principle (arguments for the emulator, see here: http://atariage.com/forums/topic/123515-so-many-games-so-hard-to-find/#entry2120002 ),

but I would prefer a standard way which eases exchange and don't put me into action if there is a new title which I like to have in my new cover-flow browser GUI.

 

BTW: Your tags don't help you while you are 'monkeying' with the emulator settings - switching from a [256K][PAL] to a [OS-B][sIO][NTSC] game. Do you really like that?

[HiassofT]

So what does that imply? You would like an untagged MP3 format more, just because some players have problems with the tags or interpret them wrong? Really?

No, my point was that extending an existing format is always problematic, so I strongly adivse against touching ATRs etc.

 

It should not be the solution to ADD information to an ATR but to define a new format. This should enable you to detect data integrity and help identifying the 'geometry'. So you actually argue for a better format.

As I wrote before, having metadata available is a good idea.

 

But I don't see the point why you would want to create a completely new format that is incompatible with all existing hard and software. Why not choose an approach that is backwards compatible with well established and well defined formats and is supported by a plethora of existing products?

 

ATR is a really well defined and perfectly working format for standard, non-copy-protected, disk images. All the compatibility issues with ATRs come from broken software that created invalid ATRs - but this is not a problem of the format. Sure, the 16-byte header and the compact storage of the boot sectors on DD images certainly is annoying but that's about it - not a show-stopper, just a minor annoyance.

 

But for now let's put all the format discussion aside and concentrate on the real, important thing:

 

What kind of metadata would you like to store and what should be the semantics of it (i.e. how should it be interpreted)?

 

Once we solved this point we can go on discussing how it should be stored.

 

so long,

 

Hias

[+MrFish]

I fully disagree and find your position quite arrogant. You blame easy access to technology and introduce the "I'm not worthy!"-scheme. If someone just likes to try out some of 'these old games' for outdated machines, you abstain from giving him a chance to do so and maybe suppress further interest. I think arousing interest and ease access it the way to keep a platform alive. (Still the "I don't prefer the LOAD"*",8,1" thing...)

 

I suppose it's just as arrogant to think that a useful idea can't possibly be rejected for simply having more than a few major drawbacks, and also to turn your back on compromise when programmers with interest in the idea would prefer an alternate method for housing the data.

 

I'm not "blaming" easy access for anything, I'm disagreeing with the proposed approach to achieving it. (I'm not really sure what you mean by the "I'm not worthy!" -scheme??? Note: I understand the reference to Wayne's World part.) I'm also not against any kind of improvements to emulation related technologies that will make things easier for users, as they'll also be easier for me. But the complexity isn't going to just magically migrate from one place to another.

 

 

So you have already your solution (like I mentioned in the other thread "tags on disk labels") - others have theirs. Wouldn't you find it practical if there is a common sense what these tags should cover and have a standard access to them? Imagine you like to try out a 65C02 in your machine, would a tag 'program makes use of undocumented opcodes' be helpful? (Which you may have not covered now, since there wasn't the necessity - for you.)

 

I also have my 'tagging' principle (arguments for the emulator, see here: http://atariage.com/forums/topic/123515-so-many-games-so-hard-to-find/#entry2120002 ),

but I would prefer a standard way which eases exchange and don't put me into action if there is a new title which I like to have in my new cover-flow browser GUI.

 

My philosophy about "disk images" is just that; they should be images of disks, which contain the essential information for them to be handled similarly to the way the original medium would be handled, in either emulation or with a real machine. Cartridge images are also lacking emulation relevant information (i.e.: OS-B and SIO patch incompatibility). Do we also want to propose changes to the cartridge image formats, and (I sure hope not) binary files as well? It seems like it would be half-baked to change the disk format and not include these other file types, if the goal is to make the user experience simpler across the board.

 

Don't get me wrong, I'd love to have an application I could use to browse my beloved Atari programs with packaging artwork, instructions, historical information, and any other sugar-coating that could be crammed in there. But big dreams take big efforts. I've spent a good number of years dealing with MP3 tags. I've got things well under control, but there is fair amount of hand work that goes along with it at times, and it certainly slows down my desire to have a larger collection -- preferring to have a sanely organized collection to a huge chaos of cosmic debris. And these tags are already widely supported. So even having a place for the data and support is not enough, it's necessary for a lot of data to be edited with care, otherwise you end up with a solution that is just as much of a headache as the problem itself.

 

 

BTW: Your tags don't help you while you are 'monkeying' with the emulator settings - switching from a [256K][PAL] to a [OS-B][sIO][NTSC] game. Do you really like that?

 

I think you're overestimating the effort involved in running an emulator and using files with various requirements. Simply setting the video to PAL and memory to 1088K takes care of a lot. All OS-B games have been converted. I turn off the SIO patch and hold down F1 when I want fast loads. So what's left after that? BASIC. I run a BASIC program disk once in a blue moon.

Edited March 29, 2014 by MrFish

[Irgendwer]

No, my point was that extending an existing format is always problematic, so I strongly adivse against touching ATRs etc.

 

It was never my intention to touch the ATR format but to create something more powerful.

 

 

But I don't see the point why you would want to create a completely new format that is incompatible with all existing hard and software. Why not choose an approach that is backwards compatible with well established and well defined formats and is supported by a plethora of existing products?

 

I see this the other way around. While creating the new format, converters to extract the ATR data (if the file contains disk data - see below) for existing and not maintained software/hardware are the task to start with. So the new format can act as master.

 

 

ATR is a really well defined and perfectly working format for standard, non-copy-protected, disk images.

 

Back in time even XFD had its friends...

 

But for now let's put all the format discussion aside and concentrate on the real, important thing:

 

What kind of metadata would you like to store and what should be the semantics of it (i.e. how should it be interpreted)?

 

Once we solved this point we can go on discussing how it should be stored.

 

I think there is no point (yet/anymore) doing this discussion.

That's why I created the poll: To clarify if there is need and/or support for such step.

Of course I have requirements/ideas what the new format should cover, but the poll and comments indicate that a new format is unwanted.

Interestingly thorfdbg, KrOtki and phaeron seem not to doom an addition generally - so there is even the chance that all big three emulators could be adopted -

but I'm unwilling to start a follow-up discussion, if the result would be undesired anyway.

 

 

I suppose it's just as arrogant to think that a useful idea can't possibly be rejected for simply having more than a few major drawbacks, and also to turn your back on compromise when programmers with interest in the idea would prefer an alternate method for housing the data.

 

According to the 'likes' you get, you must be right.

 

 

(I'm not really sure what you mean by the "I'm not worthy!" -scheme??? Note: I understand the reference to Wayne's World part.)

 

"I haven't enough knowledge about the platform/emulator, so I'm not worthy to successfully execute this application."

 

 

 

Do we also want to propose changes to the cartridge image formats, and (I sure hope not) binary files as well? It seems like it would be half-baked to change the disk format and not include these other file types, if the goal is to make the user experience simpler across the board.

 

Please read the title again. I even would not exclude cassette images. But especially for cartridge images: it is not fun to 'guess' the correct format and type of it.

 

 

I think you're overestimating the effort involved in running an emulator and using files with various requirements. Simply setting the video to PAL and memory to 1088K takes care of a lot. All OS-B games have been converted. I turn off the SIO patch and hold down F1 when I want fast loads. So what's left after that? BASIC. I run a BASIC program disk once in a blue moon.

 

Yes, in former times I had a similar default. But IMHO a game like 'Rescue on Fractalus' deserves NTSC even it runs under PAL. The point I'm trying to make is that the user experience could be better, if the optimum settings are applied automatically. Like switching artifacting on when loading 'Ultima IV', loading drives with matching images for a multi-disk title etc.

And that you run a Basic program once in a blue moon: When you know that you have to switch back and forth, could this also influence your decision? At least it was so here...

[+MrFish]

Yes, in former times I had a similar default. But IMHO a game like 'Rescue on Fractalus' deserves NTSC even it runs under PAL. The point I'm trying to make is that the user experience could be better, if the optimum settings are applied automatically. Like switching artifacting on when loading 'Ultima IV', loading drives with matching images for a multi-disk title etc.

 

In honesty, I usually run PAL/NTSC 50/50 percent of the time for the same reason you state, and because I prefer NTSC pixel aspect ratio, and the color schemes for games have often been geared towards NTSC and don't always look so good with the PAL palette (the same thing being true for some games of PAL origin that run fine otherwise on NTSC). But my point is that the settings don't necessarily need to be tweaked all the time, and a newcomer could be instructed which settings to use in order to limit incompatibilities as much as possible. Obviously it's not going to afford the new user the optimal experience in certain instances, but it will have less of a chance of frustrating him/her, which is the more important of the two when getting started with a new piece of software.

 

 

And that you run a Basic program once in a blue moon: When you know that you have to switch back and forth, could this also influence your decision? At least it was so here...

 

No, it's not influencing my decision whether or not to run BASIC programs at all. There just aren't many BASIC programs that I'm interested in, except the simulation and role-playing games -- from SSI and Epyx for instance -- which typically take more time to play than I have available. Even if I had the time I probably wouldn't be playing them much because I'm more of an arcade, puzzle, and board game player.

[fibrewire]

I haven't taken the time to look through this thread, but:

 

a) how do other emulators handle this on other platforms - has this been done before?

b) do games that require certain hardware touch specific locations in ram, so that an emulator might try to "auto-detect" configuration?

c) is there a standard naming convention for different media format games already - are we talking a new container or a master CSV sheet?

 

Anyway, I hope all games make it into the KryoFlux format sooner than later across all platforms. Our media will only last so long... however i have faith that the 5.25 360K and below formats will last another 100 years or so