Модуль АГАТ-7 для эмулятора Башкирия-2М

Последние несколько дней обсуждаем с b2m возможность поддержки АГАТ-7 в его эмуляторе.
В данный момент модуль Агата оставляет желать лучшего, просто потому, что автор не был знаком с Агатом в реальности.
Со своей стороны постараюсь предоставить все необходимые подробности и неочевидные тонкости.

Обсуждение решили перенести на форум, в отдельную тему - чтоб не засорять основную.

Вообще эмулятор АГАТов для ОС Windows уже существует - автор Олег Одинцов.
http://deka.ssmu.ru/er/agat/Soft/winEmul.shtml
Он сто процентов совместим со всем софтом.
Однако из-за большОго кол-ва эмулируемых плат/устройств и максимального набора функций - иногда
вызывают сложности в настройке и использовании у рядового пользователя.

Для запуска игрушек и подавляющего большинства прикладных программ - достаточно штатной
комплектации Агата в эмуляторе, без всяких лишних настроек и доп. оборудования.
Поэтому замечательный эмулятор b2m - обещает быть весьма и весьма популярным.

После непродолжительной переписки по мылу, решили продолжать тут. Пока разбираемся с поддержкой образов дисков с сайта GARNIZON-а (как основного источника образов).

Цитата:

---

Сообщение от GARNIZON

Какой софт брал? Если от девятки, то может и не работать.

---

Софт от девятки я даже и не пытаюсь брать. Взял .aim из каталога 7 ДОС-эмулятора. В принципе оно работает, но есть ньюанс: копировщик и рапира работают нормально, а вот бейсик весьма требователен к скорости вращения диска. Вообще странно, что там у каждой программы свой драйвер. Получается, что все программы, работающие с дисками, содержали в себе код ДОСа?

Цитата:

---

Сообщение от GARNIZON

уверен что для семерки это лишнее , однако вот:

AIM:
160 дорожек
Дорожка фиксированного размер $1940 (TrkSize800) слов 16 бит.
Следовательно, размер образа: 2068480 байт.

Байты слов хранятся в обратном порядке. Слова анализируются так:
00xx - обычные данные, через регистры IO передается младшая часть
01xx - синхросбой
02xx - конец дорожки (заворот на начало) [читается, но не записывается]
03xx - индекс начало (1 -> 0)
13xx - индекс конец (0 -> 1)

---

Про 00хх и 01хх я и сам догадался, а других байтов не видел. Конец дорожки и без того понятен, по размеру дорожки, а индекс я сделал фиксированный, несколько байтов от начала и конца, предположив, что дорожка дампится с диска сразу после индекса. А несколько индексных маркеров на дорожке - это нонсенс :)

Про ДОС:

Ну это фишка и семёрки и девятки ( у Apple этого нету ). В ПЗУ у машины только маленький системный монитор 2 Кбайт.
Системное ПЗУ (грубо - BIOS) содержит программу первоначального запуска машины, конфигрурирования базовой памяти,
процедуру поиска устройства, с которого можно загрузить операционную систему......

Всё остальное грузится с диска. Сами файлы конечно не имеют кода доса, но все системы имеют конечно.
Смысл в чем - что надо и больше подходит для конкретного случая, то и загружу, не обязательно штатную ДОС.
Агат работает с диском очень быстро, для загрузки в память (при включении) : ДОС системы , языка напрмер бейсик со
своим монитором! и стартовой программы на бейсике - сущие секунды.

Скажем надо в Apple игрушки поиграть - грузим Эпл дос,
Крупные пакеты тоже имеют свои собственные ДОС - такие, как лучше для данного случая.
Как раз именно эта гибкость системы и дает свободу, вплоть до вариантов когда агат начинает изображать из себя
другую ЭВМ : http://deka.ssmu.ru/er/agat/Apps/Onix.shtml

Обрати внимание: любой агат уже с рождения имел флоповод. Всё в системе завязанно на ДОС и любые программы
изначально написаны для работы с диском. Магнитофоном никто не пользовался - а зачем есть диск.
Нет, конечно разъем магнитофон был, но он использовался для например таких случаев:
http://deka.ssmu.ru/er/agat/Apps/Fonograf.shtml
http://deka.ssmu.ru/er/agat/Apps/Picler.shtml

