tnt23: (amiga)
IMAG0974 by tnt23
IMAG0974, a photo by tnt23 on Flickr.

И пяти лет не прошло, как отдал в проявку версию 1.2 с кое-какими улучшениями и дополнениями. Тем временем используемые в дизайне гнезда SD вышли из употребления и перестали выпускаться.

tnt23: (amiga)
Понемногу реанимирую стюардессу:


Битовый поток генерируется SPI1, причём в режиме TI. В режиме SPI выдача байт не бесшовная.
tnt23: (amiga)
Итак, Roland D-20. Осциллоскопирование показало, что на флоп пишутся данные в виде импульсов длительностью около 2мкс и периодом следования, тоже кратным 2мкс. Параллельно флопу был подключен эмулятор - от синтезатора брались только сигналы выборки дисковода и собственно поток бит на запись. Таким образом удалось получить слепок данных, посылаемых синтезатором в дисковод при форматировании дорожки.
Read more... )
tnt23: (amiga)
Дым пока не пошел. Слайды будут позже.

Имеем 2 потока MFM-бит. Один снят с отформатированного на машине-пациенте диска, другой формируется программно мегадрайвом. При этом с первого, естественно, машина-пациент грузится, со второго не может или не хочет.
Информация к размышлению )
tnt23: (amiga)
Это отформатированная на УКНЦ дорожка 00:

mfmdisk.exe -i track30.mfm
Format: IBM PC
Track 0/0: 10 sectors per track
Order of sectors: 0 1 2 3 4 5 6 7 8 9
Sector gap: 299 274 274 304 304 304 304 273 304 304 bits (std 368)
Data gap: 222 222 192 192 192 192 222 192 192 192 bits (std 176)


А это дорожка 00, формируемая Megadrive256 при загрузке .BKD образа в память:

mfmdisk.exe -i empty.mfm
Format: IBM PC
Track 0/0: 10 sectors per track
Order of sectors: 0 1 2 3 4 5 6 7 8 9
Sector gap: 1160 368 368 368 368 368 368 368 368 368 bits (std 368)
Data gap: 176 176 176 176 176 176 176 176 176 176 bits (std 176)
tnt23: (amiga)
Мануал к Catweasel срывает покров тайны с write precompensation:

The magnetic flux transitions on a floppy disk tend to move slightly farther apart if they are recorded very close together, thus lengthening the short intervals and shortening the long ones, a phenomenon sometimes called bit-shifting. When a disk is recorded, the disk controller ordinarily applies write precompensation to reduce this effect; that is, it makes the short intervals extra short and the long ones correspondingly longer, especially on the inner, higher-numbered tracks.

In general, disks need more precompensation on the inner (higher-numbered) tracks than on the outer tracks, and this effect is more pronounced for larger disks where the difference in length between the inner and outer tracks is greater. The default value of 140ns for all tracks seems to work reasonably well on 3.5-inch and 5.25-inch disks, though it is surely not optimal.

Update. Роскошный документ 1980 года "ENCODING/DECODING TECHNIQUES DOUBLE FLOPPY DISC CAPACITY" by John F. Hoeppner and Larry H. Wall, Shugart Accociates, Inc.

MFM quirks

Feb. 16th, 2008 05:13 pm
tnt23: (amiga)
Еще отловилась замечательная блоха.
Ради ускорения процесса формирования сектора (и в нарушение стандарта) контрольные суммы заголовка сектора и собственно данных писались в него прямо как есть. Это замечательно работало на непустых секторах, а на пустых так же замечательно сбоило (последовательность 00000000 00000000 сбивала с толку Paula).
tnt23: (amiga)
Формат .MFM файла - 160 треков, каждый длиной 12800 байт. В битах это 102400 бит на дорожку, получается даже с небольшим запасом (для DD диска теоретическая плотность записи 1000000 бит на дорожку).
Размер файла 2048000 байт, загрузка-выгрузка ~16 секунд.
tnt23: (amiga)
С режимом записи на Амиге все довольно просто: даже если нужно записать всего один сектор, Амига всегда пишет всю дорожку целиком. Выглядит это так: сначала весь трек читается в память, затем в него вносятся изменения (сектор или несколько секторов), затем весь трек записывается обратно.
На PC все иначе. Записать дорожку целиком тоже можно, но только при ее форматировании. При необходимости записать сектор контроллер сперва ищет на дорожке метку требуемого сектора, затем в определенный момент переключает головку в режим записи и "впечатывает" сектор в требуемое место.

