Closed SimonGoodwin closed 8 months ago
To be honest I mashed Sam Coupe in there following the same categorisation as SAMdisk: https://simonowen.com/samdisk/formats/
So my understanding is that EDSK may be used for Sam Coupe disks. Well, of course it can, but I mean actually you may find Sam Coupe EDSK images "in the wild", supported by emulators, etc?
I should split out DSK from EDSK, as you are correct that DSK can also be a raw sector image (not an Amstrad CPC image format). Greaseweazle auto-detects on import, by looking for the CPC image header signature, and on export cannot write Amstrad CPC images and so will always write a raw sector DSK image.
Based on all this, what do you think I should do? Split DSK from EDSK, and perhaps further split DSK into two (raw vs CPC)?
Those splits make sense to me.
I've not seen an EDSK but can imagine why Si Owen would find it useful personally, especially as a sort of CPC CP/M to SAM ProDOS bridge.
I have hundreds of .DSK images and original media from Sams and Spectrums, all exactly 800K.
I've had a go at this, see what you think before I close the ticket.
You can safely add Sam Coupe to the .MGT cluster. The original SamDOS and better BetaDOS are identical format-wise, differing only in file-type flags. I'd also add Sam Coupe after Spectrum +3, given the Si Owen/EDSK information, his site, use of .DSK for e.g. the entire Sam Supplement collection, and knowing him. I guess he might yet be inclined to bridge SAMdisk, SimCoupe/DSL (running here now) and gw direct access, which would be awesome though going via .dsk etc makes more sense for those with specific intent rather than triaging hundreds of floppies including many swaps.
This ticket has been closed prematurely. Please reread my comment of 27th December above, in the context of your helpful offer that day to ‘have a go’. Further to the deletion of SAM coupe from what you problematically choose to mean by .DSK,
MGT (Sinclair ZX Spectrum DISCiPLE/+D)
should more helpfully read
MGT (Sinclair ZX Spectrum DISCiPLE/+D, SAM Coupe)
as the SAM coupe was also an MGT product based on the same DOS and with IDENTICAL formatting and default directory structure.
Given this correspondence it would be helpful to list Sam Coupe in the MGT group rather than simply do away with the ambiguous DSK classification and pretend that Greaseweasel does not support SAM media when it does.
The category errors that remain are substantially caused by the prevalent but problematic presumption that the characters in a file name are predictive of its content. That mistake bites both experts and beginners, as it did Keir in the case of DSK. But a more substantial redesign of the document, to incorporate more reliable (yet still uncertain) signifiers such as byte count (always a multiple of 204800 for .MGT and equivalent .DSK files, almost always 819200 in practice) would be necessary to make the document more accurate and useful.
The presumption about file extensions, derived from DEC SYSTEM 10 via CP/M, also causes trouble in other contexts such as .DOC (not proprietary to Microsoft, inconsistently applied even by them) , .TXT (ambiguous for the majority of bytes which are not defined by ASCII, and most problematic for line termination), .WAV (could be WMA, NVADPCM or many other non-PCM formats), .MOV etc etc.
Thanks, SAM Coupe is now added to MGT and EDSK clusters.
Thanks, that’s fine now.
Some of my software to unpack the contents of MGT disk images is here: https://simon.mooli.org.uk/nextech/index.html#NextMGTreader
It runs on a ZX Spectrum Next (or emulation) and supports GDOS, G+DOS, UniDOS, SAMDOS, MasterDOS and BetaDOS; with a little tweak to seek to the required 800K offset it could also access SAM file within BDOS hard disk images.
https://github.com/keirf/greaseweazle/wiki/Supported-Image-Types
puts Sam Couple discs in with Amstrad ones.
This is misleading and they should be noted and are supported just like other MGT disks from e.g. disciple or+D, using the identical 80TDSDD 10 sector 800 format as all the other MGT interfaces.
I suspect the error is caused by over-reliance on the last three characters of a filename as some 1970s legacy hint about the contents. .DSK is widely used for all MGT image formats, and presumably someone from Amstrad-land jumped to conclusions.
To disambiguate these the length of 819200 bytes is a better determinant than whatever the name happens to end with. To be sure, mash up the first 40 sectors on side 0 and make sure there are no multiple bits set in the 80 sector address maps there (two per 512-byte sector) - see https://sinclair.wiki.zxnet.co.uk/wiki/MGT_filesystem