Вид для печати
cy6, я просто пишу все байты, которые подсовывает компьютер, признак синхробайта игнорирую. Соответственно и обратно выдаю все байты. Разбор на сектора и прочее делает РК ДОС. Размер трека 3125 байт, 300 оборотов в минуту.
Но это я сделал для быстроты реализации. Если делать RDI, то просто сектора на 400Кб.
Цитата:
Сообщение от Pyk
Но если не знать реальных длин секторов (а они бывают меньше 512, как минимум в последнем секторе файла), тогда не собрать файл как надо, ведь так?Цитата:
Сообщение от uart
Плюс, хотелось бы совместимости с эмуляторами, или возможности конвертации в формат для эмуляторов. Настоящих и будущих.
Выходит, мне как минимум надо сохранять длину и считанную контрольную сумму для каждого сектора. Остальные служебные поля предопределены.
cy6, что-то я не обращал внимания, что сектор может уменьшаться, сейчас проверю.
- - - Добавлено - - -
Да, действительно длину сектора надо хранить. А вот контрольную сумму не обязательно, ее можно рассчитать на ходу.
Да уж, тогда формат "без служебных структур", очевидно, не получится...
Я тоже буду реализовывать в эмуляторе поддержку ДОС, надо будет нам все-таки определиться с форматом образа диска.
Стоит ли что-то хранить коме длин секторов? В каком виде хранить длины? Хранить ли карту здоровья в образе либо в отдельном файле? Есть ли смысл в хранении другой служебной информации информации, как в rkdisk?
Есть соображения?
Это как это плавающий размер сектора? Ану как понадобиться большой сектор в место малого записать?
Насколько я понимаю, с эмулятором связаны две вещи:Цитата:
Сообщение от Pyk
1) Ему даются скорее всего образы исправных дисков. Неисправные нужны видимо для ручного вытаскивания нужной инфы.
2) Эмулятор выполняет код ДОСа, а тот код читает служебные структуры сектора из порта ввода, он ожидает их. Генерировать ли их на лету или считывать из файла, это вопрос реализации.
Если говорить о простом образе, то длины можно хранить в виде отдельной таблицы в конце 400кб, в виде LE words. Что либо связанное со здоровьем диска, только у неисправных дисков, после таблицы длин. Завершать файл можно сигнатурой, после таблицы длин или после необязательной карты здоровья.
Завершающую сигнатуру, можно взять что то типаКарту здоровья, в виде таблицы считанных КС, либо просто битовая карта как VTOS. Начало любых структур (таблиц) можно тоже предварять простой двухбайтовой сигнатурой и длиной блока (Type|Length|Value). Начало любого блока выравнивать на границу 512 байт.Код:'RK86DISK', 0
- - - Добавлено - - -
Вот, кстати, скрин работы программы.
Скрин
Время считывания диска 2м 10с.
Запуск производится из коммандера на SD карточке. Внизу ">", это приглашение модифицированного монитора, с директивой "U", запускающей загрузку с SD без длинной последовательности "R...G".
Все исходники на программу будут открытые, по выпуску первой версии с законченным форматом RDI.
cy6, а может быть, раз уж разбор на сектора делает сама ДОС, все-таки хранить все подряд, как это и сделал uart, и не усложнять без необходимости формат образа?
Кстати, я тоже не совсем понимаю, как происходит перезапись секторов уменьшенного размера? Может быть, перезаписываются дорожки целиком? Можете пояснить?
Насколько я понимаю, при форматировании сектор имеет размер 512 байт. Таким образом, резервируется место. Далее, в сектор записывается любое количество байт (не более 512) и сразу за этой плавающей длиной КС (word) сектора. Весь трэк переписывать не требуется, благодаря аппаратной синхронизации на первый байт после синхробайта.Цитата:
Сообщение от Pyk
Я не совсем понимаю, как у него организован трэк. Длина выходит больше, чем если считать по формату из журнала Радио #1, 1993.Цитата:
Сообщение от Pyk
По журналу, служебная информация 42 байта (включая синхробайты и R0, R1) плюс максимум 512 байт. Пять секторов (512 + 42) * 5 = 2770 байт. Остается только гадать, что скрывается за 3125 байтами, возможно в журнале описано не все?
Ну вот, например, начало файла RK86DOS29.rkdisk
Пять синхробайтов, как по журналу и вдруг шесть нулевых байт вместо пяти, перед адресной меткой заголовка сектора.Код:00000000 06 06 06 06 06 00 00 00 00 00 00 EA D3
Вложение 57549
Ага, то, что резервируется место - хорошо, проще будет с образом.
А что касается формата трека - беру пока небольшой таймаут на изучение вопроса...
cy6, uart имеет в виду, что 3125 байт - это общая длина трека. При скорости записи 125000 бит/с (промежуток времени между битами 8 мкс) и скорости вращения диска 300 об/мин как раз получится максимум 3125 байт на трек. Умножаем на количество треков и получаем 500000 байт - именно столько и резервируется для файла. Естественно, между секторами могут быть промежутки.
Подозреваю, что 5 нулевых байт - это примерное значение. Может быть больше, а может и меньше - в зависимости от того, как долго РК ДОС готовится к следующей операции, но в любом случае с запасом, чтобы успеть сделать необходимые действия при чтении. Видимо, ДОС, после того, как будет готова к чтению, ждет адресную метку и игнорирует все другие значения после синхробайта, ей не критичны именно 5 нулевых байтов. Не совсем также понимаю, почему иногда 5 синхробайтов дополняются в конце байтом 0D. Надо изучать код ДОС.
В эмуляторе uart, очевидно, существует привязка к скорости вращения диска, поэтому все тайминги примерно соответствуют реальной работе с дискетой. Существующий формат образа также позволяет зафиксировать реальное положение секторов на треке и промежутки между ними. Так что, как ДОС читает записанную ей же реальную дискету, то будет читаться в эмуляторе и записанный в нем же образ. Способ универсальный, хотя и медленный. Если остановиться на нем, то при необходимости искусственного формирования образа диска важно просто обеспечить достаточные нулевые промежутки, конец же секторов до 3125 байт можно просто занулить.
А еще можно в эмуляторе попробовать обмануть ДОС и постоянно подсовывать ей сигнал готовности, чтобы ввод/вывод осуществлялся на максимальной скорости. В таком случае точность формата дискеты уже не важна, и можно попробовать сжать образ за счет служебной информации и/или межсекторных нулевых промежутков. Но первый вариант мне кажется более универсальным.
Ну так что, переименуем .rkdisk в .rdi и оставим формат как есть?