РАДИО-86РК на Z80

Вид для печати

Показывать 40 сообщений этой темы на одной странице

27.01.2017, 06:55
barsik

Цитата:

Сообщение от Vladimir_S

вот чем мне не нравятся средства разработки на РС - результат трансляции приходится считывать НЕХ редактором, копировать, создавать новый файл, писать туда скопированное с адреса 4, по адресу 0 вносить начало файла, по адресу 2 конец файла. Потом читать его в эмуляторе, узнавать КС, подставлять её в конец файла, а потом директивой О делать вывод уже готового к записи на РК файла.

Почему не подставлять адреса блока в исходнике операторами DEFB, и заботиться ни о чём не надо. А для редакции дампов не нужен HEX-редактор. Все программисты пользуются UltraEdit-ом, где всё, что надо программисту есть. Если лень узнавать КС за счёт загрузки в эмулятор, то это автоматизируется. За 15 минут можно написать программку, которая считывает GAM-файл, считает КС и записывает её в этот же файл. Я такую программку сделаю на досуге, чтобы удобнее было проверять программы в эмуляторе B2M, хотя меня КС мало волнуют.

BAT-файлы позволяют всё автоматизировать. Мне КС не нужна. Стартую BAT-файл, всё само транслируется и если всё успешно, стартует эмулятор ОРИОНА, где всё проверяю. Мой эмулятор ОРИОНА удобный и полноценный (а вот два эмулятора РК86 - неполноценные, их не дорабатывал, не было потребности). Так что на ОРИОН я пересылал редко, только чтобы убедиться, что всё работает. Т.к были случаи когда в эмуляторе работает, а в реале нет. Когда на ОРИОНЕ был КНГМД с ВГ93, то обмениваться через дискету было быстро и удобно. Но когда на ОРИОНЕ остался только РК-КНГМД, то пришлось пересылать по проволоке.

По науке для РК86 надо ставить ВВ51. Только так можно получить скорость. Но мне это делать лениво, так что я просто сделаю скоростной протокол обмена через тот же порт принтера. Но теперь протокол не временнОй (что из-за PC очень тормозной). А по 4-м проводам с подтверждением. По одному проводу передаём 0, по другому 1. Когда РК считал, он ставит 0 на проводе READY. Тогда PC выдаёт очередной бит. При этом "рваность работы" как PC, так и РК86 нисколько не вредит. Для меня лучше 4 проволоки, чем пайка, т.к пайку и возню с железом не люблю. Думаю, что таким протоколом я достигну максимальной скорости, которую не достичь даже с ВВ51. Причём и экран РК гаснуть не будет.

Цитата:

Сообщение от Vladimir_S

регистр который управляет окном 8400...BFFF - и это в 21 веке! Зачем для области памяти регистры управления? Память должна выбираться выставлением адреса процессором.

Диспетчеры ОЗУ есть и в 386-той и даже в Пентиуме, виртуальная память всегда больше физической. И причём здесь текущий век, если используется процессор, что адресует лишь 64К, а ОЗУ - 1 мб. Memory Manager есть в Z180, но в случае РК86 и он бесполезен. Если изначально архитектура уродская, здесь никакой процессор не поможет. А вот диспетчер памяти поможет. Регистр управления в порту удобен, т.к позволяет его считывать и реальный РК имеет низкую нагрузочную способность, так что добавлять регистры ИР22 и нагружать шину мы не можем.

Непонятна критика. Предложите лучшее решение, как использовать в РК86 1 Мб ОЗУ. И как сделать так, чтобы на РК86 работала ДОС с объёмом кода 10-12 кб (плюс дисковые буфера), причём чтобы она могла грузить файлы размером до 7600. Вспомните, что говорил советский разведчик Штирлиц: "Критиковать и злобствовать - проще всего. А вот предложить конкретную программу действий - значительно сложнее".
27.01.2017, 08:56
Vladimir_S

Цитата:

Сообщение от barsik

Предложите лучшее решение, как использовать в РК86 1 Мб ОЗУ.

Не понял как будет использоваться память в 1Мб если речь идет о кусочке 8400-BFFF? Как память для хранения софта или как оперативная?
27.01.2017, 08:57
uart

Цитата:

Сообщение от Vladimir_S

Но вот чем мне не нравятся средства разработки на РС - результат трансляции приходится считывать НЕХ редактором, копировать, потом создавать новый файл, писать туда скпированное с адреса 4, по адресу 0 вносить начало файла, по адресу 2 конец файла. Потом чтать его эмулятором (который естественно показывает ошибку без КС), потом директивой О под этим же именем делать запись уже готового к записи на РК файла. Меня очень раздражают все эти танцы с бубном.