Да, код доса и драйверов был индивидуальным. Почему .... Ну, наверное, каждый автор стремился сделать свою
программу наиболее автономной и не надеялся на других разработчиков. НО! Почти всегда эти досы и драйвера имели
исходники с общими корнями, поэтому ковырятся в них легко - всегда есть место чувству deja vu.

Но насчёт привередливости к скорости - это странно. Я бы сказал так: к скорости привередливы некоторые форматтеры,
особенно те, которые создают защищённые от копирования диски. А просто чтение/запись, особенно на 840кб - никаких
проблем быть не должно: они работают по битам готовности дисковода, и я бы не назвал их логику сильно привередливой.
Разве что у них есть таймауты на случай отказа контроллера или дисковода, но это как электрические пробки: пока явно
ножницы в розетку не сунешь - они не должны срабатывать.


Несколько индексных маркеров на дорожке - нонсенс, это понятно. Но:

- дорожка дампится от индекса только для дисков с защитой (точнее, дампится она от балды, но сигнал индекса запоминается и потом может быть перенесён в aim). Обычные агатовские драйвера сигнал индекса не анализируют
http://zx.pk.ru/showthread.php?t=9812&page=9
и поэтому как его отображать - значения не имеет (если диск не защищён).

- в описании формата aim не случайно чётко оговаривается как и когда должен появляться сигнал индекса в виртуальном
дисководе, как при наличии маркера так и при его отсутствии: диски с защитой могут строится как с явным маркером так и
без него - как мне удобнее. Игнорируя эти правила можно попасть в ситуацию, когда отмеченный как живой диск на сайте
в эмуляторе не заработает.

- маркер конца дорожки тоже может иметь существенное значение. Могу заверить, например, что некоторые сборники
http://deka.ssmu.ru/er/agat/Gamez/Compilat32.shtml
не будут загружаться, если маркер конца дорожки не будет обрабатываться. Понятно, что без него можно было бы
обойтись, но я вводил его не для красоты, а потому что бывают ситуации (при прямой конвертации eim -> aim) когда этот
маркер сильно помогает.

Надо сказать что контроллер 840 Кбайт - вообще штука с интересной историей:
http://zx.pk.ru/showpost.php?p=370591&postcount=166

Обновил эмулятор на сайте, добавлена поддержка новых образов дисков:
*.dsk - посекторная копия диска (140 или 840Кб)
*.aim - специальный формат для нестандартных дисков (правда, пока из служебных байт поддерживается только синхросбой).

Запись на диски пока не поддерживается.

Вопрос к GARNIZON-у: судя по FDSPEED скорость эмуляции процессора достаточно точная, т.е. какой период обращения диска я эмулирую, такой он и показывает (максимум на 1% меньше). Однако если эмулировать один оборот за 200мс, то драйверы не читают диски - не успевают к синхросбою метки данных. Если между маркером сектора и вторым синхросбоем три байта AA, то минимальный период 270мс, а если четыре, то 230мс. А сколько на самом деле байт AA записывается при форматировании?

b2m, а *.NIB и *.IMG образы дисков будут поддерживаться в эмуляторе ?

Я скачал последнюю версию, но там еще нету разделения на
- агат7 +140 в 3 слоте
- агат7 +840 в 5 слоте?

И да, что-то не в порядке ИКП-1 например не грузится автоматом, только после сброса в мониор и C500G...


Щас... Спою..........

Ничего в целом, только по отдельности:

- о каком, на всякий случай, драйвере идёт речь? Чтобы предметнее было. То есть, ИКП-бейсик, РАПИРа, .......... ?

- есть такой вариант: FF&SYNC 95 6a vol track sect 5a aa aa aa aa aa a4 FF&SYNC 6a 95 .....

- там что-то такое было.... В общем, нужно учитывать, что драйвер ждёт синхро, но это ожидание тоже требует времени.

