Блок КНГМД БК0010 "Опток"

[MM]

Уважаемый господин photon прислал дамп БК0010-01 с адреса 120000-137777, с передними 2 шт. 2 слова лишними :
https://cloud.mail.ru/public/y63k/GtEC2ixLt
Походу РТшкой на лету коммутируется ППЗУ ОПТОКа, т.к. оно всего 4 Кбайт ( 010000 ( 8 )).

[photon]

1. дамп делал программой PARADISE, это, видать, она добавила первые два слова. Было бы интересно узнать как кидать дамп в МГ командами 019ой ПЗУ ("а что так можно было?..")
2. мой живой опток запускается по S177600. Признак успешного запуска - в верхней служебной строке будет написано "ОПТОК ДОС-90"
3. на фото в первом посте как раз дохлый опток, но зато его проводья позволили мне запустить другой опток, что лежал у меня уже несколько лет без проводов. (Зато у него был теперь опубликованный паспорт)
4. радости от живого оптока в хозяйстве пока мало - думал хоть скину загруженный через МГ paradise на дискету. Но как?.. По директиве /W опток что-то делает с дискетой, озу экрана заполняется чем-то. Скорее на чтение похоже. Файлов новых на дискете во всяком случае не появляется. Директивы формата /F и инициализации /I проходят без ошибок, директива /L сообщает, что у меня около 1410 блоков на дискете свободно. Если кто знает как надо пользоваться директивой /W расскажите пожалуйста.
5. я точно знаю,что есть товарищи с опточными дискетами, желающие их вычитать. Готов попытаться помочь. Бесплатно конечно. Присылайте.
6. для красоты надо найти типа системную дискету опток, в доке написано, что там утилита должна быть, позволяющая из-под бейсика проги сохранять. Может ещё что-то там найдётся...
7. про РТ4. В принципе при морально-информационной поддержке общественности могу демонтировать и считать её. У меня есть программатор TL866 он пойдёт под это?
8. бывали оптоки (и у меня такой есть один нерабочий) - у него печатная плата более короткая.

[MM]

Было бы интересно узнать как кидать дамп в МГ командами 019ой ПЗУ

При запуске БК0010 ( без -01 ) с Оптоком вытащить из БК 018 ( или 084 ) ПЗУ с Фокалом.
Включить.
Набрать :
Т(ввод)
(рус)(загл)ТС
177630АА
0,
120000АА
200Л
(скриншот)
МЗ ( запись на магнитофон )
(ввести параметры файла)

TL866 он пойдёт под это?

Да, но придется сделать переход на макетке, например под 573РФ5, задействовать мл. 4 бита. Биты 0...7 "573РФ5" подтянуть к +5в. резисторами 2 ком.

[gid]

Походу РТшкой на лету коммутируется ППЗУ ОПТОКа, т.к. оно всего 4 Кбайт

Я немного порассматривал содержимое ПЗУ в дизассемблере. Там видно, что для подсчёта КС ПЗУ считается содержимое всех 8 Кб. Нет, оказывается таки только первых 4Кб, вторые 4 Кб игнорируются.
Но весь полезный код умещается в первые 4 Кб и в последние 01000 байт. В оставшемся месте находится какая-то мешанина из кода из первых 4 Кб, мне показалось, что там набросаны случайные куски непонятно для чего. Чтобы просто было, или чтобы КС подогнать к определённому значению. Никаких вызовов туда не делается, а из-за того, что куски обрываются посреди многословных команд, код вообще неработоспособен.
ПЗУ в зависимости от бита 15 регистра управления 177630 мапится по адресу 120000 (значение 0) или по адресу 160000 (значение 1) Нет, оно вообще выключено, там обычное ПЗУ бейсика на своих местах, только по адресам 177600..177617 - кусок ПЗУ с кодом инициализации Оптока.
Назначение остальных битов неизвестно.
Ещё, подозреваю, что РТшка отвечает за выдачу RPLY при обращении к регистрам контроллера 177620-177630, как в СМК сделано, хотя без схемы утверждать не буду.
Всё непонятно, что это за регистры, каково их назначение, какие данные принимают/передают, придётся долго разбираться, анализируя ПЗУ.

