kl99 Posted May 10, 2015 Share Posted May 10, 2015 (edited) I got a Disk Image of SDUMP, made by Quality 99 Software. It includes multiple copy protections. The software works on the real TI-99, and in PC99 it works as well. However most Emulators fail to get the software running and therefore behave different than the real TI. First of all, TI-99 Dir and TiImageTool both fail to show the files that are on this disk. The reason is that the author added 0x0000 as the first entry from the File Descriptor Index Record - Sector 1. Sector 1 is where any catalog program shall check entry by entry to get the complete list of File Descriptor Records on the disk, it shall stop once it hits 0x0000. Since the first one is manually set by the author to 0x0000, any cataloger stops searching for any files and therefore thinks the disk does not contain any files. So why does it work on the real TI-99 at all? Well, the Autoload feature from Extended Basic is loading LOAD and seems to bypass this check. More interesting bits are the disk is set to have unusual 35 tracks defined, it's set to have all 360 sectors used. The Basic Programs on it LOAD & SDUMP contain the basic file-protection that disallows LIST and SAVE. The Assembler Files all have special characters at the end of their filenames which breaks the FILETYPE check of TI99Dir, even if you manually fix the FDR Index in Sector 1. TiImageTool still refuses to load a fixed FDR Index Version of that DiskImage. It says: "Defect or missing file system: Sector 19535 beyond image size." SDUMP.dsk is the original DiskImage [PC99] SDUMP-C.dsk is the "cracked" version with the fixed Sector 1 (FDR Index) [PC99] SDUMP-C V9T9.dsk is V9T9, converted from the SDUMP-C.dsk [PC99] with TI99Dir. So let the challenge begin... Who fixes his tools/emus first? Klaus SDUMP.dsk SDUMP-C.dsk SDUMP-C V9T9.dsk Edited May 10, 2015 by kl99 Quote Link to comment Share on other sites More sharing options...
Willsy Posted May 10, 2015 Share Posted May 10, 2015 Should be easy enough to fix with a sector editor. No change to emulators required. Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted May 10, 2015 Share Posted May 10, 2015 fiddle fiddle fiddle please have a look on that now: SDUMP-C-RMS.DSK 1 Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted May 10, 2015 Share Posted May 10, 2015 yep, looks somehow bettererer: 1 Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted May 10, 2015 Share Posted May 10, 2015 ...more on the files itself maybe later, motherday first Quote Link to comment Share on other sites More sharing options...
kl99 Posted May 10, 2015 Author Share Posted May 10, 2015 Should be easy enough to fix with a sector editor. No change to emulators required. The purpose of an emulator is to emulate the machines behavior. If it works out of the box on the real machine, it should work without a fix on the emulators as well. If that is not the case, the emulator behaves different. At least regarding the Autoload feature of Extended Basic. It seems that module does a binary search within the File Descriptor Index Record to find the FDR of "LOAD" exactly the way it was specified for the Disk Peripheral. And therefore according to the specs for LOAD to autoload it doesn't matter whether the first entry is 0x00 or not. And therefore it doesn't matter on the real TI and the disk image is working there. Therefore it shall work on emulators as well. According to the Software Specifications for the 99/4 Disk Peripheral: "6.1.2. File Descriptor Index Record ... Since the file descriptors are alphabetically sorted in this block, a binary search method can be used to find any given filename, limiting the maximum number of disk searches to 7 if more than 63 files are defined. In general if between 2**(N-1) and 2**N files are defined, a file search will take at most N disk searches. To obtain faster directory search response times, the system will prefer to allocate data blocks in the area above AU number 34 (>22). Only if no AU can be allocated in that area will the disk data block allocator start allocating blocks in the AU area 2-33." Quote Link to comment Share on other sites More sharing options...
kl99 Posted May 10, 2015 Author Share Posted May 10, 2015 (edited) Used Emulators: Classic99: 2015-05-10 (interims) Ti994w v4.4c 2015-01-10 Pc99 Stage 6 within DosBox Mess 0.161b x64 Windows Binary Win994a Version 3.010 4/2/2013 Js99er 2015-05-10 (online version) Used Disk Image: SDUMP V9T9.dsk Disk Image V9T9 original - for all except Pc99 SDUMP.dsk Disk Image PC99 original - for Pc99 Test 1 - Autoload of LOAD in XB: Classic99: passed Ti994w: passed Pc99: passed Mess: passed Win994a: failed Js99er: passed Test 2 - RUN "DSK1.LOAD": Classic99: passed Ti994w: passed Pc99: passed Mess: passed Win994a: failed Js99er: passed Test 3 - handling of Filenames with special chars - the LOAD Basic Programs loads "SDUMP1.." [ >53 >44 >55 >4D >50 >31 >0D >1B ] later "SDUMP2.." [ >53 >44 >55 >4D >50 >32 >1B >0D ] and "SDUMP3.." [ >53 >44 >55 >4D >50 >33 >0D >1B ] are loaded as well. Classic99: passed Ti994w: failed Pc99: passed Mess: passed Win994a: skipped Js99er: failed Test 4 - Software SDUMP running fine (requirement of PIO Device is excluded): Classic99: passed Ti994w: skipped Pc99: passed Mess: passed Win994a: skipped Js99er: skipped Edited May 10, 2015 by kl99 2 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted May 10, 2015 Share Posted May 10, 2015 Fascinating.... Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted May 10, 2015 Share Posted May 10, 2015 Interesting disk compatibility test. . . Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted May 10, 2015 Share Posted May 10, 2015 So it looks like MESS and PC99 remain the gold standard for accurate emulation of the hardware to date. Since PC99 is now incompatible with most newer OS'es, this leaves us with MESS. There was an interesting exchange between Michael and Tursi regarding the overarching goals of MESS versus Classic99 recently, and it seems like MESS thrives to very accurately emulate the hardware, flaws and all, whereas Classic99 fudges it a bit for the sake of efficiency and ease of coding. The former is a historically accurate representation of the machine for future preservation, and the latter is an excellent platform for program development. I use both depending on what I'm trying to do, and am extremely thankful that we have these two dedicated and talented individuals to maintain these essential modern tools for us. 3 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted May 10, 2015 Share Posted May 10, 2015 ^^this^^ What a cool community we have. 2 Quote Link to comment Share on other sites More sharing options...
Tursi Posted May 10, 2015 Share Posted May 10, 2015 When you list Classic99, you kind of need to test all three disk controllers - they are all running different code for the actual file handling, it's only the internal handling that's shared. Only the TI Disk Controller is intended to be an accurate representation of the TI Disk Controller, although the disk image reading is intended to be compatible. Testing using the TI Disk Controller emulation in Classic99: Autoload from XB: works fine on both PC99 and V9T9 disk images. RUN "DSK1.LOAD": works fine on both PC99 and V9T9 disk images. Loading of the special filenames does NOT work, which I found interesting. After a quick look, though, it's not because of the special characters, it's because the actual filename opened is "DSK.QUALITYSOF.SDUMP1xx" (where 'xx' are the two control characters) - and I did not support passing that through to the TI controller emulation (in fairness, it finds the right disk but the TI code gets confused by the entry point). So I fixed that, and then the OPEN call succeeded. Then the next problem is that the filename used for read replaces the period in "QUALITYSOF.SDUMP1xx" with character >81, which is not period. Classic99 couldn't parse the disk name so couldn't find the right disk to send the command to (with 10 disks, it needs to know which driver gets the request. ) I checked how the TI DSR copes with that particular one, and apparently characters in disk names with the high bit set end copy loops. As far as I can tell -- that's always legal, but not used: a period or a high ASCII character can be used to separate names in a DSR entry (didn't check everywhere). I can fix that. As for the search failing in Classic99's own disk image reader, your excerpt says "a binary search method can be used to find any given filename" -- it does not say "a binary search method must be used". The disk is deliberately corrupt and may or may not work in other controllers, even controllers that follow that specification. But I can scan the whole sector, too. What the hell. I'm not entire sure how to tell if the CALL LINK works, but it executes. Classic99's PIO doesn't go anywhere, so I can't tell you what it wrote. Anyway, with the above fixes, Classic99 now runs both the PC99 and V9T9 disk images in both its native disk image reader and in TICC mode, with no issues I can see. I didn't test FIAD mode since it's about your copy protected disk, and the control characters would need to be removed from the filenames. I don't have time to upload a new release right now, so I'll just dump a copy of my WIP here. classic99WIP.zip Quote Link to comment Share on other sites More sharing options...
Tursi Posted May 10, 2015 Share Posted May 10, 2015 whereas Classic99 fudges it a bit for the sake of efficiency and ease of coding. ^^ this ^^ ... is actually is a pet peeve of mine. I don't emulate the TI disk controller by default, and I never set out to. The dependence on the original disk controller frustrates me no end - but all that said, I don't deliberately fudge things for ease of anything. What is implemented, is intended to be accurate (except the speech synth, which was just a 'shut up' feature for someone else ). The original DSR that I implemented was files on a disk, based on the concept that V9T9 used. It was a from-scratch implementation and over the years it's been hit pretty hard. It's pretty stable and compatible now but there are parts of the original controller spec that I refuse the implement in it, because I don't understand why we deliberately limit ourselves moving forward. It's a new DSR that I intend to port to hardware and use on real modern filesystems, I don't want it to look like a TI disk controller. After much complaint, I implemented reading of disk images. This was largely so the files could be copied to the FIAD disks more easily. At the same time, having this code stable and reliable will also help the above mentioned real DSR, since people are never going to give up their damned images. This was also a new, from scratch implementation. Neither of the above DSRs had any requirement on the TI system save a PAB - it quickly became obvious how much software depended on the disk buffers being allocated, so that much was hacked in at least. Due to the number of issues people were having with compatibility, I started looking at what parts made sense to reproduce, and what parts did not. My criteria was very strict - are you using data that is documented, commonly-used, and reliable, or are you reading side-effects from the TI disk controller ROM? Side effects, as much as possible, I omitted, in order to keep the disk system as pure as possible. What do I mean by 'pure'? When the TI creates an OPEN command, it doesn't look for a disk interface or a cassette interface or a hexbus, or anything else, like some systems do. All it has is a name and it looks for that name. This is why you can "SAVE PIO" and "OLD RS232" - the console doesn't know or care what the hardware is, or what it does with the data. It asks the DSR to open, then it asks for data or sends data to the DSR. After that, it's done. The device ITSELF defines the storage or retrieval of the data, so the format of a TI disk image is entirely contains inside the TI Disk Controller ROM -- not the TI console. It was never intended, nor should it have been, that a hard drive controller would store files using the same format. But that's what we ended up doing. The idea being that software written generically would run on all devices - not just mine and not just a TI disk controller - but certainly including those. We have more and more options but almost every new device keeps ending up a glorified TI disk controller. It'd be lovely to walk away from that, but people seem to search for single examples (out of thousands that work) and waving them around making a lot of noise that emulation isn't perfect because one case fails. So, because of those two issues, and to help myself trace through the operation of the real disk controller for some of the lingering issues we faced on certain titles, I implemented Classic99 support for the real TI disk controller. It's still a hack only because I still need to go through and allow it to talk to DSK0-DSK9 and allow it to deal with disk images larger than 180k (both very minor tweaks I just haven't had time for), so that it integrates into Classic99's other disk drivers cleanly. But for cases where you are testing something that needs to work like a TI disk controller, this is the only thing that SHOULD work like a TI disk controller (except that instead of reading flux data it reads sectors out of a file on the host system, and doesn't support the track based commands at the moment). So I rather object to it being called an accuracy or a fudging issue -- a compatibility issue, certainly. And there are bugs, certainly - but bugs I try to get to. But saying that Classic99 is less accurate because the primary disk system isn't a TI disk controller is misleading and gives a bad reputation. (Again, say it about speech and I'll back you up 100% But not disk.) 1 Quote Link to comment Share on other sites More sharing options...
Willsy Posted May 10, 2015 Share Posted May 10, 2015 Classic99 is a much better solution than the other emulators. The way it integrates into the pc platform is a god send. The way it can read and write to native PC files is something in thankful for every time I use it. The debugger is great too. There's zero chance that TurboForth would exist without Classic99. Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted May 10, 2015 Share Posted May 10, 2015 So I rather object to it being called an accuracy or a fudging issue -- a compatibility issue, certainly. And there are bugs, certainly - but bugs I try to get to. But saying that Classic99 is less accurate because the primary disk system isn't a TI disk controller is misleading and gives a bad reputation. (Again, say it about speech and I'll back you up 100% But not disk.) Perhaps fudging was the wrong term as it has connotations of laziness or misunderstanding. What I meant by it was that artistic license was taken with Classic99 on some specific aspects of the emulation like the disk controller for example as compared to the actual hardware based on your own views of how things should be implemented. Please understand that this is not a bad thing by any stretch, particularly given the fact that Classic99 remains the premier emulator for most program developers, however it does imply that Classic99 is not a pure unadulterated emulation of the TI system, not does it claim to be. This fact certainly does not imply that it is a less accurate emulation though. Quote Link to comment Share on other sites More sharing options...
kl99 Posted May 10, 2015 Author Share Posted May 10, 2015 Hi Tursi! I hope you didn't take it personal. I owe you a beer if that is the case. I respect very much your work in the emulator. It's just when you learn about the inner structure of the TI, the oddities are always an eye catcher. I thought, if such an diskimage was breaking Web99 (the TI tool I am working on), therefore I thought it might be interesting to see how the other TI Software (Emus, Disk Tools) is handling this particular one, therefore i will probably post more odd disk images in this thread. kl99 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted May 10, 2015 Share Posted May 10, 2015 Ah, I remember those Quality99 pieces of software. Those things gave me a headache trying to unprotect and create backups of. Besides non standard disk sector crap, plus XB protection (As I recall, even if you did a CALL LOAD-31931,0 to unprotect, and tried to list it, it corrupted the VDP screen table, and required you to reset the computer... but that might have been another program that also had protection.) I know Quality99 had quite a few programs; does anyone have them all in one place? Some of the other programs that gave me headaches trying to duplicate were the MG ones (which someone passed along the unprotected Advanced Diags, DiskAssembler, and Explorer to me a long time ago.) I also remember the MG XB programs had protection too, and some of the other programs like the ToD editor likewise had strange protection. I think Bill Gronos did describe in his Disk Fixer book about some of these sneaky methods of protection. Quote Link to comment Share on other sites More sharing options...
atrax27407 Posted May 10, 2015 Share Posted May 10, 2015 I think Will McGovern was the first to break the protection on the MG programs after Craig Miller proclaimed that his protection scheme was "unsolvable". It took him all of 20 minutes to break the scheme. I got copies to go along with my originals on one of my trips to Oz. 1 Quote Link to comment Share on other sites More sharing options...
Gazoo Posted May 10, 2015 Share Posted May 10, 2015 Ah, I remember those Quality99 pieces of software. Those things gave me a headache trying to unprotect and create backups of. Besides non standard disk sector crap, plus XB protection (As I recall, even if you did a CALL LOAD-31931,0 to unprotect, and tried to list it, it corrupted the VDP screen table, and required you to reset the computer... but that might have been another program that also had protection.) I know Quality99 had quite a few programs; does anyone have them all in one place? Some of the other programs that gave me headaches trying to duplicate were the MG ones (which someone passed along the unprotected Advanced Diags, DiskAssembler, and Explorer to me a long time ago.) I also remember the MG XB programs had protection too, and some of the other programs like the ToD editor likewise had strange protection. I think Bill Gronos did describe in his Disk Fixer book about some of these sneaky methods of protection. http://atariage.com/forums/topic/229041-fiads-or-doads-dsk-images-or-zips-your-favorite-here/?do=findComment&comment=3059170 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted May 10, 2015 Share Posted May 10, 2015 Perhaps fudging was the wrong term as it has connotations of laziness or misunderstanding. What I meant by it was that artistic license was taken with Classic99 on some specific aspects of the emulation like the disk controller for example as compared to the actual hardware based on your own views of how things should be implemented. But I disagree with this too - although my disagreement is probably just perspective. When the actual hardware is released, will it still be considered "artistic license"? From day one I've built the FIAD code to make it possible to use it with real hardware, there's nothing in there that is impossible or magic - or at least, nothing that can't be obtained with the same code elsewhere. From the VDP usage to the file system access, it's all very possible and elements like the AVR GROM are intended as pieces of the final product. This fact certainly does not imply that it is a less accurate emulation though. "Less accurate", however, is how it is described. You will find it now in many threads and even on some webpages. I'm not going to harp on it beyond today, but as the term continues to spread it is more and more frustrating. I thought, if such an diskimage was breaking Web99 (the TI tool I am working on), therefore I thought it might be interesting to see how the other TI Software (Emus, Disk Tools) is handling this particular one In fairness, it's the first such disk I've actually seen, though I've known such tricks were feasible. It /is/ a corrupt disk for all intents and purposes, but the particular corruption is not terribly dangerous (I thought of several other hacks that would still fail on the fix I made, we'll see if any of your other disks try them. ). Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted May 11, 2015 Share Posted May 11, 2015 I have a feeling this is not an argument I'm going to win (Not that I was trying to argue in the first place!). I think everybody here gets the gist of the discussion without having to wade too deeply into semantics. I'll leave it at that 1 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted May 11, 2015 Share Posted May 11, 2015 http://atariage.com/forums/topic/229041-fiads-or-doads-dsk-images-or-zips-your-favorite-here/?do=findComment&comment=3059170 Nice! Thanks! Quote Link to comment Share on other sites More sharing options...
Gazoo Posted May 12, 2015 Share Posted May 12, 2015 Nice! Thanks! You are most welcome, kind sir. G Quote Link to comment Share on other sites More sharing options...
klrw111-78 Posted September 1, 2017 Share Posted September 1, 2017 I am looking for the SDUMPII for use on real iron. I am using an ImageWriter for a printer and this software supports the Pro-Writer. No luck on finding how the ping firing on this printer works different from an Epson. Thought I could use this tool to get the information. I have found SDUMPII as a .dsk image on WHTECH but can't get it converted to back to real floppy or .hfe . Any thoughts? Thanks Quote Link to comment Share on other sites More sharing options...
sparkdrummer Posted September 1, 2017 Share Posted September 1, 2017 Are you needing it to inspect sectors? If so I would recommend John Birdwells Disk Utilities. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.