Kegs —> GSport —> GSplus. .woz images [message #381254] |
Mon, 18 February 2019 16:39 |
|
Originally posted by: Leon Sargent
Having a look at the documentation for all three, GSport can handle "raw", ..dsk, .po, 2IMG, 5.25" ".nib" images, most Mac Diskcopy images and partitioned images. The .dsk and .po formats you often find on the web are really "raw" formats, and so they work fine. GSport uses the host file permissions to encode the read/write status of the image. GSport can open any image file compressed with gzip (with the extension ".gz") automatically as a read-only disk image.
I am not seeing support for .woz files and I know this takes time and a lot of effort and perhaps it may just be that I don’t understand .woz format.
Would .woz format fit the definition of “raw” as listed from the GSport documentation?
I am currently using rasbpi Jessie with GSplus on a raspi 3 model b.
Leon
|
|
|
|
Re: Kegs —> GSport —> GSplus. .woz images [message #381256 is a reply to message #381255] |
Mon, 18 February 2019 17:50 |
|
Originally posted by: Leon Sargent
Thank you for that answer.
I have seen the .woz releases appear to be 8bit [ via Twitter ]. So. Would I be correct in assuming 8bit emulators like Virtual ][ would have been updated to support .woz format and 16 bit emulators, as you answered, do not support .woz format at this time.
Leon
|
|
|
Re: Kegs —> GSport —> GSplus. .woz images [message #381271 is a reply to message #381256] |
Tue, 19 February 2019 09:05 |
David Schmidt
Messages: 993 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On 2/18/19 5:50 PM, Leon Sargent wrote:
> Thank you for that answer.
>
> I have seen the .woz releases appear to be 8bit [ via Twitter ]. So. Would I be correct in assuming 8bit emulators like Virtual ][ would have been updated to support .woz format and 16 bit emulators, as you answered, do not support .woz format at this time.
Each emulator has to build that support in - it's not dependent on
bit-width, it's dependent on developer time/interest/malleability of the
emulator platform.
|
|
|
Re: Kegs —> GSport —> GSplus. .woz images [message #381280 is a reply to message #381271] |
Tue, 19 February 2019 11:09 |
|
Originally posted by: fadden
On Tuesday, February 19, 2019 at 6:05:55 AM UTC-8, schmidtd wrote:
> Each emulator has to build that support in - it's not dependent on
> bit-width, it's dependent on developer time/interest/malleability of the
> emulator platform.
While we're on the subject, is there a compelling reason for CiderPress to support .woz? I've been ignoring it since its primary purpose is to preserve original disks with any non-standard formatting (i.e. copy-protection) intact. That's not really CP's forte -- anything worth storing as .woz rather than .do/.po probably wouldn't be readable by CP anyway.
Is there a compelling use-case for storing standard-format disks in .woz format?
|
|
|
Re: Kegs —> GSport —> GSplus. .woz images [message #381281 is a reply to message #381280] |
Tue, 19 February 2019 11:25 |
David Schmidt
Messages: 993 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On 2/19/19 11:09 AM, fadden wrote:
> On Tuesday, February 19, 2019 at 6:05:55 AM UTC-8, schmidtd wrote:
>> Each emulator has to build that support in - it's not dependent on
>> bit-width, it's dependent on developer time/interest/malleability of the
>> emulator platform.
>
> While we're on the subject, is there a compelling reason for CiderPress to support .woz? I've been ignoring it since its primary purpose is to preserve original disks with any non-standard formatting (i.e. copy-protection) intact. That's not really CP's forte -- anything worth storing as .woz rather than .do/.po probably wouldn't be readable by CP anyway.
>
> Is there a compelling use-case for storing standard-format disks in .woz format?
It's entirely possible to store a completely normal disk image in .woz,
but as you suggest, there's not a great many reasons to incur all the
overhead. The metadata wrapper is interesting, but again not useful in
interpreting the ultimate data that in in the tracks.
You'd get some nice benefits like preambles and volume IDs. But what to
do when things went off the rails is an interesting question. Only mark
as writable those tracks that are normal in the context of the
filesystem? Each protection scheme could ultimately become a
"filesystem" of its own - and there could be read/write rules specific
to that system.
|
|
|