- фрагмент реального диска с ИКП (предположительно форматировался копировщиком ИКП):
AA AA 00+01 00+01 00+01 95 6A 00+00 0B 00+00 5A AA AA AA AA AA A4 00+01 00+01 00+01 6A 95 9B
(числа с "+" - это как бы один шаг: 00+01 - sync, 00+00 - просто ноль)

- фрагмент реального диска (предположительно, форматировался по init hello):
AA AA AA A4 00+01 95 6A FE 27 14 5A AA AA AA AA AA A6 00+01 AA AA AA AA A4 00+01 6A 95

Так что кто как хочет так и форматит.

Тут ещё нужно учитывать, что в реальности, свежеформатированный диск и диск, с перезаписанными полями данных могут отличаться: в т.ч. может проскочить несколько синхро (Тот, который записывался форматтером и при последующей записи. Возможен синхросбой и за счёт разрушения gap-байт).

ИКП-Бейсик-7:

0CFF - A9 20 .. ")." LDA #20
0D01 - 85 26 .. ".." STA 26
0D03 - C6 26 .. "F." DEC 26
0D05 - F0 37 .. "П." BEQ 0D3E
0D07 - 9D 8A C0 "..@" STA C08A, X
0D0A - BD 86 C0 "=.@" LDA C086, X Ждем sync
0D0D - 0A .. .. "." ASL A
0D0E - 30 FA .. ".З" BMI 0D0A
0D10 - BD 84 C0 "=.@" LDA C084, X
0D13 - 20 ED 0A ".М." JSR 0AED Читаем пролог
0D16 - C9 95 .. "I." CMP #95
0D18 - D0 E9 .. "PИ" BNE 0D03
0D1A - 9D 8A C0 "..@" STA C08A, X
0D1D - 20 ED 0A ".М." JSR 0AED
0D20 - C9 6A .. "Iй" CMP #6A
0D22 - D0 DF .. "P_" BNE 0D03
0D24 - A0 02 .. " ." LDY #02
0D26 - 20 ED 0A ".М." JSR 0AED
0D29 - 99 2D 00 "..." STA 2D, Y Читаем поля
0D2C - 88 .. .. "." DEY
0D2D - 10 F7 .. ".В" BPL 0D26
0D2F - 20 ED 0A ".М." JSR 0AED
0D32 - C9 5A .. "Iz" CMP #5A
0D34 - D0 CD .. "PM" BNE 0D03
0D36 - BD 86 C0 "=.@" LDA C086, X Проверяем, что не было сбоя синхро
0D39 - 0A .. .. "." ASL A
0D3A - 10 C7 .. ".G" BPL 0D03
0D3C - 18 .. .. "." CLC
0D3D - 60 .. .. "ю" RTS Выходим, совершенно ничего больше не проверяя и не ожидая


Дальше исполняется примерно 20 команд без обращения к флопу.

Затем ждем поля данных:

0A80 - A0 30 .. " ." LDY #30
0A82 - 9D 8A C0 "..@" STA C08A, X
0A85 - 88 .. .. "." DEY 2 такта
0A86 - F0 56 .. "Пv" BEQ 0ADE 3 такта (или 2 ?)
0A88 - BD 86 C0 "=.@" LDA C086, X 4 такта
0A8B - 0A .. .. "." ASL A 2 такта
0A8C - 30 F7 .. ".В" BMI 0A85 3 такта

Итого, он будет ждать (2 + 3 + 4 + 2 + 3) * 30 = 420 тактов, такт как раз микросекунда, значит столько и ждём. На дорожке обычно байт 7070 примерно, 200000 микросекунд на оборот, получается где-то 30 микросекунд на байт. Получается, за время ожидания может проскочить где-то байт 20, что всяко с запасом при размере GAP в пять-шесть байт. Проверяйте, может я где-то ошибся в цифрах.

---------- Post added at 08:38 ---------- Previous post was at 08:34 ----------

ЗЫ !!! Сейчас сообразил: 7070 байт - это полный цикл форматтера, перекрывающий дорожку (т.е. он пишется не 200, а 203 мкс, чтобы гарантированно переписать старое содержимое).

