|
|
О
флэш контроллере SD-контроллер от vinxru
Орион-128
Флэшка в Орионе 128
О флэш контроллере SD-контроллер от
vinxru
Я (от автора статьи) не собирал
флэш-контроллер от vinxru и имею смутное представление о нём. Могу
ошибаться, но из прочтения форумов на эту тему у меня сложилось мнение,
что контроллер является закрытым для сторонних программ устройством.
Разработка состоит из двух частей - из собственно контроллера,
обеспечивающего доступ к micro-SD с файловой системой FAT16 и
программы-оболочки типа Нортон для управления файлами в кодах КР580.
Таким образом это устройство заменяет только магнитофон (и даже не
полностью, т.к не является эмулятором магнитофона). Конечно, запускать
игры удобно и это устройство вполне устраивает тех, кому надо только
посмотреть старое ПО и затем поставить ретро-компьютер на полку. В
условиях когда запись на micro-SD невозможна (хотя другие подобные
изделия это могут) такое решение наилучшее.
Но даже, если бы запись была возможна, для тех, кто более серьёзно
пользуется компьютером, у данной концепции есть недостатки. Для
магнитофонных программ более правильным был бы эмулятор магнитофона,
так, как это сделано в эмуляторах.
Если речь идёт о низкоуровневой эмуляции магнитофона, т.е обслуживании
контроллером самого МГ-входа и выхода (т.е контроле и управлении
сигналов прямо на ножке ППА), то я считаю, что это не очень полезная и
намного более сложная в реализации затея. Во-первых, есть разные
форматы, например, MSX-двухчастотка, РК-двухфазка, а в ZX-Spectrum для
защиты от пиратства применяются и более хитрые форматы.
Если цифровой МГ не будет хранить данные в WAV-формате, а декодировать
принятые данные в байты и хранить их уже в виде кодов, то можно сделать
цифровой магнитофон пригодный только для РК86 и близких по МГ-формату
компьютеров. Владельцам ZX такое устройство не подойдёт. А вот хранение
записей в WAV формате полностью заменит обычный магнитофон, хотя
цифровой магнитофон проще купить в магазине, а цифровой диктофон есть в
любом телефоне. Однако WAV-формат неудобен, т.к при этом скорость обмена
та же, как с реальным магнитофоном (составляет всего 200 байт в
секунду), тогда как эмулятор магнитофона работает мгновенно.
Более простой программный эмулятор магнитофона на базе внешнего привода
устроен так. Пользователь выбирает файл или маркирует группу файлов в
файловой панели, а затем по выходе из оболочки на вектор ПЗУ-шной
подпрограммы F806 вешается побайтовая процедура чтения из открытого и
считанного в буфер файла, причём к файлу вначале и, если надо и в конце,
добавляются байты, которые входят в МГ-формат данного компьютера (в
случае РК и ОРИОНА это пилот-тон в 256 нулевых байтов, затем синхробайт
Е6, нач.адрес в формате старший, младший, затем сам файл, после блока
файла следуют два нуля и КС блока). Впрочем, проще хранить данные прямо
в МГ-формате, используя, например, простейший алгоритм для сжатия
повторяющихся байтов (если пилотон сжать в 3 байта, то служ.байтов от
МГ-формата всего десяток).
А на вектор F80F тоже вешает обработчик вызовов. В случае, если ещё нет
открытого на запись файла, то при первом вызове F80F начинается
процедура ожидания пилот-тона с поиском синхробайта. После обнаружения
факта выдачи на F80F синхробайта, считываются 4 байта адресов (начальный
и конечный) и, для запроса имени записываемого файла, открывается окно.
После ввода имени файла управление возвращается программе вызвавшей
F80F, и все последующие вызовы F80F до тех пор пока не будет получено
указанное в заголовке число байтов, передают байты в буфер. После
передачи указанного числа байтов, файл автоматически закрывается и
пишется на диск, а вывод завершающих 5 байтов в блочке КС игнорируется.
Если на вывод выведено меньшее число байтов, чем заказано, то в
эмуляторах критерием конца записи файла является пауза в вызовах F80F
длительностью более 2-3 секунд (меньшее время помешает записи/чтению с
ленты многоблочных программ).
Но ввод и вывод с магнитофона по сути нужен только двум программам -
бейсику и текстовому редактору. Если не учитывать многоблочные
программы, то для обычных файлов способ попадания кода в ОЗУ вообще не
важен и применённая концепция намного удобнее, чем возня с командной
строкой в которой набирается директива для МГ-ввода. Для текстового
редактора можно обойтись загрузкой блока в буфер, т.к любой редактор РК
имеет запрос NEW?
Но и для бейсика и для текстового редактора уже с 1993 существует
дисковое решение - это дисководные верcии текстовых редакторов и
бейсика-плюс для РК-ДОС. Получается, что имея дисковод с РК-ДОС
магнитофон вообще низачем не нужен.
Потому я считаю, что вместо мало кому интересной
разработки эмулятора магнитофона, стоило бы сделать на порядок более
простую работу. А именно, обеспечить программистский интерфейс для
доступа к micro-SD как к обычному приводу с посекторным обменом. Для
этого надо ввести всего несколько функций - чтение сектора размером в
512 байт и запись такого сектора на micro-SD.
Адресацию по диску можно сделать традиционную - через указание номера
трека и номера сектора. Для этого даже не нужны как в DOS отдельные
функции типа "установка N трека" и "установка N сектора". Можно просто
указывать трек и сектор в регистрах при вызове процедур чтения/записи
сектора. А можно использовать сплошную адресацию по типу LBA в
винчестере, когда просто задаётся порядковый номер сектора в парном
регистре (т.е адресация максимум до 65535 секторов по 512 байт и
максимум в 32 мб, чего для дисков 8-ми разрядок более, чем достаточно).
Хотя все DOS работают с секторами и треками, но пересчёт в LBA это всего
десяток команд процессора, что не существенно усложнит BIOS в DOS 8-ми
разрядки.
Высокоуровневый формат micro-SD не важен. Он может оставаться FAT16 или
можно использовать низкоуровневый доступ, т.е micro-SD без файлового
формата, когда напрямую читаются/пишутся сектора с заданным номером.
Удобнее для считывания и записи на PC и в телефоне сохранить формат
FAT16.
Если остаётся формат FAT16, то для организации дисков для конкретной
дискеты создаются файлы образы дисков (которые могут иметь, например,
расширение DSK). С помощью функции "выбор диска" выбираем какой-либо
файл. После чего все обращения на чтение/запись выполняются с этим
файлом. Например, если вызвана операция чтения сектора номер 100, то из
файла в буфер читается 512 байт с отступом в 512*100 байтов от начала
файла.
Например, для дисков оригинальной РК-ДОС создаются файлы образы размером
в 400 кб (для чуть изменённой РК-ДОС размер диска может быть до
8*0.5*255= 1020 кб. Это максимальный размер, который возможен в РК-ДОС (т.к
в одном байте VTOC таблицы занятости описывающем один трек можно описать
лишь 8 секторов, а число треков ограничено в 255, хотя это макс.число
треков при желании можно изменить).
Для CP/M диски могут быть намного большего размера, но для удобства в
силу отсутствия подкаталогов неудобны диски с размером более 2 мб.
Для меня неинтересен контроллер от vinxru, даже с записью. Мне нужен
именно контроллер внешнего привода. Совсем неважно как устроен этот
привод, реальный он или на базе излишнего ОЗУ компьютера. Нужны лишь
процедуры записи и чтения сектора с указанным номером. Модификация
имеющихся DOS для 8-ми разрядки простейшая, в них убираются имеющиеся
процедуры работы с физическим носителем и вставляется десяток команд
вызывающих процедуру контроллера. Таким образом контроллер работает как
аппаратно-программный драйвер DOS.
На базе флэш-памяти можно сделать также устройства с побайтовым обменом.
Тогда имеющиеся DOS даже не надо модифицировать. Например, и для РК и
для ОРИОНА есть версии RK-DOS, CP/M и других DOS в которых в качестве
привода А использован эл.диск из излишнего ОЗУ. Интерфейс происходит
всего двумя подпрограммами - чтение и запись байта из излишнего ОЗУ -
F836 и F839. Программе без разницы откуда и как берётся и куда
записывается байт. Потому эти DOS для работы на флэш даже не требуется
модифицировать (чуть-чуть модифицируется лишь ПЗУ, чтобы п/п-ммы F836/39
работали иначе).
Т.к реально 8-ми разрядки используют дополнительное банковое ОЗУ только
для целей эл.диска, то контроллер с побайтовым обменом эквивалентен, т.е
заменяет, расширение ОЗУ на большой объём.
Например, если к ОРИОНУ с всего двумя банками РУ5-тых подключить
флэш-карту и все обращения по F836/39 выше, чем в банку N1
переадресовывать во внешний носитель (а флэш-память это как раз быстрый
носитель), то программа будет считать, что это ОРИОН, который имеет 256
банок памяти по 64 кб. В ORDOS достаточно забить одну команду, а вместо
родного ПЗУ поставить соответствующе модифицированное и получится ORDOS
с 255 квазидисков (реально лишь 26, для большего не хватит букв
латинского алфавита для названия дисков).
Естественно побайтовый обмен с флэш-памятью не работает побайтово, а
буферизуется. В реальности байты читаются/пишутся подряд. Потому при
первом обращении в буфер считывается целый сектор и чтение последующих
байтов происходит без повторного обращения к флэш, а до достижения
адресацией конца сектора байты читаются из буфера
Вот такое устройство контроллера флэш-памяти для 8-ми разрядок решает
все проблемы 8-ми разрядок, заменяя дисковод и винчестер и позволяет
использовать и сохраняет всё имеющееся ПО без переделок, а если есть
побайтовый обмен, то и заменяет расширение ОЗУ. А текущий вариант
контроллера от vinxru не решает ни магнитофонных ни дисководных проблем,
а может использоваться лишь для запуска игр. Сообщение alemorf Ср Дек 19
2018, 17:50
6
Ну дак оно так и работает. В память, по любому адресу, загружается
маленький драйвер (SDBIOS). У драйвера есть множество команд, вот,
например:
Открыть файл (A=2, D=0, HL=имя файла / A=код ошибки)
Установить позицию чтения записи файла (A=3, B=режим, DE:HL=позиция / A=код
ошибки, DE:HL=позиция) (С начала B=0, с текущего положения B=1, с конца
B=2)
Прочитать из файла (A=4, HL=размер, DE=адрес / A=код ошибки, HL=сколько
загрузили)
Записать в файл (A=5, HL=размер, DE=адрес / A=код ошибки)
Что бы вызвать команду надо заполнить соответствующие регистры и сделать
CALL этого драйвера. Драйвер - простейшая штука, просто выдает в
параллельный 8-битные код эти команды. Можно и порт писать.
---
Протокол открытый, описанный:
alemorf. ru/comps/specialist_lin/sd.html
---
Например:
; Выбираем образ диска
mvi a, 2
lxi hl, disk_name
call 0C800h
; Устанавливаем сектор
mvi a, 3
lxi hl, 120 // Сектор + дорожка + сторона
lxi de, 0
call 0C800h
; Закписываем сектор
mvi a, 5
lxi hl, 256 // Размер сектора
lxi de, buffer
call 0C800h
disk_name: .db "disk1.dsk";
---
Я кстати CPM к этому драйверу подключал.
Автор под псевдонимом, источник https://ruecm.forum2x2.ru/
Доработки и схемы прочие... непроверенные
Полезные и интересные статьи
На предыдущую страницу
На главную страницу На следующую
страницу
|
|