DSDOS для ПРК "Орион-128"

[Error404]

Привет. Страницы по порту FEh выше 512 кб какими битами переключаются? Там вроде первые три бита, 4-й бит работает со спикером, и 5 и 6 с переключением остальных страниц ЕМНИП. Я в отпуске, компа нет под рукой, проверить. Через пару дней посмотрю.

ЕМНИП D0..D4=2Мб max
те биты что у Спектрума были под клаву (5 линий из матрицы 5х8)

- - - Добавлено - - -

Хотя опять же припоминая, в CP/M я никак не обходил "звуковой" D5, там номер сектора и дорожки в адрес в ПЗУ транслируется сплошняком. Т.е. оно будет и более 2Мб работать, но попердывая в спикер. Тут другой вопрос встает: надо ли иметь более 2Мб в ПЗУ - вместо гирлянды параллельных ПЗУ уже надо нормальный носитель (если не карты памяти, то хотя бы те же spi-ПЗУ которые за 16Мб по 3 проводам стоят 50руб).

[Advertiser]

[Denn]

Страницы по порту FEh выше 512 кб какими битами переключаются?

К сожалению, на форуме нет систематизированной и конкретно оформленной в одном быстро доступном месте информации по портам. Банальная логика мне подсказывает, что для переключения банков должны быть задействованы четыре младших бита (D0..D3) порта #FE.

Там вроде первые три бита, 4-й бит работает со спикером, и 5 и 6 с переключением остальных страниц ЕМНИП.

Если это так, то очень странно и не логично, имхо. За спикер вроде должен отвечать порт с другим адресом - #FF.

Через пару дней посмотрю.

Буду премного благодарен. У меня нету аппаратной реализации порта #FE, поэтому не проверить.

- - - Добавлено - - -

Тут другой вопрос встает: надо ли иметь более 2Мб в ПЗУ

При составлении сборки на 1 Мб уже буквально пришлось "пихать всё подряд". Можно конечно закинуть в ROM-диск различные файлы с данными (картинки, AY-музыка и т.п.), но большого смысла в этом лично я не вижу. Read-only носитель всё же предполагает хранение базового набора ПО (преимущественно системного), а файлы ресурсов логичнее хранить на других, перезаписываемых носителях.
Есть ещё и такой момент: увеличение объёма предполагает увеличение кол-ва файлов на диске, при этом увеличивая объём носителя более 1 Мб мы скорее всего упрёмся в ограничение "max 255 файлов на диске", и к тому же неудобно с т.з. юзабилити искать нужные файлы в списке из 200 и более файлов.
Если делать ROM-диск на большие объёмы, то придётся думать в сторону другой (кластерной) организации хранения файлов и введения подкаталогов, но это уже совсем другая история, которая потянет переделку ROM-загрузчика в ПЗУ Монитора...

...вместо гирлянды параллельных ПЗУ уже надо нормальный носитель (если не карты памяти, то хотя бы те же spi-ПЗУ которые за 16Мб по 3 проводам стоят 50руб).

Можно, но придётся придумать прозрачное аппаратное решение, которое для Ориона будет эмулировать классический параллельный интерфейс ROM-диска на ВВ55. И, как писал выше, придумывать файловую систему с подкаталогами, что ударит по совместимости с классикой и быстродействию, а также по отжираемым ОС ресурсам

- - - Добавлено - - -

На данном этапе для меня очень ясно нарисовалась вкусная и вполне конкретная аппаратная хотелка для Ориона - трушный SRAM-диск объёмом 1 Мб (а ещё лучше - 2 Мб ), с батареечный резервным питанием, "лежащим" в адресном пространстве МП, организованный как дополнительные 16 банков, переключаемые через порт #F9, с номерами страниц, идущими после ОЗУ. Фиг с ним - пусть даже со стандартной орионовской потерей верхних 4 Кб в каждой банке, дабы не усложнять дешифрацию и коммутацию. Можно было бы полностью разгрузить основное ОЗУ от кода ОС, предоставив прикладному ПО всё стандартное (расширенное) ОЗУ ПРК. Закэшировать каталоги всех дисков, что очень ощутимо повысило бы скорость работы одновременно с несколькими дисками. Получить полноценный сохраняемый рабочий диск по скорости работы аналогичный квазидиску. Появилась бы возможность сделать поддержку расширенного экрана (480/512 точек по горизонтали). Короче говоря, профит был бы ощутимый!

[Error404]

На данном этапе для меня очень ясно нарисовалась вкусная и вполне конкретная аппаратная хотелка для Ориона - трушный SRAM-диск объёмом 1 Мб (а ещё лучше - 2 Мб ), с батареечный резервным питанием, "лежащим" в адресном пространстве МП, организованный как дополнительные 16 банков, переключаемые через порт #F9, с номерами страниц, идущими после ОЗУ. Фиг с ним - пусть даже со стандартной орионовской потерей верхних 4 Кб в каждой банке, дабы не усложнять дешифрацию и коммутацию. Можно было бы полностью разгрузить основное ОЗУ от кода ОС, предоставив прикладному ПО всё стандартное (расширенное) ОЗУ ПРК. Закэшировать каталоги всех дисков, что очень ощутимо повысило бы скорость работы одновременно с несколькими дисками. Получить полноценный сохраняемый рабочий диск по скорости работы аналогичный квазидиску. Появилась бы возможность сделать поддержку расширенного экрана (480/512 точек по горизонтали). Короче говоря, профит был бы ощутимый!