Размер AIM-дорожки меньше, 6464 байта. Почему так - не помню, но цифра была получена не случайно, я её долго подбирал чтобы работали особо изощренные Бадеровские защиты и креаторы этих защит. Возможно, это связано с тем, что 7070 - это цифра, предполагающая размер синхросбоя как 1 байт, но, возможно, это не так. К сожалению, пока что физический формат записи 840кб дисков никем не описан и не изучен (видимо, кроме разработчика).

Цитата:

---

Сообщение от ZEman

b2m, а *.NIB и *.IMG образы дисков будут поддерживаться в эмуляторе ?

---

Это одно и то-же, *.IMG поддерживаются.

Цитата:

---

Сообщение от GARNIZON

Я скачал последнюю версию, но там еще нету разделения на
- агат7 +140 в 3 слоте
- агат7 +840 в 5 слоте?

---

Да, поленился сделать. Хотелось сначала поддержку образов доделать.

Цитата:

---

Сообщение от GARNIZON

И да, что-то не в порядке ИКП-1 например не грузится автоматом, только после сброса в мониор и C500G...

---

Это который .aim? Он же для девятки вроде? Он у меня и из монитора не грузится. Нулевой сектор грузится, дальнейший блок тоже, а после запуска блока вылетает.

Цитата:

---

Сообщение от GARNIZON

о каком, на всякий случай, драйвере идёт речь?

---

В бейсике.

Цитата:

---

Сообщение от GARNIZON

есть такой вариант: FF&SYNC 95 6a vol track sect 5a aa aa aa aa aa a4 FF&SYNC 6a 95 .....

---

В образах дисков, которые есть у меня, три и четыре байта AA. С пятью будет наверное нормально.

Цитата:

---

Сообщение от GARNIZON

Тут ещё нужно учитывать, что в реальности, свежеформатированный диск и диск, с перезаписанными полями данных могут отличаться: в т.ч. может проскочить несколько синхро (Тот, который записывался форматтером и при последующей записи. Возможен синхросбой и за счёт разрушения gap-байт).

---

Вот тут наверное собака и порылась. Как я понимаю, когда диск переставал читаться в бейсике, его переписывали на чистый отформатированный диск копировщиком (который читает вообще без проблем). А на новом диске перед вторым синхросбоем достаточно байт АА.

Цитата:

---

Сообщение от GARNIZON

Получается, за время ожидания может проскочить где-то байт 20, что всяко с запасом при размере GAP в пять-шесть байт.

---

Там проблема в другом: когда выполнение доходит до ожидания синхросбоя, он (синхросбой) уже пролетел и считывается следующий за ним байт.

> Там проблема в другом: когда выполнение доходит до ожидания синхросбоя, он (синхросбой) уже пролетел и считывается следующий за ним байт.

???? А внимательное чтение документации на контроллер уже имело место?

Синхросбой не может пролететь: это флажек, реализованный RS-триггером. Он устанавливается при обнаружении ошибки чтения контроллером и сбрасывается программно. Драйвер сбрасывает его либо до ожидания sync (перед чтением поля адреса) либо после получения sync (если sync найден, но сигнатура за ним неверна и драйвер ожидает следующий sync), но не потому что пришел "следующий байт".

На всякий случай:
http://deka.ssmu.ru/er/agat/Reading/docs/es5323.txt
http://deka.ssmu.ru/er/agat/Reading/fl800k.shtml


> Это который .aim? Он же для девятки вроде? Он у меня и из монитора не грузится. Нулевой сектор грузится, дальнейший блок тоже, а после запуска блока вылетает.

AIM - формат контроллера 840 кб. Независимо от того, в какую архитектуру он воткнут. Есть порядком загрузочных образов 840 для семёрки. Семёрка в комплектации с 840 кб дисководом была вполне распространена.

> Вот тут наверное собака и порылась. Как я понимаю, когда диск переставал читаться в бейсике, его переписывали на чистый отформатированный диск копировщиком (который читает вообще без проблем). А на новом диске перед вторым синхросбоем достаточно байт АА.

Это находка :) Переписывать не читающиеся диски :)
Не, я -то приводил пример хорошо работающих дисков.

