Agat-7 (Apple II USSR) 800kb disk support

HxC Floppy emulator support for all others computers...
Post Reply
kapitan-u
Posts: 33
Joined: Fri Mar 07, 2014 6:08 am

Agat-7 (Apple II USSR) 800kb disk support

Post by kapitan-u » Sun Mar 09, 2014 6:30 am

Hi!

Here is another disk format for HxC team consideration.
Agat-7 is an USSR Apple II clone, which was available with 140kb GCR disks and
propitiatory MFM 800kb disks.

Agat-7 MFM disk details:

MFM, 300rpm, 250000 bps

5"25 80 Tracks, 21 Sectors per track, Sector 256 bytes, 2 sides, 860160 bytes formatted

un-Formatted track capacity 6464 bytes.

Track format
1. GAP 20x 0xAA bytes
2. 21 sectors of the following format:
2.1 desync
2.2 Address field: 0x95, 0x6A, volume number (1 byte), track number (1 byte), sector number (1 byte), 0x5A
2.3 GAP 3x 0xAA bytes
2.4 desync
2.5 Data field: 0x6A, 0x95, 256 Data Bytes, CRC(1 byte), 0x5A
2.6 0xFE ??? volume number?
2.7 GAP 34x 0xAA bytes

There is disk image files that contain payload only:

.dsk, .do - DOS 3.3 Sector sequence
(0, 7, 14, 6, 13, ...)
.po - ProDOS Sector sequence
(0, 8, 1, 9, 2, 10,...)

However, due to nature of software controlled FDC, the most important is AIM image file format.


AIM file encode each track with 6464 16 bit words.
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
aa 00 x20 bytes GAP
00 01 desync
95 00 6a 00 address field marker
fe 00 Volume
00 00 Track
00 00 Sector
5a 00 address field end

aa 00 x3 bytes GAP
00 01 desync
6a 00 95 00 data field marker
xx 00 x256 bata bytes
xx 00 CRC
5a 00 data field end
fe 00 ??

aa 00 x34 bytes GAP
next sector address marker

Kind regards,
Oleksandr Kapitanenko

Jeff
Site Admin
Posts: 6464
Joined: Fri Oct 20, 2006 12:12 am
Location: Paris
Contact:

Re: Agat-7 (Apple II USSR) 800kb disk support

Post by Jeff » Sun Mar 09, 2014 9:02 am

Is the Agat-7 disk formlat compatible with the Apple II ? If yes this should already work.

kapitan-u
Posts: 33
Joined: Fri Mar 07, 2014 6:08 am

Re: Agat-7 (Apple II USSR) 800kb disk support

Post by kapitan-u » Sun Mar 09, 2014 7:15 pm

There is two formats. One is 140kb is compatible with Apple II, but it is not very common.
Here I'm talking about proprietary MFM 800kb, which is only usable for this type of the computer.

Jeff
Site Admin
Posts: 6464
Joined: Fri Oct 20, 2006 12:12 am
Location: Paris
Contact:

Re: Agat-7 (Apple II USSR) 800kb disk support

Post by Jeff » Sun Mar 09, 2014 7:56 pm

kapitan-u wrote:There is two formats. One is 140kb is compatible with Apple II, but it is not very common.
Here I'm talking about proprietary MFM 800kb, which is only usable for this type of the computer.
Do you have some kind of device able to do a stream dump, like kryoflux?
Maybe you can send me one floppy disk ?

kapitan-u
Posts: 33
Joined: Fri Mar 07, 2014 6:08 am

Re: Agat-7 (Apple II USSR) 800kb disk support

Post by kapitan-u » Mon Mar 10, 2014 1:21 am

I have no disks, only the actual computer. For Agat-7 each disk will be different, so support of AIM files, as described above, is crucial.

kapitan-u
Posts: 33
Joined: Fri Mar 07, 2014 6:08 am

Re: Agat-7/9 (Apple II USSR) 840kb disk support

Post by kapitan-u » Mon May 12, 2014 11:45 pm

Agath (Агат) is working with HxC now. Please see the description and software attached.

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.

================================================================================================
Attachments
agath-to-hfe.rar
(18.06 KiB) Downloaded 429 times

kapitan-u
Posts: 33
Joined: Fri Mar 07, 2014 6:08 am

Re: Agat-7 (Apple II USSR) 800kb disk support

Post by kapitan-u » Mon May 19, 2014 5:13 am

I'm attaching V1 final with write support including upd file for HxC with Agath write support
(thanks to Jean-François DEL NERO !!!).

Revised DOS track format after write support implementation:

DOS Track format
1. GAP1 13x 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 5x 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 22x 0xAA bytes
3. There is NO GAP4, after last sector track is exactly 6250 bytes
Attachments
agath-to-hfe.rar
(70.02 KiB) Downloaded 446 times

kapitan-u
Posts: 33
Joined: Fri Mar 07, 2014 6:08 am

Re: Agat-7 (Apple II USSR) 800kb disk support

Post by kapitan-u » Thu Feb 26, 2015 9:04 pm

I'm attaching V2 software with many improvements.
Now default output format is HFE V2 which allows correct track looping over the disk index.
Attachments
agath-to-hfe V2.zip
(75.12 KiB) Downloaded 288 times

tour
Posts: 7
Joined: Sat Feb 22, 2014 10:38 pm

Re: Agat-7 (Apple II USSR) 800kb disk support

Post by tour » Sun Mar 15, 2015 5:02 pm

Are you from Moscow?

shattered
Posts: 4
Joined: Wed Oct 17, 2018 9:58 pm

Re: Agat-7 (Apple II USSR) 800kb disk support

Post by shattered » Tue Jun 25, 2019 10:57 pm

kapitan-u wrote:
Thu Feb 26, 2015 9:04 pm
Now default output format is HFE V2 which allows correct track looping over the disk index.
Where is this V2 format documented? I am working on Agat emulation in MAME and it supports only HFE revision 0 (version 1 in the Perl script).

Post Reply