Это кстати вполне можно сделать, например в виде платы второго этажа над основным ОЗУ (на журнальном Орионе-128 и его клонах). Например в Ревизии-512 на эту плату выводятся сигналы КТ2 КТ3 для выборки еще двух банок РУ7 (т.е. 513..1024кб) и есть несколько незанятых контактов на тех же разъемах куда можно подать еще дополнительные адреса (потребуется расширить порт F9). Это может быть вариант платы с 6 СОЗУ 512 кб и одной 8битной ИРxx для защелки RAS (демультиплексировать адрес) - итого получится 2Mb ОЗУ. Ну, или делать внешнюю плату в слоте, тут чуть посложнее будет.

[Denn]

Это может быть вариант платы с 6 СОЗУ 512 кб...

А почему с 6-ю (3 Мб)? Это как-то не 8-битно что ли... Ну и чересчур жирно, пожалуй
Обычно либо 2, либо 4, либо 8.

Ну, или делать внешнюю плату в слоте, тут чуть посложнее будет.

Тут дело такое, конструкция должна вставляться в слот, в идеале - в системный, как доп. плата расширения, в противном случае дело пахнет поножовщиной и МГТФингом, а это не вариант. Что-то меня терзают смутные сомнения, что возможно внедрить доп. СОЗУ малой кровью. По крайней мере в Орион-128, в "ПРО" вроде есть такая возможность.

[Sancho45]

Скрытый текст

[свернуть]

Скрытый текст

[свернуть]

Образ 256кб 3.91, первое включнеие, как-то не все работает на новоделе. Впечатление, будто определилось, но не задействовано или что-то нажать надо ?!

- - - Добавлено - - -

с этого образа часы работалти

https://zx-pk.ru/threads/27462-sbork...l=1#post952199


upd: после нажатий кнопок в конфигураторе и выхода из него, другие страницы ром диска увиделись и шелл запустился.

[Denn]

Sancho45, спасибо за помощь в тестировании. Да, я тоже обнаружил косяки в релизе 3.91 по части инициализации часов, а также есть косяк и по части порта #FE (проявится при чтении файла, тело которого попадает на разные банки).
Всё уже исправлено, сегодня вечером обновлю образы и отпишусь.
Попутно взялся оптимизировать код работы файловой системы, и как выяснилось, там есть потенциал для ускорения алгоритмов.
Так что пока пауза до v3.92, там будет что потестировать

П.С. кстати, косяк с часами из v3.91 проявляется только если CMOS "слетает" и ход часов останавливается; на ПРО (мой основной рабочий ПРК) я косяк даже не заметил, т.к. там ВИ1 никогда не сбивается, в отличие от 128-го (

[Sancho45]

IDE тоже не определился, у меня СF карта через переходник.
С часами проверю....

- - - Добавлено - - -

Привет. Страницы по порту FEh выше 512 кб какими битами переключаются? Там вроде первые три бита, 4-й бит работает со спикером, и 5 и 6 с переключением остальных страниц ЕМНИП. Я в отпуске, компа нет под рукой, проверить. Через пару дней посмотрю.

На плате Рябцова в выборке страниц РОМ-диска учавствуют D0-D3 биты, D4 идет на вкл/откл спикера и далее D5 и D6 тоже на выборку страниц ром диска,но уже на разьем расширения.

- - - Добавлено - - -

Только не понятно зачем?! На разьем расширения выведены все сигналы, в том числе и pFE, а биты D5 и D6, идут после тригера страниц на основной плате, но почему то без младших битов 0-3, так что смысла в них нет, на плате расширения надо будет отдельно тригер страниц делать

[Denn]

IDE тоже не определился, у меня СF карта через переходник.

И опять мой косяк (( Вероятно речь про вывод информации о диске. В сборку для О-128 нечаянно попала не та утилита HDDINFO$, она ищет только HDD по схемотехнике NEMO (на портах #F79x).
Утилита форматирования HDD$FMT должна определять жёсткий диск корректно.

На плате Рябцова в выборке страниц РОМ-диска учавствуют D0-D3 биты, D4 идет на вкл/откл спикера и далее D5 и D6 тоже на выборку страниц ром диска,но уже на разьем расширения.

Битов D0..D3 достаточно, получаются доступными 16 банков, т.е. 1024 Кб (1 Мб), переключение банков в DSDOS должно работать корректно.

- - - Добавлено - - -

Обновлённая (исправленная) версия DSDOS v3.92




Изменения:

1). Исправлена недоработка в поддержке альтернативного переключения страниц ROM-диска через порт #FE;

2). Исправлена ошибка инициализации RTC в утилите TIME$;

3). Исправлена ошибка поддержки НЖМД через порт юзера #F6 в утилите HDDINFO$;

4). Оптимизация алгоритмов поддержки файловой системы (модули BIOS, KERN);