---------- Post added at 07:07 ---------- Previous post was at 07:03 ----------

... В каком виде эмулятор имеет отладку? Мож мне его глянуть живьём, если там по шагам можно пройти драйвер?

Сейчас перечитал вот это:

> Вот тут наверное собака и порылась. Как я понимаю, когда диск переставал читаться в бейсике, его переписывали на чистый отформатированный диск копировщиком (который читает вообще без проблем). А на новом диске перед вторым синхросбоем достаточно байт АА.


Пришла в голову мысль, может тебе показалось что бывают такие случаи когда при многократном стирании\записи
на диск контроллер валяет дурака и портит диск? типа становится недостаточно байт АА :)

НЕТ!!! хоть сколько раз это сделать не испортит. С чего бы бейсику перестать читать диск?

И потом к Агату не подходит выражение "его переписывали на чистый отформатированный диск" ,
Специального режима "форматирование" в контроллере агата нет. Есть режим записи и чтения. Если драйвер не выключает режим записи в течение всего оборота диска и планомерно фигачит подряд все поля, включая синхросбои - это условно называется форматированием. Если же он только находит поля адреса и затем переключается в режим записи, пишет поле данных и затем сразу возвращает контроллер в режим чтения - это называется запись сектора. Разница между операциями довольно условная.
Поэтому на агате были популярны такие штуки, как, например, копировщик дисков (посекторный), которыйформатировал и записывал данные в один проход. Т.е. при форматировании - создании полей адреса - сразу записывались заполненные поля данных. За один оборот диска !

Цитата:

---

Сообщение от GARNIZON

???? А внимательное чтение документации на контроллер уже имело место?

Синхросбой не может пролететь: это флажек, реализованный RS-триггером. Он устанавливается при обнаружении ошибки чтения контроллером и сбрасывается программно. Драйвер сбрасывает его либо до ожидания sync (перед чтением поля адреса) либо после получения sync (если sync найден, но сигнатура за ним неверна и драйвер ожидает следующий sync), но не потому что пришел "следующий байт".

---

Это уже учтено, как раз в последней версии и переделал.
Перед циклом ожидания синхросбоя этот триггер сбрасывается. Но к этому моменту синхросбой уже был. Проблема в том, что в образе только один синхросбой, а реально, перед меткой данных, будет несколько: самый первый - это разрушенный байт AA, а последний - записанный программно. Часть дорожки, от первого синхросбоя перед меткой данных до последнего, в образе отсутствует - её похоже мне и не хватает.

А программно записанный сбой будет на фиксированном расстоянии от конца маркера сектора, т.к. записывается программно. Таким образом мои рассуждения о переписывании на новый диск копировщиком - неверны.

Цитата:

---

Сообщение от GARNIZON

AIM - формат контроллера 840 кб. Независимо от того, в какую архитектуру он воткнут. Есть порядком загрузочных образов 840 для семёрки. Семёрка в комплектации с 840 кб дисководом была вполне распространена.

---

У тебя на сайте есть пункт меню ИКП, оттуда я и скачивал.

Цитата:

---

Сообщение от GARNIZON

В каком виде эмулятор имеет отладку? Мож мне его глянуть живьём, если там по шагам можно пройти драйвер?

---

???? А внимательный просмотр меню уже имел место? :)
По клавишам в отладчике есть подсказка - F1.
В строке статуса отладчика есть пара чисел, могут оказаться весьма полезными: количество тактов от последней точки останова и номер строки от последнего кадрового СИ.

На сайте в разделе ИКП пока только для агат-9 (просто всё не успеваю), там так и указано в текстовике. Я всегда однозначно пишу для чего это, или прям на сцылке или в текстовике в архиве.

вот для семёрки например:

http://deka.ssmu.ru/er/agat/Gamez/Compilat03.shtml
http://deka.ssmu.ru/er/agat/Apps/Tfp.shtml

Вообще я немного запутался:
не очень понимаю фразы, например: "Часть дорожки, от первого синхросбоя перед меткой данных до последнего, в образе отсутствует - её похоже мне и не хватает". Как понять "в образе отсутствует"? уже говорил, что образы рабочие. три примера я привёл этих полей.

