PVV
29.10.2018, 23:59
Давно хожу вокруг идеи подключения SD карты к ZX, и для полноты картины нужно получить ответы на несколько вопросов. Недавно я прорабатывал подключение SD на портах (http://www.nedopc.org/forum/viewtopic.php?f=71&t=9407&start=270#p145375) звукового чипа UM2149F(AY3-8910), соответственно первый вопрос:
Используются ли в Spectrum_е gpio порты AY3-8910?
Сам звуковой чип установлен на многих клонах, его порты фиксированы, так что мешает эти порты задействовать под наши нужды?
Конечно, такое 'прямое' подключение SD карты достаточно медленное (будет что-то около 1-2КБ в секунду), но простота решения уж очень подкупает. Ускориться примерно на порядок можно используя другое решение, по моим прикидкам, реализуемое на 6 корпусах, подключаемых к AY3-8910 (ИР24, ИЕ5, ТМ2-2шт, ЛЕ1 и ЛА3), но это на развитие.
Следующий вопрос по программной части, и наиболее животрепещущий, каким ПО эту SD поддерживать?
Есть у меня одна идея, как максимально безболезненно сделать поддержку работы с файлами на SD с файловой системой FAT16. Я просмотрел ветку с операционными системами и не увидел реализации чего то подобного, но я очень плохо знаком с наработками в этом направлении, и возможно, эта идея уже давно кем то используется, тогда хотелось бы узнать, в чем ее минусы, а ее суть вот в чем:
Положение файлов на диске в FAT16 описывается позициями кластеров (по сути последовательными наборами групп номеров секторов, а один сектор равен 512 байт). Если специальной программой монтирования записать в определенный, строго фиксированный, участок памяти последовательность из секторов(кластеров) на TRD файл, то мы будем иметь для 640КБ TRD файла 640/0.5=1280 записей секторов, один сектор 4 байта (а если в кластерах, то существенно меньше, тк для больших дисков один кластер может быть 64КБ, но для удобства работы с таким списком вполне можно использовать посекторный список) 1280*4= 5120 байт. И хранить эти 5120 байт на той же самой SD карте в области не используемой файловой системой, между нулевым сектором и началом первой таблицы FAT диска! (для справки, эта область, по умолчанию, составляет от 8КБ до 1МБ, в зависимости от размера диска, и никто не запрещает изменить ее размер на нужный нам при форматировании - это все на 100% совместимо согласно спецификациям на разбивку диска, к примеру arm процессоры используют эту область для размещения там своего начального загрузчика - и это почти все наши смартфоны, и ничего страшного не происходит... ) при эмуляции нескольких дисководов таких 5120КБ списков, соответственно, должно быть несколько. Код поддержки работы с SD уже имеется, нужно лишь его вставить в нужные места тех операционных систем, в которых планируется работа с SD. Это примерно 500-700байт.(к примеру в TRDOS 5.04 есть почти 1.5КБ свободного места, куда это можно спокойно разместить). Работа же должна выглядеть так - при обращении к диску переводить позицию дорожки-сектора-стороны в номер элемента списка секторов, считывать 4 байта номера сектора на карте, и читать сам сектор, все! На данный момент вижу здесь только одну проблему - сектора в TRD по 256байт, а с SD за один присест читается 512байт, и если для чтения это не проблема пробросить ненужные 256 байт, то при записи (а это полностью эквивалентно и не запрещено чтение-запись) это создает проблему, нужно прочитать все 512 байт, заменить нужные 256, и записать обратно 512 (эквивалентно прочитать и сохранить 256байт, которые надо оставить и пробросить 256, которые будут перезаписаны).
Вот и второй глобальный вопрос:
В чем минусы или плюсы в реализации описанной выше идеи?
Опять же, на развитие, SD карта подключается по SPI, соответственно можно в качестве памяти для списка секторов использовать дополнительную SPI память, выбираемую вторым чипселектом (25LC256 и тд ~50руб в SO-8 корпусе).
Эта идея перекликается с идеей монтирования TRD файла в RAMдиск клонов спектрума с 1МБ ОЗУ, но не требует этого 1МБ, и будет работать даже на 48КБ спектрумах!
Используются ли в Spectrum_е gpio порты AY3-8910?
Сам звуковой чип установлен на многих клонах, его порты фиксированы, так что мешает эти порты задействовать под наши нужды?
Конечно, такое 'прямое' подключение SD карты достаточно медленное (будет что-то около 1-2КБ в секунду), но простота решения уж очень подкупает. Ускориться примерно на порядок можно используя другое решение, по моим прикидкам, реализуемое на 6 корпусах, подключаемых к AY3-8910 (ИР24, ИЕ5, ТМ2-2шт, ЛЕ1 и ЛА3), но это на развитие.
Следующий вопрос по программной части, и наиболее животрепещущий, каким ПО эту SD поддерживать?
Есть у меня одна идея, как максимально безболезненно сделать поддержку работы с файлами на SD с файловой системой FAT16. Я просмотрел ветку с операционными системами и не увидел реализации чего то подобного, но я очень плохо знаком с наработками в этом направлении, и возможно, эта идея уже давно кем то используется, тогда хотелось бы узнать, в чем ее минусы, а ее суть вот в чем:
Положение файлов на диске в FAT16 описывается позициями кластеров (по сути последовательными наборами групп номеров секторов, а один сектор равен 512 байт). Если специальной программой монтирования записать в определенный, строго фиксированный, участок памяти последовательность из секторов(кластеров) на TRD файл, то мы будем иметь для 640КБ TRD файла 640/0.5=1280 записей секторов, один сектор 4 байта (а если в кластерах, то существенно меньше, тк для больших дисков один кластер может быть 64КБ, но для удобства работы с таким списком вполне можно использовать посекторный список) 1280*4= 5120 байт. И хранить эти 5120 байт на той же самой SD карте в области не используемой файловой системой, между нулевым сектором и началом первой таблицы FAT диска! (для справки, эта область, по умолчанию, составляет от 8КБ до 1МБ, в зависимости от размера диска, и никто не запрещает изменить ее размер на нужный нам при форматировании - это все на 100% совместимо согласно спецификациям на разбивку диска, к примеру arm процессоры используют эту область для размещения там своего начального загрузчика - и это почти все наши смартфоны, и ничего страшного не происходит... ) при эмуляции нескольких дисководов таких 5120КБ списков, соответственно, должно быть несколько. Код поддержки работы с SD уже имеется, нужно лишь его вставить в нужные места тех операционных систем, в которых планируется работа с SD. Это примерно 500-700байт.(к примеру в TRDOS 5.04 есть почти 1.5КБ свободного места, куда это можно спокойно разместить). Работа же должна выглядеть так - при обращении к диску переводить позицию дорожки-сектора-стороны в номер элемента списка секторов, считывать 4 байта номера сектора на карте, и читать сам сектор, все! На данный момент вижу здесь только одну проблему - сектора в TRD по 256байт, а с SD за один присест читается 512байт, и если для чтения это не проблема пробросить ненужные 256 байт, то при записи (а это полностью эквивалентно и не запрещено чтение-запись) это создает проблему, нужно прочитать все 512 байт, заменить нужные 256, и записать обратно 512 (эквивалентно прочитать и сохранить 256байт, которые надо оставить и пробросить 256, которые будут перезаписаны).
Вот и второй глобальный вопрос:
В чем минусы или плюсы в реализации описанной выше идеи?
Опять же, на развитие, SD карта подключается по SPI, соответственно можно в качестве памяти для списка секторов использовать дополнительную SPI память, выбираемую вторым чипселектом (25LC256 и тд ~50руб в SO-8 корпусе).
Эта идея перекликается с идеей монтирования TRD файла в RAMдиск клонов спектрума с 1МБ ОЗУ, но не требует этого 1МБ, и будет работать даже на 48КБ спектрумах!