5). Радикальное ускорение работы ЭД™ !!!


По последним двум пунктам стоит написать чуть подробнее. Были проведены сравнительные тесты на файловых операциях (254 файла размером 512 байт), результаты которых были опубликованы ранее. Результаты оптимизации впечатляющие:


Квазидиск [B:]

Чистая запись файлов: 0:20 -> 0:12 *
Запись файлов "поверх": 0:40 -> 0:22
Удаление файлов: 0:12 -> 0:04
Чтение файлов: 0:20 -> 0:16

Резюме: скорость записи выросла почти в 2 раза! Скорость чтения "подтянулась" до уровня ЭД™. Скорость удаления файлов стала в 3 раза выше.


ЭД™ [E:]

Чистая запись файлов: 1:03 -> 0:14
Запись файлов "поверх": 1:39 -> 0:25
Удаление файлов: 0:28 -> 0:05
Чтение файлов: 0:16 -> 0:15

Резюме: скорость записи выросла в 4,5 раза! Скорость чтения сохранилась практически на прежнем уровне (небольшой прирост из-за оптимизации алгоритма поиска файла в каталоге). Скорость удаления файлов возросла в 5,6 раз!

Самое важное: скорость работы ЭД™ стала практически аналогичной квазидиску, т.е. его уже вполне можно рассматривать как альтернативу и использовать в качестве рабочего диска.

__________________________________________________ ____________
* <время до оптимизации> -> <время после оптимизации>, в мин:сек




▼▼▼ Ссылки для скачивания различных вариантов сборок ▼▼▼


Для ПРК ОРИОН-128 всех ревизий:


ПЗУ ROM-диска объёмом 64 Кб

ПЗУ ROM-диска объёмом 128 Кб

ПЗУ ROM-диска объёмом 256 Кб

ПЗУ ROM-диска объёмом 512 Кб


ПЗУ ROM-диска объёмом 1024 Кб

специализированная "программерская", ПЗУ ROM-диска объёмом 512 Кб

специализированная "программерская", ПЗУ ROM-диска объёмом 1024 Кб

- - - Добавлено - - -

П.С. отдельное спасибо камраду Sancho45 за помощь в тестировании на альтернативном железе

[Sancho45]

Всё тоже самое. Нажимаю Esc- пишет шелл не найден,нажимаю D, выводит только 1ую страницу ром, захожу и выхожу в конфигуратор(system$), потом обязательно D (dir), пролистывает все файлы (из др страниц тоже), только потом при нажатии Esc вываливается шелл. Часы так же не видит. И IDE даже в конфигураторе не видит, на скринах выше видно

- - - Добавлено - - -

образ 256кб

- - - Добавлено - - -

загрузил Altair-dos, через IDE для проверки, часы видит, время кажет, выключил, переставил ром, и утилита TIME$ все равно не видит часы

- - - Добавлено - - -

Гружу Altair dos, часы сбиты.

- - - Добавлено - - -

Update

Утилита HDD$FMT увидела CF, но после вторичного запуска, в первый раз написала прерваная команда, а HDDINFO не найдена адрес метка. После HDDinfo тоже распознала CF карту в IDE

[Denn]

Всё тоже самое.

На всякий случай, сборка точно новая встала? Версия 3.92 ?

Нажимаю Esc- пишет шелл не найден,нажимаю D, выводит только 1ую страницу ром, захожу и выхожу в конфигуратор(system$), потом обязательно D (dir), пролистывает все файлы (из др страниц тоже), только потом при нажатии Esc вываливается шелл.

Идею понял, причину нашёл (загрузчик не дёргал переключалку..), исправил. Нужно перескачать образ по тем же ссылкам.

Часы так же не видет.

Так, смотрю скриншот и вижу, что SYSTEM$ находит в системе RTC первого типа, т.е. по адресам посадки #F7B0(данные), #F7B1(адрес).
Часы действительно там сидят?

И IDE даже в конфигураторе не видит, на скринах выше видно

Как аппаратно реализован интерфейс IDE ?
Если запустить тест юзер-порта (TEST#F6$), какое состояние линий он показывает?


- - - Добавлено - - -

Update

Утилита HDD$FMT увидела CF, но после вторичного запуска, в первый раз написала прерваная команда, а HDDINFO не найдена адрес метка.

В случае посадки IDE на юзер-порт, для обнаружения используется особенность интерфейса HDD: при отсутствии обращения хоста, он подтягивает все сигнальные линии к лог."1". Как ведёт себя CF-карта через переходник, честно говоря не знаю. Можно посмотреть с помощью утилиты теста порта: TEST#F6$

После HDDinfo тоже распознала CF карту в IDE

Можно скриншот HDDINFO, плиз? Интересно в деталях, как определяется CF-карта на Орионе