К сожалению, на форуме нет систематизированной и конкретно оформленной в одном быстро доступном месте информации по портам. Банальная логика мне подсказывает, что для переключения банков должны быть задействованы четыре младших бита (D0..D3) порта #FE.Сообщение от Sancho45
Если это так, то очень странно и не логично, имхо. За спикер вроде должен отвечать порт с другим адресом - #FF.
Буду премного благодарен. У меня нету аппаратной реализации порта #FE, поэтому не проверить.
- - - Добавлено - - -
При составлении сборки на 1 Мб уже буквально пришлось "пихать всё подряд". Можно конечно закинуть в ROM-диск различные файлы с данными (картинки, AY-музыка и т.п.), но большого смысла в этом лично я не вижу. Read-only носитель всё же предполагает хранение базового набора ПО (преимущественно системного), а файлы ресурсов логичнее хранить на других, перезаписываемых носителях.
Есть ещё и такой момент: увеличение объёма предполагает увеличение кол-ва файлов на диске, при этом увеличивая объём носителя более 1 Мб мы скорее всего упрёмся в ограничение "max 255 файлов на диске", и к тому же неудобно с т.з. юзабилити искать нужные файлы в списке из 200 и более файлов.
Если делать ROM-диск на большие объёмы, то придётся думать в сторону другой (кластерной) организации хранения файлов и введения подкаталогов, но это уже совсем другая история, которая потянет переделку ROM-загрузчика в ПЗУ Монитора...
Можно, но придётся придумать прозрачное аппаратное решение, которое для Ориона будет эмулировать классический параллельный интерфейс ROM-диска на ВВ55. И, как писал выше, придумывать файловую систему с подкаталогами, что ударит по совместимости с классикой и быстродействию, а также по отжираемым ОС ресурсам
- - - Добавлено - - -
На данном этапе для меня очень ясно нарисовалась вкусная и вполне конкретная аппаратная хотелка для Ориона - трушный SRAM-диск объёмом 1 Мб (а ещё лучше - 2 Мб), с батареечный резервным питанием, "лежащим" в адресном пространстве МП, организованный как дополнительные 16 банков, переключаемые через порт #F9, с номерами страниц, идущими после ОЗУ. Фиг с ним - пусть даже со стандартной орионовской потерей верхних 4 Кб в каждой банке, дабы не усложнять дешифрацию и коммутацию. Можно было бы полностью разгрузить основное ОЗУ от кода ОС, предоставив прикладному ПО всё стандартное (расширенное) ОЗУ ПРК. Закэшировать каталоги всех дисков, что очень ощутимо повысило бы скорость работы одновременно с несколькими дисками. Получить полноценный сохраняемый рабочий диск по скорости работы аналогичный квазидиску. Появилась бы возможность сделать поддержку расширенного экрана (480/512 точек по горизонтали). Короче говоря, профит был бы ощутимый!
Ответить с цитированием