>???? А внимательный просмотр меню уже имел место?

Я не случайно спросил есть ли отладка: я имел ввиду не то, что лежит на поверхности и видно в меню, а что-то дополнительное. Олег, например, когда отлаживал свой эмулятор, вытаскивал из него текстовые дампы-трассы. Я так понимаю, та версия, которую ты распространяеш, этого делать не умеет или умеет, но это - скрытая возможность.
Вот я и спросил есть ли такое. Есть отладочное окно проца, но для отладки дисковода этого маловато. Ты сам как-то подсчитываеш отдельные проходящие от дисковода байты, возможно, в режиме отладки самого эмулятора. Но чтобы этим воспользоваться, нужна среда разработки, исходные коды и умение этим всем пользоваться.
Т.е. - практически - такой возможности у меня нет.

Цитата:

---

Сообщение от GARNIZON

Вообще я немного запутался:
не очень понимаю фразы, например: "Часть дорожки, от первого синхросбоя перед меткой данных до последнего, в образе отсутствует - её похоже мне и не хватает". Как понять "в образе отсутствует"? уже говорил, что образы рабочие. три примера я привёл этих полей.

---

Во всех трёх примерах между байтами track sect 5A и 6A 95 достаточно много байт AA и байтов с синхросбоем. В имеющихся у меня образах почему-то лишь три-четыре вместе с синхросбоем. Вот они и не работают.

Цитата:

---

Сообщение от GARNIZON

Я не случайно спросил есть ли отладка: я имел ввиду не то, что лежит на поверхности и видно в меню, а что-то дополнительное.

---

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

Цитата:

---

Сообщение от GARNIZON

Ты сам как-то подсчитываеш отдельные проходящие от дисковода байты, возможно, в режиме отладки самого эмулятора.

---

В режиме отладки самого эмулятора я редко смотрю содержимое буферов. Приходящие от дисковода байты я смотрю в команде чтения регистра данных при трассировке драйвера в отладчике эмулятора.

Добавил просмотр текущей дорожки. Чтобы посмотреть, надо нажать Ctrl+M в отладчике и выбрать fdd.track. В строке статуса отображается позиция "под головкой", точнее, позиция байта, который только что считался и находится в регистре данных.

Для образов 840Кб *.img оборот диска эмулируется за 270мс, при этом достаточно трёх байт AA, последний из которых с синхросбоем (именно такой img у меня на сайте лежит).

Для 840Кб *.aim - 230мс, при этом достаточно четырёх байт между концом метки сектора и началом метки данных. Образ с таким количеством байт у меня называется ikp_7.aim.

А вот для *.dsk я формирую пять байтов AA. При этом драйвер бейсика нормально работает и при 200мс оборота диска.

Выкладываю здесь только плагин, его нужно скопировать в каталог Plugins.

В nib-файлах, которые были до aim, то есть nib800, действительно три байта gap-поле между AF и DF.
Ну так вот их Voldemar тогда делал.
Почему именно три байт - не помню уже, может быть где-то в техдоках так писалось в каких-то.
Его эмулятору под MS-DOS это глубоко безразлично, потому что он вообще не был привязан потактово ни к реальному времени ни между выполнением команд и вращением дисковода: это совершенно открыто указано в его описании. Потому что никому кроме скоростеметра дисковода до этой привязки дела нет. Просто все действия были так подогнаны, чтобы
всё везде чётко работало. Но nib800 уже закрытый формат , не поддерживается и не обосновывается. А в aim у тебя вроде всё правильно. А если и не правильно - то разбирайся в тактах: я все цифры привёл

В общем, мысль уже высказана:
dsk можеш делать как тебе удобнее,
nib800 больше не поддерживается,
а AIM: "Для 840Кб *.aim - 230мс, при этом достаточно четырёх байт между концом метки сектора и началом метки данных" -
вообще-то в моих примерах пять байт. Ты считаеш , что достаточно даже 4-х, но на скорости явно заниженной (230 вместо 200)......

230 потому что типа дорожка убегает уже? и проц не успевает к началу поля данных?
Что-то со временем, или проц медленный или что-то с дисководным временем.

