DSK/EDSK file format: Data rate
John Elliott
by this problem: The DSK file format (and other formats, but DSK is the
important one) don't store the data rate or encoding used. This isn't a
problem on emulated Spectrums, CPCs or Joyces, because they always use MFM
encoding and Double Density data rate.
The problem is that the PcW16 uses both High Density and Double Density data
rates, and it depends on not being able to read DD discs if it's using the
HD rate. If I want to emulate this behaviour properly, then the DSK file
needs to say what data rate it's using. For completeness we might as well
have the recording mode (FM or MFM) in there as well.
I've looked over the DSK specification, and it seems that the best place
to put this information is in the Track-Info block (some weird old CP/M
systems apparently use different recording modes on different tracks).
Bytes 12h and 13h are currently unused; so I suggest:
Byte 12h: Data rate.
0 = Unknown
1 = Double Density (180k, 720k, etc.)
2 = High Density (1.2M, 1.4M, etc.)
3 = Extended Density (2.8M)
Byte 13h: Recording mode.
0 = Unknown
1 = FM
2 = MFM
Use of 0 for 'unknown' avoids breaking compatibility with existing DSK
files.
So: Emulator/utility authors: Should this feature be added to the DSK
specification? Or should I create a separate disc image format which
supports multiple data rates / recording modes?
--
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)
Mike Wynne
"John Elliott" <j...@seasip.demon.co.uk> wrote...
> Byte 12h: Data rate.
> 0 = Unknown
> 1 = Double Density (180k, 720k, etc.)
> 2 = High Density (1.2M, 1.4M, etc.)
> 3 = Extended Density (2.8M)
While you're at it, why not include Single Density? - I don't know if
it's used in Sinclair/Amstrad circles, but I've a fair few 90k CP/M
disks knocking around...
MikeW
John Elliott
: "John Elliott" <j...@seasip.demon.co.uk> wrote...
As I understand it, Single Density is the same data rate as Double
Density, but using FM recording mode rather than MFM. In which case,
perhaps
1 = Single / Double Density
2 = High Density
3 = Extended Density
would be more informative.
Andreas Micklei
John Elliott <j...@seasip.demon.co.uk> wrote:
> So: Emulator/utility authors: Should this feature be added to the DSK
> specification? Or should I create a separate disc image format which
> supports multiple data rates / recording modes?
By all means try to extend the existing EDSK format if possible. Having a
new format floating around would only make things more complicated.
Just make shure that the changes are compatible with existing emulators
and still leave room for future enhancements. IMHO your proposal looks
quite reasonable in this respect. To make sure put some test DSKs on
your web page so people can feed them to their favorite emulator or DSK
processing software.
Just my 0.02 EUR.
Andreas Micklei
Woody
wrote:
>Hiho,
>
>John Elliott <j...@seasip.demon.co.uk> wrote:
>> So: Emulator/utility authors: Should this feature be added to the DSK
>> specification? Or should I create a separate disc image format which
>> supports multiple data rates / recording modes?
>
>By all means try to extend the existing EDSK format if possible. Having a
>new format floating around would only make things more complicated.
OTOH, when the current format doesn't come close to allowing proper
emulation at low levels, why not just go right ahead and create a new
format?
Kevin Thacker
"John Elliott" <j...@seasip.demon.co.uk> wrote in message
news:dmnptb...@seasip.demon.co.uk...
[proposed extension to dsk/edsk image format concerning data rate and
recording mode cut]
> So: Emulator/utility authors: Should this feature be added to the DSK
> specification? Or should I create a separate disc image format which
> supports multiple data rates / recording modes?
I have no objection for these extensions to be added to the existing disc
image format; and would be happy to update my specification doc.
But, I also agree with Woody, that the current disc image format is
inadequate and can't describe some copyprotections; a better low level disc
image format may be needed.
Instead of creating our own, what about the "MFM_DISK" image format used on
the Oric emulators? Would this be sufficient, or do we also need to encode
the clock bits into the data? (Clock bits *may* be needed; if the missing
clock bits cause the random sector data found with some copyprotections on
the Amstrad and Spectrum).
Regards,
Kev
--
Unofficial Amstrad WWW Resource
http://andercheran.aiind.upv.es/~amstrad/
Arnold emulator
http://arnold.emuunlim.com/
John Elliott
: Just make shure that the changes are compatible with existing emulators
: and still leave room for future enhancements. IMHO your proposal looks
: quite reasonable in this respect. To make sure put some test DSKs on
: your web page so people can feed them to their favorite emulator or DSK
: processing software.
Right. I've now uploaded some sample files to
<http://www.seasip.info/testdsks.zip>
Kevin Thacker <ams...@aiind.upv.es> wrote:
: But, I also agree with Woody, that the current disc image format is
: inadequate and can't describe some copyprotections; a better low level disc
: image format may be needed.
:
: Instead of creating our own, what about the "MFM_DISK" image format used on
: the Oric emulators?
I can't find a description of this file format anywhere - what sort of
data does it hold?
: Would this be sufficient, or do we also need to encode
: the clock bits into the data?
Perhaps what we want is a disc equivalent of TZX/CDT, where we can store
normal sectors in the same way that we do now, but switch to low-level
bitwise dumps in the case of funny protection schemes.
Oh, and if we do end up designing a new format, then it should include a
'comment' block.
Jonathan Needle
"Kevin Thacker" <ams...@aiind.upv.es> wrote in message
news:btrlf7$vr0$1...@newsg4.svr.pol.co.uk...
> Instead of creating our own, what about the "MFM_DISK" image format used on
> the Oric emulators? Would this be sufficient, or do we also need to encode
> the clock bits into the data? (Clock bits *may* be needed; if the missing
> clock bits cause the random sector data found with some copyprotections on
> the Amstrad and Spectrum).
The UDI format, already used by many (Russian) Spectrum emulators, stores
just that. Rather than storing sectors individually, it stores whole track
dumps.
There is a separate bitmap per track which specifies if a byte in the track
dump has missing clock bits or not.
It's up to the emulator to decode the track and identify the individual
sectors.
Cheers,
Jon.
--
--
Jonathan Needle
Spectaculator Creator
http://www.spectaculator.com/
Philip Kendall
John Elliott <j...@seasip.demon.co.uk> wrote:
>
> So: Emulator/utility authors: Should this feature be added to the DSK
>specification?
Sounds like the right way to handle things to me.
Phil
--
Philip Kendall <pa...@srcf.ucam.org>
http://www.srcf.ucam.org/~pak21/
Nich Campbell
In comp.sys.amstrad.8bit Kevin Thacker <ams...@aiind.upv.es> wrote:
> I have no objection for these extensions to be added to the existing disc
> image format; and would be happy to update my specification doc.
This discussion on extending the DSK format reminds me of McSPE's proposal
to extend it so that games could run automatically, by specifying a
filename to load. Did anything ever result from that proposal?
--
Nicholas 'Nich' Campbell
e-mail : nich <AT> durge <DOT> org
website : http://users.durge.org/~nich/
PGP keys: 0x87BA6D91 (PGP 2.6.x); 0x4F361801 (GnuPG)
J.G.Harston
[snip encoding denstiy, etc. in DSK/EDSK images]
You might be interested in http://www.mdfs.net/Docs/Comp/BBC/FileFormat/RawDisk
where I proposed a raw disk image format that includes the density of each
track.
--
JGH - www.mdfs.net
John Elliott
I'd suggest adding at least a magic number, and probably a header
containing the offset of each track (like DSK has). Here's one way it could
be incorporated:
(The following suggestion is entirely separate from my proposed extensions
to the existing DSK/EDSK formats; it's more aimed at a universal DSK format.
I'd also choose a filetype other than DSK, such as DXK, to avoid confusion.)
* Keep the EDSK header (with a new signature, such as 'EXTEND*2' ).
* For each track, allow the signature to be either 'Track-Info'
(which behaves as now, including the data rate and encoding specs) or
'Track-Dump' (containing a raw track dump as in your proposal).
* Since all tracks have to be a multiple of 256 bytes in length, the real
length of a Raw-Track would need to be stored in its header.
* The DSK header may contain a length entry for one or two more tracks than
the number in header byte 30h. If so, the extra tracks are 'Archive Info'
and 'Hardware Info' blocks (concept cheerfully stolen from TZX/CDT):
00: 'Archiving \r\n'
0C: Spare
10: Length (byte) of first block
11: Type (byte) of first block
12: Text of first block
...
(repeated until length = 0).
The block types would be as in TZX/CDT, plus one extra (FE):
00 - Full Title
01 - Software House / Publisher
02 - Author(s)
03 - Year of Publication
04 - Language
05 - Game/Utility Type
06 - Price
07 - Protection Scheme / Loader
08 - Origin
FE - Boot command (what you have to type to get the disc to boot).
FF - Comment(s)
Hardware info block:
00: 'Hardware \r\n'
0C: Spare
10: Number of records (each is 3 bytes long)
10: List of machines and hardware, as in TZX / CDT. We'd need
to invent a few extra ones for the PCW and PcW16.
John Elliott
: image format; and would be happy to update my specification doc.
OK. Unless anyone contacts me this weekend, I'm going to release a version
of JOYCE that creates disc images with these fields. And after that, it'll
be too late.