2. мой живой опток запускается по S177600. Признак успешного запуска - в верхней служебной строке будет написано "ОПТОК ДОС-90"

Это признак того, что ПЗУ живое, и КС совпадает с заданной. А вот живой или нет сам ВГ93, это неизвестно.

8. бывали оптоки (и у меня такой есть один нерабочий) - у него печатная плата более короткая.

Точно Оптоки? А то я совершенно случайно узнал, что был ещё один контроллер на ВГ93 - Альфа-ДОС, он как раз короткий.

[photon]

Точно Оптоки? А то я совершенно случайно узнал, что был ещё один контроллер на ВГ93 - Альфа-ДОС, он как раз короткий.

оказывается у меня альфа-дос). Корпус просто синий, а обозначений нет. Вот я и "думал", что это опток, ведь они тоже в синем корпусе встречаются. Мой не работает или не знаю как с ним работать. Документацию не видел. Хорошо бы обновить ссылку на пзу альфа-дос - https://zx-pk.ru/threads/13386-spiso...erii-k-bk.html .

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

Если кто знает как надо пользоваться директивой /W расскажите пожалуйста.

сам спросил - сам ответил. Вот как надо копировать файл game.exe с магнитофона на дискету:
MO<ввод>S177600<ввод>М<ввод>М:game.e xe<ввод>(грузимся с МГ)
далее, собственно, запись на дискету
М<ввод>0:<ввод>М<ввод>/W<ввод>
можно выключить БК. По ключении грузимся с дискеты:
MO<ввод>S177600<ввод>М<ввод>game.exe< ввод>S1000<ввод>

А вот живой или нет сам ВГ93, это неизвестно.

Все три мои ВГ-шки (из 2х оптоков и одного альфа-доса) оказались живыми, то есть все читают то, что одна из них записала

[gid]

Товарищи, прошу помощи. Не могу понять, как программа из ПЗУ Оптока записывает данные на дискету.
Собственно процедуры записи/чтения находятся при работе с дискетой по адресу 0137100, 0137136.
Вот подпрограмма записи:

; Вход: R0 - Регистр Команд/Состояния
;       R1 - Регистр Данных
;       R2 - адрес буфера данных
;       R3 - размер данных в байтах
;       R4 - адрес блока параметров контроллера
;       R5 - 0

WriteOpFake:    mov     110(R4), @R0
                sob     R5, .
                sob     R5, .
                sob     R5, .
                br      2$

1$:             br      1$
                sob     R3, 1$
                br      3$

2$:             bis     #4, 164(R4)
3$:             mov     @R0, 106(R4)
                return
; End of function WriteOpFake

Как видим, она не делает ничего полезного. Но если предположить, что ПЗУ дублируется первыми 4кБ во вторую половину 4Кб, то по адресу 0137100 уже будет вот такой код:

; Вход: R0 - Регистр Команд/Состояния
;       R1 - Регистр Данных
;       R2 - адрес буфера данных
;       R3 - размер данных в байтах
;       R4 - адрес блока параметров контроллера
;       R5 - 0

WriteOp$:       mov     110(R4), @R0    ; подаём команду запись сектора
                br      0$
                br      0$
                br      0$
                br      1$

0$:             movb    (R2)+, @R1      ; передаём данных
                sob     R3, 0$
                br      2$

1$:             bis     #4, 164(R4)
2$:             mov     @R0, 106(R4)    ; читаем статус
                return
; End of function WriteOp$

Уже что-то осмысленное.
Но у меня никак не получается уложиться во времянки. Тут сразу после подачи команды "Запись сектора", в регистр данных хреначатся все данные сектора.
А в документации на ВГ93 написано, что после подачи команды "Запись сектора" сперва нужно найти нужный сектор, т.е. прочитать его заголовок, потом пропустить 22 байта пробела, потом записать маркер данных, и только после этого начинать приём данных из регистра данных.
Ну не успевает он всё это сделать за одну команду BR.