Так попросите автора своего эмулятора поддержать выходной файл вашего ассемблера. Я в своем так сделал, теперь выполняю директиву I и читаю из файла bin, потом O, одновременно читаю I на Апогее.
27.01.2017, 09:18
Vladimir_S

Цитата:

Сообщение от uart

Так попросите автора своего эмулятора поддержать выходной файл вашего ассемблера.

А может там и без просьбы это есть, просто я не в курсе.
http://zx-pk.ru/threads/23087-prekra...kie-bukvy.html
27.01.2017, 13:07
barsik

Цитата:

Сообщение от Vladimir_S

Не понял как будет использоваться память в 1Мб если речь идет о кусочке 8400...BFFF? Как память для хранения софта или как оперативная?

Ответов на этот вопрос много. Каждый использует так, как хочет и может. Моя же концепция использования доп.ОЗУ следующая. Мне доп.ОЗУ нужно не только для загрузки программ в ОЗУ выше 8000, но и для организации из доп.ОЗУ RAM-диска.

Область 8400...BFFF - это окно, через которое CPU получает доступ к памяти значительно больше его адресного пространства. Это архитектура с диспетчером памяти (в противовес архитектуре цельно банковой коммутации, которая тоже имеет свои плюсы).

Но одновремено, это не только окно, но и область где работают ДОС и все те программы, что не должны портить основное ОЗУ. В частности отладчики в этой области позволяют отлаживать любые программы РК86, тогда как отладчики в основном ОЗУ это делать не могут. Текстовый редактор и ассемблер могут иметь всё основное ОЗУ для хранения исходника. А Вы видели, что редактор с макро-ассемблером имеют размеры более 12 кб и если их загрузить в основное ОЗУ, то можно транслировать исходник лишь крошечного размера, что делает макроассемблер бессмысленным.

Программа в области 8400 может занимать своим кодом несколько сегментов по 15К. Но пока это не требуется. Я исхожу из того, что для работы программ из области 8400 отводится только один сегмент в 15 кб. Номер этого сегмента не важен (это первый сегмент, что не из основного ОЗУ). Если ОЗУ раздельные, то это сегмент 0, а если совмещённые, то 2 (тогда сегменты 0 и 1 это куски основного ОЗУ). ДОС при старте
грузится на 8400 и узнает номер текущего сегмента считывая байт из адреса F102. А затем все последующие сегменты использует под RAM-диск. Поэтому ROM-BIOS при сбросе должен инициализировать порт F102.

Из-за того, что для доступа к доп.ОЗУ используется тот же самый участок памяти (8400...BFFF), где работает ДОС, то возникают сложности программирования. Программа работающая в окне 8400 не может сама переключать ОЗУ в этом же окне (иначе при переключении, код самой программы исчезнет из адресного пространства и произойдёт улёт). Подпрограммы чтения/записи из доп.ОЗУ могут располагаться только в некоммутируемой памяти. Именно поэтому так необходимы две подпрограммы в ПЗУ позволяющие читать и писать в любое место ОЗУ, а не только в текущий сегмент, включённый в окне. В крайнем случае, некоммутируемый участок можно программно имитировать в коммутируемом ОЗУ.

П/п-ммы F836/39 не обязаны быть прошитыми в ПЗУ целиком. Достаточно иметь только входы и вектора (заглушенные по сбросу). Тогда для любой внешней памяти можно загрузить драйвер, что сделает входы F836/39 рабочими. Только грузить драйверы расширенной памяти придётся в основное ОЗУ (т.к эти драйверы переключают окно и не могут сами работать в окне 8400).

Пока я стремился сделать эти подпрограммы аналогичными орионовским, т.к тогда мне не требуется переделывать модули VDISK.INC во всех ДОС. Но видимо для такой архитектуры это не оптимально. Процедуры в ПЗУ получились слишком медленными и огромного размера. Это для 256К, а для 1 мб размер кода увеличится. Изменив программный интерфейс (т.е идеологию) можно в те же 75 байт засунуть вместо обмена по 1 байту, обмен целым сектором в 512 байт. Что раза в 3-4 ускорит работу с эл.диском.

