Requires: Apple IIGS with 3MB+ and a platinum 3.5" drive. Note: As of 9/7/15 all known emulators fail to run this properly due to incorrect emulation and timing of the Sony drive microcontroller (RDY line). -- Usage -- Note: These programs can crash GSOS and should be run from Prodos8. They are tools-free and directly write to 3MB of memory from bank $02 through bank $2C. Ram disks may also be overwritten and should be disabled before use. "-DiskImage" to read the disk in s5,d1, with timestamps, and display in SHR. "-CalcTime" to convert the timestamps to per-nibble cycle times. "call -151" to enter the monitor and inspect/modify/extract data. "\01<2/0.ffffp" to find the start of side 0 track 1 (end of track 0). "\d5 a 96\<2/0.2710p" to find all sector headers in side 0 track 0. To look at timestamps for specific nibble data, add $16 to the bank address: "18/0.2710" to view the timestamps for all nibbles on side 0 track 0. You can copy tracks/sectors to bank 0 and save them: "\0/1000<2/0.2710m" to move side 0 track 0 to bank 0. "bsave mydiskS0T0,a$1000,l$2710" to write it to a drive. -- DiskImage -- This utility will read all the bits off a 3.5" disk and display them on the SHR screen. As it displays the disk nibbles, it also stores the bit image to memory along with a timestamp of how many 1MHz cycles were required to read each nibble. The timestamp indicates which nibbles have extra hidden 0 bits in front of them, and whether the nibble is valid or abnormal (due to float-bit protection or a failing disk). This is useful for copying protected programs, backing up failing disks, and accurate usage of custom DOS disks on modern emulators. This program relies on some of my custom GS DOS routines to control the IWM and 3.5" drive. It demonstrates extremely fast disk I/O and head stepping in a tiny amount of code (512 bytes). -- Data format -- Disk image data is written to memory at $02/0000-$16/FF00. Side 0, tracks 0-79 are stored first in ascending order, followed by side 1 tracks 79-0 in descending order. The first byte of each track contains the track number 0-79, followed by disk nibble bytes ($80-$FF), as read from the IWM. Timestamp data is written to memory $18/0000-$2C/FF00. Each timestamp byte corresponds 1-to-1 with each image byte and is simply the Mega II 1MHz counter read from $C02F and stored to memory. The first timestamp byte of each track indicates the time the track read was started. Note: the high bit of each timestamp has the video scan line even/odd bit. Since scan lines take ~64 microseconds, and typical disk nibble reads take ~16us, you'll normally see 4 timestamps with the high bit set, followed by 4 timestamps with the high bit 0. 10-bit sync nibbles take 20us to read and will often have 3 timestamps with the same high bit. -- CalcTime -- After reading the disk image into memory with DiskImage, run CalcTime to convert the absolute 1MHz timestamps into a relative, per-byte 1MHz cycle count which is much easier to inspect and understand. The 1MHz Mega II cycles are actually 980ns in length. See Apple GS TN 39 for more on the Mega II 1MHz timer at $C02F. Normal 8-bit nibble data takes ~16us to read and has timestamp cycle times of $0F, $10, or $11. 10-bit self-sync $FF nibbles will have times like $13, $14, $15. There is some timing jitter both between the drive and the IWM, and between the IWM and the Mega II $C02F counter, so timestamps can vary by ~+/-2 us. CalcTime does not alter the nibble data, and just converts the data timestamps to a relative cycle time. It preserves the high bit (scan line) when converting each timestamp. CalcTime does not alter the first timestamp of each track, leaving it as an absolute $C02F time. -- Road map -- Future versions will support 5.25" disks, and a more compact "track bit array" format which can be easily written to disk or used by emulators. Add support for explicit track synchronization data for sync & spiral copy protection schemes. Ultimately, I'd like to see this technology and these techniques integrated into existing Apple II copy and image utilites like fEDD-up and ADT. I'd also like to use this tech in a data-recovery utility for failing disks. -JBrooks 9/7/2015