[Advertiser]

[MM]

не получается уложиться во времянки

Это интересный вопрос...
Я оценивал быстродействие ВГ93 в БК0010-3 мгц для МФМ плотности - чёт его маловато, возможна лишь плотность ФМ именно по причине нехватки быстродействия БК.
Например, 16-бит ВП1-128 еле-еле , кряхтя и сея ошибки , справляется на БК0010-3 мгц, и то кроме форматирования - оно не особо корректно.
А тут сразу надо в 2 раза шустрее - т.к. 8 бит шина.

Например, в др. варианте блока на ВГ93 коммутация ПЗУ идет мелкими секторами :

Выв. 01 РФок, что соответствует адресам 000400 ( 8 ), и еще завязана на выв. ВГ93 DRQ - т.е. связано с прерываниями, а они могут возникать по готовности ( какого-то бита в ВГшке ).

[reddie]

сразу после подачи команды "Запись сектора", в регистр данных хреначатся все данные сектора

Само собой, так работать не будет. После каждого принятого/переданного байта должно быть ожидание готовности ВГ, точнее, запроса на приём данных.

еще завязана на выв. ВГ93 DRQ - т.е. связано с прерываниями, а они могут возникать по готовности ( какого-то бита в ВГшке )

Да, активный сигнал DRQ это запрос данных при записи либо сигнал забрать байт при чтении. Соответственно, вижу три варианта:
1) контроллер аппаратно тормозит ЦП на каждом байте с помощью сигнала захвата шины (DMGO или как его там). Наименее вероятный сценарии, однако он позволяет реализовать наилучшее быстродействие при чтении-записи
2) сигнал DRQ вызывает прерывание, ЦП выходит из холостого цикла и производит чтерие-запись байта. Чем-то похоже на работу с Марсианкой через блок КМ
3) DRQ участвует в формировании ША, как в вышеприведённой схеме, и по активному сигналу проц выполняет код из другой области ПЗУ. В общем, это сходится с "непонятным кодом" в посте [gid] -а: пока DRQ неактивен - в цикле крутится "бесполезный" холостой код, а по приходу DRQ адрес в ПЗУ указывает на "настоящую" процедуру. Тут же кроется и разгадка отсутствия паузы между записью байт (ожидания готовности ВГ).
Не гуру БК, но предполагаю, что так оно работает.

[gid]

Спасибо! Я понял как оно работает.
Сейчас сопоставил два куска кода, и получается вполне работоспособный вариант.
Когда DRQ == 0, выполняется код по адресу 0137100, там как раз происходит ожидание - sob'ы - это выполняем поиск сектора, всякие подготовительные операции и ждём первого DRQ, как только DRQ == 1, то первые 4 кБ мапятся во вторые, и начинает выполняться код с адреса 0127100 - пересылка байта в регистр данных, при этом DRQ снимается, и снова начинает выполняться код с 0137100, там начинает выполняться команда 1$: br 1$ - и будет цикл, до тех пор пока снова не возникнет DRQ и не замапится код с командой пересылки байта. И так до конца.
Занятно, неочевидно, и мне самому бы такое в голову не пришло.

[reddie]

Занятно, неочевидно, и мне самому бы такое в голову не пришло.

Подозреваю, что такое решение было выбрано как раз для ускорения работы с ВГ93. Ну, чтобы относительно медленный проц БК успевал заниматься побайтовым обменом. Как писал выше MM, даже словный обмен с ВП-128 (по два байта) и тот на БК10 сбоит, а тут вдвое чаще. Спектрумовский метод с программным чтением
состояния DRQ в цикле тут вряд ли возможен, зато аппаратное решение позволило обойтись одной командой BR, чего вполне достаточно.