Irgendwer Posted March 23, 2014 Share Posted March 23, 2014 (edited) Please inspect post http://atariage.com/forums/topic/162372-his-dark-majesty/page-5#entry2953919 and following ones for background information... Edited March 23, 2014 by Irgendwer Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 23, 2014 Share Posted March 23, 2014 Torn between "No! Not another file format" and "I would appreciate and even actively support it". If any new format had a 512 byte header, I'd sure appreciate it. That would greatly simplify disk image handling in things like Ultimate 1MB PBI, and even allow for performance improvements (since disk image sectors would align with physical sectors). Quote Link to comment Share on other sites More sharing options...
Rybags Posted March 23, 2014 Share Posted March 23, 2014 Yes - but needs to be downward compatible. To have environmental parameters that an emulator can use - at the minimum might eliminate a whole bunch of people complaining about things not working. But once images get out in the wild, it'd probably take years for everyone to get up to date. Quote Link to comment Share on other sites More sharing options...
HiassofT Posted March 23, 2014 Share Posted March 23, 2014 No, not another file format. What about existing hard and software? How do you handle multi-disk images? What about software requiring both a CAR and an ATR? Multiple, stacked carts? If I understand you correctly, this is all about adding some metadata to help emulator users and (maybe?) library software to help structuring your software archive. Just store the metadata in a separate file, describing the required system parameters (PAL/NTSC, memory etc), which images should be loaded into which drives, other typical metadata stuff (release year, version, author(s), ...) and so on and ZIP everything up. Then convince emulator authors to support your metadata file format (optionally with direct support for opening the ZIP file) and you are done. No need for yet another disk or cartridge image format. BTW: This is basically the same approach as the JAR (java archive) format - a ZIP with all the java classes and resources plus a manifest file. so long, Hias 2 Quote Link to comment Share on other sites More sharing options...
Rybags Posted March 23, 2014 Share Posted March 23, 2014 Bundle or seperate descriptor file has it's merits but probably not real useful on real machines using SIO2SD and the like. Although generally real hardware you're on a fixed configuration and such metadata isn't really vital anyway. But for me, if it can be a seamless addition that doesn't break anything then why not? Quote Link to comment Share on other sites More sharing options...
Xuel Posted March 23, 2014 Share Posted March 23, 2014 (edited) I see this as a way to wrap existing formats like XEX, ROM, ATR, CAS, etc. Maybe look at SAP and SID/PSID formats for inspiration? Another possibility is to make a separate metadata file. That way you still have the actual file in an established format. Edit: Just realized I repeated what was already said. Anyhow I lean towards a separate file. Edited March 23, 2014 by Xuel Quote Link to comment Share on other sites More sharing options...
+JAC! Posted March 23, 2014 Share Posted March 23, 2014 I'm also against changing the existing container formats (ATR/CAR/XEX). They fully do what they were intended to do and are widely supported.If we need additional information, it should be added as separate file. Just like Altirra already today automatically looks up the "example.atdbg" "example.lst", "example.lab" files if you start "example.xex". This file (suggestion ".ati") should be in an extensible text format with well defined encoding (e.g properties/xml) and should be able to optionally include: - release information (producer, title, year, authors, ...) - documentation (in multiple languages) - environment requirements (PAL/NTSC, ROMs, RAM sizes etc, as "required" or "supported") It also gives you the simple choice if you want to run the executable in the "current" environment (click on the ATR) or in the required envionment (click on the ATI). This would be a compatible, optional extension that might also be valueable on the real machine. In that sense, I vote for "Yes". Quote Link to comment Share on other sites More sharing options...
phaeron Posted March 23, 2014 Share Posted March 23, 2014 No to extending the existing formats. For one thing, they all have different levels of extensibility: ATR is a fixed size header format, CAR is a chunk-based format, and XEX has no extensibility at all since it is the raw DOS executable format. Second, from a layering standpoint this doesn't belong in the image formats. It would mean that the disk/tape/EXE parser would have to be able to reconfigure global system parameters above it. Ick. We do need a new disk format, but not for this. A separate launch file makes more sense, but will run into setting differences between emulators. For instance, emulators differ in whether they have separate XL and XE settings and what the difference is. IIRC, Atari800 has a single XL/XE setting, Atari++ enables extended memory in XE mode, and Altirra enables floating data bus in XE mode. Very basic settings like BASIC enabled/disabled and 800/XL mode are doable, but at that point it would be more useful simply to check that in the program itself: auto-disable BASIC and report a startup error if the system or memory configuration isn't supported. This would help on real hardware as well as emulation, and Ice-T is a good example. Unfortunately, very few programs do this, and we don't have a good source for people to learn how to do these kinds of things, either. Side note, I'd also highly discourage XML for any interchange format like this for complexity overkill reasons. Look up "internal DTD subset" for why. 4 Quote Link to comment Share on other sites More sharing options...
Kr0tki Posted March 24, 2014 Share Posted March 24, 2014 (edited) No, not another file format. (...) Just store the metadata in a separate file, describing the required system parameters (PAL/NTSC, memory etc), which images should be loaded into which drives, other typical metadata stuff (release year, version, author(s), ...) and so on and ZIP everything up. Exactly my idea. It's actually on my long ToDo file of things-I-wanna-add-to-Atari800. A separate launch file makes more sense, but will run into setting differences between emulators.An emulator that doesn't support a particular option, could simply ignore it (and notify the user). Also, the metadata file's syntax shouldn't be based on capabilities of any particular emulator. Edited March 24, 2014 by Kr0tki Quote Link to comment Share on other sites More sharing options...
+Larry Posted March 24, 2014 Share Posted March 24, 2014 Looks thus far like the "new standard" needs some "campaign promises!" -Larry Quote Link to comment Share on other sites More sharing options...
thorfdbg Posted March 25, 2014 Share Posted March 25, 2014 Please inspect post http://atariage.com/forums/topic/162372-his-dark-majesty/page-5#entry2953919 and following ones for background information... Well, I did not inspect that post, but here are my two cents: The problem is that ATR is pretty messy, though can represent a lot of disk formats. Unfortunately, it is unable to represent copy protected disks that use various tricks, like sector skew or duplicate sectors. ATX does, but ATX is even messier, and does not even cover anything beyond SD-FM coded disks. So yes, it would be appreciated to have a format that just works, and not the junk we have now. Anyhow, even though I would support this by adding it to Atari++, it does currently makes only limited sense to do so. Who converts the existing files? Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted March 25, 2014 Share Posted March 25, 2014 From a collectors POV I'd hate another format but from a user POV the idea that a file could hold all the data to self modify its running state to be as perfectly compatible as possible intrigues me but the notion of having to re weed out the horrendous number of duplicates that to this day I'm still struggling with puts me right off. Conventional dupe finding techniques would have zero effect and it would be a per item issue or hoping the format converter would explain what version of a file was used? Either way it sounds a lot of work.. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 25, 2014 Share Posted March 25, 2014 Well, let's face it: if we were using actual floppy disks, the onus would be on the user to select the appropriate OS/RAM/BASIC state before running the software. The only shortcoming in the ATR format I recently noticed is that one must intuit the PERCOM data by analysing the geometry of the disk image: i.e. there's no track count, etc in the ATR header. But this is no great problem. As for internal BASIC: it should be a basic (no pun intended) requirement that software disable it automatically when required. Nevertheless, something as simple as a different file extender (ATN, for example) would be enough to tell the host system that internal BASIC should be disabled. That said, a new format would be fun to play with if only to see what would be possible, but support for the old file formats would have to be preserved, since we could never hope to completely eradicate the ATR in our lifetimes. For better or worse, it's the proliferating standard. So, rather than streamlining things, parallel support for any new disk image format would tend to bloat existing implementations, so on balance I'd be happy to leave well enough alone - especially after having spent a lot of hours catering for the idiosyncrasies of the existing ATR layout. Quote Link to comment Share on other sites More sharing options...
thorfdbg Posted March 25, 2014 Share Posted March 25, 2014 It seems concepts are pretty much confused here. A disk image format should be exactly that: a "disk image format" and not an "emulator configuration file format". Whether the user loads the disk with or without BASIC enabled is up to the user, in the very same way it was up to the user with the original machine. Who knows which plans the user has? Second-guessing does not look like a wise idea for me. 3 Quote Link to comment Share on other sites More sharing options...
phaeron Posted March 26, 2014 Share Posted March 26, 2014 If I had to name requirements for a replacement for ATR, they'd be: simple format with pointers and fixed blocks for minimal parsing, aligned sectors for direct use on real hardware, able to support 256 and 512 byte sectors, no ambiguity over boot sector layout, support protected disk imaging, have a spec document, and have a publicly available disk imager that produces it. Anything less than that isn't going to go anywhere with ATR and ATX already in play. Even then, it'd have to be used for something that the existing formats aren't good for, such as faster direct access from an Atari-IDE adapter to images in a FAT32 partition, or imaging DD protected disks. With regard to an auto-configure file, what I would suggest is having that file be the "image" handled by the emulator, and then loading that is what brings everything else along for the ride including configuration and associated disks/tapes/etc. The reason that works for me, though, is that Altirra has a separate "Boot Image" command similar to Atari800WinPLus's Autoboot Image command that is suited for such a master bootstrap operation. For existing disks, it'd probably be better to keep them in the existing formats and just store the associated info in aggregate in a database file. I was thinking of starting something like this for Altirra anyway for auto-detection and flagging of disk images with known problems -- basically, a much more expanded version of the compatibility list I've been maintaining in the help file. Nobody is going to want entire collections of images reformatted to a new format that no existing emulators or PC-Atari connection tools can read. Quote Link to comment Share on other sites More sharing options...
Rybags Posted March 26, 2014 Share Posted March 26, 2014 Would something along the lines of a CRC32 database work - for ROMs it would be easiest, probably 1 or 2 per title, ie raw and cracked (although of course multiple crack versions exist for many titles). For ATR, just cover the data portion for the common images that have single games. If just the "known problem" titles were covered, ie - need OS-A, 400/800 only, >64K required that would reduce the overall workload to construct the database significantly. Quote Link to comment Share on other sites More sharing options...
snicklin Posted March 26, 2014 Share Posted March 26, 2014 Personally, I like the idea of a 2nd file which then specifies the required settings. I also think a larger file may be in order. To address the concern of the user not being able to override the settings, any emulator that uses the new file format must also have an option to ignore the file's recommendations also. Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted March 26, 2014 Author Share Posted March 26, 2014 (edited) It seems concepts are pretty much confused here. A disk image format should be exactly that: a "disk image format" and not an "emulator configuration file format". I find both aspects important. The resulting requirements do not exclude each other, but should be respected in common. Whether the user loads the disk with or without BASIC enabled is up to the user, in the very same way it was up to the user with the original machine. Who knows which plans the user has? Second-guessing does not look like a wise idea for me. While the user should be able to overrule environmental settings, I don't see your point. I mean we are Atarians, and I always felt (and still feel) it was/is an advantage not to enter "LOAD"*",8,1" as a precondition to express the "users will"... It is much more convenient and user friendly to have something self-contained which runs out-of-the box and don't send the user on a long journey through settings which may allow to execute an application. And please don't forget the documental/preservation effect. We are here (more or less) experts, knowing the abilities and have an idea which tweaks could help running a game or make it look better. But most of us have more than 25 years experience. Beginners (and maybe we too - when we starting to become real old) would be happy about some 'advice'... Independent from the result of the poll, I already find this discussion very insightful and valuable - so please don't stop with comments! Edited March 26, 2014 by Irgendwer Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted March 26, 2014 Author Share Posted March 26, 2014 (edited) Side note, I'd also highly discourage XML for any interchange format like this for complexity overkill reasons. Look up "internal DTD subset" for why. In the linked post, I mentioned MP3-ID3 tags, which are quite simple and tied to the data, which I regard as an advantage... BTW: If you prefer something without the XML overkill there is even a standard developed by an 'Atarian': JSON... ( http://a8.fandal.cz/search.php?search=Douglas+Crockford&butt_details_x=x ) Edited March 26, 2014 by Irgendwer Quote Link to comment Share on other sites More sharing options...
pixelmischief Posted March 26, 2014 Share Posted March 26, 2014 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. Quote Link to comment Share on other sites More sharing options...
HiassofT Posted March 26, 2014 Share Posted March 26, 2014 In the linked post, I mentioned MP3-ID3 tags, which are quite simple and tied to the data, which I regard as an advantage...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. 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... A lot more important than the file format is to decide what kind of information should be stored in your metadata file/block/whatever and how the semantics of that information should be. First of all, metadata should be static. You most certainly wouldn't want to add information that could possible change over time or isn't valid for 100% of the cases (like, for example, specific emulator settings like needing the SIO patch to be disabled in emulator X). Concentrating on real, existing hardware would be a good approach, I guess. For example you could specify the minimum system requirements in a metadata file like this: config.system.type=Atari 800XLBut, what does this actually mean? Does it work on XEGS, or an 130XE? Or do you want to specify multiple configuration choices, like "the software can run either on an 800XL with Rambo 320k upgrade, but not on an 130XE or an 800XL with 320k newell"? Most likely this information is easier to represent in 2-3 lines within a README.TXT than in a formal way in some metadata file/block. Simple things like "requires OS/A" or "needs at least 64k RAM" are easy, but after you go beyond that things get _very_ tricky. so long, Hias Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 27, 2014 Share Posted March 27, 2014 (edited) It seems concepts are pretty much confused here. A disk image format should be exactly that: a "disk image format" and not an "emulator configuration file format". Whether the user loads the disk with or without BASIC enabled is up to the user, in the very same way it was up to the user with the original machine. Who knows which plans the user has? Second-guessing does not look like a wise idea for me. Exactly. Most likely this information is easier to represent in 2-3 lines within a README.TXT than in a formal way in some metadata file/block. Simple things like "requires OS/A" or "needs at least 64k RAM" are easy, but after you go beyond that things get _very_ tricky. Quite so. And if ATRs were real disks, they'd also have sticky labels attached with instructions like "boot with Option pressed", etc; such cues might easily be incorporated into the ATR's filename, even. It is much more convenient and user friendly to have something self-contained which runs out-of-the box and don't send the user on a long journey through settings which may allow to execute an application. And please don't forget the documental/preservation effect. We are here (more or less) experts, knowing the abilities and have an idea which tweaks could help running a game or make it look better. But most of us have more than 25 years experience. Beginners (and maybe we too - when we starting to become real old) would be happy about some 'advice'... Surely there's a line between ease of use and over-sanitisation (or idiot-proofing, if you like), and I wonder if having to boot a game with Option pressed isn't integral to the retro computing experience. It's hardly an expert-level requirement, figuring this out, but if that's too much for the user, why is he bothering to mess with old computers in the first place? I recently started fiddling with CP/M in the WinAPE CPC emulator, and I found it difficult to boot some disks, since the system is unfamiliar to me. Getting stuff to work involved experimenting with a new system, and none of my "expertise" seemed to be much use. Nevertheless, I eventually figured it out, and that was part of the fun. Edited March 27, 2014 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
+MrFish Posted March 27, 2014 Share Posted March 27, 2014 Quite so. And if ATRs were real disks, they'd also have sticky labels attached with instructions like "boot with Option pressed", etc; such cues might easily be incorporated into the ATR's filename, even. I take the opposite angle on labeling files. I put a [bAS] on the end of the filename if the disk requires BASIC to run, and assume everything else is machine machine language. Quote Link to comment Share on other sites More sharing options...
+MrFish Posted March 27, 2014 Share Posted March 27, 2014 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. 1 Quote Link to comment Share on other sites More sharing options...
+MrFish Posted March 27, 2014 Share Posted March 27, 2014 I take the opposite angle on labeling files. I put a [bAS] on the end of the filename if the disk requires BASIC to run, and assume everything else is machine machine language. 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]. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.