![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Итак, Roland D-20. Осциллоскопирование показало, что на флоп пишутся данные в виде импульсов длительностью около 2мкс и периодом следования, тоже кратным 2мкс. Параллельно флопу был подключен эмулятор - от синтезатора брались только сигналы выборки дисковода и собственно поток бит на запись. Таким образом удалось получить слепок данных, посылаемых синтезатором в дисковод при форматировании дорожки.
( Read more... )
( Read more... )
КМД УКНЦ - собран и заработал
May. 15th, 2009 11:32 amДым пока не пошел. Слайды будут позже.
Имеем 2 потока MFM-бит. Один снят с отформатированного на машине-пациенте диска, другой формируется программно мегадрайвом. При этом с первого, естественно, машина-пациент грузится, со второго не может или не хочет.
( Информация к размышлению )
Имеем 2 потока MFM-бит. Один снят с отформатированного на машине-пациенте диска, другой формируется программно мегадрайвом. При этом с первого, естественно, машина-пациент грузится, со второго не может или не хочет.
( Информация к размышлению )
УКНЦ и дискеты
Apr. 24th, 2009 10:24 amЭто отформатированная на УКНЦ дорожка 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)
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)
write precompensation
Apr. 20th, 2009 10:20 pmМануал к 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.
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Еще отловилась замечательная блоха.
Ради ускорения процесса формирования сектора (и в нарушение стандарта) контрольные суммы заголовка сектора и собственно данных писались в него прямо как есть. Это замечательно работало на непустых секторах, а на пустых так же замечательно сбоило (последовательность 00000000 00000000 сбивала с толку Paula).
Ради ускорения процесса формирования сектора (и в нарушение стандарта) контрольные суммы заголовка сектора и собственно данных писались в него прямо как есть. Это замечательно работало на непустых секторах, а на пустых так же замечательно сбоило (последовательность 00000000 00000000 сбивала с толку Paula).
Floppy .MFM image
Feb. 6th, 2008 12:43 pmФормат .MFM файла - 160 треков, каждый длиной 12800 байт. В битах это 102400 бит на дорожку, получается даже с небольшим запасом (для DD диска теоретическая плотность записи 1000000 бит на дорожку).
Размер файла 2048000 байт, загрузка-выгрузка ~16 секунд.
Размер файла 2048000 байт, загрузка-выгрузка ~16 секунд.
про запись
Jan. 23rd, 2008 07:14 pmС режимом записи на Амиге все довольно просто: даже если нужно записать всего один сектор, Амига всегда пишет всю дорожку целиком. Выглядит это так: сначала весь трек читается в память, затем в него вносятся изменения (сектор или несколько секторов), затем весь трек записывается обратно.
На PC все иначе. Записать дорожку целиком тоже можно, но только при ее форматировании. При необходимости записать сектор контроллер сперва ищет на дорожке метку требуемого сектора, затем в определенный момент переключает головку в режим записи и "впечатывает" сектор в требуемое место.
Теперь о грустном. Чтобы принимать DD MFM поток, требуется отрабатывать каждую единичку как минимум за 4us. Это худший вариант, два других - 6us и 8us. Запись в DRAM кушает 2.5us, ужиматься дальше практически некуда. Работая по прерываниям, теряем целую микросекунду только на прерывание и возврат из него.
Можно попробовать работать не по прерываниям, развернув байтовый цикл в линию, но тогда всплывает проблема синхронизации с потоком. Нужно обдумать.
На PC все иначе. Записать дорожку целиком тоже можно, но только при ее форматировании. При необходимости записать сектор контроллер сперва ищет на дорожке метку требуемого сектора, затем в определенный момент переключает головку в режим записи и "впечатывает" сектор в требуемое место.
Теперь о грустном. Чтобы принимать DD MFM поток, требуется отрабатывать каждую единичку как минимум за 4us. Это худший вариант, два других - 6us и 8us. Запись в DRAM кушает 2.5us, ужиматься дальше практически некуда. Работая по прерываниям, теряем целую микросекунду только на прерывание и возврат из него.
Можно попробовать работать не по прерываниям, развернув байтовый цикл в линию, но тогда всплывает проблема синхронизации с потоком. Нужно обдумать.
on sector checksums
Feb. 28th, 2007 09:54 pmCнято с дискетки 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)
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)
megadrive256
Jan. 22nd, 2007 05:48 pm
Постепенно дорисовывается плата для нового варианта эмулятора флопа. Камень ATmega2560, 16MHz, SIMM-72 в качестве памяти.Постарался напихать в схему чего только не - и IDE разъем (вдруг захочется подключить CF), и пищалку, и два варианта ЖК-индикатора, I2C и параллельный.
Все это еще предстоит программировать.
PC 720K track
Mar. 1st, 2006 12:02 am24 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 ...
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 ...
(no subject)
Jan. 5th, 2006 08:27 pmПосмотрел на результат работы avr-gcc и вспомнил эпизод из "Пятого элемента", где главный злец возвращается на корабль ("Все приходится делать самому"). Взял шашку в руки, учинил оптимизацию кодирования с 1m 45s до 1m 30s.
Понравилось.
Повозился еще - 1m 13s и дальше уже просто некуда.
Чувак, который загоняет A500 в FPGA (кстати, он уже и звук освоил), посоветовал наплевать на стопроцентное следование MFM стандарту и схалявить, зная, как хост читает треки (просто выкидывает каждый второй бит). Вся, мол, надежда на то, что PLL в Paula не успеет растеряться.
Результат - 35 секунд!
Понравилось.
Повозился еще - 1m 13s и дальше уже просто некуда.
Чувак, который загоняет A500 в FPGA (кстати, он уже и звук освоил), посоветовал наплевать на стопроцентное следование MFM стандарту и схалявить, зная, как хост читает треки (просто выкидывает каждый второй бит). Вся, мол, надежда на то, что PLL в Paula не успеет растеряться.
Результат - 35 секунд!
о франкенштейне
Dec. 18th, 2005 08:27 pmПроект в процессе перевода на более-менее цивилизованные рельсы (ну там двустороняя ПП с маской и шелкографией, DRAM в виде отдельной микросхемы, а не старинного SIMM-30pin и так далее). DRAM нужного мне объема уже не бывает пятивольтовой, только 3.3в. С другой стороны, ATmega128 при 3.3в работает только на 8МГц, так что о двукратном повышении скорости чтения SD/MMC можно забыть. С третьей стороны, в ATmega128 статической RAM вчетверо супротив прототипа, что позволит дико соптимизировать скорость кодирования треков.
В плане конструктива зреет мысль выполнить плату по посадочным размерам дисковода 3.5", вынеся в виде торчащей дискеты дочернюю плату с LCD, кнопками и разъемом MMC.
В плане конструктива зреет мысль выполнить плату по посадочным размерам дисковода 3.5", вынеся в виде торчащей дискеты дочернюю плату с LCD, кнопками и разъемом MMC.
эмулятор дисковода
Dec. 1st, 2005 09:38 amВчерашнее корпение до полуночи над моим франкенштейном не прошло бесследно: отрабатывается STEP, отдается правильная дорожка.
Правда, пока дорожки только четные (правильней говорить о STEP в смысле цилиндров), но это вопрос времени - прикрутить в tight loop еще и SIDE. Tight loop работает изумительно: генерирует MFM той чистоты и правильности, какие в природе практически не встречаются, одновременно рефреша DRAM и еще подшивая по мелочи.
Еще из мелочей - наладить грамотный обход секторов файла по кластерам, а не так, как сейчас. Ну там добавить поддержку каталогов кроме корневого, и, мбыть, LFN.
Пожалуй, самая большая проблема - нехватка вычислительной мощности. На MFM-кодирование трека уходит почти секунда (8MIPS). То есть .ADF всасывается секунд за 20, а затем можно идти курить минуты на три. Или попробую вариант с прекодированными .MFM файлами, или нужно смотреть в сторону ARM с тактовой под сотню мегагерц.
Правда, пока дорожки только четные (правильней говорить о STEP в смысле цилиндров), но это вопрос времени - прикрутить в tight loop еще и SIDE. Tight loop работает изумительно: генерирует MFM той чистоты и правильности, какие в природе практически не встречаются, одновременно рефреша DRAM и еще подшивая по мелочи.
Еще из мелочей - наладить грамотный обход секторов файла по кластерам, а не так, как сейчас. Ну там добавить поддержку каталогов кроме корневого, и, мбыть, LFN.
Пожалуй, самая большая проблема - нехватка вычислительной мощности. На MFM-кодирование трека уходит почти секунда (8MIPS). То есть .ADF всасывается секунд за 20, а затем можно идти курить минуты на три. Или попробую вариант с прекодированными .MFM файлами, или нужно смотреть в сторону ARM с тактовой под сотню мегагерц.
