kapitan-u
13.05.2014, 02:22
Работает!
Подробности и софт тут.
Aghat 840k
MFM, 300rpm, 250000 bps
5"25 80 Tracks, 21 Sectors per track, Sector 256 bytes, 2 sides, 860160 bytes formatted
un-Formatted track capacity 6250 bytes.
================================================== ==============================================
DOS Track format
1. GAP1 24x 0xAA bytes
2. 21 sectors of the following format:
2.1 Desync 0xA1
2.2 0xFF may be any byte, not available sor software
2.2 Address field:
0x95, 0x6A (2 byte address field mark),
volume number (1 byte, default 0xFE),
Track number (1 byte 0x00 - 0x14),
Sector number (1 byte),
0x5A (1 byte End of address field mark)
2.3 GAP 3x 0xAA bytes
2.4 Desync 0xA1
2.5 0xFF may be any byte, not available sor software
2.6 Data field:
0x6A, 0x95 (2 byte data field mark),
256 Data Bytes,
CRC(1 byte),
0x5A (1 byte End of data field mark)
2.7 GAP3 24x 0xAA bytes
3. After last sector intead of GAP4 there is GAP4 13x 0xAA bytes
Agath is using Apple 2 Disk checksum algorithm.
Despite of being called "simple arithmetic sum" is is more complicated:
function CalcCRC(const d: tSec): Byte;
var c: Word; n: Byte;
begin
c:=0;
for n:=0 to 255 do begin
if c>255 then begin inc(c); c:=c and 255 end;
inc(c,d[n]);
end;
CalcCRC:=c and 255;
end;
Sector numbering is 0..20, Sector order and interleave is not important. Usual sector order is 0..20
Address field has no disk side information. Tracks are numbered 0..159 and present on disk in following order:
Track 0, Side 0: Track 0
Track 0, Side 1: Track 1
Track 1, Side 0: Track 2
Track 1, Side 1: Track 3
And so on.
This is done for simple Apple DOS usage with 840k disks.
It has one interesting side effect: 140k disk images may be transferred to 840k disks
By copying sectors 0..16 of each track and leaving sectors 17..20 empty.
VTOC and Catalog structures of 140k disk will be pointing only to valid
Track/Sector pairs and disk will be fully functional in 840k drive.
================================================== ==============================================
DSK Image file information
Files contain payload for DOS formatted disks.
840k DSK files
- 256 bytes header
- 128 byte epilogue
- 4 byte epilogue
- clean 860160 files with NO header or epilogue
140k DSK files
- 128 byte epilogue
- 4 byte epilogue
- clean 143360 files with NO header or epilogue
in of above payload stored on following order:
840K
Track 0, Sector 0,.... Track 0, Sector 20,
Track 1, Sector 0,.... Track 1, Sector 20,
and so on.
140K
Track 0, Sector 0,.... Track 0, Sector 15,
Track 1, Sector 0,.... Track 1, Sector 15,
and so on.
================================================== ==============================================
Agath FCD is 100% software driven, so software is capable to:
- write any data on FDD track, with one exception.
In order Desync sequence to be correct and detectable by FDC during the read cycle
software must put 0xA4 to FDC data register before issuing Desync command
and write one extra byte after Desync. This extra byte is usually 0xFF, but may be of any value.
- read any data from FDD track, with one exception.
Byte following after Desync is invisible for software
Also, Index signal is may be or may be not used by software.
Due to FDC design, timing is very important (issue is similar to Apple 2 FDC).
Many Agath programs exploit FDC capabilities for copy protection purposes.
================================================== ==============================================
AIM file encode each track with 6464 16 bit words.
Track/Side order: bottom side, top side, next track.
LSB - data, MSB - A attribute
A=0x01 - desync
A=0x80 - desync
A=0x03 - index mark start
A=0x13 - index mark end
A=0x02 - end of the track
If index mark is missing then index pulse assumed to start at 0 byte and end at 30 byte.
AIM file example:
Track start
0xAA 0x00 x48 bytes GAP
0x00 0x01 desync
0x95 0x00 address field marker byte 1
0x6A 0x00 address field marker byte 2
0xFE 0x00 Volume
0x00 0x00 Track
0x00 0x00 Sector
0x5A 0x00 address field end
0xAA 0x00 x3 bytes GAP
0xFF 0x01 desync
0x6A 0x00 data field marker byte 1
0x95 0x00 data field marker byte 2
0xXX 0x00 x256 data bytes
0xXX 0x00 CRC ( 1 byte simple sum of 256 data bytes )
0x5A x000 data field end
0xAA 0x00 x24 bytes GAP
next sector address marker
AIM files are crafted to work with software Agath simulators.
6464 is way more than 6250 bytes of MFM track.
My speculation is, that software simulators are lacking correct CPU-FCD-FDD timing
and AIM file manually crafted. There is other problems from file to file.
For instance, Desync is encoded at list in 3 different ways:
(0x00 0x01), (0xA4 0x00, 0x00, 0x01), (0xA4 0x00 0xFF 0x00 0x00 0x01)
Before MFM encoding for HxC the following tasks must be accomplished:
- All Desync sequences
(0x00 0x01), (0xA4 0x00, 0x00, 0x01), (0xA4 0x00 0xFF 0x00 0x00 0x01)
must be replaced with
(0xA4, 0x01, 0xFF, 0x00)
- All gap's bigger than 5 (adjustable option) bytes must be found and total gap length calculated.
Intelligent state machine for that purpose must execute correct processing of
invalid Desynk+Mark sequences, data blocks at index pulse position, and data hidden in gap's
- AIM track truncated according to track end command and real track length determined,
it will be still way over 6250 bytes
- Index pulse position determined according AIM Index start command
- Track rotated in order Index pulse to be at beginning of the track always
- If track rotation split the gap, then redistribute GAP1/GAP4 and calculate new length for each gap
- As adjustable option another track rotation is implemented to avoid data blocks to be at index pulse position
- Find the last gap bigger than 5 bytes
- Calculate gap deflation rate in order to shrink the track to 6250 bytes
- Shrink the track to 6250 bytes by decreasing big gaps, redistributing rounding error over many and
doing final rounding error correction on the last gap
================================================== ==============================================
HxC Information
http://hxc2001.free.fr/floppy_drive_emulator/
http://www.lotharek.pl/
Emulator is using pre-encoded data MFM stored in hfe container files.
Due to complicated nature of AIM file processing, implementing Agath support in HxC PC software is not feasible.
A suite of Perl utilities has been developed:
hfe-agath-decode.pl - for HFE decoding and verification
agath-dsk-to-hfe.pl - for DSK to HFE conversion
agath-aim-to-hfe.pl - for AIM to HFE conversion
agath-dsk-to-hfe.pl
# Encoding data from Agat DSK file to HxC hfe
#
# 840k DSK files supported:
# - 256 bytes header
# - 128 byte epilogue
# - 4 byte epilogue
# - clean 860160 files with NO header or epilogue
#
# 140k DSK files supported
# - 128 byte epilogue
# - 4 byte epilogue
# - clean 143360 files with NO header or epilogue
#
# Usage:
# agath-dsk-to-hfe.pl <dsk file> <hfe file>
agath-aim-to-hfe.pl
# Encoding data from Agat AIM file to HxC hfe
#
# Supported AIM commands
# 0x00 Payload
# 0x01 DESYNC
# 0x80 DESYNC
# 0x03 Index Pulse Start
# 0x02 End of Track
# 0x13 Index Pulse End
#
# Usage:
# agath-aim-to-hfe.pl <aim file> <hfe file> [<debug mode>] [<debug track>]
#
# Debug modes:
#
# 'AIM' Initial analysis after AIM read
# 'GAP' After DESYNC expansion and GAP count
# 'DEF' After GAP deflation
# 'MFM' MFM Encoding
#
# Debug track is assuming Agath / Apple 2 track numbering
#
hfe-agath-decode.pl
# Decoding MFM stream from HxC hfe files one track at a time.
# Only Agath MFM encoding supported
# On Agath track 17 ( track 8 side 1 ) VTOC and CATALOG is decoded
#
# Usage:
#
# Assuming Track 0 Side 0
# hfe-agath-decode.pl <hfe file>
#
# Assuming Agath / Apple 2 Track number
# hfe-agath-decode.pl <hfe file> <Agath track number>
#
# Physical disk track number and side number
# hfe-agath-decode.pl <hfe file> <track number> <side number>
#
Sample output of
hfe-agath-decode.pl ikp7.hfe 17 > ikp7-T17.txt
is provided.
================================================== ==============================================
Подробности и софт тут.
Aghat 840k
MFM, 300rpm, 250000 bps
5"25 80 Tracks, 21 Sectors per track, Sector 256 bytes, 2 sides, 860160 bytes formatted
un-Formatted track capacity 6250 bytes.
================================================== ==============================================
DOS Track format
1. GAP1 24x 0xAA bytes
2. 21 sectors of the following format:
2.1 Desync 0xA1
2.2 0xFF may be any byte, not available sor software
2.2 Address field:
0x95, 0x6A (2 byte address field mark),
volume number (1 byte, default 0xFE),
Track number (1 byte 0x00 - 0x14),
Sector number (1 byte),
0x5A (1 byte End of address field mark)
2.3 GAP 3x 0xAA bytes
2.4 Desync 0xA1
2.5 0xFF may be any byte, not available sor software
2.6 Data field:
0x6A, 0x95 (2 byte data field mark),
256 Data Bytes,
CRC(1 byte),
0x5A (1 byte End of data field mark)
2.7 GAP3 24x 0xAA bytes
3. After last sector intead of GAP4 there is GAP4 13x 0xAA bytes
Agath is using Apple 2 Disk checksum algorithm.
Despite of being called "simple arithmetic sum" is is more complicated:
function CalcCRC(const d: tSec): Byte;
var c: Word; n: Byte;
begin
c:=0;
for n:=0 to 255 do begin
if c>255 then begin inc(c); c:=c and 255 end;
inc(c,d[n]);
end;
CalcCRC:=c and 255;
end;
Sector numbering is 0..20, Sector order and interleave is not important. Usual sector order is 0..20
Address field has no disk side information. Tracks are numbered 0..159 and present on disk in following order:
Track 0, Side 0: Track 0
Track 0, Side 1: Track 1
Track 1, Side 0: Track 2
Track 1, Side 1: Track 3
And so on.
This is done for simple Apple DOS usage with 840k disks.
It has one interesting side effect: 140k disk images may be transferred to 840k disks
By copying sectors 0..16 of each track and leaving sectors 17..20 empty.
VTOC and Catalog structures of 140k disk will be pointing only to valid
Track/Sector pairs and disk will be fully functional in 840k drive.
================================================== ==============================================
DSK Image file information
Files contain payload for DOS formatted disks.
840k DSK files
- 256 bytes header
- 128 byte epilogue
- 4 byte epilogue
- clean 860160 files with NO header or epilogue
140k DSK files
- 128 byte epilogue
- 4 byte epilogue
- clean 143360 files with NO header or epilogue
in of above payload stored on following order:
840K
Track 0, Sector 0,.... Track 0, Sector 20,
Track 1, Sector 0,.... Track 1, Sector 20,
and so on.
140K
Track 0, Sector 0,.... Track 0, Sector 15,
Track 1, Sector 0,.... Track 1, Sector 15,
and so on.
================================================== ==============================================
Agath FCD is 100% software driven, so software is capable to:
- write any data on FDD track, with one exception.
In order Desync sequence to be correct and detectable by FDC during the read cycle
software must put 0xA4 to FDC data register before issuing Desync command
and write one extra byte after Desync. This extra byte is usually 0xFF, but may be of any value.
- read any data from FDD track, with one exception.
Byte following after Desync is invisible for software
Also, Index signal is may be or may be not used by software.
Due to FDC design, timing is very important (issue is similar to Apple 2 FDC).
Many Agath programs exploit FDC capabilities for copy protection purposes.
================================================== ==============================================
AIM file encode each track with 6464 16 bit words.
Track/Side order: bottom side, top side, next track.
LSB - data, MSB - A attribute
A=0x01 - desync
A=0x80 - desync
A=0x03 - index mark start
A=0x13 - index mark end
A=0x02 - end of the track
If index mark is missing then index pulse assumed to start at 0 byte and end at 30 byte.
AIM file example:
Track start
0xAA 0x00 x48 bytes GAP
0x00 0x01 desync
0x95 0x00 address field marker byte 1
0x6A 0x00 address field marker byte 2
0xFE 0x00 Volume
0x00 0x00 Track
0x00 0x00 Sector
0x5A 0x00 address field end
0xAA 0x00 x3 bytes GAP
0xFF 0x01 desync
0x6A 0x00 data field marker byte 1
0x95 0x00 data field marker byte 2
0xXX 0x00 x256 data bytes
0xXX 0x00 CRC ( 1 byte simple sum of 256 data bytes )
0x5A x000 data field end
0xAA 0x00 x24 bytes GAP
next sector address marker
AIM files are crafted to work with software Agath simulators.
6464 is way more than 6250 bytes of MFM track.
My speculation is, that software simulators are lacking correct CPU-FCD-FDD timing
and AIM file manually crafted. There is other problems from file to file.
For instance, Desync is encoded at list in 3 different ways:
(0x00 0x01), (0xA4 0x00, 0x00, 0x01), (0xA4 0x00 0xFF 0x00 0x00 0x01)
Before MFM encoding for HxC the following tasks must be accomplished:
- All Desync sequences
(0x00 0x01), (0xA4 0x00, 0x00, 0x01), (0xA4 0x00 0xFF 0x00 0x00 0x01)
must be replaced with
(0xA4, 0x01, 0xFF, 0x00)
- All gap's bigger than 5 (adjustable option) bytes must be found and total gap length calculated.
Intelligent state machine for that purpose must execute correct processing of
invalid Desynk+Mark sequences, data blocks at index pulse position, and data hidden in gap's
- AIM track truncated according to track end command and real track length determined,
it will be still way over 6250 bytes
- Index pulse position determined according AIM Index start command
- Track rotated in order Index pulse to be at beginning of the track always
- If track rotation split the gap, then redistribute GAP1/GAP4 and calculate new length for each gap
- As adjustable option another track rotation is implemented to avoid data blocks to be at index pulse position
- Find the last gap bigger than 5 bytes
- Calculate gap deflation rate in order to shrink the track to 6250 bytes
- Shrink the track to 6250 bytes by decreasing big gaps, redistributing rounding error over many and
doing final rounding error correction on the last gap
================================================== ==============================================
HxC Information
http://hxc2001.free.fr/floppy_drive_emulator/
http://www.lotharek.pl/
Emulator is using pre-encoded data MFM stored in hfe container files.
Due to complicated nature of AIM file processing, implementing Agath support in HxC PC software is not feasible.
A suite of Perl utilities has been developed:
hfe-agath-decode.pl - for HFE decoding and verification
agath-dsk-to-hfe.pl - for DSK to HFE conversion
agath-aim-to-hfe.pl - for AIM to HFE conversion
agath-dsk-to-hfe.pl
# Encoding data from Agat DSK file to HxC hfe
#
# 840k DSK files supported:
# - 256 bytes header
# - 128 byte epilogue
# - 4 byte epilogue
# - clean 860160 files with NO header or epilogue
#
# 140k DSK files supported
# - 128 byte epilogue
# - 4 byte epilogue
# - clean 143360 files with NO header or epilogue
#
# Usage:
# agath-dsk-to-hfe.pl <dsk file> <hfe file>
agath-aim-to-hfe.pl
# Encoding data from Agat AIM file to HxC hfe
#
# Supported AIM commands
# 0x00 Payload
# 0x01 DESYNC
# 0x80 DESYNC
# 0x03 Index Pulse Start
# 0x02 End of Track
# 0x13 Index Pulse End
#
# Usage:
# agath-aim-to-hfe.pl <aim file> <hfe file> [<debug mode>] [<debug track>]
#
# Debug modes:
#
# 'AIM' Initial analysis after AIM read
# 'GAP' After DESYNC expansion and GAP count
# 'DEF' After GAP deflation
# 'MFM' MFM Encoding
#
# Debug track is assuming Agath / Apple 2 track numbering
#
hfe-agath-decode.pl
# Decoding MFM stream from HxC hfe files one track at a time.
# Only Agath MFM encoding supported
# On Agath track 17 ( track 8 side 1 ) VTOC and CATALOG is decoded
#
# Usage:
#
# Assuming Track 0 Side 0
# hfe-agath-decode.pl <hfe file>
#
# Assuming Agath / Apple 2 Track number
# hfe-agath-decode.pl <hfe file> <Agath track number>
#
# Physical disk track number and side number
# hfe-agath-decode.pl <hfe file> <track number> <side number>
#
Sample output of
hfe-agath-decode.pl ikp7.hfe 17 > ikp7-T17.txt
is provided.
================================================== ==============================================