Adding copy-to-resized-image support
Closed this issue · 9 comments
Hello Ralph,
I'm one of the growing number of people that have replaced the 40-track ROMs in their disk controller with 80-track ROMs.
I've been using xdm99.py to extract files from 40-track images and DSDD images, then add them into a fresh 2S1D80T disk image, but that seems to have problems with filenames that start with shell reserved characters ("*" and "-", for example.
Attached is a patch that adds a "-c" (for copy) flag to xdm99.py. Usage is:
./xdm99.py -c 2S1D80T -n /path/to/dest.dsk /path/to/source.dsk
... and can be used to batch-convert disks like so:
for i in *.dsk; do ./xdm99.py -c 2S1D80T -n echo $i | sed 's,\.dsk,-80.dsk,g' $i; done
I hope that you would consider adding this functionality into the main branch, because it is (to me, at least) very useful.
Cheers,
-- Chris
Hi Chris,
Thanks for the contribution! I really appreciate the time and effort you spent on making the patch available, instead of just modifying the code in private.
Now regarding your particular problem, couldn't you just use
$ xdm99.py sssd.dsk --resize 720 --set-geometry SSSD80T -o sssd80.dsk
Well, you couldn't 😄, because for some reason I made --resize and --set-geometry mutually exclusive. So I fixed that in my latest commit, and I also cleaned up the incorrect warnings that you pointed out some time ago.
Please let me know if this doesn't cover your use case -- or if something is buggy.
(And a side question: So if I have a DSDD 80T disk, I can still only use 1600 sectors, right? Or does 80T not work with DD?)
Regards
Ralph
Hmm, thinking about this a bit more, maybe --resize should also support an "xxT" modifier? You can already specify "--resize SSSD" etc., so "--resize SSSD80T" would do the sector calculation for you. Would that be preferable?
Hello Ralph,
Thanks for the quick response. I always feed my patches back upstream; if I have a problem with something, then someone else probably will too, but they might not tell you about it :)
Unfortunately, "./xdm99.py romdump1a.dsk --resize 1440 --set-geometry SSSD80T -o sssd80.dsk" doesn't produce a working image. Or, at least, the disk header has the wrong geometry.
Consider an image with the header "ROMS : 1300 used 140 free 360 KB 2S/2D 40 TpS"
With my patch, the resulting header is "ROMS : 1300 used 140 free 360 KB 2S/1D 80 TpS"
With a copy of xdm99.py that I just grabbed, the header is "ROMS : 1300 used 140 free 360 KB 2S/2D 40 TpS", which is clearly incorrect. In fact, it's not clear from the output that --resize did anything to the target disk.
If --resize could be amended to fixing the header, that would be helpful. Are you certain that it's fixing up the file/sector mapping as well? I was having inconsistent results with it several months ago ...
... this behavior, in fact, was why I hacked in my resize code -- the "--resize" switch was not having any apparent affect, sometimes corrupted the image, and with my code I was extremely sure that it was not only creating the new disk image with the correct geometry but that all of the files were placed on the image correctly.
It would be very nice if an xxT modifier existed, by the way.
Thanks again for looking at this, much appreciated,
-- Chris
Sorry, I missed the last question in your first post the first time around: "(And a side question: So if I have a DSDD 80T disk, I can still only use 1600 sectors, right? Or does 80T not work with DD?)"
No, with DSDD80T, you would get 1880 sectors, but I don't know if Myarc supported 80 TpS nor if anyone modified the Myarc ROM to do so. I've never seen one, nor an 80-track DD image for that matter, but that doesn't mean they don't exist :)
I do know that they made a controller that did DSHD80T, so 36 sectors and 80 TpS for a total of 5760.
I'd recommend assuming that DSDD80T and DSHD80T both exist, so that you've got all bases covered :)
Crap, I really wasn't awake this morning when I ran the first test.
The test invocation should have been: ./xdm99.py romdump1a.dsk --resize 1440 --set-geometry DSSD80T -o dssd80.dsk
... and the erroneous output is:
[13:32:33] dhcp11-118:~/unix/xdt99-master$ ./xdm99.py dssd80.dsk
ROMS : 1300 used 140 free 360 KB 2S/2D 40 TpS
... so no change in the error behavior I reported, but my test was wrong.
Maybe I didn't explain the situation properly. Stock TI FDCs are DSSD40T. Some bright fellow, about twenty years ago, realized that the stock TI 5.25" 40-track drive single-head drive could be replaced with a PC 80-track double-head drive (either 5.25" or 3.5"). That doubled capacity from 90k to 180k (by virtue of having two available sides), but half of the disk was unused because the controller DSR would switch to the other side if it tried a track > 39.
Then another bright fellow patched the DSR so that it would switch from side 0 to side 1 at track > 79, so the entire disk could be used. Unfortunately, the chip in the TI FDC wasn't capable of double-density, so the maximum (and default!) storage was now 360k.
So, if you see a 80TpS image, it's always going to be double-sided. If it's double-density, then it was written by a Myarc controller, but the track handling will be the same.
I hope that clears up any misunderstanding that might have existed,
-- Chris
Sorry for hacking this together too hastily. You're right: When combining --resize and --set-geometry in a single command, the --resize undoes the settings of the --set-geometry.
But that's the chance to do it properly now. I've added track handling to the --resize command, so you can now say
$ xdm99.py dsdd40t.dsk --resize dssd80t -o dssd80t.dsk
As far as .dsk dumps are concerned, the physical order of tracks on the disk is irrelevant. That's why you can easily change disk geometry simply by setting 3 bytes in the disk header. Of course, you can also set it to bogus values.
So, if the capacity doesn't change, e.g. from DSDD/40T to DSSD/80T, you can use either --resize or --set-geometry. If you really want to increase the capacity, e.g., SSSD/40T to DSSD/80T, you'll have to use --resize.
From your explanation of the 80 track patch a SSSD/80T disk should be possible, and it should be, in fact, single sided.
A hypothetical DSDD/80T disk should have 2 x 1440 = 2880 sectors, but the TI file system has a 1600 sector limit in the sector allocation table. Thus, a DSDD/80T disk doesn't offer that much benefit compared to a DSDD/40T disk, unless there's some hackery I'm not aware of -- hence my original question. (The sector limit is also the reason why the CF7+/nanoPEB uses 1600 sector disk images.)
Please let me know if the new version works for you.
Ralph
"./xdm99.py -Z DSSD80T -o test.dsk ros001.dsk" works as expected now, thank you.
Regarding the maximum theoretical size of the disk, I think you're technically correct with regards to the bitmap in the VIB as specified by TI... but the maximum start sector in the FDR is 0xFFF (both per https://www.disavowed.jp/mirrors/nouspikel/ti99/disks.htm#VIB), so it's theoretically possible to have a maximum of 455 (SD), 227 (DD), or 113 (HD) tracks. The DSR would need to keep a separate sector map for the high tracks and calculate the real used/free values when DSKn is opened and read, but that's easy.
Again, I've never seen a DSHD, so I don't know what games (if any) it's playing with the sector map, so this part of the conversation is just academic :)
(and you're right, it's technically possible to have a SSSD80T image. I can't imagine anyone actually using one, because if the drive suppors 80 tracks it's going to have two sides, but it is possible :)
(edit: I should't mix bases 10 and 16 when doing division)
Great! I'm closing this ticket then, but please keep them coming! A this point you're probably the only xdm99 user with an interest in 80 tracks, so I'm very keen on your suggestions, feature requests, and bug reports. (And besides, I think you're probably the most proficient power user of xdm99 in general, so I value your opinion.)
Thanks for the kind words, and more particularly, thanks for writing xdm99 ... it saved me the trouble of having to write it myself. I strongly dislike things that a) require x86 because b) they require wine because c) I don't run windows, so everything Fred wrote (TIdir, in this case) is right out :)
I have noticed a few more not-quite-bugs when exporting and then re-importing non-PROGRAM files, and a few of the one-argument commands won't run unless I feed them a "-n dummy". I'll come up with a few test cases and open issues for you.
Thanks again for xdm99 :)
-- Chris