Есть ещё один способ организовать доступ к эл.диску при такой архитектуре. При этом даже не требуется менять базовое ПЗУ. Суть в следующем. В каждом сегменте в адресах BFC0...BFFF программно имитируется непереключаемый участок. Для этого в каждый сегмент (программой из основного ОЗУ) в эти адреса записывается один и тот же код. Тогда при включении в окне любого сегмента по адресам BFC0...BFFF остаётся один и тот же код. Т.е этот участок стал как бы некоммутируемым. Где и располагаются две подпрограммы чтения/записи байта или сектора.

ОЗУ размером больше чем 32+16 кб нужно только для ДОС, точнее для эл.диска ДОС. Если же ДОС имеет другой массовый носитель, например "micro-SD"-карточку в 2 Гб, или плату внешнего эл.диска 512К, то доп.ОЗУ более, чем 15 кб не нужно. Для ДОС 15 кб как раз достаточно. Это 10-12 кб для самой ДОС, а остальное под дисковые буфера и системные таблицы (т.к при больших дисках очень большие 'Allocation Tables', VTOC или FAT).
27.01.2017, 23:24
Pyk

barsik, где взять версии РК-ДОС, о которых говорится в этом сообщении?
http://zx-pk.ru/threads/20887-radio-...l=1#post899021