Теперь о грустном. Чтобы принимать DD MFM поток, требуется отрабатывать каждую единичку как минимум за 4us. Это худший вариант, два других - 6us и 8us. Запись в DRAM кушает 2.5us, ужиматься дальше практически некуда. Работая по прерываниям, теряем целую микросекунду только на прерывание и возврат из него.
Можно попробовать работать не по прерываниям, развернув байтовый цикл в линию, но тогда всплывает проблема синхронизации с потоком. Нужно обдумать.
tnt23: (amiga)
Cнято с дискетки 720к.
Track 0, side 0, sector 0, header CRC: CA 6F
Track 0, side 0, sector 1, header CRC: 9F 3C
Track 0, side 0, sector 2, header CRC: AC 0D
CRC формируется по варианту CCITT X25 с полиномом 0x1021 (или 0x11021?).
CRC 512 байт пустого сектора: 5144 9454 (DA 6E)
tnt23: (amiga)
Постепенно дорисовывается плата для нового варианта эмулятора флопа. Камень ATmega2560, 16MHz, SIMM-72 в качестве памяти.
Постарался напихать в схему чего только не - и IDE разъем (вдруг захочется подключить CF), и пищалку, и два варианта ЖК-индикатора, I2C и параллельный.
Все это еще предстоит программировать.
tnt23: (Default)
24 x 0xAA
3 x 0x4489
AA AA AA AA AA A9 2A A4 52 44 94 55 12 54
21 x 0x9254
24 x 0xAA
3 x 0x4489
55 45 54 45 25 12 49 2A 92 A5 12 92 92 51 24 AA A4 AA A5 25 24 54 A5 25 2A AA AA A4 AA A4 AA A9 2A AA AA A4 95 2A AA AA 44 AA AA 91 55 49 2A A5 2A AA AA 49 2A AA AA A4 AA ...
tnt23: (amiga)
Посмотрел на результат работы avr-gcc и вспомнил эпизод из "Пятого элемента", где главный злец возвращается на корабль ("Все приходится делать самому"). Взял шашку в руки, учинил оптимизацию кодирования с 1m 45s до 1m 30s.
Понравилось.
Повозился еще - 1m 13s и дальше уже просто некуда.
Чувак, который загоняет A500 в FPGA (кстати, он уже и звук освоил), посоветовал наплевать на стопроцентное следование MFM стандарту и схалявить, зная, как хост читает треки (просто выкидывает каждый второй бит). Вся, мол, надежда на то, что PLL в Paula не успеет растеряться.
Результат - 35 секунд!
tnt23: (Default)
Проект в процессе перевода на более-менее цивилизованные рельсы (ну там двустороняя ПП с маской и шелкографией, DRAM в виде отдельной микросхемы, а не старинного SIMM-30pin и так далее). DRAM нужного мне объема уже не бывает пятивольтовой, только 3.3в. С другой стороны, ATmega128 при 3.3в работает только на 8МГц, так что о двукратном повышении скорости чтения SD/MMC можно забыть. С третьей стороны, в ATmega128 статической RAM вчетверо супротив прототипа, что позволит дико соптимизировать скорость кодирования треков.
В плане конструктива зреет мысль выполнить плату по посадочным размерам дисковода 3.5", вынеся в виде торчащей дискеты дочернюю плату с LCD, кнопками и разъемом MMC.
tnt23: (Default)
Вчерашнее корпение до полуночи над моим франкенштейном не прошло бесследно: отрабатывается STEP, отдается правильная дорожка.

Правда, пока дорожки только четные (правильней говорить о STEP в смысле цилиндров), но это вопрос времени - прикрутить в tight loop еще и SIDE. Tight loop работает изумительно: генерирует MFM той чистоты и правильности, какие в природе практически не встречаются, одновременно рефреша DRAM и еще подшивая по мелочи.

Еще из мелочей - наладить грамотный обход секторов файла по кластерам, а не так, как сейчас. Ну там добавить поддержку каталогов кроме корневого, и, мбыть, LFN.

Пожалуй, самая большая проблема - нехватка вычислительной мощности. На MFM-кодирование трека уходит почти секунда (8MIPS). То есть .ADF всасывается секунд за 20, а затем можно идти курить минуты на три. Или попробую вариант с прекодированными .MFM файлами, или нужно смотреть в сторону ARM с тактовой под сотню мегагерц.

Profile

tnt23: (Default)
tnt23

April 2016

S M T W T F S
     12
3456789
1011 1213141516
17181920212223
24252627282930

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 20th, 2017 06:16 pm
Powered by Dreamwidth Studios