Т.е. ты поле адреса обработал, дальше ещё несколько команд на чтение поля данных, а дисковод в это время gap-байты пропускает. Вот в реале должно быть так, что проц уже ждёт поле данных, а дисковод только подъезжает к нему , а у тебя почему-то наоборот.

Цитата:

---

Сообщение от GARNIZON

вообще-то в моих примерах пять байт. Ты считаеш , что достаточно даже 4-х, но на скорости явно заниженной (230 вместо 200)......

---

Да, я брал aim из ДОСовского эмулятора, там 4 и при 230мс работает.

Цитата:

---

Сообщение от GARNIZON

230 потому что типа дорожка убегает уже? и проц не успевает к началу поля данных?
Что-то со временем, или проц медленный или что-то с дисководным временем.

Т.е. ты поле адреса обработал, дальше ещё несколько команд на чтение поля данных, а дисковод в это время gap-байты пропускает. Вот в реале должно быть так, что проц уже ждёт поле данных, а дисковод только подъезжает к нему , а у тебя почему-то наоборот.

---

Весь сыр-бор только из-за того, что при менее 5 байт AA на 200мс не успевает. Но если реально было 5 байт и больше, то можно эту тему закрыть.

Кстати, прикольно - драйвер бейсика у меня в эмуляторе при 230мс-обороте (c aim) работает явно быстрее, чем при 200мс (c dsk).

Цитата:

---

Сообщение от b2m

Весь сыр-бор только из-за того, что при менее 5 байт AA на 200мс не успевает. Но если реально было 5 байт и больше, то можно эту тему закрыть.

---

Можно и закрыть. Однако замечу - в реальности было по разному, и 3 и 4 и 5 и .... даже 10.
Зависит от форматтера и от того, если диск только что отформатирован и от случайностей при последующей записи.
GAP поле нужно как раз для того, чтобы компенсировать ошибки скорости дисковода, т.е. оно по определению может менятся.

Цитата:

---

Сообщение от GARNIZON

На дорожке обычно байт 7070 примерно, 200000 микросекунд на оборот, получается где-то 30 микросекунд на байт. Получается, за время ожидания может проскочить где-то байт 20, что всяко с запасом при размере GAP в пять-шесть байт. Проверяйте, может я где-то ошибся в цифрах.

---------- Post added at 08:38 ---------- Previous post was at 08:34 ----------

ЗЫ !!! Сейчас сообразил: 7070 байт - это полный цикл форматтера, перекрывающий дорожку (т.е. он пишется не 200, а 203 мкс, чтобы гарантированно переписать старое содержимое).

Размер AIM-дорожки меньше, 6464 байта. Почему так - не помню, но цифра была получена не случайно, я её долго подбирал чтобы работали особо изощренные Бадеровские защиты и креаторы этих защит. Возможно, это связано с тем, что 7070 - это цифра, предполагающая размер синхросбоя как 1 байт, но, возможно, это не так. К сожалению, пока что физический формат записи 840кб дисков никем не описан и не изучен (видимо, кроме разработчика).

---

Значит, скорость записи выше стандартных 250 кбит/с -- от 260 до 280 (= 6500 ... 7000 байт на дорожке).

видимо, потому, что сигнал шины "2 МГЦ", из которого получается тактовая "4 МГц" для работы контроллера 840К, на самом деле 14,3 МГц / 7 =~ 2,043 МГц?

так и есть (https://zx-pk.ru/threads/23428-agat-...tor/page2.html)

Цитата:

---

контроллер работает с 255.357 Кбит/с (14.3 МГц / 7 / 8).

---

Цитата:

---

Сообщение от b2m

Весь сыр-бор только из-за того, что при менее 5 байт AA на 200мс не успевает. Но если реально было 5 байт и больше, то можно эту тему закрыть.

---

скорее всего, это ошибка формирования исходных образов AIM, и размеры GAP2/GAP3 нужно исправлять, иначе длина формируемой дорожки получается сильно больше реальности (~6500 байт)

например, копировщик IKP9 форматирует с GAP2 = 5, GAP3 = 22