-
Notifications
You must be signed in to change notification settings - Fork 0
/
dti.txt
130 lines (98 loc) · 4.88 KB
/
dti.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
.DTI - Deep Thought disk Image
==============================
DTI images contain a byte-level decoding of disk created by the Deep Thought
disk interface for the Jupiter Ace. For further details see:
http://www.jupiter-ace.co.uk/hardware_DeepThought.html
File Format
-----------
Image Header
offset length description
0 4 signature "H2G2"
4 1 tracks per side (40 or 80, taken from DOS catalogue)
5 1 disk sides (1 or 2)
6 2 track block size in bytes (typically 2304)
8 ? start of track data
Tracks are stored in the order cyl 0 head 0, cyl 1 head 0, ...
Track Header
offset length description
0 1 flags: b0: framing/parity error, b1: block checksum error
1 2 used data length in bytes
3 ? track data, zero-padded up to track block size
Data Storage
------------
Rather than using a traditional FDC chip, Deep Thought uses a Motorola MC6850
UART for its data read and write operations. This makes the media incompatible
with PC floppy controllers, and requires special tools to access data on them.
Data is encoded using an FM-like system, but with the bit values reversed. Two
flux reversals represent a 0, and a reversal followed by no reversal represents
a 1. The bitcell size is 4us in a 300rpm drive.
Within the bitstream it uses an asynchronous system similar to RS232-C, where
1 is idle, and a transition to 0 represents the start bit for a frame. This is
followed by 8 data bits, a parity bit (odd parity is used), and the return to
idle for a stop bit.
DOS Behaviour
-------------
Writing process:
- motor on and wait 20ms head settle time
- wait for index signal
- enable write line
- wait for 1ms, to write stream of idle '1' bits
- write 6 bytes of FF (255) sync and 1 byte of 2A (42) as block header
- write each byte in data block to UART
- write 8-bit block checksum, calculating from sum of block bytes
- wait for 1ms for writing to complete, and more idle
- disable write line
Reading process:
- motor on and wait 20ms head settle time
- wait for index signal
- read byte and loop until FF (255) found
- read byte and check for 2A (42), loop waiting for FF (255) if not
- read requested count of bytes in data block
- read checksum byte, test against sum of block bytes
Image Considerations
--------------------
The lack of traditional FDC on-disk structures makes it difficult to represent
the content in a neutral way, without resorting to storing the bitstream. This
image format is very much tuned to known DOS usage. It is also intended to
provide simple access to the content for emulators and other tools.
To avoid too much junk in the disk image, track data is trimmed at both ends.
The start of the stored block begins at the FF (255) sync bytes, ignoring any
bad data generated due to false start bits. The end of the stored block is cut
at the first long idle detected inside a valid data block. This is also done
because the remainder of the track is not cleared, and still contains whatever
was last written to the disk.
Each byte read from the original source can generate a parity or framing error.
Rather than store an error bit for each byte, the image stores an overall
error status for the track. Bit 0 is set for parity or framing errors, and for
convenience, also if the block checksum is incorrect. DOS rejects tracks read
with an error, so it was felt sufficient to use a track-level status.
The 4us bitcell size gives a potential 25000 bits per track in a 300rpm drive.
With 11 bits per UART byte frame, that gives a maximum capacity of 2272 bytes
(not including the DOS wait before and after each block). For that reason the
image header suggests the rounded 2304 bytes for the track block size.
Creating DTI Images
-------------------
The current dumping process requires either a KryoFlux or SuperCard Pro USB
board, connected to the appropriate drive type. The dumped image data is passed
through SAMdisk for conversion to a DTI image:
For KryoFlux:
SAMdisk track00.0.raw image.dti --ace
For SuperCard Pro:
SAMdisk image.scp image.dti --ace
If 40-track media is dumped using an 80-track drive you'll need to add -d to
the command-line options to double-step the head between source tracks.
Using DTI Images
----------------
At this time there are no Jupiter Ace emulators that support the Deep Thought
interface, so the DTI images can't be used directly. However, the included
Python script can extract individual files from them:
./extract.py image.dti
This extracts files to a 'image.files' sub-directory.
Even these raw files are not ready for emulator use. Creating TAP files from
them requires constructing a suitable Ace tape header, calculating some system
variable values active at the point of saving. This has not yet been achieved.
The final 16 bytes of each data file appears to contain meta-data related to
(but not directly compatible with) the required header values.
---
Simon Owen
simon@simonowen.com