Появилась возможность посмотреть, но вложений уже не вижу :(
28.01.2017, 05:20
barsik

Цитата:

Сообщение от Pyk

barsik, где взять версии РК-ДОС, о которых говорится в этом сообщении?
Появилась возможность посмотреть, но вложений уже не вижу

Действительно, вложение исчезло. Поэтому вложил то же самое вложение в два каких-то предыдущих сообщения. Нельзя класть вложения с одним именем. Новые вложения лучше класть с другим именем. Иначе при удалении старого вложения, удалится и новое.

Переделал для РК86 RK-DOS от эмулятора ОРИОНА. Но пока не до конца. Проблема в том, чтобы найти Z80 команды и заменить их, чтобы работало на КР580. Для обычной программы, т.е в основном ОЗУ - это не проблема. Я запускаю её в своём эмуляторе РК86 на ОРИОНЕ, и если обнаруживается команда Z80, то происходит останов и выход в отладчик эмулятора. Где я смотрю адрес, далее нахожу в листинге трансляции это место и затем исправляю Z80 команду в исходнике. Отчего переделка Z80 --> КР580 происходит быстро.

Но в моём эмуляторе РК на ОРИОНЕ нет ОЗУ выше 8000, в эмуляторе РК на PC нет такой архитектуры. Поэтому приходится использовать эмулятор B2M. А он, в режиме КР580, встретив Z80 команду, не останавливается, а программа просто улетает. И таким образом он никак не помогает очистить код от Z80-команд.

Поэтому пока версия RK-DOS для ОЗУ работает в эмуляторе B2M только с конфигом для Z80. Переделка программ с Z80 на КР580 станет проблемой, если нет эмулятора со свойством отлавливать Z80-команды. Лишний раз доказывает, что надо иметь собственный эмулятор. Полагаться на чужие эмуляторы неудобно.

Но зато увидел с какой скоростью работает электронный диск. Очень долго форматируется. И это ещё п/ри установленном в конфиге клоке CPU 1.77 МГЦ. Причём в чужих эмуляторах нет возможности на время форматирования программно включить эмулируемый такт 100 МГЦ. Хотя скорость чтения-записи файлов приемлемая.

Кстати, во всех конфигах РК86 эмулятора B2M надо заменить частоту клока с 1.77 МГЦ на 1.3. Реальная (эффективная) скорость РК86 - 1.3 МГЦ. 1.77 МГЦ - только с погашенным экраном.

Некоторые современные браузеры (монстрообразные по размеру и скорости работы) заметно тормозят эмулятор (любой). Я использую OPER-у. Если находиться в эмуляторе и одновременно использовать OPER-у, то прогон в эмуляторе тормозится. Это не особо важно, но реакция на клавиши становится плохой. В моём эмуляторе это не проблема, т.к есть настройка и можно сделать любую скорость CPU, хоть 100 МГЦ. Но в эмуляторе B2M скорость не регулируется. Поэтому приходится использовать старые, намного менее тормозные браузеры. Для такого случая я использую Mozilla Firefox пятилетней давности - он совсем не тормозит эмулятор.

Вообще-то грамотный эмулятор должен автонастраиваться на скорость. И желательно не только по его запуску, но и по сбросу. Т.к нагрузка процессора во временем меняется, а скорость прогона программ в эмуляторе не должна меняться.
28.01.2017, 20:52
b2m

Цитата:

Сообщение от barsik

А он, в режиме КР580, встретив Z80 команду, не останавливается, а программа просто улетает.

Эмуляция недокументированных кодов в точности соответствует реальному процессору ВМ80.

Цитата:

Сообщение от barsik

Вообще-то грамотный эмулятор должен автонастраиваться на скорость.

Эмулятор выполняет ровно столько тактов, сколько должно было выполниться за некоторый реальный промежуток времени. Но это при условии, что процессор успевает. Иначе будет пропуск тактов. Сделано не просто так: если процессор одноядерный и не успевает, то чтобы закрыть эмулятор, приходится долго ждать. По крайней мере такое было раньше на ХР - если процессор не успевал, то система практически была в ступоре.
30.01.2017, 00:22
Pyk

barsik, проверил последний вариант из "RKDOS Z80 и оригинал.rar". Как и следовало ожидать, он работает в эмуляторе без проблем.
Варианта с условной компиляцией по ключам DIRORG и NO_KAN я уже не нашел, пришлось комментировать и менять код. Результаты такие:
- если поменять DIR на оригинальный, все работает без проблем
- если поменять в 3-колоночном DIR вызовы OUT_13 в трех местах на вызов F809 с 13 в регистре C, то вывод происходит без переводов строк. Такое ощущение, что оно вообще не вызывается. Попробовал поменять 13 на другой символ - его нет в выводе. Доделаю отладчик - попробую посмотреть, в чем там дело, а пока разобраться проблематично.
31.01.2017, 12:04
barsik

Вложений: 1

Эмулятор B2M с конфигом для РУ7, предложенный B2M, не работает как следует.

Диспетчер ОЗУ в окне 8400...BFFF для РУ7 состоит из одной микросхемы КП11, на вход SEL которой заведён адрес A15 от КР580. Такой диспетчер памяти физически работает так.

При обращении CPU к памяти ниже 8000 с помощью КП11 на адреса памяти A15,A16,A17 подаётся 0, а на адрес памяти A14 подаётся A14 от КР580. Этим в адресах 0...7FFF включается самый младший кусок ОЗУ в 32К, образуя основное базовое ОЗУ.

При обращении CPU к памяти выше 8000 с помощью КП11 на адреса памяти A14,A15,A16,A17 подаются разряды PC0...PC3 из ППА по адресу F100. Тем самым в адресах 8000...BFFF включается сегмент размером в 16К, чей номер записан в порт C ППА.

Из-за клавиатуры на 8000, из 16К сегмента видимы только 15К (отступ 400H). Таким образом при записи в ППА числа 0, в окне 8400...BFFF отображается участок 0400...3FFF базового ОЗУ, а при записи в ППА числа 1 в окне 8400...BFFF отображается участок 4400...7FFF базового ОЗУ.

Эмулятор B2M не включает в окне 8400...BFFF сегмент 1 при записи в ППА числа 01. Т.е основное ОЗУ 4400...7FFF в окне 8400 не включается, сегмент не работает как надо. Этот сегмент оказывается как-бы из абстрактного ОЗУ, никак не связанного с общей памятью. Сегмент 00, т.е кусок ОЗУ 0400...3FFF прекрасно включается в окне 8400. А сегмент 01 не включается.

Более того, старшая половина расширенного ОЗУ вообще не работает. Мне пришлось потратить уйму времени и написать кучу тестов, чтобы понять почему программы не работают в эмуляторе так, как следует.

Вот что стоит в конфиге предложенном B2M:

Код:

mem1 : Memory { size=40000 frame[0].size=8000 frame[0].page=DOPPPA.portC[0-3] }

Ошибка в том, что шаг управления памятью здесь равен 8000, а надо 4000.

А вот как надо, чтобы получить то, что требовалось:

Код:

mem1 : Memory { size=40000 frame[0].size=4000 frame[0].page=DOPPPA.portC[0-3] }

Чтобы убедиться в вышеизложенном достаточно "поставить" в эмуляторе B2M базовое ПЗУ F800 (точнее любое ПЗУ, что не инициализирует порт F102 по WARM BOOT, чтобы можно было менять содержимое порта вручную), записать в F102 число 01, записать директивой M любое число на 4400H и убедиться, что оно не появилось в ячейке 8400. Затем поставьте исправленный конфиг и повторите эксперимент.

Прилагаю тест архитектуры, а также ПЗУ F800 (то же самое, что и раньше, но на 6 байтов больше свободных ячеек).

Показывать 40 сообщений этой темы на одной странице