Просмотр полной версии : Радио-86РК: Подключение дисковода
Vladimir_S
24.01.2016, 16:25
А кстати, как себя ведет дисковод? В разных режимах. Например при форматировании из под монитора.
Да вроде ничего криминального. По команде dir крутит дискету, может даже дорожкой "хрустнуть" потом I/O ERR.
Форматирует медленно, дискету крутит и периодически "похрустывает" дорожками.
- - - Добавлено - - -
С 5.25 контроллер тоже не взлетел, только в этом случае крутит привод, но пишет нет диска.
Vladimir_S
25.01.2016, 06:13
крутит привод, но пишет нет диска.
Если шлейф не трогал, то переставь перемычку на В.
- - - Добавлено - - -
У тебя может шлейф гадить, который идет к кроватке ПЗУ.
Если шлейф не трогал, то переставь перемычку на В.
Запускал на "оригинальном" шлейфе для 5,25.
У тебя может шлейф гадить, который идет к кроватке ПЗУ
Прозванивал перед запуском, причем прозванивал п точкам в РК и точкам на плате контроллера, т.е. не просто сам шлейф. Остается если что только выпаять его и садить контроллер прямо в панельку ПЗУ, но это на крайний случай.
Vladimir_S
25.01.2016, 08:38
прозванивал
Прозванивать бесполезно. У шлейфа дисковода жилы хоть через раз с "землей", а на этом шлейфе сумасшедшие наводки.
Vladimir_S, согласен, в совокупности с импульсным питальником хоть что может быть. РОМ-диск на шлейфе 10см тоже не работает, а в разъеме на плате РК (порт D14) все прекрасно.
Может шлейф этот оплеткой медной обмотать и заземлить?
Попробую еще питальник отрубить и с внешнего БП запитать.
А тестовую прогу для контроллера запускали? Если осциллограф есть, желательно проверить осциллограммы в контрольных точках. Может где то бракованная микросхема попалась.
Сто лет еще не прошло, но все же. В рамках подготовки к клонированию платы контроллера для "Микроши" перерисовал схему в KiCad.
Хорошо бы добавить туда улучшения от Prusak (http://zxbyte.ru/radio86rk.htm), или оставить для поздней ревизии, а пока клонировать оригинал 1:1.
Еще нужно определиться с типом разъема, куда впаивается плата. И с шагом ножек миросхем - метрическим или дюймовым :)
http://sensi.org/~tnt23/rk86/rk986kngmd.png
- - - Добавлено - - -
Краевой разъем - что-то типа ОНп-КС-23 (аналог СНП342-60В)
tnt23, если это внешний модуль для Микроши, то IMHO вообще было бы здорово туда и 16кб ОЗУ добавить.
И с шагом ножек миросхем - метрическим или дюймовым
Если что то ставить в панельки то с метрическими панельками боюсь будет проблема с покупкой.
Потом на основе этой платы можно будет сделать и гибрид с ОЗУ.
- - - Добавлено - - -
Если что то ставить в панельки то с метрическими панельками боюсь будет проблема с покупкой.
Отверстия сейчас диаметром 0.9мм, вроде и дюймовые чипы и панельки должны туда лезть.
Отверстия сделать 1.6х0.97 мм, даже 40-как ножки влезут, но со скрипом :)
Вопрос по схеме, не выбора микросхем ПЗУ.
Отверстия сделать 1.6х0.97 мм, даже 40-как ножки влезут, но со скрипом :)
Вопрос по схеме, не выбора микросхем ПЗУ.
Отверстия можно и 1мм сделать, вопрос в трассировке проводников между площадками. Ну да посмотрим, это поменять недолго.
По поводу панелек - лично я не вижу смысла ставить логику в панельки, ну ВВ55 еще туда-сюда, хотя тоже запаял бы для надежности.
Схема еще не дорисована, конструктивно под ПЗУ все равно одно посадочное место, как в оригинале. Вот потому и тянет туда добавить улучшения от Prusak.
- - - Добавлено - - -
Раскидал микросхемы по плате.
http://sensi.org/~tnt23/rk86/rk86kngmd
вопрос в трассировке проводников между площадками
Я привел цифры с реальных плат. Такие размеры у Мика на Фениксе, у меня на Радио-86РК SRAM(ессно автор не я :) ) и Орион-ПРО, все трассируется хорошо.
Есть "стандарты" на ПП, в свое время по ним считал, очевидно что не я один :)
56993
Все дорожки "сняты", осталось нарисовать и поставить разъем. Кстати, разъемы я нашел в Туле и Брянске, заказал десяток на будущее.
http://sensi.org/~tnt23/rk86/inprogress.png
Занятно, что на плате нет вообще ни одного конденсатора по питанию.
Плата снята целиком, DRC ошибок не находит. Кое-где под микросхемы заглянуть не удалось, но раз со схемой бьется, то буду надеяться, что соединения все правильны.
http://sensi.org/~tnt23/rk86/rc.png
Еще немного повыверяю геометрию, посмотрю на диаметр отверстий под контакты и подумаю насчет увеличить диаметр переходных отверстий. Потом можно отдавать в проявку.
Точно такой же мной был отправлен tnt23 - 4года тому назад.
Кстати удалось оживить?
Mr-Linker, в процессе перерисовывания платы возникли неясности с парой сигналов. Решил посмотреть их осциллографом на включенной плате. Как прежде, компьютер с платой не запускался, но я посмотрел тактовый сигнал и форму сигналов на шинах адреса и данных.
Так вот через какое-то время, нажав "Сброс", увидел подобие запуска: экран проинициализировался и появился мигающий курсор. Символов нет, только курсор, и компьютер стал отзываться на нажатия клавиш.
Набрал ему вслепую "GE000" и по поведению курсора похоже, что ПЗУ живы и отрабатывают :) на линиях дисковода какая-то ерунда, и судя по всему не работает ВВ55, но это уже кое-что :)
В общем, дело было в мертвом ВВ55А. Заменил на такой же, но живой - все зашевелилось, задышало.
Подключил флопик от ноутбука - при старте ДОС диск раскручивается, и выпадает закономерное I/O ERR. Я правильно понимаю, что чтобы отформатировать дискету, нужно откуда-то загрузить (набить в кодах) FORMAT.COM? в дистрибутиве он есть в формате .rk, грузить, надо полагать, с адреса 0, а запускать как?
tnt23, насколько я помню, сначала надо GE000 для инициализации внутренних структур, а уже потом format.rk запускать.
- - - Добавлено - - -
И, кстати, это не format.com. Это отдельный format, специальный.
Vladimir_S
05.05.2016, 04:14
FORMAT из под монитора можно взять здесь.
http://zx-pk.ru/threads/11319-radio-86rk-podklyuchenie-diskovoda.html?p=363684&viewfull=1#post363684
FORMAT из под монитора можно взять здесь.
http://zx-pk.ru/threads/11319-radio-86rk-podklyuchenie-diskovoda.html?p=363684&viewfull=1#post363684
Было бы здорово в первое сообщение треда понадобавлять полезных ссылок, а то сорок страниц пролистывать туда-сюда могут только сильные духом :)
Опять же я надеюсь сюда выложить архив с печатной платой, ссылку на него тоже имело бы смысл поставить в первое сообщение.
- - - Добавлено - - -
Подключил флоп от ноутбука (26 пинов), перегнал форматтер с PC. Дискеты вроде бы форматируются, но заканчивается все одинаково - I/O ERR.
Vladimir_S
06.05.2016, 02:48
tnt23, Покопайся с сигналом ready, может есть смысл посадить его на землю, что бы он как пионер был всегда готов.
tnt23, Покопайся с сигналом ready, может есть смысл посадить его на землю, что бы он как пионер был всегда готов.
Как вариант попробую. Имеется в виду вход контроллера?
Ноутбучные флопы имеют отдельные выходы READY и DC, так что вроде READY работает правильно.
Но попробую, ага.
Vladimir_S
06.05.2016, 09:02
Ноутбучные флопы имеют отдельные выходы READY и DC
Тогда наверное не вариант. А отдельные выходы - это на разные ноги что ли?
Да, в стандарте на 26 пинов есть и то и другое. Позже запощу сюда схему подключения ноутбучного флопа.
У него есть еще один плюс помимо размера - для работы требуется только +5в.
Vladimir_S
06.05.2016, 11:48
+12 нужен только для 5 дюймового.
Точно? В имеющихся у меня БП ATX кишки питания для 3.5 флопов имеют и красный, и жёлтый провода.
Vladimir_S
06.05.2016, 14:50
красный, и жёлтый провода.
Да, во всех разъемах и желтый и красный, но желтый висит в воздухе.
Пробую test.rk на "Микроше" - такое впечатление, что висит. В меню постоянно выбран пункт [1] и на нажатия других цифр не реагирует.
- - - Добавлено - - -
Выгрузил проект в формате KiCad на GitHub:
https://github.com/timtashpulatov/rk86kngmd
Слушайте, а форматирование так и должно медленно идти, примерно 1 шаг за 2 секунды? У меня по-прежнему I/O ERR.
С горя уже подцепил эмулятор флопа, чтобы посмотреть, что пишется на дорожку.
Два заголовка сектора с нулевого трека:
000014f0 11 11 11 11 11 11 11 11 11 11 11 11 44 44 44 aa |............DDD.|
00001500 aa aa 2a 88 88 88 44 44 44 51 44 44 44 51 44 44 |..*...DDDQDDDQDD|
00001510 44 51 44 44 44 51 44 44 44 55 44 44 44 55 44 44 |DQDDDQDDDUDDDUDD|
00001520 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 |DDDDDDDDDDDDDDDD|
00001530 44 44 44 44 44 44 44 44 44 44 45 55 45 45 45 54 |DDDDDDDDDDEUEEET|
00001540 54 45 54 44 44 44 54 44 44 44 54 44 44 45 44 44 |TETDDDTDDDTDDEDD|
00001550 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 |DDDDDDDDDDDDDDDD|
00001560 44 44 44 44 44 42 22 22 22 11 11 11 14 51 11 11 |DDDDDB"""....Q..|
00001570 14 51 11 11 14 51 11 11 15 51 11 11 15 51 11 11 |.Q...Q...Q...Q..|
00001580 15 51 11 11 55 15 11 11 55 15 11 11 11 11 11 11 |.Q..U...U.......|
00001590 11 11 11 11 11 11 11 11 11 11 11 11 11 11 55 15 |..............U.|
000015a0 55 15 55 55 11 55 11 11 11 11 11 11 11 11 11 11 |U.UU.U..........|
000015b0 11 51 11 11 11 11 11 11 11 11 11 11 11 11 11 11 |.Q..............|
000015c0 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 |................|
*
00001f90 11 11 11 11 11 44 44 44 aa 8a a2 22 22 8a 22 22 |.....DDD..."".""|
00001fa0 22 8a 22 22 22 8a 22 22 22 aa 22 22 22 aa 22 22 |".""".""".""".""|
00001fb0 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 |""""""""""""""""|
00001fc0 22 22 22 22 22 22 22 22 22 22 2a aa 2a 2a 2a a2 |""""""""""*.***.|
00001fd0 a2 2a a2 22 22 22 a2 22 22 a2 22 22 22 a2 a2 22 |.*."""."".""".."|
00001fe0 22 22 22 22 22 22 22 22 22 22 22 22 22 11 11 11 |"""""""""""""...|
00001ff0 10 88 88 88 a2 88 88 88 a2 88 88 88 a2 88 88 88 |................|
00002000 a2 88 88 88 a2 88 88 88 aa 88 88 8a a8 a8 88 88 |................|
00002010 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 |................|
00002020 88 8a a8 aa a8 aa aa a8 8a aa aa a8 8a a8 88 88 = DD F3 метка данных
00002030 88 88 88 88 88 88 88 88 8a 88 88 88 88 88 88 88 |................|
00002040 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 |................|
Невооруженным глазом просматривается адресная метка заголовка сектора (0xEA 0xD3):
00001530 44 44 44 44 44 44 44 44 44 44 45 55 45 45 45 54
00001540 54 45 54 44 44 44 54 44 44 44 54 44 44 45 44 44
55545454 55454455
11101010 11010011
В процессе борьбы за восстановление контроллера накодил простейшую читалку данных с диска.
0000: 3E DF 32 02 F0 3A 01 F0-E6 10 C2 05 00 3A 01 F0 >.2..:.......:..
0010: E6 40 C2 0D 00 21 00 10-11 FF 1F CD 2C 00 77 23 .@...!......,.w#
0020: 1B 7A B3 C2 1B 00 3E 7F-32 02 F0 F7 3A 01 F0 E6 .z....>.2...:...
0030: 80 CA 2C 00 3A 04 F0 C9- ..,.:...........
Раскручиваем диск, ждем готовности READY, потом ждем начало сигнала INDEX и принимаем подряд байты в буфер по адресу 1000h. В полученной кашице можно уже искать намёки на секторную разметку.
- - - Добавлено - - -
01 81 19 83 83 06 06 00 00 00 00 00
EA D3 01 03 04 04 00 C0 01 83 83 C1 83 00 00 00 00 00
DD DD F3 00
Благодаря подсказке пользователя uart (ДОС перепрограммирует ПДП ВГ75, а адреса ВГ75 в "Микроше" и "Радио-86РК" различаются, пикантные подробности тут http://zx-pk.ru/threads/26559-nastrojki-pdp-vg75.html?p=871402&viewfull=1#post871402) все заверте!
Сделал файл DEBUG.COM. Располагается в адресах 5ED0-71FF. При запуске устанавливает в адреса 6100-73FF отладчик и на вопрос START? и при нажатии Y отладчик запускается. При нажатии любой клавиши кроме Y - выход в монитор без запуска отладчика. Теперь отладчик можно хранить и грузить с дискет.
Vladimir_S, на "Микроше" после загрузки рисуется знак вопроса и приглашение "Монитора". Одним словом, не работает :( что бы это могло быть?
Кстати, DBG.COM из архива cy6 тоже на "Микроше" не желает работать, просто сбрасывается.
Смотрю, в самом начале кода с 5ED0 есть вызов CALL F990, это какой-то чисто РКшечный вызов? Точки входа "Монитора" же все в F8xx лежат. Может, различия "Мониторов" тому виной?
Смотрю, в самом начале кода с 5ED0 есть вызов CALL F990, это какой-то чисто РКшечный вызов? Точки входа "Монитора" же все в F8xx лежат. Может, различия "Мониторов" тому виной?
Разработчики использовали недокументированную п/п, для уменьшения своего кода.
MF990: MOV A,H
CMP D
RNZ
MOV A,L
CMP E
RET
Vladimir_S
26.05.2016, 04:56
Разработчики использовали недокументированную п/п, для уменьшения своего кода.
Да, это сравнение HL с DE.
- - - Добавлено - - -
tnt23, Замени F990 на FA17 для Микроши.
tnt23, Замени F990 на FA17 для Микроши.
Заменил. Перемещение происходит, но запуск после ответа Y на вопрос START? успевает нарисовать приветствие отладчика и далее происходит сброс.
Нашел в архивах http://home.onego.ru/~bav9/94.html отладчик BDU, попробую его.
- - - Добавлено - - -
BDU оказался не совсем отладчиком. Пошаговый запуск там отсутствует как класс. На очереди OTLADCH из поставки "Микроши", внутри которого безмятежно виднеется копирайт SID.
(не создать ли отдельную ветку для софта, в том числе дискового, под "Микрошу"?)
Vladimir_S
26.05.2016, 14:44
tnt23, А это на микроше не пробовал?
http://zx-pk.ru/threads/11319-radio-86rk-podklyuchenie-diskovoda.html?p=735725&viewfull=1#post735725
tnt23, А это на микроше не пробовал?
http://zx-pk.ru/threads/11319-radio-86rk-podklyuchenie-diskovoda.html?p=735725&viewfull=1#post735725
Ха, забыл! найти что-то в этом треде уже большая проблема :) сегодня попробую. Хотя это же ассемблер с редактором, а не отладчик.
- - - Добавлено - - -
Vladimir_S, редактор сохраняет и грузит нормально. Единственное, что при попытке снова сохранить файл под тем же именем выдает сообщение "ПОВТОРНОЕ ИМЯ" и все. То есть, видимо, нужно выходить в дос, грохать файл, возвращаться в редактор и сохранять снова.
Vladimir_S
27.05.2016, 07:46
выдает сообщение "ПОВТОРНОЕ ИМЯ" и все
Да, это я не пробовал. Да и не к чему. Если пишешь какую то программулину, то лучше сохранять промежуточные варианты под разными именами, проще откат делать. А и все это что? Я сейчас в отпуске и на железе проверить не могу.
- - - Добавлено - - -
И еще, может переделать редактор, что бы он работал только с файлами ASM? Соответственно и каталог выводил только ASM? Тогда на запрос имени, вводить только имя без расширения.
Да, это я не пробовал. Да и не к чему. Если пишешь какую то программулину, то лучше сохранять промежуточные варианты под разными именами, проще откат делать. А и все это что? Я сейчас в отпуске и на железе проверить не могу.
- - - Добавлено - - -
И еще, может переделать редактор, что бы он работал только с файлами ASM? Соответственно и каталог выводил только ASM? Тогда на запрос имени, вводить только имя без расширения.
"И все" - надпись просто остается до нажатия любой клавиши, после чего идет возврат в редактор. На диск ничего не записывается.
Сохранять промежуточные варианты - это, по-моему, на любителя. Было бы здорово сделать все же перезапись следующим образом:
- проверить, есть ли уже такой файл (или обработать код ошибки "файл уже существует")
- если он есть, переименовать его в .BAK
- сохранить новый файл
Работать только с .ASM неудобно, IMHO. Например, я сделал файл DOS29.H с определениями всех функций и ячеек ДОС и загружаю в редактор его, а потом уже свои тексты .ASM.
- - - Добавлено - - -
По мотивам исходников утилиты DUMP из поставки CP/M 2.2 сваял аналогичное для ДОС 2.9. Не умеет тормозить по пробелу и выходить по УС+Ц, и не показывает ASCII, но это все дело наживное. Загружать и запускать с адреса 1100H.
Vladimir_S
28.05.2016, 04:36
tnt23, Согласен, утилитка полезная. насчет ASCII, это наверное лучше отдельную LIST утилиту написать. И насчет пробела и УС+Ц - вставить 13 байт.
- - - Добавлено - - -
А кстати, почему не в 'своих' адресах выводится?
HardWareMan
28.05.2016, 07:10
Микрон?! Ты ли это?
Про вывод "в своих адресах" я думал, но пока оставил как есть. Для этого нужно вычитать адрес загрузки из VTOC, да и классический дамп дает представление об относительном смещении от начала файла.
Это все можно доделать-добавить, вот перетащу исходник с "Микроши" и выложу.
Занятно, что ДОС читает несколько секторов за раз при операциях OPRD/READ, типа read ahead такой. Хорошо видно при работе утилит TYPE и DUMP :)
Vladimir_S
28.05.2016, 09:04
Микрон?! Ты ли это?
Да, это я.
/Микрон/
Меж тем, есть фундаментальная проблема переноса данных, а точнее, несовместимости формата дорожки ДОС2.9 с остальным миром. Большинство современных FDC уже не умеют переключаться в режим FM, а которые и умеют, не поддерживают (нестандартных) синхросбоев.
С другой стороны, ДОС2.9 аппаратно заточена на FM с одним-единственным типом синхросбоя. Даже если добавить несложное расширение схемы, в лучшем случае она сможет читать FM дискеты, записанные другими контроллерами. На поддержку CRC уже не хватит ресурсов, не говоря уже о MFM.
XXI век на дворе, неужели так и пользоваться магнитофонным гнездом?
HardWareMan
29.05.2016, 15:05
Можно прикрутить синезуб. Все становится лучше, если к нему прикрутить синезуб.
Можно подумать в сторону nRF24 или вовсе уж esp8266
Ну что, так и не прикрутили ВГ93 к 86РК?))
makbar, в Партнере прикрутили.
uart, я просто вчера нашел старые расчеты, как это можно сделать...
p.s. а что такое "Партнер"
p.s. а что такое "Партнер"
https://ru.wikipedia.org/wiki/%D0%9F%D0%B0%D1%80%D1%82%D0%BD%D1%91%D1%80_01.01
Повторил журнальный floppy контроллер. Основная особенность - мелкую логику заменил на EPM7032. Подробности во вложении (или здесь (https://yadi.sk/d/tKA2UdNrsbMdU)).
makbar, в Партнере прикрутили.
Где?
Узнав, что с РК-КНГМД и дисководами без READY некоторые имели проблемы, решил поделиться своим опытом использования РК-КНГМД.
Я столкнулся с этим в 1995, когда стал использовать РК-КНГМД с HD-дискетами на TEAC 5.25''. Сначала я поставил один КМОП 561 серии, формирующий READY с задержкой на 2 секунды после поступления START. Это работало, но всё-равно я перетранслировал РК-ДОС, чтобы READY не использовался (он эмулируется из сигнала INDEX). Тем самым проблема была решена раз и навсегда.
Из РК-ДОС Е.Седова я взял п/п-мы чтения/записи сектора и поставил на РК86 CP/M. Сначала в несовместимом варианте с высоким TPA, что позволяло использовать ЯВУ. Но затем от этого отказался в пользу совместимого варианта (т.к ЯВУ для 8-ми разрядки бесполезны). Совместимость достигается за счет того, что доп ОЗУ до 128К прокачивается в окне 8400...BFFF. В этом ОЗУ работают разные ДОС. Причём, в отличие от РК-ДОС, запускают файлы РК любого размера. Главная польза от CP/M - в компилляторе M80. Т.к я использовал на РК86 красивый фонт 8*10 с инверсией и аппаратную клавиатуру (от APPLE-IIe), то пользоваться РК было комфортно.
Однако CP/M использует деблокирование физических секторов (лишние копирования), поэтому реально работает намного медленнее РК-ДОС. А т.к РК имеет реальный такт всего в 1.2 МГЦ, то пришлось принять меры ускорения. Для этого вместо секторов в 512 байт, я стал использовать сектора в 2К, а затем перешёл на формат - один сектор размером со всю дорожку. Кварц в РК-КНГМД я ставил до 20 МГЦ и скоростей даже на нетурбированном РК вполне хватало.
Оказалось, что РК-КНГМД обеспечивает намного лучшую надежность, чем КНГМД с ВГ93. Особенно, когда диски старые и дохлые. Если ВГ93 на старой дискете дает 800 Кб дохлоты и 0 Кб свободного места, то РК-ДОС дает 560 Кб свободного места и 0 Кб дохлоты. Особенно надежны древние дисководы на 35 дорожек. Пусть всего 130 Кб, но зато работают дискеты ИЗОТ 1985 года.
Поэтому уже в 2000 году я выкинул КНГМД на ВГ93 и стал использвать РК-КНГМД на всех своих компьютерах. Имея те-же самые 800К, но без проблем с дохлотой. RK-DOS в базовом виде, естественно, не может поддерживать никаких других форматов, кроме 400К. Её пришлось перетранслировать, попутно введя в РК-ДОС поддержку электронного диска. Для РК-ДОС РК86 пришлось странслировать свой НОРТОН, использующий инверсию знакомест (т.к иначе никак не вывести "балку подсветки").
После 1997 я использовал РК-ДОС 3.0 только на ОРИОНЕ с Z80. Необходимость в реальном РК, отпала, т.к я написал эмулятор РК86 на ОРИОНЕ с Z80. Скорости ОРИОНА позволяли с РК-КНГМД иметь формат 880К (11 секторов), но РК-ДОС не может обслуживать более 640К. Поэтому пришлось написать свою ДОС, работающую так же быстро, но устраняющую все недостатки РК-ДОС.
HardWareMan
20.11.2016, 14:38
А т.к РК имеет реальный такт всего в 1.2 МГЦ, то пришлось принять меры ускорения.
Как же так, Кормилец? при 16МГц кварце ГФ24 выдает: 16/9=1,7МГц. А при твоем 20МГц - 20/9=2,2МГц.
barsik, так может стоит свои наработки для всех выложить?!
Как же так? При 16 МГЦ кварце ГФ24 выдает: 16/9=1,77 МГЦ. А при 20МГц - 20/9=2,2 МГЦ
Речь шла о такте РК-КНГМД. Режим HD/DD переключается перемычкой на флопе - при этом меняется скорость колеса и ток подмагничивания. Дисковод 5.25'' в режиме HD вращается со скоростью не 300, а 360 об/мин, т.е на 20% быстрее. Чтобы при этом РК-КНГМД мог работать в формате 400К надо одновременно увеличить такт на те же 20%. Т.е на РК-КНГМД надо подавать не 16 МГЦ с платы РК86, а такт 20 МГЦ. Для этого на плате РК-КНГМД устанавливается генератор на 531ЛН1 с кварцем 20 МГЦ.
Я не использовал на РК86 формат более 6 секторов (480К), но почти уверен, что базовый РК потянет и формат 7 секторов на трек (560К).
Теоретически в РК-ДОС для РК86 можно использовать формат диска до 8 секторов. Но лишь при расширении ОЗУ (выше 8400), т.к РК-ДОС 3.0 для любого числа секторов имеет размер 6К в кодах Z80 (хотя там ёще драйвер эл.диска 180К из лишнего ОЗУ ОРИОНА). Большую ДОС можно грузить только в верхнее ОЗУ. Базовая РК-ДОС не имеет БПД (блока параметров диска), поэтому, в отличие от CP/M, может работать только в одном формате.
Совместимость c старыми программами при РК-ДОС в верхнем ОЗУ не потеряется, если в ПЗУ E000 прошить программу из 2-х команд - XOR A : JP A000H. TS-EDIT, DOCTOR жёстко рассчитаны на формат 5 секторов, поэтому мне пришлось написать CHKDSK РК-ДОС. При наличии "верхнего" ОЗУ, не надо тратить базовое ОЗУ на дисковые буфера, отчего можно запускать файлы любого размера.
При формате в 7...11 секторов приходится ставить кварц ещё намного выше. Т.к высокочастотные кварцы дефицитны и работают нестабильно, я разрезал перемычку между 12 и 1 ногами ИЕ5, подав такт на ногу 1. Исключив тем самым из цепочки деления один триггер. Тогда входной такт надо подавать вдвое меньше. Т.е для стандартного формата РК-ДОС и DD-НГМД - нужно 8 МГЦ.
При кварце 10.5 МГЦ на DD-дисках я имел формат 7 секторов (560К), а при кварце 16.5 МГЦ - на HD-5.25'' - формат 9 секторов (720К) и на 3.5'' - формат 11 секторов (880К). Для этого мне приходилось на плате КНГМД иметь переключатель двух кварцев. Но в последние 15 лет новых дисков не достать, поэтому старые полудохлые HD-диски 3.5'' приходится использовать в формате 560К.
Поправка. Реальная скорость РК86 в стандартном режиме не 1.2 МГЦ, а 1.3 МГЦ. А в графическом режиме 64 строк - 800 КГЦ.
Кстати, мой РК86 с ОЗУ TMS4164-20 при турбировании по схеме РАДИО 01.1991 без В/У "тянул" кварц 32 МГЦ. Но, увы, при подключении эл.диска и РК-КНГМД приходилось снижать кварц до 24 МГЦ и всё-равно надёжность резко снижалась (это из-за отстутствия буферов ОЗУ). Попытка поставить ВК28 на отдельной платке, втыкаемой в панельку КР580, - не получилась, и я до сих пор не знаю почему. Из-за этого я не стал ставить Z80, опасаясь, что не будет работать по той-же непонятной причине. Из-за этого пришлось бросить РК86.
может с`тоит свои наработки для всех выложить?
Что Вас конкретно интересует? CP/M для РК86 или аппаратные улучшения РК86?
Сохранились исходники оригинальной РК-ДОС 2.95, форматеров и SYS-утилит. Даже при наличии IDA, это может c'экономить кому-то много часов (метод работы со стеком Е.Седова трудно дизассемблировать в полноценный исходник, надо анализировать код и вручную считать адреса).
CP/M для РК86 не проблема, это легко сделает любой за час работы - 50 мин, чтобы дизассемблировать ДОС и выдрать п/п-мы чтения/записи сектора, и 10 минут чтобы странслировать CP/M. У меня конкретно исходников тех CP/M для РК86 нет. При гибели винчестера на PC в 2000 погиб весь архив, по счастью всё актуальное сохранилось на винчестере ОРИОНА. Но есть версии для ОРИОНА и их перетрансляция для любого железа не представляет проблемы.
Если хотите, я Вам странслирую CP/M для РК-КНГМД для базового железа. Практической пользы это не даст, т.к CP/M отнимает 8К ОЗУ и поэтому для программ остается лишь 20К. Любую программу большего размера Вы не загрузите. Хотя M80 пользоваться сможете. Поэтому без расширения ОЗУ CP/M почти бессмысленна.
Программ именно для РК86 я не писал, т.к перестал пользоваться РК очень давно. Но для РК-ДОС сделал программатор УФ-ПЗУ, текстовый редактор, макро ассемблер, CHKDSK и нортон РК-ДОС для ОРИОНА. Причём странслировал его версию и для РК-ДОС РК86, используя инверсию для вывода балки подсветки и окон. Любые корректные текстовые программы для КР580 не сложно перетранслировать для РК. Например, для адаптации текстового редактора достаточно убрать из исходника команды Z80, изменить работу со служ.ячейками POSX, POSY (в РК они в обратном порядке) и учесть неприятное смещение начала координат на 3,8.
Почти все чужие программы РК86 у меня сохранились, но думаю, они у всех и так есть. Это были игры с 4-х дисков из Лианозово и то, что я считал со своих кассет РК из 1987-88. И мне кажется, что всё это я видел ещё в 1999 в дистрибутивах эмуляторов Пыхонина и Дёмина. Так, что это не представляет интереса.
Сам я играю на РК86 (в своём эмуляторе РК на ОРИОНЕ) только в XONIX (чтобы было интересно играть, я "забил" жориков, т.к они не дают спокойно играть, благодаря чему набирал 14.000 очков). У меня есть дизассемблированными с десяток игр РК (пришлось дизассемблировать, чтобы понять почему они не работают в эмуляторе). Но сейчас, когда есть интерактивный дизассемблер IDA, получить исходник любой программы стало на порядок проще, чем это было с древним дизассемблером DISZILOG, так что это тоже не актуально.
Несколько ДОС, что я написал для РК-КНГМД и для винчестера используют Z80-команды (т.к без индексных регистров просмотры VTOC и построение Allocation Table получаются громоздкими), но я их собираюсь в будущем переделать на КР580, чтобы применить на ИРИШЕ с КР580. Свои ДОС мне пришлось писать потому, что
отрывок старого текста:
Недостатком CP/M является её непригодность для больших дисков. CP/M лишь теоретически поддерживает диски до 8 Мб. Но т.к CP/M хранит список файлов всех юзеров в общем списке, то уже при числе файлов более 200, поиск оказывается слишком медленным. ALLOC TABLE общий на весь диск и его построение для большого диска сильно тормозит (и отнимает слишком много места в ОЗУ). В итоге, при реальных тактах Z80, CP/M неудобна для дисков с объёмом более 2 Мб. Остается лишь разбивать 40 мегабайтный винчестер на 20 дисков, а т.к для каждого диска CP/M отводит служебное ОЗУ, то уровень BDOS фатально падает, что делает такую версию CP/M бессмысленной. Для использования на ОРИОНЕ с винчестером более удобна TURBO-DOS 3.20, которая рассчитана для работы на медленных компьютерах с маленьким ОЗУ с дисками большого объёма.
Чтобы было понятно какие апп.доработки я использовал на РК86, придётся привести ещё один древний текст. Помещу его в следующем посте.
- - - Добавлено - - -
Это мой древний текст про железо, чуть дополненный.
Я не люблю возиться с железом, поэтому признаю только простейшие доработки. Если доработку нельзя сделать за 2 часа, это неприемлемо. А дико громоздкий монстр РК-МАКСИ, что опубликовал недавно РАДИО - это издевательство. Сомневаюсь, что хоть кто-то это сделал... Гораздо выгоднее маленькие, но нужные доработки, чем сложные и бессмысленные. И глупо менять архитектуру, теряя совместимость с имеющимся ПО. Улучшения должны быть совместимы - это аксиома! Пентиум совместим с XT образца 1982 года. Кто этого не придерживается, тот явный вредитель и враг народа...
Я занимался РК в 1987-88 годах, делая первые шаги. Затем в 1993 г достал РК-ДОС и на её базе сделал РК-CP/M с РК-КНГМД. CP/M нужна вовсе не из-за ЯВУ (для 8-ми разрядок они бесполезны). И не для обслуживания дисковода, - для этого хватает РК-ДОС, несмотря на всю её убогость. А только из-за макро ассемблера M80. Только с M80 можно заниматься разработкой программ (и в принципе НГМД не обязателен, достаточно эл.диска). Попутно мне пришлось сделать некоторые доработки РК86, т.к базовое железо не устраивало для многих задач.
РК86 FOR EVER
Вот перечень простейших переделок РК86, что я сделал в 1988-96 и которые превращают РК86 в приемлемую машину
1. Выкусываем 155ЛА3, заменяем на ЛА9 (они совпадает по цоколевке, но ЛА9 - ОК) и методом монтажного ИЛИ получаем /CAS для 565РУ5. Выкидываем 2 банки РУ3 и ставим РУ5 (надежнее, проще и потенциально 64К). Работа паяльником на 15 минут.
2. Совместимым образом расширяем ОЗУ. Это несколько доп ИМС 555 серии. Результат: в окне 8400...BFFF - прокачиваются две банки ОЗУ по 15К, коммутируемые битом ППА D14. Получаем 62К ОЗУ, причем нет нагрузки шин, отчего надежность не падает. Расширение ОЗУ необходимо, чтобы из него могли работать разные ДОС (не снижая объём ОЗУ для программ). Работа паяльником на 2 часа.
3. Заменяем в плате РК кварц 16 МГЦ на 20. Счетчик ИЕ4 меняем на ИЕ5 (+ 2 диода). Перешиваем ПЗУ знакогенератора. И получаем матрицу знакоместа 8x8, вместо 6x8. Фонт значительно красивее и ускорение на 25%. Работа паяльником на 1 час.
4. Вариант для рамок. Ставим 3 диода по схеме, как и рассчитана ВГ75 и получаем 11 символов для рисования рамок. Но в РК86 это получается плохо, т.к горизонталь идет по линии подчеркивания. Работа на 0.5 часа, но делать это не стоит.
5. Вводим инверсию знакомест на базе атрибута RVV, по статье "Цветные РК86" в РАДИОЛЮБИТЕЛЕ (1993, а RVV - это ReVerse Video). Расход: ТМ2, ЛП5 и 2 диода. Такая инверсия проста, но не совместима с п/п-ми ПЗУ. Сделать можно, не вредит (есть программы это использующие). Но для программиста более удобна инверсия за счёт альтернативного фонта (см.далее). Работа на 0.5 часа.
6. Вводим два фонта. Дошиваем в ПЗУ знакогенератора РФ2 альтернативный фонт. Управление текущим фонтом одним битом из ППА D14. Шины не нагружаются, - надежность не падает. Расход деталей: 10 сантиметров проволоки. Работа паяльником на 10 секунд.
7. Делаем ТУРБО. Используя идею из РАДИО 01.91, ставим отдельный генератор для ГФ24 с частотой 24...30 МГЦ (сколько Ваш РК потянет). Последовательно с кварцем нужна емкость 5-10 пф. Получаем быстродействие намного выше оригинала. Работа паяльником на полчаса.
8. Подключаем винчестер к РК86. Покупаем Б/У винчестер на 40 Мб. Паяем интерфейс на 3-х корпусах 1533 (есть схемы и проще, но у меня их не было, и я сделал так). Прошиваем в ROM-диск соответствующую DOS (и не обязательно CP/M). Это работа уже на 8 часов, но винт того стоит, т.к старые дискеты дохнут как мухи...
Достигается значительное улучшение компьютера при минимальных расходах деталей и времени. Сразу не понятно, но особенно ценно введение второго фонта. Что дает инверсию знакомест, нужную для НОРТОН-ов, рисование рамок, возможность открывать окна на экране, и графику 192x128 (с базовым фонтом графика 128x128). В режиме графики ВГ75 перенастраивается на режим в 64 строки (вместо 30 в станд.режиме), а экран переносится в доп.ОЗУ, выше 8400. Наличие второго фонта позволяют иметь КОИ-8: маленькие русские буквы прошиваем вместо кодов псевдографики (0...1F). Кстати первым графику 192x128 сделал кто-то в 1989 году (см.РАДИО о радиолюбительской выставке 1989).
Но, как говорят, "хороша ложка к обеду". Эти идеи пригодись бы в 1988 году, но в 1995 были уже никому не нужны. Тем не менее, переключение фонта реализовано в моём эмуляторе РК для ОРИОНА (в моём эмуляторе для PC этого нет, т.к я не поддерживаю этот эмулятор с XX века, а эмулятор РК86 на ОРИОНЕ использую в эмуляторе ОРИОНА на PC, т.е при двойной эмуляции).
Чтобы закончить проект RK86 FOR EVER осталось сделать всего 3 вещи.
- заменить КР580 на Z80
- сделать в РК 256К ОЗУ, заменив РУ3/РУ5 на РУ7 (даёт RAM-диск для ДОС)
- обеспечить РК полноценной графикой.
В 1988, я спаял внешнюю плату граф.адаптера 384*256 по схеме RFE 10.1987 (21 TTL-корпус + банка 4116). Но тогда я не мог поддержать это программами, теперь такая возможность есть.
Можно также сделать несложную плату граф. процессора на ГДК 1809ВГ4 (его прототип NEC 7220, или 82720 разных фирм). ГДК это графический дисплейный контроллер. Он существенно упрощает плату графического адаптера для РК, причем реализует множество эффектов: сдвиги во все стороны, панорамирование, ZOOM... Но нам ценно то, что мало корпусов, что важно при ручном монтаже. Т.о малой кровью получаем графику. В 1993 я купил 15 штук NЕС 7220, но тогда даже не дошёл до пайки. Есть и вся документация на ГДК 1809ВГ4. Схемка платки - в журнале FUNKAMATEUR 07.1990 (там же дамп п/п-мм для CP/M-BIOS). Смотри также журнал RFE 04.89 (это журнал из ГДР "Radio Fernsehen Elektronik", там есть и список литературы).
HardWareMan
21.11.2016, 07:45
Речь шла о такте РК-КНГМД. Режим HD/DD переключается перемычкой на флопе - при этом меняется скорость колеса и ток подмагничивания. Дисковод 5.25'' в режиме HD вращается со скоростью не 300, а 360 об/мин, т.е на 20% быстрее. Чтобы при этом РК-КНГМД мог работать в формате 400К надо одновременно увеличить такт на те же 20%. Т.е на РК-КНГМД надо подавать не 16 МГЦ с платы РК86, а такт 20 МГЦ. Для этого на плате РК-КНГМД устанавливается генератор на 531ЛН1 с кварцем 20 МГЦ.
Поправка. Реальная скорость РК86 в стандартном режиме не 1.2 МГЦ, а 1.3 МГЦ. А в графическом режиме 64 строк - 800 КГЦ.
3. Заменяем кварц 16 МГЦ на 20. Счетчик ИЕ4 меняем на ИЕ5. Перешиваем ПЗУ знакогенератора. И получаем матрицу знакоместа 8x8, вместо 6x8. Фонт значительно красивее и ускорение на 25%. Работа паяльником на 1 час.
Пора бы уже определиться, о чьей скорости речь. Какое конкретно значение вкладывается в "реальная скорость РК[86]"? Как она измерялась? И почему, одно и то же применяется то к самому РК86, то к его контроллеру РКНГМД?
В первых двух постах речь о РК-КНГМД и о том какие кварцы я в него ставил. И соответственно о кварце на плате РК речь не идет (предполагается базовый нетурбированный РК). В третьем посте (правда он почему-то "слипся" со вторым), речь идёт уже о доработках самой платы РК86 и о КНГМД там ни слова.
Доработку фонта до красивого (пункт 3) можно делать как с двумя кварцами (тогда на счетчики и ВГ75 подается такт 20 МГЦ, а для ГФ24 остаётся старый кварц 16 МГЦ). Это получается как бы ТУРБО-1991 наоборот, увеличиваем не такт КР580, а такт сдвига точек на экране, в то время как при ТУРБО-1991 такт сдвига точек остаётся 16 МГЦ, а такт КР580 увеличиваем до предела. Такой вариант удобен, чтобы играть в игры РК на старой скорости.
Однако из экономии, можно использовать один кварц 20 МГЦ, заменив кварц ГФ24 (тогда не надо отрезать входы счётчиков от OSC). При этом и быстродействие поднимется на 30% и на знакоместо будет приходиться не 6 тактов сдвига, а 8.
Турбирование и смена ширины фонта возможны потому, что узел ВГ75 с счётчиком точек знакоместа на ИЕ4/ИЕ5 и процессорное ядро работают асинхронно. Поэтому для жульничества в игре удобен триггер, который делит такт для КР580 вдвое (коммутация не тумблером, иначе при переключениях ОЗУ разрушается, а например, КП11)
Насчёт реального такта. Это же не серьёзный вопрос. Ну что так трудно написать программную петлю, которая длится, например, минуту. И сравнить с прогоном этого фрагмента на компьютере без ПДП и WAIT. Я это делал в 1988 на СПЕЦИАЛИСТЕ, сравнивая его с РК.
Киньте мне в личку Ваш адрес E-mail, я скину Вам вложением к письму исходники программы, которая измеряет скорость компьютера. Если Вы не программист, то скину с инструментарием, так что надо будет только запустить BAT-файл.
На реальных ЭВМ тест даёт верные результаты. А вот в эмуляторах нет. Потому что во всех эмуляторах времена прогона команд не сбалансированы. Потому при одном наборе команд в тесте будет один результат, а при других командах другой. Точно сбалансировать времена команд невозможно, т.к процессоры разных фирм работают по разному (разные конвейры, кэши и даже число тактов на команду).
В эмуляторе более верные результат дает прогон CP/M-программы CPUTEST.COM (размер 19К, CRC: CE8E), т.к в ней прогоняются при тесте все команды КР580.
Так вот. В реальном базовом ОРИОНЕ она прогоняется за 95 секунд, а в РК86 в стандартном режиме дисплея - 182 секунды. Что и даёт скорость РК точно в 1.3 МГЦ.
HardWareMan
21.11.2016, 19:34
Насчёт реального такта. Это же не серьёзный вопрос. Ну что так трудно написать программную петлю, которая длится,
например минуту. И сравнить с прогоном этого фрагмента на компьютере без ПДП и WAIT. Я это делал в 1988 на СПЕЦИАЛИСТЕ, сравнивая его с РК.
Ясно, опять "попугаи" измеряют люди. Вопрос закрыт.
Совместимым образом расширяем ОЗУ. Это пара корпусов 555 и перекидываем 2 адреса на КП11 (иначе нет регенерации выше 8000). Результат: в окне 8400...BFFF - прокачиваются две банки ОЗУ по 15К, коммутируемые битом порта D14. Получаем 62К ОЗУ
Доброй ночи! Можно узнать подробнее про эту доработку?
В РК maddev*xlat (http://zx-pk.ru/threads/25696-plata-radio-86rk-(novodel-versiya-maddev*xlat)-obsuzhdenie.html) уже стоят РУ5, осталось доработать, чтобы использовать более чем 32К. :)
Сохранились исходники оригинальной РК-ДОС 2.95, форматеров и SYS-утилит.
Интересно!
barsik > исходники оригинальной РК-ДОС 2.95, форматеров и SYS-утилит
Интересно.
Интересно что? Непонятно. Исходники для самого РК86 не интересны, т.к уже ничего невозможно изменить в РК-ДОС. Там очень плотный код, нет ни одного свободного байта (кроме надписи "E.SEDOV" в конце). ДОС 2.95 это предел того, что можно выжать из КР580 и 4К ПЗУ. Лучшая версия для такой архитектуры уже невозможна. Единственное для чего может понадобиться такой исходник - это адаптация для РК на Z80. После устранения OUT и тому подобных вещей, код разбухнет и не будет влезать в 4К. По счастью выручают JR-команды. Они позволят ужать код до 4К.
Из контекста понятно, что речь идет не об оригиналах Е.Седова (где бы я их взял ?), но о полноценных исходниках, полученных ручным дизассемблированием. Получить просто дизассемблированный текст (например, чтобы посмотреть код) - очень легко. А вот получить полноценный исходник, т.е чтобы код можно было перемещать, без потери функциональности, намного сложнее. Особенно, если используется извращённый метод работы со стеком. При этом недостаточно понять где код, где данные, - приходится разбираться в коде.
Мне пришлось получать полный исходник РК-ДОС, потому что надо было перемещать код. Чтобы получить несмешную версию РК-ДОС для ОРИОНА. Оригинальная версия, т.е с управляющими ячейками посередине ОЗУ глупо выглядит на ОРИОНЕ. И кстати, мне пришлось пользоваться примитивным дизассемблером, что сложнее.
У РК-ДОС очень неудачный интерфейс. В отличие от других ДОС, она абсолютно неперемещаема, т.к интерфейс в ней не только через вход E001, а напрямую управляется жестко фиксированными ячейками в ОЗУ. Поэтому грамотно переделать RK-DOS для другого компьютера невозможно, не потеряв совместимости. Даже сохранив вход E001, но убрав из области 7600 управляющие ячейки ДОС, теряется совместимость с абсолютно всеми программами РК-ДОС. Поэтому для переноса РК-ДОС и упр.ячеек на другие адреса (сразу под экран C000), мне и пришлось получать исходники всех программ РК-ДОС.
В РК-ДОС для Z80 мне пришлось также убрать работу с портами командами IN/OUT, а также анализ флагов КНГМД командой INC (HL), адресуемой в порт.
Исходники оригинала РК-ДОС не интересны, т.к их очень легко получить. Более интересны версии RK-DOS переделанные на другой формат диска. Но они только для ОРИОНА. Причём на Z80 (вариант "голый Z80", т.е базовая схема установки Z80 1991 года). Переделать обратно на КР580 - не проблема (достаточно заменить JR и DJNZ), т.к другие свойства Z80 не использованы. Но полученный код КР580 не влезет в ПЗУ 4К на плате РК-КНГМД, даже если выкинуть драйвер эл.диска из излишнего ОЗУ ОРИОНА.
Если Вы скинете мне в личку Ваш E-mail адрес, то через час я пришлю Вам исходники РК-ДОС, форматеров и SYS-файлов (всех кроме тех, что для работы с МГ, это мне было не надо).
Могу также скинуть сами версии РК-ДОС для ОРИОНА, - только скажите для реального ОРИОНА на Z80, или для эмулятора ОРИОНА. В обоих диск A: это эл.диск из излишнего ОЗУ, поэтому их можно стартовать без дисковода, как в реале, так и в эмуляторе. Версия для реала имеет подпрограммы РК-КНГМД. Причём ДОС для ОДНОГО конкретного числа секторов, т.е есть версии на 5 секторов, 7 секторов и 8 секторов. Кроме того в версии РК-ДОС для ОРИОНА встроены драйверы шрифтов 5*10, 6*10, 6*8, 7*10, 8*10, 8*8 разных версий.
Т.е возникает очень много версий. В итоге общее число исходников всего, что есть для РК-КНГМД составляет 48 мб (28 мб для CP/M, 19 мб для РК-ДОС и 1 мб других ДОС). Версии для эмулятора отличаются тем, что в них для эл.диска используются 7, а не 4 банки ОЗУ ОРИОНА - столько остаётся в ОЗУ PC после загрузки самого эмулятора ОРИОНА (90 Кб). Если в Вашем эмуляторе ОРИОНА банок ОЗУ меньше 7, то в версиях для эмулятора будут проблемы.
Можно узнать подробнее про расширение ОЗУ на 565РУ5?
Сутки назад ответил E-mail-ом.
Кто-нибудь скиньте какое-нибудь сообщение (минимальное это - 1 точка) в эту тему. Нужна прослойка. А то, если я сделаю следующее сообщение, то оно "слипнется" с этим (на других WEB-движках этого нет).
Интересно что? Непонятно. Исходники для самого РК86 не интересны, т.к уже ничего невозможно изменить в РК-ДОС. Там очень плотный код, нет ни одного свободного байта (кроме надписи "E.SEDOV" в конце). ДОС 2.95 это предел того, что можно выжать из КР580 и 4К ПЗУ.
Интересно - в смысле "интересует". Исходники РК-ДОС интересуют не с целью что-то в них изменить, а посмотреть, как там сделано то да сё. Например, нигде никакой информации по поводу "резидентных драйверов ДОС" нет.
Варианты и переделки под Орион, к сожалению, меня лично не интересуют. Но вдруг кого интересуют?
Мой email: tim.tashpulatov@gmail.com. Спасибо.
tnt23 я послал Вам E-mail-ом 15 мб исходников, 13 мб некачественных фотографий и 1 мб текстов. Все тексты и исходники в альтернативной кодировке MSDOS с построчными разделителями 0D,0A.
Можно узнать подробнее про расширение ОЗУ на РУ5?
Готовя E-mail нашёл в древних текстах фрагменты о расширении ОЗУ РК86. Причём это даже не все, есть ещё, как минимум два, подобных текста, где рассказывается о простых аппаратных доработка РК.
Проблема решается, если иметь в адресах выше 8000 дополнительное ОЗУ, только для целей системы. Если в РК86 память выполнена на 565РУ3, то расширить ОЗУ удобно на статических ОЗУ 6264. Плата РК86 специально имеет участок "слепыша" (со стороны ПЗУ с фонтом), где при минимальных трудозатратах за полчаса труда распаивается панелька для 6264 (537РУ17).
Если же основные 32К ОЗУ реализованы на 565РУ5, то есть еще один вариант расширения ОЗУ. ОЗУ РУ5 ставятся следующим образом. На 13,14 ноги мультиплексора DD19 заводят адреса А14,А15 (38,37 ноги КР580) и выход 12 этого мультиплексора формирует адрес MX7 для динамических ОЗУ (9 нога у РУ5). Микросхему DD10 155ЛА3 выкусывают и запаивают вместо неё 555ЛА9 (это то же самое, что ЛА3, но с открытым коллектором, поэтому выходы вентилей ЛА9 можно соединять друг с другом напрямую - по схеме "монтажное ИЛИ"). Выходы 6 и 8 у этой ЛА9 соединяют, что и дает сигнал /CAS для 565РУ5. To есть вся работа сводится к распайке 3-х проводов. При этом используется то свойство отечественных (и некоторых импортных аналогов 4164, 2164 или 8164), что вектор регенерации у них не 8-ми битовый, а как и в 565РУ3 - семибитовый (в 565РУ7 вектор 9-ти битовый). Поэтому так проста замена 565РУ3 на 565РУ5.
Но даже, если Ваши ОЗУ имеют 8-ми битовый вектор регенерации, то они все-равно будут работать в РК86 (что странно, но факт !). Но это уже из-за особенностей программы МОНИТОР. При этом возможно может встретиться такая программа, что вызовет "сбой" в регенерации данных в 8-м столбце... Обычно ИМС с маркировкой 4164 имеют 7-ми битовый вектор. Но некоторые очень скоростные иностранные ОЗУ (150 НСЕК) фирм TMS, MOTOROLLA, MOSTEC имеют 8-ми битовый вектор регенерации.
Вот более древний вариант введения расширенного ОЗУ, но в окне не в 15К, а только в 8К, - зато он даёт доступ ко всем 64К. Впоследствии выяснилось, что для ДОС мало 8 Кб, поэтому пришлось увеличить размер окна до 15К:
Получить дополнительные 8К ОЗУ проще всего установив дополнительную панельку на свободном участке платы РК86 (с той стороны платы где стоит ПЗУ с фонтом, там где для этого уже предусмотрены ряды отверстий с шагом 2.5 мм). ОЗУ 6264 включается как и ПЗУ, только на 27 ногу заводится сигнал /WR от процессора.
Если ОЗУ сделано на 565РУ5, то "открыть ОЗУ" по этим адресам несложно. Для этого нужен всего один вентиль от ИМС 155ЛИ1 (или просто два диода). 155ЛИ1 включают в разрыв цепей от DD11/15,14,13,12, объединяя на ЛИ1 один из этих сигналов и DD11/10 (т.е выборка A000-BFFF также, как и выборки первых 4-х 8-килобайтовых кусков памяти будет вызывать формирование /CAS).
Однако тут надо учесть следующее. Если у Вас используется ОЗУ с 8-ми битовым вектором регенерации, то оно не будет работать в адресах выше 8000. Чтобы такое фирменное ОЗУ работало надо поменять провода на контактах DD19/13 и DD18/2. То есть вместо старшего адреса регенерации A7 берется наиболее высокочастотный адрес - 16-й провод шины по схеме РК86 - уж не помню суть этих явлений, т.к давно делал, но факт, что только отечественные РУ5 работают по базовой схеме, а некоторые фирменные требуют такой перестановки адресов.
Иметь 565РУ5 выгодно оттого, что при них получается возможность получить доступ ко всем 32К, расположенным в ОЗУ 565РУ5 "выше 8000". Для этого на DD18 напаивается еще один 1533КП11, который управляется сигналом /CS A000. Эта КП11 коммутирует адреса A12 и A13, подавая в зависимости от сигнала /CS A000 на ОЗУ 565РУ5, то адреса с процессора, то два бита от доп.ППА. Идея заключается в том, что эти два бита PA0,PA1 доп.порта ВВ55 позволяют выбирать тем самым один из 4-х восьми-килобайтовых кусков ОЗУ из области 8000-FFFF, включая их в окне A000-BFFF. То есть, в РК86 становятся доступными все 64К ОЗУ. Заметим, что это наиболее полноценное использование ОЗУ 565РУ5 (в других ЭВМ из-за необходимости иметь ПЗУ и В/У, 565РУ5 обычно используется только на 60-62К, а не на полные 64К).
Также о расширении ОЗУ на РУ5 расказано в тексте про мой макро ассемблер КР580. Так как он работает в расширенном ОЗУ из-за того, что слишком большой по размеру, и потому если его использовать в базовом ОЗУ, то он оставляет для исходного текста менее 20К.
barsik, спасибо.
Можно ли эти материалы выложить в публичный доступ?
Можно ли выложить полученные материалы для публичного доступа?
Нет, пожалуйста, ничего не выкладывайте, я это сделаю завтра сам.
Никакие исходники, пожалуйста, не раздаватйте. В таком виде они и не годятся - надо добавить тексты пояснений. И мне кажется, что лучше выкладывать не исходники, а странслированные программы для эмулятора, чтобы их можно было посмотреть не возясь с трансляцией. Исходные тексты представляют интерес лишь для программистов.
Да и все исходники, что я Вам отправил, кроме оригиналов РК-ДОС и утилит - не для РК, а для ОРИОНА. А у владельцев ОРИОНА нет РК-КНГМД, да и не бывают они в этой теме.
PS: Те кому я что-нибудь послал, не забывайте "кликнуть" на СПАСИБО - это же обычная вежливость. Я потратил на Вас время и вправе рассчитывать хотя бы на такую благодарность. А то у меня такой низкий рэйтинг, что уже стыдно заходить на сайт.
Готовя E-mail нашёл в древних текстах фрагменты о расширении ОЗУ РК86. Причём это даже не все, есть ещё, как минимум два, подобных текста, где рассказывается о простых аппаратных доработка РК.
Спасибо за ответ. Мне кажется, интересные доработки можно обсуждать и публично, ведь для понимания нужны и грамотные вопросы, которые я не уверена, что всегда могу задать. К тому же, речь идет о доработках которые могут оказаться полезными и кому то еще.
Хотела уточнить, кто автор найденных текстов, они Ваши или из какого то журнала?
Если же основные 32К ОЗУ реализованы на 565РУ5, то есть еще один вариант расширения ОЗУ. ОЗУ РУ5 ставятся следующим образом. На 13,14 ноги мультиплексора DD19 заводят адреса А14,А15 (38,37 ноги КР580) и выход 12 этого мультиплексора формирует адрес MX7 для динамических ОЗУ (9 нога у РУ5). Микросхему DD10 155ЛА3 выкусывают и запаивают вместо неё 555ЛА9 (это то же самое, что ЛА3, но с открытым коллектором, поэтому выходы вентилей ЛА9 можно соединять друг с другом напрямую - по схеме "монтажное ИЛИ"). Выходы 6 и 8 у этой ЛА9 соединяют, что и дает сигнал /CAS для 565РУ5. To есть вся работа сводится к распайке 3-х проводов. При этом используется то свойство отечественных (и некоторых импортных аналогов 4164, 2164 или 8164), что вектор регенерации у них не 8-ми битовый, а как и в 565РУ3 - семибитовый (в 565РУ7 вектор 9-ти битовый). Поэтому так проста замена 565РУ3 на 565РУ5.
Не поняла, как происходит изменение схемы адресации (для формирования дополнительного окна в 15 кб), которая изначально сделана на чипе D11 (ИД7)?
Нет, пожалуйста, ничего не выкладывайте, я это сделаю завтра сам.
Никакие исходники, пожалуйста, не раздаватйте. В таком виде они и не годятся - надо добавить тексты пояснений. И мне кажется, что лучше выкладывать не исходники, а странслированные программы для эмулятора, чтобы их можно было посмотреть не возясь с трансляцией. Исходные тексты представляют интерес лишь для программистов.
Хорошо, ничего раздавать не буду.
Скрин-шоты моих эмуляторов ОРИОНА на IBM PC и РК86 на ОРИОНЕ http://barsik.ut88.ru/Screen_Shots.rar
Документация на эмулятор и некоторые антикварные тексты:
http://barsik.ut88.ru/DOC.rar
http://barsik.ut88.ru/RK86_ALL.rar - здесь все мои чужие программы РК86 (т.е из сезона 1987-88 поднятые с кассет, и из 1994 с дискет Лианозово). Также тут исходники программ для РК86 и мои тексты из 1993-96, имеющие отношения к РК-КНГМД.
http://barsik.ut88.ru/SOURCE.rar - здесь исходники 1995...2004 для РК-КНГМД и инстументарий для их трансляции. Всё что остается сделать - только запустить BAT-файл.
После распаковки RAR-файла подкакаталог '../SOURCE/RKDOS_SRC' содержит исходники RK-DOS разных форматов дискеты с разными драйверами для эмулятора и для реала, CHKDSK, нортон, LORD, и по мелочи. Вот список основных каталогов с размерами.
CHKDSK RKDOS....... 28 кб - исправление дискет (РК-ДОС глючит, это ошибки логики, не железа)
CP........................ 52 кб - перегружает все файлы квазидиска ORDOS в диcк РК-ДОС
DOS for EMU ....... 2.45 мб - для работы в эмуляторе, потому не содержит дискетных п/п-мм
DOS for REAL ...... 2.52 мб - привод A:- эл.диск из лишнего ОЗУ ОРИОНА, B:- реальный дисковод
FILES ................... 69 кб - странслированные DOS ОРИОНА, внешние команды и ORDOS драйверы
FORMAT .............. 203 кб - форматёры на 5, 7 и 8 секторов, больше 8-ми (640К) РК-ДОС не может
LORD RKDOS ........ 152 кб - НОРТОН, где одна панель квазидиск ORDOS, вторая диск РК-ДОС
NC RKDOS ........... 127 кб - НОРТОН на два привода РК-ДОС (работает и при одном)
ORIG SRC ............ 155 кб - исходники оригинала РК-ДОС 2.95
TESTS ................. 35 кб - примеры чтобы понять идиотский программный интерфейс РК-ДОС
Внешние команды... 34 кб - исходники SYS-файлов (они без Z80 команд, т.к оригиналы)
В каталоге ' ..\SOURCE\RKDOS SRC\ORIG SRC' находятся оригиналы RK-DOS 2.95 для КР580. Исходники внешних команд (*.SYS) годятся и для РК86 (достаточно в исходнике изменить адрес BDOS на E001).
Некоторые работы по железу 1989-1999 здесь:
http://barsik.ut88.ru/SP_and_ORION.rar и здесь:
http://barsik.ut88.ru/Irisha.rar.
Можете также посмотреть моё промышленное железо APPLE-II:
http://barsik.ut88.ru/APPLE-II.rar
Извиняюсь за качество фотографий (телефон с поганой оптикой и без вспышки).
- - - Добавлено - - -
Данные выкладки теперь недоступны, т.к временно арендуемый домен в котором они были выложены теперь закрыт. Потому и также временно эти файлы перенесены вот сюда (https://yadi.sk/d/6nRNeDP63KseH6).
А эмуль рк на железном Орионе 512 запускается и работает?
ОРИОН как платформа для эмулятора
Для эмуляции РК86 пригоден даже медленный 8-ми разрядный компьютер, причём эмулятор оказывается проще, если в нём стоит Z80. В качестве регистров КР580 удобны альтернативные регистры Z80, совместимость по командам упрощает эмуляцию КР580, а если в компьютере стоит клавиатура РК86, её вообще не требуется эмулировать. Таким образом самым удобным для эмуляции РК является ОРИОН на Z80. Именно такой эмулятор РК и был разработан, причём работающая версия эмулятора была создана всего за несколько дней.
Выяснилось, что эмуляция системы команд КР580 тормозит в 24 раза, и на базовом ОРИОНЕ с тактом 2.5 МГЦ эмулированый такт КР580 составил около 100 кГц (а при эмуляции флага PARITY еще меньше). Казалось бы, что для игр такой эмулятор не годится. Изначально предполагалось, что эмулятор будет пригоден лишь для взлома и отладки программ и отчасти для прогона системных программ РК. А игры РК, работающие в реальном времени будут непригодны. В реальности оказалось всё наоборот...
Неожиданно оказалось, что на ОРИОНЕ с тактом 3.5 МГЦ (схема турбо с WAIT) половина игр РК работает с нормальной скоростью (в том числе XONIX и PACMAN), а остальные визуально медленнее всего в несколько раз (тут желателен ОРИОН с тактом 5-6 МГЦ). Объясняется это тем, что в данном эмуляторе подпрограммы ПЗУ РК не прогоняются как код КР580, а прогоняются на скорости Z80, в несколько раз быстрее чем на реальном РК. Оказалось, что игры РК в качестве задержек мало используют программные паузы, - задержкой часто служит время выполнения подпрограммы опроса клавиатуры в ПЗУ (что прогоняется в эмуляторе в 24 раза быстрее скорости эмуляции). Естественно, шахматы РК 'думают' над ходом в 24 раза дольше, а музыкальные тона превращаются в хрипы.
Впоследствии эмулятор РК на ОРИОНЕ был доработан и теперь он имеет встроенный монитор-отладчик с мини ассемблером, поддерживает один видеорежим с нестандартным числом строк (42), инверсию символов за счёт альтернативного фонта, и работает с квазидиском ОРИОНА. Эмулятор позволяет программистам для РК удобно отлаживать программы и ломать их.
Это был отрывок из ДОК-файла (1999). Это мой ответ на вопрос почему возможен эмулятор РК на ОРИОНЕ.
barsik,
За откомментированные DASM-исходники разных программ и игр огромное спасибо! Просто сундучек пряников какой то. Полюбовалась, закрыла и спрятала в укромное место. :)
http://barsik.ut88.ru/irisha.rar
404 Not Found
404 Not Found
Проще так http://barsik.ut88.ru/
Или прямая ссылка http://barsik.ut88.ru/Irisha.rar (регистр имеет значение в Си, на котором написан Apache).
404 Not Found
Спасибо за обнаруженную опечатку. Исправил.
Внимание, всем кто скачал файл http://barsik.ut88.ru/SOURCE.rar до 09:30 сегодня, следует скачать этот файл ещё раз. Первоначальный вариант оказался с двойным дублированием - каталог RKDOS SRC оказался внутри себя под именем SRC RKDOS, отчего объём каталога бесполезно удвоился. Кроме того добавлены комментарии и удалено несколько ненужных BAK-версий.
Если интересуют комментарии к коду РК-ДОС, то их больше в версиях для ОРИОНА.
Версии ОРИОНА для 5-ти секторов и без встроенного драйвера от версий РК фактически отличаюся только процедурой старта и наличием эл.диска. Из них несложно получить версию для РК с процессором Z80. Это будет намного проще, чем переделывать оригинал РК-ДОС, т.к там код уже оптимизирован по объёму за счёт JR-команд.
Может ли эмулятор РК на ОРИОНЕ работать на новоделе ОРИОН-512?
Увы, без соответствующих доработок не сможет. Ответ почему содержится в файле DOC\EMULS_DOC\EMRK86OR.TXT строка 175 (глава 4.Требования к аппаратуре).
perestoronin
26.11.2016, 09:22
написан Apache
Не люблю ни Апач, ни МариюДБ, ни других медлительных и прожорливых глючных монстров.
Потому использую только хобби-проект (http://nginx.org/) + небольшой улучшайзер модуля autoindex https://larsjung.de/h5ai/
Получается web-sharing очень качественный. Осталось разобраться как upload настроить, чтобы все могли свои файлы выкладывать.
# curl -I http://barsik.ut88.ru/
HTTP/1.1 200 OK
Server: nginx (http://nginx.org/)
Date: Sat, 26 Nov 2016 06:19:42 GMT
Content-Type: text/html;charset=utf-8
Connection: keep-alive
Keep-Alive: timeout=20
X-Powered-By: PHP/7.0.13-pl0-gentoo
Выгрузил проект в формате KiCad на GitHub
А можно конвертировать в Пикад или в Лейку?
А можно конвертировать в Пикад или в Лейку?
А смысл? Герберы настрогать и так можно.
А смысл?
У меня KiCad_а нет, и ставить не особо охота. Может скинете мне герберы, а я уже там в привычные для себя КаДы переведу. Или может KiCad может экспорт в ПиКад сделать?
HardWareMan
14.01.2017, 19:29
Кикад работает портабельно, установки не требует.
Выложил туда же герберы: https://github.com/timtashpulatov/rk86kngmd/tree/master/gerber
- - - Добавлено - - -
Может скинете мне герберы, а я уже там в привычные для себя КаДы переведу. Или может KiCad может экспорт в ПиКад сделать?
Из гербера уже переводить особо не во что, это просто послойная геометрия меди и сверловки. Кикад не умеет экспортить в пикад.
Повторил журнальный floppy контроллер. Основная особенность - мелкую логику заменил на EPM7032.
Я правильно понял, что флопики 3,5 переделывать не надо? Как работает контроллер, без сбоев?
Хочу повторить вашу схему, ЕРМ7032 у меня достаточно )
Я правильно понял, что флопики 3,5 переделывать не надо? Как работает контроллер, без сбоев?
3.5 я не пробовал. Работал с чем-то, типа, МС53хх и подавал с него честный READY.
Загрузил на дискету софт, по запускал и как-то я "остыл". За этот период глюков не было.
Собираюсь заказать штук 5 плат реплики для "Микроши". Интересующиеся, стучитесь в личку.
А сложно ли переразвести так, чтобы поставить панельку на 28 ног вместо 24-х ногой ? Отчего можно будет ставить ПЗУ типа 27256 вместо двух напаянных друг на друга ПЗУ РФ2. Тогда это будет одновременно и плата КНГМД и плата расширения ПЗУ в РК86. Для управления адресами ПЗУ A12, A13, A14 удобно использовать разряды порта D14. Это существенно повысит спрос на такие платы.
Удобство при расширенном ПЗУ в том, что тогда можно использовать не только RK-DOS V2.95, но и версии с объёмом кода уже в 8 кб. Преимущество расширенных ДОС в том, что поддерживается не только формат 400К, но и 560/640 кб, но главное с расширенной RK-DOS не нужно на каждом диске хранить внешние команды DOS, т.е SYS-файлы, - они перемещены в тело ДОС.
А кроме того появляется возможность сделать версию RK-DOS работающую с другими носителями. Например RK-DOS, которая одновременно поддерживает обычный НГМД, винчестер и привод на базе "micro-SD" 256М/1Г от телефона. А ограничение ПЗУ на плате РК-КНГМД в 4 кб не позволяет вообще никаких доработок RK-DOS (даже, чтобы переделать это ПЗУ для работы с НГМД без без READY, надо жертвовать каким-то функционалом DOS или иметь Z80).
Какой шаг ламелей врубного разъёма ?
В оригинале был метрический шаг, но теперь невозможно найти отечественные 60-ти контактные слоты с метрическим шагом. Сигналы на плате разведены так, что можно отпилить 5 рядов ламелей (кинув проводками питание на крайние ламели) и получить 50-ти контактный врубной разъём совместимый со слотами, что стоят в Apple-II и Правец-82 (Правец-8М). Эпловские 50-ти контактные слоты сейчас можно купить. К тому-же их легко составить из двух отпилков AT/XT слота по 12 и 13 контактов. Но для этого шаг ламелей должен быть дюймовым.
Можно поступить наоборот. Увеличить число контактов на один ряд, что даст 62 контакта. Тогда подойдёт XT-слот (или AT-слот с отпиленным EISA участком в 36 контактов). И шаг тогда, естественно, тоже д.быть дюймовый.
Если есть возможность переразводить плату, то желательно добавить задающий кварцевый генератор на саму платку КНГМД. По двум причинам. Во-первых, в турбированном РК86 уже нет кварца на 16 МГЦ. Во-вторых, чтобы получить на дисководе 5.25" формат дискет 560 кб (7 секторов на трек) нужен кварц 10.5 (или 11) МГЦ, а для формата 640 кб (8 секторов, но это уже только на HD-флопе 5.25" или 3.5") нужен кварц 12 МГЦ. В базовом КНГМД от МИКРОШИ приходилось монтировать задающий генератор на 1533ЛН1 вторым этажом.
А сложно ли переразвести так, чтобы поставить панельку на 28 ног вместо 24-х ногой панельки ? Отчего можно будет ставить ПЗУ типа 27256 вместо двух напаянных друг на друга ПЗУ РФ2. Тогда это будет одновременно и плата КНГМД и плата расширения ПЗУ в РК86. Для управления адресами ПЗУ A12, A13, A14 можно использовать разряды порта D14. Это существенно повысит спрос на такие платы.
В принципе переразвести не сложно. Для этого желательно внести изменения в принципиальную электрическую схему, а по ней уже вносить изменения в плату, чтобы пользоваться всеми прелестями процесса разработки (нетлист, DRC). Повысит ли это спрос - вопрос спорный. Важно понимать, что это реплика, а с изменениями и дополнениями, конечно, можно на ее основе сделать что угодно по своему вкусу.
Какой шаг ламелей врубного разъёма ?
В оригинале был метрический шаг, но теперь невозможно найти отечественные 60-ти контактные слоты с метрическим шагом.
Само собой, 2.5мм, как и у оригинала. Краевой разъем рассчитан на установку вилки ОНп-КС-23. Это может показаться странным, но и вилки эти, и соответствующие им разъемы еще вполне реально найти. Еще раз подчеркну, что речь идет о реплике, которая должна максимально полно соответствовать оригиналу, и которую предполагается вставлять в штатный разъем "Микроши".
А я никогда не видел МИКРОШИ и сдуру до сегодняшнего дня считал, что там стоят слоты, т.к судил об этом по плате КНГМД. Потому и поставил на плату РК86 50-ти контактные слоты. Получилось отлично, хотя ламели и не золочённые. Лишь периодически приходилось чистить ламели стирательной резинкой, чтобы удалить окислы и улучшить контакт. Плата с врубным разьёмом и слотом смотрится гораздо лучше, чем плата с разъёмами и общая высота меньше. Похоже, что такие же разъёмы использованы и в АГАТЕ.
Но переразводить плату КНГМД, если это не проблема, всё-равно надо, т.к выходной разьём там не 34-х контактный стандартный шильдик для втыкания туда разъёма с ленточным шлейфом. Мне приходилось привинчивать винтиками платку с 34-мя контактами. Посмотрите как неудобно было крепить на плате задающий генератор и 2 кварца (один для флопа 3.5", второй для 5.25", чтобы иметь форматы 880К и 560К). Кстати формат 560К на DD-флопе оказался надёжнее, чем формат 400К.
Кроме того, на плате не предусмотрена установка блокировочных емкостей, что неудобно.
А я никогда не видел МИКРОШИ и сдуру до сегодняшнего дня считал, что там стоят слоты, т.к судил по плате РК-КНГМД для МИКРОШИ.
Тут у нас какая-то терминологическая путаница. Слоты там стоят в количестве 1 штуки. Действительно похожи на Агатовские, но на этом сходство заканчивается.
Картинку платы "Микроши" можно посмотреть тут: http://retropc.org/images/072_003.jpg
Но переразводить плату КНГМД, если это не проблема, всё-равно надо, т.к выходной разьём там не 34-х контактный стандартный шильдик для втыкания туда разъёма с ленточным шлейфом.
Любопытно, что цоколевка этого действительно нестандартного разъема практически совпадает с одной из сторон разъема тонких ноутбучных дисководов. В общем, если кто соберется переделывать, пусть предусмотрит возможность установки разъема под ноутбучные винты, там вроде 26-пиновый тонкий шлейф является стандартом.
Кроме того, на плате не предусмотрена установка блокировочных емкостей, что неудобно.
Вот тут соглашусь, меня это в процессе работы над репликой тоже несколько шокировало. Впрочем, можно керамику навесить как обычно на советских платах делали - поверх корпусов микросхем. Но и так работает достаточно надежно.
Картинку платы "Микроши" можно посмотреть тут
Картинку посмотрел и увидел на плате нормальный отечественный слот на 60 контактов (называемый почему-то розетка). Затем нашёл в сети ДОК-и на вилку и розетку, т.к не мог понять зачем для слота нужна ещё и вилка. Понял, что вилка это вообще бессмысленная вещь, т.к тоже самое делает врубной разьём, что образуется из самой платы. Но внимательно посмотрев на плату МИКРОШИ понял, что весь смысл применения вилки заключается в том, чтобы поднять плату на сантиметр, т.к 5-ти штырьковые МГ разъёмы, стоящие по бокам слота мешают втыкать в слот печатную плату с врубной частью.
Думал, что в МИКРОШЕ два слота, перепутал с ПАРТНЁРОМ. А что они изначально рассчитывали на плату КНГМД или выпускались ещё какие-то другие периферийные платы ? Например, имея окно доступа в E000...EFFF можно было легко сделать втыкаемую туда плату расширения ПЗУ и даже плату внешнего электронного диска (64/128/256 кб), что как раз и было очень разумно до эпохи когда дисководы стали более-менее доступны, что случилось только в 1992 и позднее.
Кстати ИНФО про МИКРОШУ на этом сайте неполное. На карте памяти не указано, что там стоит в адресах 8000...BFFF.
Для "Микроши" выпускался модуль ПЗУ (http://zx-pk.ru/threads/20618-mikrosha-modul-pzu.html?p=565892&viewfull=1#post565892) и еще как минимум один модуль в похожем корпусе, дополнительные 16К ОЗУ.
- - - Добавлено - - -
Кстати, на Агатовских платах тоже ставили вилку на край платы. Видимо, неспроста.
Вилку на врубной разъём из самой платы напаивали, во-первых видимо, оттого, что в стране не хватало золота для золочения ламелей. А во вторых, у вилки есть горизонтальный упор, который упирается в слот и не даёт плате раскачиваться в стороны (отчего не требуется дополнительно закреплять плату винтом, как на IBM PC.
То, что у МИКРОШИ область 8000...BFFF зарезервирована для расширений ОЗУ и ПЗУ, - это грамотно. Из этого можно сделать чёткий вывод, что авторы РК86 (они же авторы и МИКРОШИ) были действительно врагами народа и Колыма по ним плачет. Для завода выпускающего МИКРОШУ всё сделали более-менее грамотно, а для народа (т.е публикации в РАДИО) занялись явным вредительством. Архитектура МИКРОШИ и АПОГЕЯ на 16 кб грамотнее, чем архитектура РК86.
Да и редакции журнала РАДИО место на Колыме. Они опубликовали монитор для МИКРОШИ, совместимый с РК86, а надо было наоборот публиковать схему переделки РК86 в МИКРОШУ. Это технически просто реализуется и если бы это сделали, то программ для РК86 было бы намного больше, т.к чем больше ОЗУ, тем легче разработать программу размером более, чем 1.5 кб. Если бы РК имел архитектуру МИКРОШИ, то естественно, любители сразу бы догадались, что выгоднее расширить ОЗУ не на 16К, а более, чтобы получить эл.диск, что сразу переводит ЭВМ на другой уровень. А т.к владельцами МИКРОШИ были не радиолюбители, а некомпетентные в железе дилетанты, отцы семейств, случайные люди, не имеющие паяльника, то ничего такого не появилось.
Исходя из такой более удачной архитектуры, для МИКРОШИ полезнее сделать плату расширения ОЗУ и ПЗУ. Для ОЗУ можно использовать РУ7 или SIMM-30 в 1 мб, а для ПЗУ 27256. Доступ к доп.ОЗУ с прокачкой в окне 8000...BFFF кусков по 16 кб, а ПЗУ с прокачкой в окне E000...EFFF.
В минимальном варианте доработки можно расширить ОЗУ на 16К с помощью w24257 и соответственно доработать RK-DOS, чтобы при её старте режим ВГ75 менялся бы, с переносом экрана на B6D0. Тогда RKDOS может грузить файлы в 45 кб. А ещё лучше иметь два ПЗУ F800 (естественно программно переключаемые). Одно ПЗУ F800 совместимое с РК86 и экраном на 76D0, а второе для ОЗУ 48К и экраном на B6D0.
Товарищи гуру, помогите одолеть сумасшествие. Никак не могут понять смысла выделенных строк в нижеприведенном коде из РК ДОС.
Тут должен запускаться дисковод (SELECT) и ожидаться сигнал готовности (READY).
Также, разрешается буферный регистр DD6, для вывода управляющих сигналов на дисковод.
И все вроде нормально, если бы не анализ номера диска (нулевой - A, или не нулевой - B), и причем тут бит PC2 и его сигнал SIDE.
Сигнал SELECT_B находится на порту PC3, вроде бы. И "включается" он тоже нулем, по идее.
:frown: :v2_dizzy_wall:
FDC_CONTROL = 0F003h
FDCPORT_CTRLIN = 0F1h
; ED2C
DRVStart:
call DRVStop
lda DOSV_OPDRV
ora a
jnz MED38
mvi a, 05h
MED38:
adi a, 05h
; 05h 0101b PC2 SIDE = 1
; 06h 0110b PC3 SELECTB = 0
; 0Ah 1010b PC5 SELECTA = 0
lxi h, FDC_CONTROL
mov m, a
mvi m, 0Fh ; 1111b PC7 DRIVEGATE = 1 (ENABLE)
DRVReady:
lxi h, 0
MED43:
in FDCPORT_CTRLIN
ani FDC_DRIVEREADY
rz
Вот дура. Если дисковод B, то A = 1 и 1 + 5 = 6 (0110b), и это PC3 в ноль! :v2_yahoo:
Разработчику (Седову) зачет за головоломки в коде. )
А что это за исходники? Мне кажется в комментариях ошибка. 05h там не может быть.
Разработчику (Е.Седову) зачет за головоломки в коде
А что это за исходники? 05H там не может быть
Исходники правильные. Просто когда исходники в труднопонятной мнемонике КР580 и используются неудобные имена констант и переменных, то логика работы ускользает, требует напряжения мозга и оттого не сразу понятна.
А Е.Седову за это явный незачёт. Трюк со сложением, вместо нормальной загрузки LD A,nn, ничего не даёт ни в скорости, ни в объёме кода, значит это извращение. Было бы понятно, если бы здесь использовался трюк Билла Гейтса (из его Altair-бейсика) с JMP-ом в середину кода команды, что даёт экономию в байт, но в данном случае экономии нет. Нетривиальный стиль программирования оправдан, когда реально необходимо вести жестокую борьбу за экономию объёма кода. Но зачем это, когда от этого нет выигрыша? У Е.Седова неприятный для понимания стиль программирования с нетрадиционным использованием стека (нет возврата в точку вызова подпрограмм), возвратом из подпрограмм со сдвинутым стеком и использованием стека для получения перемещаемого кода КР580. Думаю, что и не используя такие приёмы можно было уложиться в 4 кб.
Быстрее и интереснее написать свою ДОС (и даже 100% совместимую с RK-DOS), чем разбираться в чужом коде, пытаясь убрать хотя бы самые существенные ограничения и недостатки. Примитивную ДОС можно уместить даже в вдвое меньший объём кода в 2 кб. Недостатки примитивной ДОС в случае 'microSD' с ограниченным ресурсом перезаписей и неограниченным объёмом дискового пространства, становятся плюсами. В примитивной ДОС место занятое стёртым файлом не освобождается для последующей перезаписи (что в случае 'microSD' как раз выгодно), а новые файлы пишутся в конец области занятой файлами, сразу за последним файлом диска.
Трюк со сложением, вместо нормальной загрузки LD A,nn, ничего не даёт ни в скорости, ни в объёме кода, значит это извращение.
Дает 3 байта экономии относительно MVI, перед которым надо было бы поставить JMP.
Дает 3 байта экономии относительно MVI, перед которым надо было бы поставить JMP
Поясните пожалуйста, что Вы имеете ввиду. Я исхожу из следующих фрагментов.
Не сразу понятный вариант Е.Седова:
.
PUSK: CALL OSTANOV
LD A, (OPDRV)
OR A
JP Z, JJJ_01
LD A, 5
JJJ_01: ADD A, 5
LD HL, PORT+3
LD (HL), A ; A=0110B/1010B
LD (HL), 00001111B ; бит D7=1
READY:
Традиционный вариант:
.
PUSK: CALL OSTANOV
LD A, (OPDRV)
OR A
LD A,1010B ; PC5=0 выбор привода B
JP NZ, JJJ_01
LD A,0110B ; PC3=0 выбор привода A
JJJ_01: LD HL, PORT+3
LD (HL), A ; A=0110B/1010B
LD (HL), 00001111B ; бит D7=1, разрешение ИР22
READY:
.
.............ИЗ ЧЕГО ЯСНО ВИДНО, ЧТО ВАРИАНТ Е.СЕДОВА НИЧУТЬ НЕ КОРОЧЕ,
....ЧЕМ ТРАДИЦИОННЫЙ ВАРИАНТ. И ТЕМ САМЫМ ВАШЕ УТВЕРЖДЕНИЕ ОШИБОЧНО.
.........
barsik, да, так тоже можно, но никакого выигрыша относительно версии Седова нет.
OrionExt
10.06.2017, 21:36
Дык о чем вы спорите. Говорите. Или код по ходу правите. Х.з. Или удобные участки кода постите???
Кто-нибудь дизассемблировал оболочку SE.COM? Почему она может не работать нормально на "Микроше"? это относится прежде всего к выводу на экран и обработке курсорных клавиш. На экране строка подсказки выглядит странно, и курсором управлять не удается.
61332
barsik, традиционный вариант это сравнение, переход по результатам сравнения, а потом действия. Все остальное оптимизация. Так или иначе Ваша оптимизация ничуть не короче оптимизации Седова. Но он - творец, а Вы - критик. Как говориться, художника всякий обидеть может...
Кто-нибудь дизассемблировал оболочку SE.COM?
Я предполагаю, что Е.Седов использовал как раз МИКРОШУ, отчего и конструктив плат КНГМД для МИКРОШИ. Возможно он вначале имел МИКРОШУ, но переделал её в РК86, чтобы сделать версии программ для РК86 для журнала РАДИО и для коммерческих продаж через КООП "Лианозово". Очевидно, что раз КНГМД для МИКРОШИ, то и RK-DOS это ДОС МИКРОШИ и всё ПО для неё - для МИКРОШИ. И несомненно существовали версии всех программ, в том числе и нортона для МИКРОШИ. Т.е Вам достаточно найти версии всех программ для МИКРОШИ.
Я дизассемблировал очень давно. С целью изучения на предмет конверсии для RK-DOS ОРИОНА. Етественно я не получал полноценного исходника. Что было и не так просто сделать на убогом дизассемблере МИКРОН, теперь получить полноценный исходник с помощью IDA намного проще. Но я сразу же увидел, что там идёт наглая прямая работа с экранной областью, отчего для ОРИОНА проще написать визуализатор (например на прерываниях, визуализировать экран пару раз в секунду), чем трахаться и разбираться и переделывать всю логику работы программы. Или проще написать свой Нортон, чем трахаться в тщетных попытках конвертировать ПО для другой ЭВМ.
Непонятно зачем было Е.Седову во всех своих системных программах "лазить" в экран. Ведь искейп-код для позиционирования курсора есть, - отпозиционировал и вывел подпрограммой CONOUT F809. Скоростных проблем тоже нет. Лазить в экран надо только, чтобы выводить вне "основного поля", куда монитор не выводит (хотя его можно заставить это делать, если нагло влезть и в системные ячейки). Ладно, я понимаю, когда напрямую читают три спец.клавиши, что вне основного поля матрицы (в порту C клавиатуры), т.к их стандартной подпрограммой не считать.
Я не разбирался, но, вероятно, проблемы с клавиатурой связаны с другим адресом порта клавиатуры и с другой схемой её включения, а проблемы с экраном могут быть связаны с тем, что как недавно выяснилось, у МИКРОШИ есть существенные отличия в ROM-BIOS. Не пробовали использовать тот совместимый с РК монитор, что опубликовали в ж.РАДИО?
А вообще-то, вероятно, несложно адаптировать вариант этой программы под МИКРОШУ. Судите сами. Служебные ячейки те же и там же. Экран там же и организован так же. Значит несовместимость только из-за ROM-BIOS, адресов портов и иной схемы клавиатуры. Для клавиатуры надо поменять прямые обращения в порт A на обращения в порт B. А те вызовы ROM-BIOS, что отсутствуют в МИКРОШЕ, надо вставить прямо в код программы.
Нашёл старый листинг, там видно, что есть прямые обращения на C000 (ВГ75) и чтение порта C клавиатуры. А вызовов подпрограмм выше F818 нет, что как раз и свидетельствует о том, что программа изначально была написана для МИКРОШИ. Возможно и лезть в экран понадобилось потому, что не хватило возможностей усечённого ROM-BIOS МИКРОШИ. Могут быть ещё и вызовы нестандартных точек в ПЗУ, но думаю, Е.Седов был достаточно грамотным, чтобы опускаться до такого. Попробуйте хотя бы изменить адрес порта клавиатуры и ВГ75. Ведь в порту С клавиатуры спец.клавиши стоят там же.
Вот непонятно зачем было Е.Седову во всех своих системных программах "лазить" в экран.
Потому что F809 работает недопустимо медленно.
Печать в командную строку в SE.COM работает нормально, также работают нормально некоторые функциональные кнопки. Проблема (пока что) только с клавишами курсора.
Т.е Вам достаточно найти версии всех программ для МИКРОШИ.
Если это так, то остается надеяться на дампы дистрибутивных дисков от cy6.
С двумя дисководами работать удобнее, чем с одним :)
61337
Не хватает форматировщика с похожим интерфейсом (или хотя бы с индикацией форматируемых трека-стороны).
Не хватает форматировщика с похожим интерфейсом (или хотя бы с индикацией форматируемых трека-стороны)
Мне тоже этого когда-то нехватало. Поэтому я и встроил в свои форматёры для РК-КНГМД индикацию трека и стороны. Т.е во время формата в строке 'TRACK nn SIDE n' меняются цифры, а затем появляются "плюсики". Т.е выводится вот такая строка
TRACK nn SIDE n ....+ + + + + + +
Где плюс означает, что сектор отформатирован и в тесте после формата трека был считан нормально. А если выводится '-', то значит сектор дохлый, не считался, тогда делается ВК и новая строка TRACK выводится уже на следующей строке. Таким образом после окончания формата на экран выведена карта дохлых треков.
В приложении исходник универсального форматёра для РК-КНГМД. Т.е для формата с секторами в 256, 512 или 1024 байта. С любым числом секторов на треке. С интерливингом и без. Одна сторона (SS) или две (DS).
- - - Добавлено - - -
Нашёл какой-то форматёр и для RK-DOS. Но он был для ОРИОНА. Я сейчас встроил в него условную трансляцию и для РК86, но на практике проверить не могу (нет соответствующего железа). Так что сами странслируйте, проверьте в реале и сообщите подробности.
barsik, у меня почему-то ваш архив не распаковывается. Можете перепаковать в ZIP?
tnt23, нормально все открывается
Печать в командную строку в SE.COM работает нормально, также работают нормально некоторые функциональные кнопки. Проблема (пока что) только с клавишами курсора.
А разве матрица клавиш в Микроше не другая? Видимо, потому и не работает.
Дистрибутивный SE я уже выкладывала (http://zx-pk.ru/threads/11319-radio-86rk-podklyuchenie-diskovoda.html?p=805443&viewfull=1#post805443).
При исследовании длины трека оказывается, что длина трека разная в пределах одного диска даже.
То есть скорость дорожек у центра выше, чем у края диска. Соответственно, вместимость (байт) лучше мерять у самого центра (минимальную).
Интересно, когда меряют скорость диска, какую дорожку имеют ввиду, нулевую (у края) видимо?
Думаю, размер трека лучше фиксировать на условных 3125 байт, чтобы можно было начало трека в файле образа быстро найти. Сама длина понятно будет разная.
Глазами образы смотреть уже напрягает, нужно писать прогу для работы с образами РК в Windows.
Вот образ трека с номером 1, с отформатированной дискеты. Чтение достоверное, без ПДП.
61342
Чтение достоверное, без ПДП.
А что, есть проблемы чтения трека с включенным ПДП?
- - - Добавлено - - -
И еще по поводу достоверности чтения, опять боюсь ошибиться, но насколько я помню, синхробайт это байт со сбитой структурой и его численное значение лишь условность. Ну и после записи сектора (не целиком трека) образуются области с условными данными.
По-моему, программа форматирования, которую надо запускать из "Монитора", выводила прогресс. Что-то такое помню, когда загружал форматтеры с ленты.
Т.к по темам РК86 никто ничего не пишет и почитать нечего, то начал читать эту тему сначала.
И уже на первом десятке страниц обнаружил, что поисковики археологи раскопали версию RK-DOS 1.0 (2 кб) и схему оригинального КНГМД для МИКРОШИ. Что подтверждает моё предположение, что сначала RK-DOS была разработана для МИКРОШИ.
Интересно было бы узнать, как соотносятся завод по выпуску МИКРОШ из Лианозово, разработчик RK-DOS для РК86 Е.Седов и промышленно выпускаемые наборы КНГМД для МИКРОШИ и РК86. Насколько я понял, только первая версия КНГМД для МИКРОШИ и, соответственно, ДОС для него (RK-DOS 1.0) была другой, но коммерческая версия КНГМД для МИКРОШИ, промышленно выпускаемая этим же заводом и одновременно в виде набора (плата, документация, дискеты) продаваемая через ТОО "Лианозово", была той же самой, что КНГМД для РК86 опубликованный в ж.РАДИО.
Интересно какое отношение Е.Седов и, соответственно, его ДОС имеют отношение к заводу. Можно было бы предположить что он программист в КБ завода в Лианозово, но в статье в ж.РАДИО указано, что он из Москвы. Тогда вопрос - как его разработки попали на завод в Лианозово. Кто у кого заимствовал?
Узнал, что формат дискет RK-DOS совместим с каким то из ранних КНГМД АГАТА. Это означает, что системная межсекторная информация заимствована именно оттуда, т.к АГАТ появился ещё в 1984. Узнал, что первая версия RK-DOS была рассчитана на дисковод 5088, которым также комплектовался АГАТ в первые годы выпуска. А если к этому добавить, что структура диска и идеология ОС в основном совпадает с Apple-DOS V3.3 (автор Стив Возняк, 1978), отличаясь только мелочами (причём, изменения не в лучшую сторону), то становится ясным, что в качестве прототипа использовался АГАТ.
В КНГМД для RK-DOS версии 1.0 для МИКРОШИ объём кода составлял всего 2 кб. Теперь стало ясно почему на РК-КНГМД всего одна панелька, отчего вторую РФ2 приходится напаивать вторым этажом. Интересно, что использовалось дополнительное ОЗУ в 2 кб на статике в области E800...EFFF, да и сама RK-DOS стояла в адресах F000...F7FF. Очевидно в ПЗУ прошивался только BDOS в 2 кб, а CCP грузился в ОЗУ на статике. И впоследствии для версии RK-DOS 2.xx сочли более выгодным заменить статичекое ОЗУ в 2 кб на второе ПЗУ РФ2.
Если появится новодел РК86 имеющий доп.ОЗУ в области A000...BFFF, то RK-DOS версии 1.0 непроблемно перетранслировать для использования этого ОЗУ (вместо E800), т.к без разницы где установлено 2 кб доп.ОЗУ. В 8 кб ОЗУ как раз влезет весь код RK-DOS V1.0. Естественно в RK-DOS 1.0 совсем другой программный интерфейс (много входов в подпрограммы, а не один вход в BDOS) и совместимости быть не может. Таким образом тут интерес только исторический.
Это меня заинтересовало потому, что у меня есть схема совсем другого РК-КНГМД для РК86 из 1989 года, который судя по всему не имеет никакой связи с разработками из Лианозово. Эту схему и кассету с CP/M и основными программами (FORMAT, ASM, LOAD, DDT...) когда то привезли из Саратова (вместе с макро-ассемблером РК, Паскалем и BEST-C). По слухам КНГМД был заимствован от "Электроники-60". Он тоже имеет ВВ55, но не просто в качестве буфера, как в РК-КНГМД Е.Седова, а использует её в режиме параллельного интерфейса. К сожалению, программы не сохранились. А это была реально первая в стране адаптация CP/M на РК86. Кто нибудь имеет информацию о этой разработке?
Кстати, ещё для РК86 была CP/M с КНГМД на базе ВГ93 (формат 800 кб с ПДП). Это продавал один КООП в 1989. Ко мне попал только ДОК на бумаге: схема, чертёж печ.платы, схема расположения, листинг CP/M-BIOS и больше ничего. Для знатока этого достаточно, но для некомпетэ без дискеты или дампов CP/M-программ - это абсолютно бесполезное ИНФО.
синхробайт это байт со сбитой структурой и его численное значение лишь условность.
Где про такое написано? Если судить по исходникам, то в РК-КНГМД есть какой-то режим формирования синхробайтов. И для синхронизации схемы после длительной паузы, выдаётся цепочка из 5-ти синхробайтов 006, затем цепочка из 5-ти обычных нулевых байтов и схема как-то по ним настраивается.
А в той схеме КНГМД о которой я упомянул выше, принцип другой (более простой сепаратор данных). Там в качестве синхробайта используется обычный байт F3, найденный первым после индексной дырки. Считанные биты вдвигаются в регистр. И как только там оказывается байт F3, то считается, что синхронизация достигнута и далее каждые 8 последующих битов считываются как байты. Т.е принцип, как в магнитофонном формате РК86. Надёжность при такой синхронизации ниже, но схема проще. А в РК-КНГМД какая-то более сложная аппаратная синхронизация.
По-моему, программа форматирования, которую надо запускать из "Монитора", выводила прогресс
Вот эта (http://zx-pk.ru/threads/11319-radio-86rk-podklyuchenie-diskovoda.html?p=363684&viewfull=1#post363684) версия для запуска из монитора не выводит никакого "прогресса", даже номера текущего трека не выводит. Т.к железа нет, то пришлось её дизассемблировать, снабдить комментариями и изучить (во вложении). Оказалось, что это тот же форматёр Е.Седова, но с удалённым анализом командной строки (т.е не анализируется дисковод для формата, и ключи для задания числа секторов в каталоге и для отмены теста).
Мне тоже для дистрибутива RK-DOS для ОРИОНА пришлось сделать форматер для запуска из монитора, т.к COM-версия для запуска из RK-DOS анализирует командную строку и если её не находит, то делает выход в ДОС. Но я поступил проще - вставил в начало форматёра код для загрузки в ОЗУ нужной командной строки.
Необходимость в такой версии возникает, когда нет ни одной дискеты в формате RK-DOS. Но если RK-DOS не в ПЗУ, а в ОЗУ, то в форматёр надо перенести все нужные подпрограммы RK-DOS, чтобы форматёр действительно мог работать в среде монитора, не завися от наличия или отутствия в адресном пространстве кода ДОС.
Где про такое написано?
В журнале Радио. Там было более менее подробное описание.
Лианозово это Москва. И еще интересно, кто автор игры Удав, Седов Е.А. или Попов С.Н.?
Время дисководов и дискет проходит. Уже не каждый может себе позволить иметь дисковод. Винчестер вполне заменяет дисковод, хотя для этого ДОС для дисковода не годится, требуется несложное изменение в её коде. В качестве носителя READ ONLY удобнее всего эмуляция дискового привода на базе 'microSD'. А в качестве износоустойчивого привода ДОС удобно использовать электронный диск на базе ОЗУ.
Если нет НГМД или винчестера и требуется использовать ДОС, то можно иметь эл.диск из большого ОЗУ самого компьютера (например при установке в РК86 SIMM 1 мб). Однако, если требуется альтернатива НГМД не на одной ЭВМ, а сразу на многих, в частности, РК86, СПЕЦИАЛИСТ, ОРИОН и ИРИША, то оказывается невыгодным в каждой из этих ЭВМ иметь много ОЗУ - столько SIMM не напасёшься, трудов по монтажу много. К тому же схемы расширения ОЗУ разные и возникает неоходимость делать кучу версий ДОС. Возникает и другой вопрос, как программы попадут в компьютер. Т.к грузить в эл.диск из IBM PC по проводной линии долго и утомительно, то возникает необходимость расширять в каждом из этих компьютеров резидентное ПЗУ. А это ещё более увеличивает трудоёмкость и возникает неизбежный долгострой. Таким образом в каждом из компьютеров надо иметь скоростной интерфейс по проводной линии, привод READ ONLY для архива на базе ПЗУ и оперативный привод на базе ОЗУ.
В этом случае разумно сделать одно универсальное внешнее устройство, которое решит все проблемы. Естественно, напрашивается идея простого контроллера на Z80, т.к он выполняет регенерацию динамического ОЗУ. Кроме того в такой контроллер легко загружается новая программа изменяющая свойства контроллера, что недоступно МК с жёсткой прошивкой. Схемотехника м.быть следующая. Z80B на такте 7-8 МГЦ, ППА для интерфейса, 256 кб ОЗУ на статике и 1 мб ОЗУ на SIMM. Контроллер может точно имитировать ATA-интерфейс IDE-винчестера, эмулируя два привода (один из которых энергонезависимый на статике), а также выполнять скоростные пересылки по проводной линии. Благодаря такту в 8 МГЦ программная передача оказывается быстрее, чем аппаратная при использовании ВВ51, к тому же без расхода деталей. При последовательном интерфейсе скорость передачи до 8 кб в секунду (при паралельном ещё в 8 раз быстрее). Заметим, что сам сам РК86 без ВВ51 может передавать не более 1 кб в секунду.
Вот и дилемма. Ставить ли в РК86 SIMM 1 мб или сделать простейший внешний контроллер на Z80, втыкаемый в разъём ППА D14, на котором стоит та же SIMM 1 мб.
В минимуме схема контроллера состоит лишь из Z80, РФ2, 4-6 корпусов обрамления и SIMM 1 мб (без буферов). По сути это внешний эл.диск. Но контроллер на Z80 оказывается намного проще, чем плата внешнего электронного диска со своим узлом регенерации (30 корпусов). Преимущество в том, что не требуется вторжение на основную плату ЭВМ и шины никак не грузятся. И контроллер получается многофункциональным, т.к программа в него загружается. Например, одновременно эта крошечная платка мультиконтроллера может эмулировать или обслуживать флоп, винт, клавиатуру, AY-8912 и 512ВИ1. Т.о при развитии эта идея вырождается в двухпроцессорный компьютер, где второй процессор занимается только периферией. Но мне важно, что это даёт расширение железа без вторжений в основной плате компьютера и универсальность.
Изобрел очередной велосипед - команда LS выводит список файлов в четыре колонки.
61389
Разработал внешнюю команду LS, которая выводит список файлов в четыре колонки.
Можно модернизировать исполняемый код команды DIR в коде ПЗУ 4К так, чтобы при вводе команды DIR<ВК> на диске 'A' искался бы файл DIR.COM и, только если его нет, то исполнялся бы резидентный в ПЗУ DIR, выдающий список файлов в одну колонку. Иначе стартует внешний DIR в виде файла. Но лучше выводить список файлов в 3 колонки, тогда не требуется откидывать размеры в секторах (и даже удобнее выводить размеры файлов в байтах). В моих версиях RK-DOS для ОРИОНА каталог выводится сразу в 3 колонки.
Интересно, Ваша команда LS игнорирует файлы с атрибутом "системный" и поддерживает вывод списка файлов по шаблону, как это делает резидентный DIR ?
Думаю, что Ваш код LS.COM небольшой, отчего им можно заменить встроенный DIR. А можно встроить и как новую резидентную команду. Причём лучше ввести это, не как новую команду LS, а чтобы такой каталог выводился по <ВК> на пустой строке. Это удобнее, как подтвердят пользователи ОРИОНА. Проблема в том, чтобы найти место в ПЗУ.
Заменив подпрограмму PRNOUT на RET, выигрывается 27 байт. Всё-равно мало у кого сохранились посимвольные принтеры, а если и есть, то всё-равно печатать удобнее из IBM PC, а не из РК86, где только КОИ-7. 11 байтов выигрываете забив в конце кода строку копи-райт автора. Ещё до 70 байт можно выиграть посокращав текстовые строки сообщений об ошибках и другие текстовые строки. Например, вместо осмысленных сообщений об ошибках выводите строки вида 'ERR N', где N код ошибки, что даёт экономию в 54 байта. Заменив имя стартового файла 'AUTOEXEC' на 'A' выигрываете ещё 7 байт. На работу ДОС это не повлияет.
В выигранные таким образом ~100 байт можно уместить много чего полезного. Я, в частности, подумываю о введении в RK-DOS юзеров. Речь о юзерах в смысле CP/M. Юзером называют не самого пользователя, а область пользователя. В CP/M имеется 16 юзеров. Юзеры это примитивный вариант подкаталогов и хоть как-то помогают разделять файлы на больших дисках. И все накладные расходы на их введение в CP/M составили - 1 байт в каталоговой записи и проверка на текущий юзер в процедурах поиска и открытия.
Ввести в RK-DOS юзеры совместимым образом несложно. Увы, Е.Седов не позаботился зарезервировать свободный байт в каталоговой записи. Потому для введения юзеров есть две возможности. Во первых, можно использовать неиспользованные биты байта атрибутов. Во-вторых, можно сократить длину имени с 10 символов до 9-ти (всё равно все привыкли к имени в 8 символов, как в CP/M и MSDOS). Т.к для простоты вывода строк, после имени длиной в 10 или менее байт в каталоговой записи ставится 0, то фактически на имя тратится 11 байтов. И если этот 11-тый байт использовать как номер юзера, то совместимость не нарушится. Тогда у файлов с длиной имени в полные 10 байт записанных базовой RK-DOS, 11-тым байтом стоит 0, что значит, что этот файл из юзера 0.
Таким образом сохраняется совместимость в обе стороны и даже можно иметь юзеры с вложенностью, что полностью эквивалентно подкаталогам. Тогда младший ниббл байта это номер юзера, а старший ниббл это номер юзера, куда данный юзер вложен. Имена юзеров тоже можно ввести. Я так уже делал в Нортоне для CP/M, храня список имён юзеров в BOOT-секторе диска (внешне всё выглядит как работата с подкаталогами). Впрочем, и ранее в CP/M имена для юзеров уже сделали в ZCPR.
Хотя думаю, что ~100 байт достаточно, чтобы ввести юзеры в RK-DOS, но использовать такие юзеры будет неудобно. Потому что, при юзерах поиск файлов происходит только в текущем юзере, что для RK-DOS в которой большинство ДОС-команд внешние (в виде SYS-файлов) потребует иметь копии SYS-файлов в каждом из юзеров. Что неэкономично. Потому вводить юзеры в RK-DOS разумно только для версии RK-DOS рассчитанной на ПЗУ с размером более 4 кб (например 8 кб) или же для RK-DOS работающей из верхнего ОЗУ в 8К (в области A000...BFFF).
Есть возможность ввести в RK-DOS и даты файлов. Опять-таки совместимо с старыми программами. Для этого на юзер тратим байт атрибутов, а для хранения даты файлов сокращаем длину имени файла с 10-ти символов до 8-ми. И в освобождённых 2-х байтах (с офсетом 10 и 11 от начала каталоговой записи) храним упакованную (как в MSDOS) дату файла. Правда это имеет смысл только, если в РК86 установлен 512ВИ1, как описано в книге "Радиоежегодник 1989", Москва, изд-во Досааф, 1989.
К сожалению строители новоделов РК86 упорно не желают, ни расширять ПЗУ, ни даже расширять ОЗУ в области A000 (что вообще просто, если ОЗУ на РУ5). Так что RK-DOS с юзерами пока нет. Всё что можно сделать при ПЗУ в 4 кб - это за счёт фатального усечения сообщений об ошибках ввести команду DEL, чтобы избавиться хотя бы от одного файла - внешней команды ERASE.SYS.
Для тех, кто не ждёт милостей от строителей новоделов РК86, и имея РУ5 самостоятельно с помощью проволоки МГТФ "открыл" дополнительное ОЗУ A000...BFFF (перенеся D14 на адрес F200), а также имеет внешний ROM-диск (совместимый с ROM-диском ОРИОНА) могу предложить использовать более удобный вариант RK-DOS. Вариант 100% совместимый со всем старым ПО, работающий с КНГМД не имеющими сигнала READY, но требующий наличия расширений "железа" и основанный на использовании ОЗУ вместо ПЗУ, хотя добавочное ПЗУ всё-равно иметь необходимо (но уже в виде внешнего модуля, а не в самом РК86).
Для этого в ПЗУ E000...E7FF прошивается не код RK-DOS, а только вход в BDOS (E001) и стартёр RK-DOS. Тогда по вызовам BDOS из программ (по CALL E001) происходит переход на A000, где загружен собственно весь основной код RK-DOS. А по холодному старту RK-DOS, т.е по JMP E000 выполняется следующее. В ROM-диске осуществляется поиск ORDOS-файла с именем RKDOS@, и если этот файл найден то весь код этого файла грузится на адрес A000, что позволяет иметь объём RK-DOS объёмом до 8 кб.
Для некоторых удобно, что при этом ROM-диск остаётся универсальным, одновременно пригодным для хранения файлов ORDOS для ОРИОНА. Для отличия в ROM-диске программ RK86 от программ ОРИОНА, я использую, как и для дисковых ORD-файлов, символ '@' вместо '$', что используется в файлах ОРИОНА. Планирую вскоре сделать версию ПЗУ F800 для РК86 рассчитанную на ROM-диск ОРИОНА. По сбросу РК86 на ROM-диске будет искаться и автоматически запускаться определённый файл. Такая программа разработана ещё в начале 90-тых (для СПЕЦИАЛИСТА) и называет ROM SERVICE. Она выводит список файлов в ROM-диске и позволяет удобным способом выбрать и запустить файл, прошитый в ROM-диск.
PS. Утомительно каждый раз набирать команду GE000<ВК>. Лучше использвать ПЗУ F800, где встроена доп.команда 'B', по которой и выполняется JMP E000. В середине 90-тых я использовал ПЗУ РК86, где, если при нажатии кнопки СБРОС удерживать клавишу CONTROL, то происходит загрузка CP/M с дискеты. Для RK-DOS это сделать ещё проще, т.к она резидентна и не требуется иметь в ПЗУ F800 дискетный загрузчик с системных треков дискеты, а достаточно сделать JMP E000.
Но лучше выводить список файлов в 3 колонки, тогда не требуется откидывать размеры в секторах (и даже удобнее выводить размеры файлов в байтах).
Ну это кому как удобнее. Для меня важнее было по LS выводить максимально плотный список файлов, а размеры как раз неинтересны. А если интересны, есть же DIR.
Интересно, Ваша команда LS игнорирует файлы с атрибутом "системный" и поддерживает вывод списка файлов по шаблону, как это делает резидентный DIR ?
Нет, LS крайне примитивна, и пока даже не обращает на имя диска в виде параметра (LS B:). Если интерес к ней не остынет, попробую это все добавить, а пока утешает, что размер её менее 256 байт.
По поводу ROM-диска как-то все это пока очень мимо. Мне не нужен ROM-диск (при наличии нормальной дисковой системы-то зачем?), лучше позаниматься вопросом переноса данных с РК на "большие" компьютеры.
лучше позаниматься вопросом переноса данных с РК на "большие" компьютеры
Вопрос этот решен (http://zx-pk.ru/threads/24092-sd-kontroller-ot-vinxru.html) Алексеем Морозовым. Что то лучше и проще, придумать сложно, имхо. Да и компоненты все современные, без устаревших и раритетных SIMM, IDE (жесткий диск - расходный материал, маловероятно найти на помойке что-то долговечное).
Я бы сказала, что нужен софт типа коммандера, который бы позволял работать с FDD и SD-картой одновременно. А в идеале, еще и эмулятор контроллера FDD на современном железе, или хотя бы эмулятор самого FDD.
И любой "базовый" РК или Апогей, должен моментально расширяться с помощью подключения такого устройства.
Вопрос этот решен (http://zx-pk.ru/threads/24092-sd-kontroller-ot-vinxru.html) Алексеем Морозовым. Что то лучше и проще, придумать сложно, имхо. Да и компоненты все современные, без устаревших и раритетных SIMM, IDE (жесткий диск - расходный материал, маловероятно найти на помойке что-то долговечное).
Я бы сказала, что нужен софт типа коммандера, который бы позволял работать с FDD и SD-картой одновременно. А в идеале, еще и эмулятор контроллера FDD на современном железе, или хотя бы эмулятор самого FDD.
И любой "базовый" РК или Апогей, должен моментально расширяться с помощью подключения такого устройства.
В чем-то да, решение на SD подходит. Но мне бы хотелось "добить" вопрос с локальной сетью "Микроши" в соседнем топике, это у меня традиционное пристрастие к использованию встроенных в ретрокомпьютеры технических средств. (К тому же к "Микроше" SD-контроллер без внешнего питания не подключить, но это мелочи)
По поводу эмулятора контроллера FDD - лучше бы просто контроллер, цепляющийся к PC через USB одним концом и к внешнему флопику 3.5" другим концом. И простой софт, читающий треки с реального флопа.
Мне не нужен ROM-диск. При наличии нормальной дисковой системы - зачем он?
Я исходил из своих реалий. Для меня доступен только электронный VDISK (теряющий файлы без питания или энергонезависимый) и винчестер. Кстати, проблема с малым ресурсом и быстрой дохлотой винчестера не стоИт, т.к они у всех есть и достать б/у винт не проблема. Например, я имею 6 винчестеров и 83% из них - уже и так дохлые. Иногда даже дохлые винчестеры можно использовать для 8-ми разрядки. 'microSD' я бы хотел использовать, но не умею программировать обмен с ними по интерфейсу SPI.
Но спасибо за критику ROM-диска, т.к после Вашего сообщения я понял, что реальный дисковод может заменить ROM-диск. Суть такой концепции следующая. В ПЗУ E000...E7FF в его начало прошиваем только входы в BDOS RK-DOS (с адреса E001). А загрузку по JMP E000 делаем уже не из ПЗУ ROM-диска, а из дискеты RK-DOS. В 2 кб РФ2 особо много "мозгов" не влезет, поэтому этот загрузчик будит грузить блок строго фиксированной длины из строго фиксированного места на диске, например с треков 0,1 и 2.
Полезная ёмкость трека 2.5 кб. На 3 трека влезает 7 кб кода ДОС (1 сектор в 512 байт тратится на T/S LIST файла). Чтобы при записи файлов эти системные треки не затирались, в каталоге эти треки занимаются под файл RKDOS.DAT (расширение SYS нельзя, т.к в RK-DOS оно стартуемое) в процессе записи системы на диск. Таким образом в ПЗУ E000 прошиваются только вход в BDOS и холодный загрузчик RK-DOS с системных треков. Такая концепция удобна при наличии реального дисковода. Но если реального дисковода нет, то ROM-диск необходим.
вопрос переноса данных с РК на "большие" компьютеры
О чём речь? Насколько большие компьютеры имеются в виду? Например ОРИОН с ОЗУ 512К достаточно большой? Или требуется ATM-Turbo с 4 мб памяти? IBM PC ещё более большой компьютер. С ОРИОНОМ беспроблемный обмен через магнитофонный вход, т.к ОРИОН выводит на МГ и в формате РК86. При наличии 'microSD' с форматом FAT16/32 обмен с IBM PC делают через телефон, куда вставляют эту 'microSD'. А с телефоном обмен по кабелю 'microUSB--USB' или беспроводной. А для обмена с клонами ZX-Spectrum надо писать для РК драйвер вывода в ZX-магнитофонном формате или для ZX программу обмена в МГ-формате РК86. Но проще написать для ZX драйвер обмена по проводной линии (используя те же порты, что для МГ обмена)
61413
- - - Добавлено - - -
Сообщение от tnt23
> вопрос переноса данных с РК на "большие" компьютеры
О чём речь? Насколько большие компьютеры имеются в виду? Например ОРИОН с ОЗУ 512К достаточно большой? Или требуется ATM-Turbo с 4 мб памяти? IBM PC ещё более большой компьютер.
Ну не с Ориона же и не с АТМ вы в интернет ходите?
нужен софт типа коммандера, который бы позволял работать с FDD и SD-картой одновременно
Эту задачу надо сформулировать точнее. Нужно уточнить форматы данных на обоих носителях. Например это может быть CP/M на НГМД и FAT16 на 'microSD', или же RK-DOS на НГМД и файл-слепок дискеты RK-DOS в одном из подкаталогов FAT16. Может быть речь о обмене RK-DOS - отдельный файл FAT16 для каждого файла с дискеты. Но лучше всего диск в формате RK-DOS прямо в 'microSD', например замаскированный под файл FAT16 (для этого нужны подпрограммы чтения/записи байта). Неясно в какой ДОС (или без ДОС) должна работать такая программа ?
Понятно, что оболочка типа Нортон для пофайлового обмена удобна. Но на РК86 программы в стиле коммандер некрасивы, т.к нечем начертить приличные панели, без инверсии с рамками не сделать окон и даже указатель "балка подсветки" невозможен. Для этого необходим хотя бы один альтернативный фонт, хотя бы такой, что использую я, дающий рамки с инверсией и без, и инверсию знакомест. Увы, если не коммутировать фонт атрибутом ВГ75, то за счёт потери русских букв при альтернативном фонте. Один альтернативный фонт обходится в расход одного куска проволоки. Но до сих пор не выработан стандарт каким портом и какими битами переключать фонты.
Контроллер 'microSD' от vinxru освобождает от необходимости работать напрямую с форматом FAT16 (что довольно сложно и требует много кода) предоставляя функции более высокого уровня, чем функции MSDOS. Поэтому, если работать по-файлово (не со слепком диска) думаю, что интерфейс со стороны 'microSD' получится несложный.
Я когда-то написал нортон для RK-DOS на ОРИОНЕ. Хотя "глюкало" не годится для РК86, но готовые подпрограммы (напр, чтение каталога в буфер, его сортировка по критерию, копирование, удаление, переименование файлов) уже имеются. Есть также и "глюкало" для РК86 (но не для RK-DOS, а для другой ОС), Т.е есть готовая панель с управлением "балкой подсветки", работающая с использованием альтернативного фонта. Потому я могу быстро сделать основу такого CHANGER-нортона работающего из RK-DOS или из CP/M (при ОЗУ 48К). Несколько программ для обмена между разными ДОС в виде Нортона я уже когда-то написал (в 90-тые).
Но чтобы сделать обмен с 'microSD' мне нужен готовый программный интерфейс с ним. В минимуме нужны следующие готовые подпрограммы: считать целиком каталог по указанному адресу (с размерами файлов, атрибутами, и м.быть с датами файлов), записать файл умещающийся в дисковый буфер, считать файл с размером не более, чем дисковый буфер, удалить файл, переименовать файл, установить файлу атрибут, установить файлу дату. В максимуме нужны функции нормальной ОС, т.е - создать файл, открыть файл на чтение или запись (APPEND не надо), закрыть файл, считать/записать в открытый файл один байт и логический сектор (128 байт).
Если в наличии только процедуры считать/записать файл целиком, то возникают сложности при копировании гигантских файлов размером до 28 кб. Сам Нортон может делать обмен только небольшими файлами, которые целиком умещаются в дисковый буфер. Считайте сами. В базовом РК доступно ОЗУ только 29 кб. 10 кб занимает сам нортон. 1.5 кб отнимают буфера RK-DOS. Итого, максимальный размер файла, что целиком умещается в память - это менее 18 кб.
Потому более крупные файлы, вплоть до размера в 28 кб между НГМД и 'microSD' из Нортона (и из CCP) можно копировать только отдельной программкой SDCOPY.COM. Нортон при попытке скопировать гигантский файл с размером до 28 кб должен формировать BAT-файл, который запускает копирование с помощью SDCOPY.COM.
Если кто-нибудь заинтересован, то давайте для начала сделаем так. Давайте для начала сделаем кучу маленьких простых программок, что позволит отладить процедуры обмена. Например, начать можно с внешних команд RK-DOS типа DIRSD.COM, CD.COM, RM.COM, LOADSD.COM, SAVESD.COM, RENSD.COM, ATRIBSD.COM, а затем и SDCOPY.COM. Я сделаю часть кода для RK-DOS, а кто-то должен помочь с кодом для 'microSD'. Насколько я понимаю, есть некий SD-BIOS, который и обеспечивает интерфейс с FAT16 очень простым способом.
Попробую в ближайшие дни странслировать дисковый РК-DOS нортон, который будет выводить файлы RK-DOS в левой панели. А в правой панели будет бутафория, т.е придуманный список файлов 'microSD', служащий лишь для проверки перемещения по ним указателя. Так обычно и делается при разработке подобных программ. Но в реале я проверить не смогу. Отладку "глюкала" я сделаю в своём эмуляторе, а работу с РК-КНГМД в эмуляторе от Pyk. Но пока не знаю, как включить в нём альтернативный фонт. А может быть эмулятор от Pyk эмулирует и контроллер 'microSD' от vinxru? Это существенно бы упростило разработку.
Контроллер для интерфейса не был обязателен. Например ДОС для ОРИОНА, разработанная error404 поддерживает 'microSD' с простым интерфейсом (оба варианта) и не нуждается ни в каком контроллере. Обслуживание выполняет CPU компьютера, без всяких контроллеров. Предполагаю, что контроллер использован потому, что для него уже имелать кем-то ранее написанная программа интерфейса с FAT16, и потому что у РК86 слишком мало ОЗУ и слишком низка скорость.
Ну не с ОРИОНА же и не с АТМ вы в Интернет ходите?
Раз речь об обмене с IBM PC, то тут с РК-КНГМД облом. Если у РК-КНГМД формат действительно FM, то теоретически возможно написать программу обмена, правда только для PC (РК-КНГМД не сможет записать межсекторную информацию, что нужна для 8272). Программа должна считывать всю дорожку целиком, а затем её программно анализировать. Встроенные в BIOS и MSDOS процедуры чтения сектора не помогут. Но увы, работу с 8272 на низком уровне многие современные компьютеры не поддерживают.
Я использую обмен с ОРИОНОМ по проволоке, но скорость обмена очень низка. Если нужно пересылать большой объём, то это надолго. В качестве альтернативы можно рассмотреть скоростной контроллер на Z80 реализующий скоростной последовательный интерфейс.
Можно применить на РК контроллер НГМД от ПАРТНЁРА на ВГ93, который записывает в формате, что можно считать на IBM PC. Тогда можно даже написать программу для РК86 записывающую прямо в формате MSDOS 720К. Однако такой контроллер нельзя применить для RK-DOS, т.к она использует сектора нестандартного размера. Потому с таким контроллером можно использовать только CP/M.
Приехали платы реплики КНГМД для "Микроши".
61419
61420
- - - Добавлено - - -
Если у РК-КНГМД формат действительно MFM
Там FM, как ясно отмечено в оригинальном цикле статей.
Можно применить на РК контроллер НГМД от ПАРТНЁРА на ВГ93, который записывает в формате, что можно считать на IBM PC. Тогда можно даже написать программу для РК86 записывающую прямо в формате MSDOS 720К. Однако такой контроллер нельзя применить для RK-DOS, т.к она использует сектора нестандартного размера.
Тогда зачем предлагать заведомо неподходящее сразу по нескольким параметрам решение?
Приехали платы реплики КНГМД для "Микроши"
Прекрасно, больше будет пользователей РК и АПОГЕЕВ с дисководом.
Там FM, как ясно отмечено в оригинальном цикле статей
Исправил. Конечно я знал и имел ввиду FM, просто перепутал название.
Но хоть кому-то уже удалось считать дорожку целиком на PC? Пока нет подтверждения этому, есть сомнение, что формат РК-КНГМД совместим с промышленным стандартом.
Можно применить на РК контроллер НГМД от ПАРТНЁРА на ВГ93, который записывает в формате, что можно считать на IBM PC. Тогда можно даже написать программу для РК86 записывающую прямо в формате MSDOS 720К. Однако такой контроллер нельзя применить для RK-DOS, т.к она использует сектора нестандартного размераТогда зачем предлагать заведомо неподходящее сразу по нескольким параметрам решение?
Почему же промышленный контроллер на БИС, как и у всех остальных отечественных компьютеров - заведомо неподходящий?
Если цель - получить обмен с IBM PC, то это как раз самое подходящее решение. Если же цель RK-DOS (для которой в сущности нет программ, т.к нортон SE малоудобный и некрасивый, а DOCTOR нужен только потому, что в работе RK-DOS есть глюки), то это действительно "заведомо неподходящее".
Печатная плата новодела есть. ПАРТНЁР это клон и если работает в нём, то будет работать и на РК. Трудоёмкости тоже нет. Раз есть готовое решение, разработанное инженерами и профессиональными программистами, то заимствовать CP/M-BIOS и перетранслировать не проблема. Увы, есть только одна маленькая проблемка, - в базовом РК ОЗУ для CP/M не хватает, а хватает только для RK-DOS.
К тому же на RK-DOS "мир не сошёлся клином". Т.е это не единственная ДОС в мире для КР580. Можно даже поставить 6502 как сопроцессор и использовать Apple-DOS 1978 года (ДОС работает на 6502, а программы прогоняет КР580). Да и RK-DOS не составляет особых проблем переделать на единообразные сектора в 512 байт. Хотя это увеличит расход ОЗУ и утратится совместимость.
Понятно почему Е.Седов применил сектора переменной длины. Это конечно губит работу с БИС, которые это не поддерживают, но зато это экономит 2 байта в каталоговой записи (длина последнего сектора в байтах), отчего имя файла м.быть не 8, а 10 байт и позволяет тратить на VTOC 160 байт (столько сколько треков) вместо 512-ти байтов. Как минус, - узнать размер файла можно только считав его, что не позволяет выводить каталог с точными размерами (только с округлением до размера сектора).
Моя аналогичная ДОС (Z80), сделанная также по идеологии Aple-DOS потому использует сектора фиксированной длины (любой) и имеет в каталоговой записи длину последнего сектора и дату файла, отчего DIR нормальный.
Почему же промышленный контроллер на БИС, как и у всех остальных отечественных компьютеров - заведомо неподходящий?
Потому, что речь изначально о контроллере РК-ДОС на ВВ55 с его уникальным форматом записи. Как при наличии контроллера РК-ДОС может помочь "промышленный контроллер на БИС", я не понимаю. Куда его вешать, и, главное, зачем умножать сущности сверх необходимого? Даже если контроллер РК-ДОС сможет записать FM-трек в совместимом с IBM или ISO формате, прочитать это на типовом настольном ПК не удастся. Значит, или SD-контроллер для переноса, или сеть, или самодельный USB-контроллер дисковода для чтения конкретно РК-ДОСовских дисков.
Но хоть кому-то уже удалось считать дорожку целиком на PC? Пока нет подтверждения этому, есть сомнение, что формат РК-КНГМД совместим с промышленным стандартом.
Как появится возможность, попробую прочитать дискету РК-ДОС на Амиге, там контроллер дисковода умеет читать вообще все, что шевелится (практически втягивает поток бит).
Как при наличии контроллера РК-ДОС может помочь "промышленный контроллер на БИС", я не понимаю
Что значит при наличии. Естественно, новый контроллер втыкается в тот же слот, куда ранее втыкался контроллер РК-КНГМД, а последний выкидывается. Кто в здравом уме захочет иметь на дискетах вдвое меньший объём (400 вместо 800) ? Да и слабосильную шину РК86 нет смысла нагружать вторым, ставшим бесполезным, контроллером.
Ценно то, что скорость обмена тоже удваивается, что не особо важно для ДОС, где обмен физическими секторами, но очень важно для ДОС, где обмен логическими секторами по 128 байт (отчего выполняется куча излишних пересылок и скорость резко падает). Так CP/M в тех же условиях тормознее в 10 раз. Даже на ОРИОНЕ с реальным быстродействием втрое больше, чем РК и при принятии всевозможных мер ускорения, c РК-КНГМД скорость обмена получается в несколько раз медленнее, чем в RK-DOS на базовом РК86.
А что неясного в том, как совместимый контроллер может помочь в обмене ?
Дискеты ОРИОНА записанные контроллером с ВГ93 прекрасно читаются на PC, чем я много лет успешно пользовался. Есть даже чтение/запись файлов на диски в формате MSDOS на самом ОРИОНЕ (MS-Commander С.Коровкина, который был полезен, т.к даёт доступ к архивам на дискетах в формате MSDOS, не требуя держать PC включённым). На PC перенос 800 кб информации через дискеты занимает 45 секунд, без всяких хлопот с перестановкой компакт-флэш или 'microSD' носителей.
Хотя некоторые современные компы не полностью эмулируют 8272, но через BIOS стандартные MSDOS форматы 720 и 1.44 все они читают. Это значит, что для РК86 нужен обмен через дискету MSDOS, а не через дискету CP/M (т.к дискету CP/M на PC не считать), а вот РК86 с контроллером на ВГ93 может читать/писать диски в формате MSDOS.
Если в РК86 будет возможно использовать CP/M (а это счастливое время наступит, когда будут сделаны платы нового варианта РК86 с увеличенным ОЗУ), то я сразу же займусь плагиатом контроллера ПАРТНЁРА, точнее кода BIOS, т.к куча КНГМД на ВГ93 у меня уже есть.
Полагаю, что вместо повторения КНГМД МИКРОШИ полезнее выпустить плату РК-КНГМД с доп.ОЗУ или доп.ПЗУ, по типу того, каким был первый РК-КНГМД для RK-DOS V1.0, содержащий на плате 2 кб статического ОЗУ. Такой контроллер можно было бы сделать универсальным РК-МИКРОША-АПОГЕЙ. Схемотехника самого КНГМД та же самая, но ПЗУ 27256 (страницами по 4К в окне E000), плюс доп ОЗУ на w24512 (w24257) в окне A000...BFFF для РК86, в окне 8000...BFFF для МИКРОШИ, и совсем без ОЗУ для АПОГЕЯ. Это даёт в МИКРОШЕ 48К и НГМД одновременно, а также единый контроллер НГМД для всех клонов РК.
Есть неясность лишь относительно АПОГЕЯ. Для него невозможен адрес КНГМД F000, а д.быть иной (из тех, что предусмотрены для расширения). И ПЗУ должно быть отключаемым. Для АПОГЕЯ, оно может стоять не обязательно с E000, а м.быть и с адреса 0. ПЗУ с 0 может работать как стартовое ПЗУ по сбросу, если в качестве чип-селекта ему подать сигнал НП (начальный пуск). Тогда по сбросу код RK-DOS или CP/M грузится под вершину ОЗУ (ниже E000, т.к выше экран) и делается JMP F800. Там проверяется, удерживается ли клавиаша <УС> и если да, то после инициализации ячеек, ДОС в ОЗУ стартует. Можно также в директивы монитора добавить команду 'B', по которой считается контрольная сумма ДОС в ОЗУ и если O'KAY, то ДОС в ОЗУ стартует.
Такая концепция позволит ввести в АПОГЕЙ дисковод без вмешательств на плату, ограничившись заменой ПЗУ F800. Разный адрес BDOS и порта КНГМД не играет роли, т.к в КНГМД напрямую никто (никто кроме форматёра) не "лазиит", а поменять в программах адрес входа в BDOS RK-DOS и её служ.ячеек несложно. Впрочем, вряд-ли пользователи АПОГЕЯ захотят RK-DOS, если есть CP/M. А для CP/M проблем с адресацией нет, она универсальная, в отличие от RK-DOS.
Это лишь рассуждения на тот случай, если в будущем кто-то будет делать новые платы КНГМД, а не буквальный римейк старого. А сейчас для владельцев АПОГЕЯ актуально придумать, как подключить дисковод, используя имеющиеся КНГМД от МИКРОШИ. Это просто. Достаточно смонтировать в АПОГЕЕ слот для установки РК-КНГМД, обеспечив выборку ППА и регистра управления по адресам портов, что свободны в АПОГЕЕ. Если кто-то возьмётся ставить РК-КНГМД в АПОГЕЙ, то охотно странслирую CP/M и RK-DOS для выбранных для АПОГЕЯ адресов.
Sancho45
26.06.2017, 09:35
Приобрел печатную платку кнгмд для микроши. Спасибо tnt23 за труды вложенные в создание реплики и за помощь в приобритении
данной платки. Процесс сборки идет). По ряду причин решил использовать пзу большего обьема на 32 или 64 кб.Панельку прикрутил на 28 пинов.
Теперь решаю как сделать дешифратор адресов для пзу такого обьема, малой кровью.Все нужные сигналы есть на системном разьеме. Хочу сделать так
же 2 кб для монитора, что бы можо было менять его прошивку на платке контроллера, а не на основной плате, сигнал есть CS4. и окно выше 8000h для
софта. Может кто подскажет наиболее просто решение для этого дешифратора.
решил использовать на плате КНГМД ПЗУ большего объёма, на 32 или 64 кб.
Очень разумное решение. Хорошо бы, чтобы полезность этого "дошла" бы и до других владельцев плат КНГМД от МИКРОШИ и разработчиков плат новодела РК-КНГМД. Вы первый разумный человек среди пользователей МИКРОШИ и РК86, кто догадался, что полезно расширить ПЗУ и ОЗУ.
Ведь ценой замены панельки 24 ноги на 28, в ЭВМ фактически без лишних хлопот добавляется ROM-диск. В этом ПЗУ можно разместить не только базовую RK-DOS 2.95, но и путем простейшей её доработки, разместить в этом же ПЗУ все SYS-файлы RK-DOS, избавившись навсегда от необходимости загромождать ими все свои дискеты. А также иметь там разное системное ПО (например, для устройства на 'microSD'), что избавляет от необходимости делать холодную загрузку системного ПО с магнитофона.
Схема установки ПЗУ 27С512 не вызывает вопросов. Чип селект для области E000...EFFF получают объёдинением на двух диодах (заменяющих вентиль ЛИ1) двух отдельных чип-селектов E000 и E800, что в базовой схеме выбирали две РФ2. Но со схемой коммутации страниц ПЗУ по 4 кб в окне E000...EFFF - проблема. Проблема не со схемой, схема ясна (адреса A12...A15 формируются доп.регистром или ППА). А проблема в том, что ещё нет стандартов на расширение ПЗУ в области E000...EFFF. Сообщество пользователей РК86 считает, что расширение ПЗУ недопустимо, т.к нарушает аутэнтичность изделия.
Вообще-то нет никакой разницы каким образом управлять дополнительным ПЗУ. Но учитывая остутствие буферов на ОЗУ в РК86 (уж не знаю, если ли буфера на ОЗУ в МИКРОШЕ), что при подключении в шину доп.устройств сразу же её перегружает (особенно если уже стоит КНГМД), то желательно всё управление дополнительным железом сделать сигналами резидентного ППА D14, т.к такое решение не нагружает шину.
Я предложил вариант (http://zx-pk.ru/threads/26099-radio-86rk-plyus-sozdanie-i-obsuzhdenie-versii-2016g.html?p=915306&viewfull=1#post915306) использования ППА для формирования упр.сигналов доп.железом в РК86. Для РК86 это требует установки дешифратора ИД7 и на область F000...F7FF, что необходимо чтобы получить дополнительные чип-селекты для В/У и главное, на РК86 это позволяет иметь доступ к ППА при включении на 8000...BFFF дополнительного ОЗУ. В МИКРОШЕ применена более грамотная адресация В/У, отчего там нет проблем с расширением ОЗУ в области 8000...BFFF и процессор может обращаться к второму ППА (аналогу D14 в схеме МИКРОШИ) даже когда подключено доп.ОЗУ в этой области.
Разумнее всего и для МИКРОШИ и для РК86 использовать единый стандарт расширений ОЗУ и ПЗУ. Можно даже иметь разные адреса ППА управляющего железом, т.к совместимости и так нет и изменить в исходнике одну переменную и перетранслировать несложно (несложно это изменить и в готовом коде). Но вот биты в порту должны быть совмещены, иначе это будет совсем другая архитектура.
В вышеприведённом посте (http://zx-pk.ru/threads/26099-radio-86rk-plyus-sozdanie-i-obsuzhdenie-versii-2016g.html?p=915306&viewfull=1#post915306) для порта D14' я предложил использовать разряды так:
PA0...PA4 - номер куска из ПЗУ в окне E000...EFFF (адреса A12...A15 ПЗУ)
PA5 - номер одного из двух кусков ОЗУ по 16К в окне 8000...BFFF
PA6 - выбор такта ВИ53 канала 2 (2 МГЦ или 50 ГЦ)
PA7 - резерв для управления памятью
PB0...PB6 - номер полу банки ОЗУ в окне 0...7FFF (на SIMM-30)
PB7 - резерв для управления памятью
PC0...PC4 - номер фонта из ПЗУ знакогенератора в 32К
PC5 - ТУРБО/НЕТУРБО
PC6 - цвет/монохром
PC7 - отключить порт 8000...9FFF (переключение памяти 40/48 кб)
Хочу сделать также 2 кб для монитора, что бы можно было менять его прошивку на платке контроллера, а не на основной плате, сигнал CS4 есть
Эту мысль я не понял. Что речь о том, чтобы снять с основной платы ПЗУ F800 (РФ2) для разгрузки шины и использовать в качестве ПЗУ F800 какой-то фрагмент в 2 кб из ПЗУ на плате КНГМД ? Это конечно разгрузит шину и путём управления адресами A11...A15 ПЗУ 27C512 позволит программно переключать ПЗУ F800. Но это кажется некрасивым решением, т.к тогда МИКРОША без воткнутого КНГМД работать не сможет. Уж лучше напаять на РФ2 с ПЗУ F800 вторым этажом панельку и ставить туда альтернативный ROM-BIOS, управляя тумблером.
Хочу сделать также... окно выше 8000 для софта. Может кто подскажет наиболее просто решение для этого дешифратора.
Это я тоже не понял. Ведь речь о МИКРОШЕ. А в ней такое окно для включения сюда промышленной карты расширения ПЗУ или промышленной карты расширения ОЗУ предусмотрено изначально. Если речь о том, как конструктивно расширить ОЗУ МИКРОШИ, учитывая, что единственный слот МИКРОШИ занят КНГМД, то тут напрашивается вариант установки 32К статики (62256 или w24257), т.к она меньше грузит шину, чем лишняя банка РУ6. Но, если бы я имел МИКРОШУ, то я бы выкинул две банки РУ6, заменив их на одну банку РУ5, как и сделал на своём РК86.
Sancho45
26.06.2017, 18:33
Схема установки ПЗУ 27С512 не вызывает вопросов. Чип селект для области E000...EFFF получают объёдинением на двух диодах (заменяющих вентиль ЛИ1) двух отдельных чип-селектов E000 и E800, что в базовой схеме выбирали две РФ2.
Это я уже сделал, залил софт, дос пускается с контроллера с ппзу 27с512. Пока что на ли1.
Сообщество пользователей РК86 считает, что расширение ПЗУ недопустимо, т.к нарушает аутэнтичность изделия.
В микроше это предусмотрено, расширение.
Эту мысль я не понял. Что речь о том, чтобы снять с основной платы ПЗУ F800 (РФ2) для разгрузки шины и использовать в качестве ПЗУ F800 какой-то фрагмент в 2 кб из ПЗУ на плате КНГМД ? Это конечно разгрузит шину и путём управления адресами A11...A15 ПЗУ 27C512 позволит программно переключать ПЗУ F800. Но это кажется некрасивым решением, т.к тогда МИКРОША без воткнутого КНГМД работать не сможет. Уж лучше напаять на РФ2 с ПЗУ F800 вторым этажом панельку и ставить туда альтернативный ROM-BIOS, управляя тумблером.
На плате стоит заводская перемычка, с помощью которой откл пзу монитора, зачем паять вторую панельку?!, если можно воспользоваться пзу контроллера дл экспериментов. Селектор монитора идет а сист. разъем.
Это я тоже не понял. Ведь речь о МИКРОШЕ. А в ней такое окно для включения сюда промышленной карты расширения ПЗУ или промышленной карты расширения ОЗУ предусмотрено изначально. Если речь о том, как конструктивно расширить ОЗУ МИКРОШИ, учитывая, что единственный слот МИКРОШИ занят КНГМД, то тут напрашивается вариант установки 32К статики (62256 или w24257), т.к она меньше грузит шину, чем лишняя банка РУ6. Но, если бы я имел МИКРОШУ, то я бы выкинул две банки РУ6, заменив их на одну банку РУ5, как и сделал на своём РК86
хочу еще окно для пзу при работе нгмд.
- - - Добавлено - - -
Так же хотел заметить, что прошивка дос 2.9 из архива сy6 больше 4кб а пару байт, с учетом файлов формата rk и отличается от приведенной тут в начале темы.
прошивка RK-DOS 2.9 из архива сy6 больше 4 кб на пару байт, с учетом файлов формата rk и отличается от приведенной тут в начале темы
Вы что-то путаете. Прошивка от сy6 не больше 4 кб (как иначе она прошивается в две РФ2). Полгода назад я специально сравнил её прошивку с той прошивкой, что продавали в TOO "Лианозово" в 1993 и они совпали. Понятно, что файл FORMAT.COM можно встроить в код RK-DOS в виде резидентной команды, но размер RK-DOS от этого увеличится не на пару байт, а скорее на пару килобайт.
А ПЗУ на КНГМД надо расширять не только из желания доработать RK-DOS (отчего размер разбухает), а хотя-бы потому, что размер RK-DOS увеличивается за пределы в 4 кб при замене использования аппаратного READY, на его программную эмуляцию на базе сигнала INDEX (т.к современные флоповоды уже не формируют сигнал READY).
хочу еще окно для ПЗУ при работе НГМД
Если область 8000...BFFF занята под расширение ОЗУ, то надо выискивать неиспользуемые "дыры" в адресном пространстве МИКРОШИ, но при шаге дешифратора в 2 кб там уже всё занято.
А зачем Вам ещё одно окно ПЗУ? Во-первых можно "прокачивать" в уже имеющемся окне E000...EFFF страницами по 4 кб любые объёмы ПЗУ. А во-вторых, т.к дополнительное ОЗУ 8000...BFFF программами не используется, то копируйте туда из ПЗУ программу размером до 16 кб. Это и программно удобнее, чем второе окно ПЗУ и деталей меньше.
Sancho45
26.06.2017, 19:43
Вот это прошивка, в начале адреса размещения 4 байта, в конце котрольная сумма, если правильно понял. После какого байта конец самого дампа прошивки ?
Мне не принципиально, в каком окне прокачать пзу, вопрос был в дешифраторе всего этого малой кровью на самом контролере.
В Вашем файле применён формат для эмулятора EMU80:
2 байта - начальный адрес (00 00)
2 байта - конечный адрес (0F FF)
4096 байта - сам файл RK-DOS для прошивки в ПЗУ E000
2 байта - пилотон длиной в 2 байта 00
1 синхробайт E6
2 байта - контр.сумма по F82A
вопрос был в дешифраторе всего этого малой кровью на самом контролере
Не понял зачем дешифратор на плате КНГМД. ПЗУ выбирается чип-селектом и сигналом /MEMR (или /RD, если без СК). На системный разъём приходят два чип-селекта /E000 и /E800. Дешифратор для них уже есть. Объёдинив эти сигналы диодами, получается чип-селект для ПЗУ в 4 кб (2732). Если ПЗУ типа 2764, 27128 или 27256, то их лишние адреса надо вывести на системный разъём. А на основной плате как-то сформировать эти адреса (проще и удобнее всего их получать из доп.ППА, аналога D14 в схеме МИКРОШИ). Если тратить доп.ППА жалко, а доп.регистры шина не тянет, то можно поставить пару микро-переключателей (для формирования адресов ПЗУ A14, A15), а в качестве адресов A12, A13 использовать неиспользуемые биты PC1 и PC2 порта клавиатуры (ведь в МИКРОШЕ клавиатура не MS-7007, где эти биты заняты).
Если из этого же ПЗУ на плате КНГМД надо получить и ПЗУ F800 и ПЗУ RK-DOS и ещё одно окно в 1 кб где-то в неиспользуемых "дырках" карты памяти, то лучше всего применить РЕ3, что сократит число деталей. Но такой дешифратор удобнее ставить на основной плате, подавая на КНГМД только готовый чип-селект (который теперь возникает для трех окно - окна ROM-BIOS F800...FFFF, окна RK-DOS E000...EFFF и третьего окна по неизвестному адресу размером в 1 кб). Какая польза от второго маленького окна ПЗУ ?
Sancho45
27.06.2017, 07:20
В Вашем файле применён формат для эмулятора EMU80:
Теперь понятно. Не разобрался до конца.
На системный разъём приходят два чип-селекта /E000 и /E800. Дешифратор для них уже есть. Объёдинив эти сигналы диодами, получается чип-селект для ПЗУ в 4 кб (2732).
Это я уже сделал на ли1 и написал выше.
Решил пока использовать все чип селекторы и один корпус ли1 на контролере . Итого будет использовано 22 кб из 64. Дальше буду думать.
Практически собрал свой экземпляр, кроме ПЗУ и резисторов с конденсаторами.
61517
Не знаю позволяет ли это конструктив МИКРОШИ, но я при спайке обоих своих плат РК-КНГМД (одна для РК, другая для ОРИОНА) на точно такой же плате, для того, чтобы можно было использовать стандартный шлейф дисковода, скраю платы на четырёх винтах закреплял маленькую платку, где был смонтирован шильдик (штырьки) на 34 контакта, куда и надевался разъём стандартного соединительного шлейфа. Это намного удобнее и эстетичнее, чем использовать отдельные провода МГТФ для соединения платы и 34-рёх контактного разъёма дисковода.
Может быть, я тоже такой переходник сделаю. Хотя мне важнее прицепить тонкий ноутбучный дисковод, у него все равно собственный 26-контактный шлейф.
Sancho45
06.07.2017, 10:33
Скрин-шоты моих эмуляторов ОРИОНА на IBM PC и РК86 на ОРИОНЕ http://barsik.ut88.ru/Screen_Shots.rar
Документация на эмулятор и некоторые антикварные тексты:
http://barsik.ut88.ru/DOC.rar
http://barsik.ut88.ru/RK86_ALL.rar - здесь все мои чужие программы РК86 (т.е из сезона 1987-88 поднятые с кассет, и из 1994 с дискет Лианозово). Также тут исходники программ для РК86 и мои тексты из 1993-96, имеющие отношения к РК-КНГМД.
http://barsik.ut88.ru/SOURCE.rar - здесь исходники 1995...2004 для РК-КНГМД и инстументарий для их трансляции. Всё что остается сделать - только запустить BAT-файл.
После распаковки RAR-файла подкакаталог '../SOURCE/RKDOS_SRC' содержит исходники RK-DOS разных форматов дискеты с разными драйверами для эмулятора и для реала, CHKDSK, нортон, LORD, и по мелочи. Вот список основных каталогов с размерами.
CHKDSK RKDOS....... 28 кб - исправление дискет (РК-ДОС глючит, это ошибки логики, не железа)
CP........................ 52 кб - перегружает все файлы квазидиска ORDOS в диcк РК-ДОС
DOS for EMU ....... 2.45 мб - для работы в эмуляторе, потому не содержит дискетных п/п-мм
DOS for REAL ...... 2.52 мб - привод A:- эл.диск из лишнего ОЗУ ОРИОНА, B:- реальный дисковод
FILES ................... 69 кб - странслированные DOS ОРИОНА, внешние команды и ORDOS драйверы
FORMAT .............. 203 кб - форматёры на 5, 7 и 8 секторов, больше 8-ми (640К) РК-ДОС не может
LORD RKDOS ........ 152 кб - НОРТОН, где одна панель квазидиск ORDOS, вторая диск РК-ДОС
NC RKDOS ........... 127 кб - НОРТОН на два привода РК-ДОС (работает и при одном)
ORIG SRC ............ 155 кб - исходники оригинала РК-ДОС 2.95
TESTS ................. 35 кб - примеры чтобы понять идиотский программный интерфейс РК-ДОС
Внешние команды... 34 кб - исходники SYS-файлов (они без Z80 команд, т.к оригиналы)
В каталоге ' ..\SOURCE\RKDOS SRC\ORIG SRC' находятся оригиналы RK-DOS 2.95 для КР580. Исходники внешних команд (*.SYS) годятся и для РК86 (достаточно в исходнике изменить адрес BDOS на E001).
Некоторые работы по железу 1989-1999 здесь:
http://barsik.ut88.ru/SP_and_ORION.rar и здесь:
http://barsik.ut88.ru/Irisha.rar.
Можете также посмотреть моё промышленное железо APPLE-II:
http://barsik.ut88.ru/APPLE-II.rar
Извиняюсь за качество фотографий (телефон с поганой оптикой и без вспышки).
Не могли бы вы повторно выложить данные файлы ?
Теперь решаю как сделать дешифратор адресов для пзу такого обьема, малой кровью.Все нужные сигналы есть на системном разьеме. Хочу сделать так
же 2 кб для монитора, что бы можо было менять его прошивку на платке контроллера, а не на основной плате, сигнал есть CS4. и окно выше 8000h для
софта. Может кто подскажет наиболее просто решение для этого дешифратора.
Младшие три бита PB0, PB1, PB2 контроллера вроде бы свободны. Нужно глянуть исходники РК-ДОС, вдруг она эти биты сохраняет.
Не могли бы вы повторно выложить данные файлы ?
Да, я уже в курсе, что данный временно арендованный домен "протух". Я могу выложить на 'Яндекс.Диск'. Хотя, насколько я понимаю, это тоже только до тех пор пока этот архив хранится в каталоге 'Яндекс.диск' на моём винчестере. Я обнаружил, что как только я удаляю файл из этого каталога, то и в сети такой файл исчезает. Увы, я не умею выкладывать так, чтобы не тратилось место на моём винчестере и оставалось в "облаках" надолго.
Выложу в ближайшее время, а вышеприведённый пост, если удастся его найти, соответственно отредактирую.
кто подскажет наиболее простое решение для дешифратора
Младшие три бита PB0, PB1, PB2 контроллера вроде бы свободны. Нужно глянуть исходники РК-ДОС, вдруг она эти биты сохраняет
Эти ноги на реальной плате КНГМД от МИКРОШИ висят в воздухе (что вообще-то, неграмотно), т.е свободны.
Порт 'B' в КНГМД используется на ввод, т.е сама ДОС на состояние битов порта не влияет. Хотя RK-DOS с портом 'B' работает нетрадиционной командой INC (HL), что для ППА делать непринято, но всё-равно можно через эти 3 входа читать 3 какие-нибудь бита, например из доп.ПЗУ. Но читать дополнительное ПЗУ побитово через порт B будет очень медленно. Других способов, как эти 3 бита помогут упростить дешифратор предназначенный для включения в неиспользуемых "дырках" адресного пространства дополнительного ПЗУ или ОЗУ, я пока не вижу.
Да, я уже в курсе, что данный арендованный сервис "протух" (хозяин сайта повысил арендную плату). Я могу выложить на 'Яндекс.Диск'. Хотя, насколько я понимаю, это тоже только до тех пор пока этот архив хранится в каталоге 'Ян.диск' на моём винчестере. Я обнаружил, что как только я удаляю файл из этого каталога, то и в сети такой файл исчезает. Увы, я не умею выкладывать так, чтобы не тратилось место на моём винчестере и оставалось в "облаках" надолго.
А его приложение не позволяет отключить синхронизацию отдельной папки? И работать с ней только через веб-интерфейс? Впрочем, для этого можно просто создать отдельный эккаунт :)
Black Cat / Era CG
07.07.2017, 12:06
Я обнаружил, что как только я удаляю файл из этого каталога, то и в сети такой файл исчезает. Увы, я не умею выкладывать так, чтобы не тратилось место на моём винчестере и оставалось в "облаках" надолго.
Да. Уже сказали. Надо просто отключить синхронизацию папки. После чего ее локальную копию можно смело чистить, на сервере она останется.
Sancho45
08.07.2017, 18:36
http://barsik.ut88.ru/SOURCE.rar - здесь исходники 1995...2004 для РК-КНГМД и инстументарий для их трансляции. Всё что остается сделать - только запустить BAT-файл.
Может кто скачал данный файл, поделится ?
Sancho45
08.07.2017, 20:25
Разбираюсь с досом. Не совсем работает мой контроллер.
А каковы симптомы? Я вот полдня убил на поиск неисправности в своем, из-за чего не стартовал процессор - оказалась дохлая ВВ55.
gurfunkel
08.07.2017, 21:35
Увы, я не умею выкладывать так, чтобы не тратилось место на моём винчестере и оставалось в "облаках" надолго.
Кроме того, что уже сказали (отключить синхронизацию папки), можно вообще установить Яндекс.Диск 2.0 (бета-версия) (https://yandex.ru/set/lp/disk2/0). Он не хранит файлы на компьютере, а сразу загружает в облако.
Sancho45, ПЗУ подправлено под "Микрошу"? У меня пока нет, заношу ручками 25 в D1D1 перед GE000.
Выложил старые файлы, что были ранее на домене, который теперь недоступен, на яндекс.диск.
Какие-то старые файлы, что ранее лежали в домене barsik какого-то сайта (https://yadi.sk/d/6nRNeDP63KseH6)
Задержка с выкладкой была вызвана тем, что у меня перестал работать 'яндекс.диск' и понадобилось время, чтобы разобраться в проблеме. В итоге, пришлось переинсталлировать 'яндекс.диск', т.к оказалось, что при удалениии яндекс.браузера удалились какие-то файлы, отчего яндекс.диск перестал выдавать ссылку на файл, хотя сам пункт "создать ссылку" в меню остался. После повторной инсталляции 'яндекс.диска', его работа восстановилась.
san010101
09.07.2017, 06:35
Не нужно ставить ни каких прог, web доступ никто не отменял.
Sancho45
09.07.2017, 07:14
А каковы симптомы? Я вот полдня убил на поиск неисправности в своем, из-за чего не стартовал процессор - оказалась дохлая ВВ55.
Sancho45, ПЗУ подправлено под "Микрошу"? У меня пока нет, заношу ручками 25 в D1D1 перед GE000.
В пзу сразу прописал D1 вместо С1, окошко на дискете заклеил, сигал READY переделал.
При форматировании диска доходит до 80(160) трека, потом на 20h (32), записывает VTOC, переходит на 0-ую дорожку и пишет IO ERR.
Соответственно в досе та же ошибка. При ручном считывании любого трека данные соответствуют разметке, на 20h(32) треке тоже все хорошо.
Каким форматёром пользуетесь? Когда происходит само форматирование, то функции RK-DOS не используются (используется подпрограмма форматирования трека в самом коде форматёра). Потому требуется изменить адрес ВГ75 и в форматёре (форматёр тоже записывает 25 в адрес C001). А вот запись VTOC выполняется уже средствами RK-DOS. При неудаче попытки чтения или записи, головка всегда отползает на нулевую дорожку (посмотрите в точке BADOP), а затем позиционируется на нужную дорожку заново.
А как Вы переделали READY ? О чём речь, о аппаратной доработке или о модификации кода RK-DOS? Кстати, в грубом варианте для дисководов не имеющих READY можно не эмулировать сигнал READY программно из сигнала INDEX, а просто при выходе из подпрограммы PUSK задавать паузу в секунду для раскрутки колеса. Это хуже, т.к здорово тормознёт, но зато это намного меньший объём кода.
Sancho45
09.07.2017, 09:33
Форматер из монитора, отсюда брал
Потому требуется изменить адрес ВГ75 и в форматёре (форматёр тоже записывает 25 в адрес C001).
про это знаю посмотрел код форматера, там тоже заменил на D0.
А как Вы переделали READY ?
переделка аппаратная, в самом диководе, с контроллера двигателя раскрутки.
А вот запись VTOC выполняется уже средствами RK-DOS. При неудаче попытки чтения или записи, головка всегда отползает на нулевую дорожку (посмотрите в точке BADOP), а затем позиционируется на нужную дорожку заново.
вот с этим и пытаюсь разобраться, изучаю ваши тексты.
В пзу сразу прописал D1 вместо С1, окошко на дискете заклеил, сигал READY переделал.
При форматировании диска доходит до 80(160) трэка, потом на 20h (32), записывает VTOC, переходит на 0-ую дорожку и пишет IO ERR.
Соответственно в досе та же ошибка. При ручном считывании любого трэка данные соответствуют разметке, на 20h(32) трэке тоже все хорошо.
Попробовать другой дисковод? У меня из примерно 5 разношерстных 3.5 дисководов (все с переделанным READY) нормально заработали только 2. Причем один из не заработавших был той же модели, что и рабочий.
- - - Добавлено - - -
При ручном считывании любого трэка
А как производится ручное считывание?
Sancho45
09.07.2017, 10:11
написал коротенькую програмку(на основе вашей читалки), отключает вг75 и считвает побайтно текущий сектор,сохраняет в озу,потом останавливает дисковод и холодный старт монитора(для иниц. вг75) и гляжу потом, разметка полностью соответствует, пропущеных байтов нет, vtoc тоже соответствует, в поле даных каталога A0, что соответствует 160 секторам и везде нули за исключеием пары байт (битые сектора), ссылки на каталог тоже присутствуют. Но не уверен, что именно должно быть в VTOC при чистом диске кроме ссылок на каталог и в нулевом секторе 32 трека отметок о чистых секторах
Подумалось вот по поводу READY. В правильном приводе сигнал устанавливается только после раскрутки шпинделя до рабочей скорости. Если READY сгенерить хакерским способом (например, как часто делают для Амиги - диодом от сигнала выборки привода), не дожидаясь выхода шпинделя на нормальный режим, то контроллер будет терпеть неудачу, пытаясь синхронизироваться по битовому потоку с неверными времянками.
Как вариант, можно попробовать добавить в READY задержку, RC цепочкой или одновибратором.
А может у Вас что-то с сигналом SIDE (сторона диска). Попробуйте читать сектора на чётном и нечётном треке. Посмотрите сигнал осцилографом при формате.
VTOC устроен просто. Это сектор размером в 160 байт. Каждый байт отвечает за 1 трек. Номер трека определяет смещение от начала VTOC (или сектора). Т.к в базовой RK-DOS формат только 5 секторов на трек, то значение имеют только биты D0,D1...D4. Если бит выставлен, то сектор занят, если равен 0, то сектор свободен.
Что за читалку используете?
В разных ДОС (всего я имел 4 другие ДОС, кроме RK-DOS) используются немного различные форматёры, хотя все они на базе подпрограмм Е.Седова. Но есть и отличия. В частности для своих ДОС (в том числе использующих ту же идеологию ДОС от АГАТА, т.е с секторами списков T/S list, я использовал общепринятую нумерацию секторов, т.е начиная с сектора 1 (а сектора 0 вообще нет), а Е.Седов в RK-DOS использовал нумерацию секторов с 0.
Чтобы получить отладочную версию RK-DOS (и других ДОС на основе п/п-мм Е.Седова) я транслировал версию ДОС с одной доп.командой VIEW. Эта команда (без параметров) просто показывает дамп секторов начиная с системного трека. Это трек 32 в RK-DOS. А в АГАТ-ДОС и оригинальной Apple-DOS 3.3 - это всегда 17-тый трек, т.к это середина 35-ти трековой дискеты. А для ускорения работы (т.к древний НГМД с улиткой шагает очень медленно, 100 МСЕК на шаг, вместо 2...6 МСЕК в современных флопах), каталог и располагают на средней дорожке дискеты.
На этой дорожке сектор 0 - это VTOC, а далее следуют сектора каталога. На дохлой дискете удобно сразу посмотреть дамп VTOC (ЕМНИП, кажется это абревиатура от "Volume Table of Contents"). Затем нажимаем пробел и видим первый сектор каталога. После каждого нажатия выводится дамп очередного сектора.
Вообще о идеологии и структуре диска ДОС АГАТА (и соответственно RK-DOS) популярно и достаточно подробно написано в болгарском журнале:
"Компьютер за вас", номер 5-6, 1990 страница 20
Название журнала не "для вас", а именно "за вас". В остальном болгарский язык вполне понятный.
Чтобы получить отладочную версию надо в исходник вставить строку INCLUDE для файла VIEW.INC, и добавить строку в таблицу команд. Обычно я в своих ДОС имел ключ OTLAD, отчего это делалось автоматически.
Для ОРИОНА адреса трансляции менять было не надо (т.к там ДОС в ОЗУ) а вот для РК86 отладочную версию придётся странслировать в ОЗУ ниже экрана (оставив ~600H для буферов), например на адрес 6000H. Приходится транслировать в ОЗУ, т.к для ПЗУ E000 в 4 кб это не странслировать, т.к размер такой RK-DOS уже намного больше, чем 4 кб. Если хочется, чтобы с такой RK-DOS в ОЗУ работали внешние SYS-команды, то на E000 можно временно поставить ПЗУ РФ2 с JMP-ом на код ДОС в ОЗУ так, чтобы вход в BDOS E001 по-прежнему работал.
если выдавать READY=0 не дожидаясь выхода шпинделя на нормальный режим, то контроллер будет терпеть неудачу, пытаясь синхронизироваться по битовому потоку с неверными времянками
Для RK-DOS это не важно. Потому что специально делается куча попыток чтения, а в современных флопах колесо разгоняется за один оборот. Это в древних флопах с резиновым пассиком (5050, 5088) колесо разгоняется намного дольше, но и с НГМД выпуска 1982 года работало. Интересно, что сразу после записи обязательно делается чтение, как раз потому, что колесо может быть ещё не разогналось и кстати, если сделать так, чтобы выполнялась всего одна-две попытки записи (при неудаче этого, - уход на ошибку), то плохо работает. А без контрольного чтения сектора после его записи вообще не работает (я хотел отключить контрольное чтение для ускорения, но увы).
У меня из пяти разных дисководов 3.5" нормально заработали только два
Странно. У меня работали все (6 штук, из них два были 3.5"). Бывает, что колесо вращается слишком быстро и последний сектор (тот, что перед индексной дыркой) затирает первый сектор (тот что первый после индексной дырки). СтОит попробовать заменить кварц на более высокочастотный (+ 5...15%) или сократить число байтов на гап, межсекторный интервал. Если дисковод 5.25"-HD включённый перемычками как HD (отчего скорость колеса выше), то входной такт нужен не 16 МГЦ, а 20 МГЦ. Кроме того, дисководы 3.5"-HD не рассчитаны на низкую частоту и длительность импульсов, отчего в формате с бОльшим числом секторов на трек (и соответственно, бОльшей частотой такта) давали лучшую надёжность. Надо пробовать разные дискеты, по разному заклеивая дырку, меняя кварцы. Тут очень удобен форматёр, который в ходе формата выдаёт плюсики и минусы для индикации дохлоты.
Запустил свой экземпляр реплики КНГМД. В качестве ПЗУ поставил W27C64. С диодами что-то у меня не заладилось, сделал выборку на ЛИ1. Также оказался битый ВВ55А, пришлось его менять. Ну и где-то наврал в переходнике на флопы, из-за чего флоп А: виден как B:, а B: не виден совсем.
61589
Чтобы SE.COM нормально шел на "Микроше", нужно заменить в нем 2 байта:
62B1: 80 -> C0
69D1: C0 -> D0
Sancho45
10.07.2017, 21:22
61604
Работают и контроллер и дисководы все(2шт.)) Проблема все таки в восприятии сигнала Ready самим досом во времени нужном для готовности дисковода (до 500ms). Надоели всякие переделки, тупо припаял провод и после команды DIR через секунду подключаю провод от синала READY на массу и все работает. Но проблема не в сихронизации. Форматируются диски без проблем из монитора при закороченном сигнале READY и задержка ему с подачей не нужна, там не используется проверка сигнала rdy в самом форматере. При прямом считывании с контроллера (при отключенным ВГ75), тоже все замечательно,используется проверка INDEX, байт в байт все соответствует, а вот в досе нужна задержка с подачей сигнала Ready . Позже буду разбераться как решить проблему .
Vladimir_S
11.07.2017, 05:13
Sancho45, По опыту знаю, что если READY посадить на землю, то до поры, до времени вроде работает, но в один момент все рушится. У меня восемь штук Samsung SFD321B и после переделки уже который год работает без единого сбоя. http://zx-pk.ru/threads/11319-radio-86rk-podklyuchenie-diskovoda.html?p=734530&viewfull=1#post734530
У меня тоже возникли проблемы с READY, когда я перешёл на импортный флоп, в котором не оказалось READY. С флопом без READY поначалу я просто закорачивал какой-то сигнал контроллера на землю, отчего колесо вращалось всегда. А затем долгое время (~год) пользовался контроллером, в котором эмулировал сигнал READY аппаратно. Для этого я напаивал вторым этажом какой-то КМОП вентиль 561 серии. Там стояла RC-цепочка (КМОП допускает резистор до 200 кОм), обеспечивающая задержку на пол-секунды, формирующая READY из сигнала выбора дисковода с задержкой для раскрутки. Это неполноценное аппаратное решение, т.к даёт READY даже, если колесо вообще не крутится. Но и это решаемо (см.ниже).
Кроме того на всех моих контроллерах от МИКРОШИ стояли два диода от сигналов выбора (флопа A и флопа B) к сигналу СТАРТ МОТОРА (т.е диоды идут от 10-той и 12-той ног на 16-тую ногу).
А для ОРИОНА я уже чуть переделал саму RK-DOS (т.к в ОРИОНЕ она размещалась в ОЗУ, отчего нет ограничения в 4К на объём кода) так, что сигнал READY программно эмулируется из сигнала INDEX.
Кстати, если кто разбирается в низкоинтегральной схемотехнике, то несложно эмулировать сигнал READY из сигнала INDEX аппаратно. В простейшем случае это одновибратор АГ3 с периодом одновибрации лишь чуть более долгим, чем одна 300-тая минуты (т.к INDEX появляется именно с таким периодом, когда колесо на номинальной скорости). Тогда одновибратор при каждом обороте будет перезапускаться сигналом INDEX, но как только колесо встанет, то как и положено, сигнал READY пропадёт. Думаю точно такая же схема формирования READY стоит и в самих древних дисководах типа МС-5305, МС-5311 и МС-5313.
Если кому-то интересно, то могу странслировать такую версию RK-DOS 2.95, в которой сигнал READY будет эмулироваться программно, причём не будет команд Z80 и размер сохранится в 4 кб (но для этого придётся выкинуть подпрограмму вывода на принтер и немного сократить тексты об ошибках).
Sancho45
11.07.2017, 08:14
Если кому-то интересно, то могу странслировать такую версию RK-DOS 2.95, в которой сигнал READY будет эмулироваться программно, причём не будет команд Z80 и размер сохранится в 4 кб (но для этого придётся выкинуть подпрограмму вывода на принтер и немного сократить тексты об ошибках).
Интересно. Я за програмное решение.
Нашёл какой-то RK-DOS на Z80 для ОРИОНА, что был без эл.диска, переделал его снова на КР580 (заменой JR команд и возвратом IN/OUT команд) и заменил в нём подпрограмму READY на другую. Кстати, если кому интересно, замена в RK-DOS кодов на Z80 освобождает более 170 ячеек. А самая простая подпрограмма READY эмулируемая из сигнала INDEX длиннее на ~50 байт. Т.е данная версия получена не из оригинала. Хотя какой-то почти без комментариев исходник оригинала RK-DOS я тоже нашёл и проверил, что он транслируется один в один, - несовпадение только в одном байте, но это так и надо, это исправлена ошибка (опечатка в исходнике) Е.Седова. Его тоже прилагаю. А также прилагаю исходник RK-DOS 1.0 2 кб в понятном виде (дампа нет, был только какой-то ASM-исходник, в котором я и попытался разобраться). Не пытайтесь прошивать эту RK-DOS 1.0 с целью с'экономить одну ПЗУ РФ2. Эта первая версия RK-DOS не только убогая, но и для совсем другого железа (схема есть, где-то в середине этой темы).
Для тех у кого нет Windows XP и невозможно пользоваться TSR-эмулятором CP/M (22NICE), чтобы странслировать выложенный исходник с помощью Microsoft M80, кроме исходника приложил и уже cтранслированные две версии - для МИКРОШИ и РК86 (хотя для трансляции можно воспользоваться DOS-BOX-ом или в крайнем случае в каком-нибудь эмуляторе, где есть CP/M). Отличие версий для РК и для МИКРОШИ лишь в одном байте (кидается в порт ВГ75+1 число 25, что сокращает длину ПДП-посылки, чтобы КНГМД лучше работал), т.к адреса ВГ75 разные (а адрес порта КНГМД F000 у РК и МИКРОШИ совпадают, а к остальным портам ДОС не лезет). Адрес доп.ППА, что служит для принтера также не важен, т.к тут принтер совсем забит.
Ни в реале, ни в эмуляторе не проверял. Не исключены ошибки и исходник был случайный. Потому не спешите прошивать сразу в ПЗУ, а проверьте сначала в ОЗУ. Для этого я странслировал на адрес 6000. Естественно, т.к вход в BDOS уже не E001, а 6001, то никакие программы RK-DOS работать не будут (в том числе и SYS-файлы). Это только, чтобы проверить, что работает. Если работает, то проверьте работу уже версии для E000 в эмуляторе EMU80 (В.Пыхонина, не B2M). И только затем, если всё O'KAY, то можно попробовать прошить в ПЗУ и проверить в реале.
Sancho45
11.07.2017, 15:33
c адреса 6000h запускается, но после ввода команды dir , пропадает изобр. На клавиши реагирует , но повторные команды не отрабатывают полостью, дисковод внешне вкл и выкл
Завтра уже займусь
c адреса 6000h запускается, но после ввода команды dir , пропадает изображение
Да, это так, - проверил в эмуляторе 'emu80' для КР580 то, что получил конверсией из кодов Z80. Там также гаснет экран. Видимо какую-то команду Z80 забыл. Просто исходник оригинала я нашёл, когда уже переделал на КР580 исходник с командами Z80. Лишний раз убедился как неудобно не иметь собственного эмулятора, в котором отловить недопустимые для КР580 команды Z80 не составляло бы труда.
Разбираться почему не работает исходник адаптированный от Z80 сложно (и лениво), потому нашёл исходник оригинала RK-DOS 2.95 и просто сделал на нём ту же простейшую переделку (т.е замену п/п-ммы READY на другую). И проверив в эмуляторе, убедился, что по крайней мере в эмуляторе, это работает. Как с адреса 6000, так и на E000. Однако проверить можно только версию для РК86, т.к эмулятор В.Пыхонина не поддерживает КНГМД для МИКРОШИ.
Заменил вложение в посте (#663 (http://zx-pk.ru/attachment.php?attachmentid=61612&d=1499785634)). Там также исходник и странслированные файлы. При перетрнсляции для МИКРОШИ проверяйте в исходнике ключ 'RK86' (он д.быть для трансляции для МИКРОШИ =0).
Удобно было бы иметь утилиту типа SteinBlume, но не для формата CP/M а для формата RK-DOS. А то вручную, т.е через магнитофон по директиве 'I' и командами SAVE, формировать новые образы дискет - утомительно. Также неудобно снимать файлы с образов дискет, - это сначала надо сделать LOADA с образа дискеты, а затем выйдя в монитор по сбросу (и не факт, что ОЗУ при этом не разрушится) директивой O монитора выгрузить на ленту, т.е сохранить файл на винчестере PC.
И так и не понял, как форматировать дискеты в эмуляторе EMU80. Сначала, не "вставляя дискету" в приводе B, с дискетой с системными файлами входящей в дистрибути в эмулятора "стоящей" в приводе A, набрал команду "FORMAT B:". После приглашения, нажал пробел и получил надпись "FORMATING...". Ждал долго, но всё зависло. Вообще-то неудобно не знать, что делает дисковод. Вот в эмуляторе АМИГИ работа дисковода индицируется в маленьких вкладках в нижней балке (под экраном) и ясно, идёт-ли запись или чтение и какая дорожка и какой сектор читаются/пишутся (т.е сразу видно где стоИт головка НГМД).
Потому новые образы дискет в эмуляторе EMU80 создаю из образа той дискеты, что входит в дистрибутив, для чего на винте IBM PC делаю её копию (под именем DISK_nn.RDI). А затем "поставив" эту новую дискету в привод 'B' запускаю удаление командой "ERASE B:*.*", что длится очень долго, но в итоге получается новая пустая дискета (хотя и не чистая, т.к каталог заполнен удалёнными файлами). Затем уже можно приступать к электротраху по её заполнению, т.е считывая файлы по одному директивой I монитора и записав на бумажку адреса, после перехода в RK-DOS командой "GE000", командой SAVE записываем считанный файл на диск.
Это довольно утомительное и трудоёмкое занятие. Поэтому ещё раз сошлюсь (просьба без злобы со стороны авторов эмуляторов) на идеологию своих эмуляторов, где вообще не используются никакие образы дисков, а используется обычный каталог на винчестере PC, а эмулятор сам при старте формирует нужный образ дискеты из файлов данного каталога (т.е каталога с именем FILES.DOS). Это одновременно избавляет от двух проблем, - не надо формировать слепки дискет и не надо потом трахаться, чтобы извлечь отдельные файлы из этих слепков. Та же идея реализована у меня и для ROM-дисков, что в чужих эмуляторах также реализованы файлом-образом, а у меня просто обычным каталогом с файлами, что хотелось бы видеть на ROM-диске (что избавляет от головной боли по формированию образов ROM-дисков).
а для Специалиста RK-DOS ?
barsik,
Коллеги, а в чем разница между досами 2.9 и 2.95?
а возможна ли RK-DOS для Специалиста?
На СПЕЦИАЛИСТА использовать RK-DOS непроблематично и удобно. Потому-что, во-первых, в базовом СПЕЦИАЛИСТЕ есть куча свободных панелек для установки ПЗУ с RK-DOS. Во-вторых, процессор КР580, а не Z80 (что избавляет от необходимости переделывать RK-DOS). В-третьих, т.к свободного ОЗУ у СПЕЦИАЛИСТА не намного больше, чем у РК86 (да и программ с размером более 7000H, кажется, немного), то перетранслировать RK-DOS на другие адреса нет смысла, отчего отпадает лишний труд по адаптации внешних команд (т.е SYS-файлов).
Я тоже одно время подключал РК-КНГМД к СПЕЦИАЛИСТУ и имел RK-DOS для него в 1994. Перетрансляция не составила проблем. Хотя "в лоб" перетранслировать, лишь заменив адрес РК-КНГМД в исходнике не получится.
Дело в том, что Е.Седов в RK-DOS использует обращение к РК-КНГМД командами IN/OUT, а хотя процессор тот же и также дублирует адрес порта на старшей половине адреса, но такой трюк требует, чтобы на порт отводилось не менее 400H байтов. А я в СПЕЦИАЛИСТЕ использовал разбиение области портов дешифратором ИД7 с шагом в 100H. Потому использовал чуть-чуть изменённую версию, где критичные команды IN/OUT заменены на LD. При области В/У шириной в 100H допустимы IN/OUT только для порта PORT+0, а обращение в PORT+1, PORT+2, PORT+3 и PORT+4 не попадают в нужные порты РК-КНГМД. Помню, что "извращения" Е.Седова экономят ему ~64 байта. А для замены только портов надо выиграть вдвое меньше байтов. Столь немного байтов для НГМД с сигналом READY легко "добыть" посокращав текстовые сообщения и "забив" вывод на принтер. Хотя, чтобы получить версию, работающую с дисководом без READY надо выиграть ещё ~40 байтов.
Но можно ничего не переделывая, просто отдать всю область F000...F7FF на адресацию РК-КНГМД, естественно выкинув из панельки ПЗУ по этому адресу. И если в вашем СПЕЦИАЛИСТЕ стоят два диода (по схеме от SP580), что обеспечивают попадание при обращениях CPU в адреса F800...F8FF на адреса C800...C8FF (т.е если входы F800, F803, F806, F809... сделаны работающими), то даже перетранслировать код RK-DOS не придётся. Если дешифратора на F800 и двух диодов нет, то достаточно лишь перетранслировать заменив вызовы F800 на C800. Это работа на 14 секунд, доступная любому, кто имеет текстовый редактор и Windows XP (т.к на более новых Windows программы MSDOS не запускаются, отчего придётся трахаться с перетрансляцией исходника для Microsoft M80 в каком-нибудь эмуляторе CP/M, что займёт намного больше времени).
Я использовал на СПЕЦИАЛИСТЕ адрес FC00 (этот же адрес используется и для КНГМД на базе ВГ93). Этот адрес потому, что так исторически сложилось. FF00 - это ППА клавиатуры. FE00 - это ППА принтера и прошивателя УФ-ПЗУ. FD00 - это внешний электронный диск на РУ7 (со своими цепями регенерации), и естественно FC00 остаётся для контроллера дисковода.
RK-DOS имеет смысл потому, что формат дискет РК-КНГМД менее требователен к качеству дискет и более надёжен. Кроме того RK-DOS работает в 10 раз быстрее (из-за наличия в CP/M буферизации) и RK-DOS может работать с минимальным базовым ОЗУ в СПЕЦИАЛИСТЕ, тогда как для CP/M необходимо ОЗУ СПЕЦИАЛИСТА расширять (в области D000...F7FF). Дискеты, что для КНГМД на ВГ93 дохлые, с РК-КНГМД работают ещё 10 лет, пока совсем не осыпятся. Кроме того, ВГ93 при такте всего в 2 МГЦ даёт только формат SD (single density), т.е те же 400 кб, тогда какой в нём прок ? На СПЕЦИАЛИСТЕ ещё нет программ для РК-КНГМД, так что можно сразу использовать формат не 400 кб, а 560 кб на диск DD или 640 кб на диск HD (аппаратно допустимо и более, но RK-DOS не может иметь более 8 секторов на трек).
Если хотите могу перетранслировать RK-DOS для СПЕЦИАЛИСТА. Но проверить это не могу, т.к эмулятор 'emu80' для СПЕЦИАЛИСТА не поддерживает РК-КНГМД. Если Вы напишете автору этого эмулятора в личку и попросите поддержать РК-КНГМД и для СПЕЦИАЛИСТА, то проблем не будет. Вероятно это не потребует даже переделок в самом эмуляторе 'emu80', а достаточно лишь составить конфиг-файл, т.к РК-КНГМД там уже поддерживается для РК86.
PS. Кстати однопанельный нортон Е.Седова SE.COM не будет работать на СПЕЦИАЛИСТЕ и переделать его без кардинальной переработки (смены алгоритма) невозможно (т.к он "лазиит" в экранное ОЗУ РК). Тут я могу немного помочь, т.к имею исходник нортона с панелями псевдографикой, окнами и инверсией знакомест, основанный на альтернативном фонте.
Для СПЕЦИАЛИСТА теоретически можно странслировать версию нортона от ОРИОНА, для начала без цвета (т.к цвет в ОРИОНЕ хранится в другой банке ОЗУ, а в СПЕЦИАЛИСТЕ этого нет). Это не совсем просто, т.к в СПЕЦИАЛИСТЕ меньше ОЗУ, чем в ОРИОНЕ и надо как-то разместить оконный драйвер D8, который имеет размер более 10 кб. Т.е для графического нортона всё-равно придётся "открывать ОЗУ" D000...F7FF. А чтобы это отладить обязательно понадобится эмулятор (хотя если я решу проблему массовой памяти для своего СПЕЦИАЛИСТА, то смогу обойтись и без эмулятора, но это не прямо сейчас). А если найдётся эмулятор СПЕЦИАЛИСТА одновременно поддерживающий его стандартный цвет (естественно 8 цветов, не 4) и РК-КНГМД, то легко странслировать и цветную версию.
PPS. Диск-доктор тоже лезет в экран и не будет работать, но есть и независящий от платформы CHKDSK для RK-DOS.
- - - Добавлено - - -
в чем разница между RK-DOS версий 2.9 и 2.95?
То, что распространялось из ТОО "Лианозово" это версия 2.95 и думаю, что именно она у всех. Но где-то читал, что археологи откопали и немного другую версию (речь не о RK-DOS 1.0, что совсем в другой концепции и несовместима).
Кроме того, ВГ93 при такте всего в 2 МГЦ даёт только формат SD (single Density), т.е те же 400 кб, тогда какой в нём прок ?
Подключать просто нормально надо. На Партнере при 2 МГц вполне себе 800Кб.
Подключать просто нормально надо. На ПАРТНЁРЕ с тактом в те же 2 МГц использовали формат 800 кб
Для машины имеющей ПДП, это нормально его использовать. А для машины без ПДП на практике оказалось проще поднять такт КР580 до 2.5 МГЦ и использовать обычный (более простой) КНГМД от КОРВЕТА. Кроме такого (типового) варианта с повышением такта КР580, для СПЕЦИАЛИСТА изобрели ещё два очень хитроумных варианта, что работали даже при мизерном такте КР580 всего в 2 МГЦ.
Однако, если хочется использовать именно ВГ93, то кто заставляет обязательно использовать тактирование его стандартно, т.е для SD или DD. Достаточно понизить частоту тактирования ВГ93, отчего на треке будет умещаться не 5 секторов по 1 кб, а только 4 сектора, при этом скорости СПЕЦИАЛИСТА достаточно. Это даёт формат дискеты в 80 TRACKS * 2 SIDES * 4 SECTORS * 1 кб = 640 кб, почти как в TR-DOS (хотя на IBM PC такой диск не прочитать). Но столько же даёт и более простой РК-КНГМД (560К на DD-дисках и 640К на HD-дисках).
То, что распространялось из ТОО "Лианозово" это версия 2.95 и думаю, что именно она у всех.
Нет. Версия 2.9 тоже из "Лианозово".
Вечером посмотрю, что у меня в ПЗУ прошито. Ну так есть разница между 2.9 и 2.95 или нет?
Приехала очередная партия плат, стучитесь в личку.
Есть интерес к плате. У меня стандартная РК из журнала. К ней получиться подключить контроллер?
Если вывести разъем или подпаяться напрямую к контактам, то да. Вот выдержка из статьи: http://www.emuverse.ru/wiki/%D0%A0%D0%B0%D0%B4%D0%B8%D0%BE-86%D0%A0%D0%9A/%D0%A0%D0%B0%D0%B4%D0%B8%D0%BE_1,2-93/%D0%9A%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D0%BB%D 0%B5%D1%80_%D0%BD%D0%B0%D0%BA%D0%BE%D0%BF%D0%B8%D1 %82%D0%B5%D0%BB%D1%8F_%D0%BD%D0%B0_%D0%93%D0%9C%D0 %94
Конструктивно контроллер НГМД для «Радио-86РК» представляет собой внешний модуль, подключаемый к компьютеру через слот, который необходимо установить на ПЭВМ. При этом требуется некоторая доработка ПЭВМ. В «Микроше» такой слот уже имеется (разъем «Внутренний интерфейс») и эту ПЭВМ дорабатывать не надо.
Доработка «Радио-86РК» сводится к установке дополнительного дешифратора на плате компьютера (см. рис. 11) и разъема (будем называть его как и в «Микроше» — «Внутренний интерфейс»). Это не ухудшит работу ПЭВМ и позволит значительно расширить возможности компьютера. Например, появится возможность в неиспользуемом ранее адресном пространстве разместить дополнительное ОЗУ, ПЗУ с наиболее часто используемыми программами, оформив их в виде отдельных модулей, подключаемых к разъему «Внутренний интерфейс». Разъем должен иметь два ряда с числом контактов в каждом не менее 30. Назначение контактов этого разъема приведено в табл. 2. Нумерация микросхем в ней дана согласно схеме, приведенной в журнале «Радио» № 5 за 1986 год.
Не получается отправить сообщение в ЛС. Что то со смартфоном что ли
Сообщение получил, даже два раза, ответил там же один раз :)
Про подключение к Апогею, нужно посмотреть разбивку адресного пространства. Под КНГМД нужен сегмент E000-F7FF.
Vladimir_S
25.07.2017, 11:58
Про подключение к Апогею, нужно посмотреть разбивку адресного пространства. Под КНГМД нужен сегмент E000-F7FF.
Только если перенести экранную область и вполовину обезжирить монитор.
- - - Добавлено - - -
Меня больше волнует почему дисковод не фурычит с Z80?
На ВМ85 все работает, а при выборе Z80 пишет I/O ERR.
HardWareMan
25.07.2017, 14:48
Может потому, что флаги не так работают? Без анализа кода никак.
Vladimir_S
25.07.2017, 15:04
Может потому, что флаги не так работают?
И я к этому склоняюсь.
Про подключение к Апогею, нужно посмотреть разбивку адресного пространства. Под КНГМД нужен сегмент E000-F7FF
Только если перенести экранную область и вполовину обезжирить монитор
Зачем обязательно использовать тот же самый код, что и в RK-DOS для РК86 или МИКРОШИ? Исходник есть, перетранслируйте для адресов удобных для АПОГЕЯ.
Надо найти 5 адресов В/У в области памяти для РК-КНГМД. Лучше конечно бы отдать под РК-КНГМД 400H байтов, тогда не придётся переделывать ДОС (заменять команды OUT на LD). Как видите, если у Вас нет 400H ячеек для РК-КНГМД, то из-за идиотического использования команд IN/OUT даже с КР580 придётся трахаться. Поэтому всегда лучше делать ПО без извратов.
Конкретный адрес РК-КНГМД не важен, т.к в порт РК-КНГМД лезет только сама ДОС, форматёр и два диск-доктора. О диск-докторах, нортонах и других программах, что лезут в экранное ОЗУ забудьте, хотя благодаря общности организации экрана их переделать гораздо проще, чем для графической ЭВМ. Форматёр перетранслировать не проблема. А адрес размещение самой RK-DOS тоже не важен. Лишь бы были доступны 4 ячейки E000...E003. Там размещаются два входа в RK-DOS - это E000 (Cold Start) и E001 (вход в BDOS). Все программы RK-DOS лезут только туда. Поэтому, если Вы поставите на адрес E001 JMP на начало кода RK-DOS в ОЗУ (например, D001), то совместимость с корректными программами RK-DOS и SYS-файлами сохранится.
Однако даже за это нет смысла цепляться. Потому, что в базовой RK-DOS управление ею осуществляется ячейками в области 7500. И таким образом, хотя для Вашей RK-DOS TPA будет до D000, т.е 52 кб, но посередине этого свободного ОЗУ будут "торчать" рабочие ячейки ДОС. Т.к исходники SYS-файлов есть, то лучше и рабочие ячейки ДОС перенести в область E000, а SYS-файлы просто перетранслировать.
Дисковый бейсик, редактор и дисковый ассемблер МИКРОН, если они Вам нужны, придётся дизассемблировать и перетранслировать. Или же самому сделать их "одисковоживание" из МГ-оригиналов. Кроме того, т.к речь об ОЗУ, то нет проблем странслировать и совместимую версию, где ячейки остались в области 7500, чтобы использовать непеределанные дисковый бейсик-Плюс и дисковый ассемблер МИКРОН. Если бейсик с загрузкой с дискеты имеет смысл, чтобы удобно смотреть игры на бейсике, то редактор и ассемблер вообще бесполезны (т.к удобнее ассемблировать на PC).
На ВМ85 все работает, а с Z80 нет
Вряд-ли дело во флагах, т.к в эмуляторе EMU80 работает, а думаю, что мало кто сомневается, что в нём ошибок нет. Попробуйте Ваш вариант RK-DOS в этом эмуляторе, может быть что-то прояснится. По крайней мере там доступен отладчик.
Если в программах всё в порядке, то можно подумать о том, чтобы изменить такт ПДП. Может быть из-за отличающихся времянок КР580 и Z80, считывание байта из РК-КНГМД не успевает в "люк" между двумя захватами шины. Попробуйте читать с отключенным ПДП, - у Вас это не приведёт к гибели данных в динамическом ОЗУ, т.к его у Вас нет.
Vladimir_S
25.07.2017, 16:06
Вряд-ли дело во флагах, т.к в эмуляторе EMU80 работает
Что то не помню в EMU80 Z80 в РКшке.
Что-то не помню в EMU80 Z80 в РК-шке
Поищите более новую версию эмулятора или удалите файл 'emu80.run'. Тогда при старте будет появляться выбор типа ЭВМ.
Для Апогея кроме РОМ- диска ничего путного по ходу изобретено не было. Хотя разьем есть.
А работать с магнитофоном это вообще жесть.
Vladimir_S
26.07.2017, 04:00
Попробовал запустить ДОС в турборежиме 3.5 Мгц - стал выводить каталог и потом виснуть. Перевел комп с 1.78Мгц на 2.0 Мгц и все зафурычило! Теперь новая проблема - на 2Мгц ДОС с VM85 хоть и работает, но дисковод так рычит, что аж страшно становится. Придется схему мучить что бы VM85 работал с 1.78Мгц, а Z80 с 2.0Мгц.
- - - Добавлено - - -
Все, победил, причем после небольшого изменения схемы с Z80 работает как переделанный под Z80 ДОС, так и родной 2.95 с IN/OUT.
Sancho45
26.07.2017, 13:16
Меня больше волнует почему дисковод не фурычит с Z80?
На ВМ85 все работает, а при выборе Z80 пишет I/O ERR.
А сигнал RDY как сделан ?
И контроллер как тактируется ?
Vladimir_S
26.07.2017, 13:26
Sancho45, Я уже писал.http://zx-pk.ru/threads/11319-radio-86rk-podklyuchenie-diskovoda.html?p=919299&viewfull=1#post919299
Sancho45
26.07.2017, 14:04
Я думаю , что проблема в сигнале RDY, по спецификациям даже 3.5" дисководу надо до 500мс для готовности, не заю что там происходит все это время , но как минимум один оборот диска 200мс (300 об/мин). А подпрограмма которая проверяет сигнал RDY работает быстрее чем 0.5 сек (500мс). Пока дисковод не готов , он не выдает сигналов. Но п/п читает сигнал RDY(а он всегда готов,когда на земле),и дос начинает работу с дисководом,а дисковод сигалов не дает, отсюда и глюки!!!
Я изменил п/п проверки сигнала RDY в досе (используя тексты barsik), поставил туда цикл ДО проверки готовности. Вся прошивка та же, только несколько байтов поменял местами (до этого был цикл опроса состояния RDY,поменял на просто цикл, а потом опрос, т.к. RDY всегда готов))
После этого все дисководы заработали (3шт) безотказно. Дисководы без пределки, стандартные ВСЕ.
Я думаю, что те дисководы которые успевали приготовиться до опроса досом сигнала RDY, работали, но при изм-и частоты проца программа работает быстрее и дисковод не успевает приготовится после подачи сигалов выборки.
Что бы проверить это, надо поставить тумблер на сигнал RDY и после команды DIR, включить контакт на землю с реакцией чуть меньше сек., но больше 0.5 сек (реакция человека дольше времени работы подпрограммы опроса сигнала) ))) Если заработает , то дело в этом и я могу выложить подробости.
Вырезку из текста спецификации 3.5 teac_fd235hf прилагаю)
61809
61810
HardWareMan
26.07.2017, 15:25
Sancho45, а почему дисковод выдает готовность до того как он становится фактически готовым? Или речь за игнорирование этого сигнала, тогда к чему претензии то? Вот у меня в 90х вообще были МСшки с загрузкой головок. Загрузкой, Карл, им секунда требовалась на разгон и щелкнуть соленоидом. Но программа с контроллером правильно учитывали READY и все работало как часы, некоторые диски я потом считывал на нем же 10 лет спустя.
Sancho45
26.07.2017, 15:46
Sancho45, а почему дисковод выдает готовность до того как он становится фактически готовым? Или речь за игнорирование этого сигнала, тогда к чему претензии то? Вот у меня в 90х вообще были МСшки с загрузкой головок. Загрузкой, Карл, им секунда требовалась на разгон и щелкнуть соленоидом. Но программа с контроллером правильно учитывали READY и все работало как часы, некоторые диски я потом считывал на нем же 10 лет спустя.
В данной дискуссии идет речь о дисководах , которые не имееют прямого сигнала RDY, вместо этого у них сигнал DISK/CHANGE и о том , что люди на контроллере дисковода соединяют вход сигнала RDY на землю, что бы контроллер считал дисковод готовым всегда. По факту, после проверки сигнала RDY софтом, начинается опрос других сигналов. Но программы могут работать быстрее , чем 500мс
(ДО 500мс для готовности дисковода, разные дисководы, разных производителей могут и быстрее, но по спецификации написанно , что требуется ДО 500мс)
И тк дисковод может быть не готов, тк не прошло еще время 200-500 мс, а софт уже начиает опрос др. сигналов, то тут DISK ERROR
И с чего вы взяли, что дисковод выдает готовность до того как он фактически готов ???
Я приложил вырезки текстов в пред. посте.
Только если перенести экранную область и вполовину обезжирить монитор.
- - - Добавлено - - -
На ВМ85 все работает, а при выборе Z80 пишет I/O ERR.
Красивая плата, и оба процессора вместе! А тыльная сторона МГТФ как я понял?
Sancho45
26.07.2017, 16:36
Все, победил, причем после небольшого изменения схемы с Z80 работает как переделанный под Z80 ДОС, так и родной 2.95 с IN/OUT.
А как победил то ?
Vladimir_S
26.07.2017, 16:56
А как победил то ?
На моей плате есть турбо режим. ДОС ни как не хотел работать с Z80. Случайно запустил ДОС на тактовой частоте процессора в два раза большей и увидел каталог диска. Правда потом комп повис, но на 2МГц Z80 надежно работает в ДОС.
А тыльная сторона МГТФ как я понял?
Ну да.
Владимир, я пошел по твоим стопам. Это на счет корпуса от Апогея.
Взял новенький в упаковке, такой же как у тебя, только синий. когда плату tnt23 пришлет, попробую воткнуть. только что FDD не хочу в корпус заводить, вдруг пригодиться для других моих компиков.
Vladimir_S
26.07.2017, 17:14
акой же как у тебя, только синий.
Так верхняя крышка с клавой и так синяя.
Для АПОГЕЯ кроме ROM-диска ничего путного изобретено не было. Хотя разъём есть
Это отлично, т.к чем меньше всего есть для компьютера, тем он интереснее. А каких машин сейчас больше у пользователей, - МИКРОШ или АПОГЕЕВ?
Я изменил п/п проверки сигнала RDY, поставил туда цикл ДО проверки готовности. Вся прошивка та же, только несколько байтов поменял местами (до этого был цикл опроса RDY, поменял на просто цикл паузы, а. физический RDY всегда готов))
Вообще-то до этого был цикл ожидания RDY с ограничением времени в 2 секунды, чтобы спустя 2 секунды неготовности выдать надпись BAD SECTOR (или что-то подобное).
Вы ввели просто паузу, удлинив п/п-мму READY до секунды. Это немного похоже на аппаратную задержку формирования сигнала READY из сигнала 'Device Select' на КМОП-вентилях, но есть существенное отличие, - если это сделано неграмотно, то это приведёт к торможению работы ДОС.
Вопрос в том, на каком исходнике Вы это делали и как. Нельзя ли "зыркнуть" на листинг?
Нежелательно это делать на оригинале Е.Седова. Потому что там нет флага о том, что колесо вращается, отчего любой вызов п/п-ммы READY будет длиться одинаково долго (секунду, что Вы отвели на раскрутку). А в варианте с эмуляцией, есть флаг PSKFLG, благодаря чему, вызов п/п READY только при невращающемся колесе длится долго, а последующие вызовы, когда колесо уже крутится, намного короче.
Если, как Вы пишете Вы ввели паузу до обслуживания READY, т.е до анализа флага PSKFLG, то это неправильно, т.к тормознёт. Но надо видеть листинг.
А чем Вас не устроил вариант с эмуляцией READY из сигнала INDEX? Работает ли это на реале, т.к проверялось только в эмуляторе? В эмуляторе есть разница в скорости реакции ДОС с аппаратным READY и ДОС с эмуляцией READY из сигнала INDEX. Разница в том, что в варианте с аппаратным READY реакция на команды быстрее. Вообще-то заметного торможения не должно быть, т.к при вызове READY при уже вращающемся колесе контроллируется только один оборот колеса, что тормозит на 0.2 секунды при каждом вызове. В принципе, можно убрать контроль на вращение колеса при повторных вызовах READY, т.е сразу же, если флаг PSKFLG выставлен, делать RET. Мне интересно, есть ли в реале такое торможение, потому что у меня в 90-тые такого не было. Т.е хочу знать это свойство эмулятора или реала.
Но немного не так делается в BIOS CP/M. CP/M в отличие от RK-DOS ничего не знает о колесе и в ней нет подпрограммы OSTANOV. Это только RK-DOS после выполнения задачи, вызывает функцию OSTANOV и колесо останавливается. С БИС ВГ93 о пуске и останове колеса тоже заботиться не надо. Обычно (если сделано грамотно) для формирования сигнала старт, используют сигнал HLD (Head Load), который предназначен для пуска колеса и пуска магнита прижимающего головку к поверхности, или, (если КНГМД неграмотный), то используют одновибратор с константой на 4-5 секунд. Одновибратор, не нужен, т.к эту задержку даёт сам ВГ93, снимая спустя 4-5 секунд сигнал HLD. Потому при БИС ВГ93 в ДОС не требуется заботиться о колесе.
В CP/M на базе РК-КНГМД иначе. Здесь заботиться о колесе приходится программно. Задача в том, чтобы обеспечить останов колеса, если в течение 5 секунд не происходит обращения к дисководу. Понятно, что с таймером или прерываниями это легко решаемо. Но раз нет прерываний (т.к они истрачены на звук), то делается так. Вызов п/п-ммы READY запускает колесо, выставляет флаг PSKFLG и заносит в счётчик большое число. Естественно, READY в первый раз (т.е при входе в п/п-мму READY с сброшенным флагом PSKFLG и когда колесо не крутится), формируется спустя паузу (пауза, задержкой, если Вы так уж хотите) или спустя паузу на обнаружение того, что колесо вращается по импульсам на выходе INDEX. Но когда к READY обращаются после старта колеса, то паузы не происходит, т.к установлен флаг PSKFLG и возврат из READY происходит мгновенно.
Как останавливать колесо в ДОС, которые ничего не знают о РК-КНГМД, например CP/M? Для этого перед вызовом п/п-ммы F81B, которая является единственным интерфейсом с клавиатурой (STATUS тоже получают из неё, F812 не используется, т.к например, в РК86 она буферизована, что нам не надо) вставляется одна строчка CALL TICK (или CALL SYSTIK. В этой подпрограмме декрементируется тот большой счётчик, что был установлен по старту колеса. Когда ДОС закончила все дисковые процедуры, она возвращается к опросу клавиш, т.е начинается вызов в цикле п/п-ммы F81B, Обычно в цикле за секунду успевает произойти 1000....5000 вызовов F81B (в зависимсоти от такта и грамотности п/п-ммы опроса). При каждом вызове F81B счётчик уменьшается и через 5 секунд опроса F81B в цикле достигается ноль. Тогда вместо RET NZ, выполняется JMP OSTANOV и колесо останавливается.
К такой идее задержки приходится прибегать только, если в дисководе нет сигнала INDEX (например 5050, 5088), тогда нет ни самого сигнала READY, ни возможности его эмулировать из сигнала INDEX. Кстати, у меня как раз есть 5 таких дисководов и все без сигнала READY и INDEX, причём и сигнала TRK0 тоже нет (это фактически голая рама с мотором и улиткой). Такой дисковод стоил 200 USD в 1976 (для пересчёта на современные деньги надо умножить сумму на 5).
Sancho45
26.07.2017, 19:34
Вообще-то до этого был цикл ожидания RDY с ограничением времени в 2 секунды, чтобы спустя 2 секунды неготовности выдать надпись BAD SECTOR (или что-то подобное).
Вообще-то я так и написал :-
до этого был цикл опроса RDY,, что и есть ожидание RDY, и не 2 сек, а от FFFFh до 0000h в цикле(в сторону уменьшения), длительость цикла и такты не считал, но явно по ощущениям меньше 2-х сек.
вот фрагмет из ваших текстов:
READY:
LD HL,0
RDYLOO:
IN A,(0F1H) ; *****
LD A,(PORT+1)
AND RDYMSK
RET Z
DEC HL
LD A,H
OR L
JR NZ,RDYLOO
LD A,3
JP PR_ERN
;──────────────── ──────────────── ───────────
Т.к. RDY припаян к земле, то из цикла выскакивает при первом проходе, а дисковод еще не готов !
Что я сделал :
READY:
LD HL,1FFFh
RDYLOO:
DEC HL
LD A,H
OR L
JR NZ,RDYLOO
IN A,(0F1H) ; *****
LD A,(PORT+1)
AND RDYMSK
RET Z
LD A,3
JP PR_ERN
;──────────────── ──────────────── ───────────
Все тоже самое, только местами поменял и вместо 0000h-1 поставил 1FFFh
Вы ввели просто паузу, удлинив п/п-мму READY до секунды.
Я просто дал время дисководу равное циклу 1FFFh для того что бы он был готов, и потом запрашиваю RDY и т.к. он на земле т.е. всегда готов и дисковод уже готов, то все работает и так же есть возможность аппаратной доработки сигнала(если не на земле а через хитрую схемку)
На счет раскрутки все равно надо 500мс, какая разница дос будет ждать раскрутки 500мс или просто ждать 500мс и потом читать RDY ?
Сигнал опрашивается один раз за сеанс , потом другие запросы , INDEX и тд. У меня все работает без тормозов, я не собираюсь тиражировать диски на микроше, что бы раз в сек опрашивать RDY, да и во всех программах что я просмотрел сигнал опрашивается один раз за сеанс при инициализации дисковода
- - - Добавлено - - -
чтобы спустя 2 секунды неготовности выдать надпись BAD SECTOR (или что-то подобное)
Не правда. Причем тут RDY и BAD SECTOR. Здесь пишут,и у меня раньше было I/O ERR
А чем Вас не устроил вариант с эмуляцией READY из сигнала INDEX?
Работа ,
не успел еще проверить ваш вариант.
Параллельно орион собираю.
И я вообще думал заменить проверку флага RDY на флаг INDEX
Но времени нет особо для отработки мыслей. Как время будет,попробую Ваш вариант и отпишусь.
Sancho45, выложи свой вариант ПЗУ c задержкой перед RDY, проверю свои "нерабочие" флопы.
Ну да, как и описывалось, Вы ввели паузу на 0.5 секунды (кстати в счётчик времени ожидания HL загружается 0, т.к это было для ОРИОНА, который в 3-4 раза быстрее РК, в котором ожидание будет не 2 секунды, а в разы больше). Но эта пауза исполняется при каждом вызове п/п-ммы READY, тогда как она нужна только тогда, когда колесо не крутится. Если же колесо уже крутится, то пауза не нужна. На скорости чтения это не отразится, потому что при чтении сектора п/п-мма READY не вызывается, т.к ради ускорения, полагаются на то, что даже если первые попытки чтения, ещё при нераскрученном до номинальной скорости колесе, дадут ошибку, то это не важно, так как число попыток чтения велико.
Но, если Вы в редакторе текстов выполните поиск метки 'WRSKT:', то увидите, что при каждой записи сектора вызывается подпрограмма READY (т.к запись при нераскрученном колесе приводит к трагедии). Если средний размер игры 20 кб, т.е она имеет размер в 40 секторов по 512 байт, то вызов п/п-ммы READY 40 раз при копировании этого файла затормозит работу на 0.5 сек * 43 сектора (1 сектор в каталоге, 1 сектор во VTOC и 1 сектор Track/Sector LIST плюс число секторов самого файла) на 21.5 секунды. Если копируется диск 400 кб, где 800 секторов, то копирование затормозится на 400 секунд, т.е на 7 минут.
Неправда. При чём тут RDY и BAD SECTOR?
В CP/M и похожих ДОС нет развитой диагностики ошибок. Там всего 4 ошибки, отчего, когда что-то не так с дисководом, выдаётся сообщение "Bad Sector". Я привёл текст сообщения лишь примерно, как пример, что что-то подобное выдаётся. А сейчас посмотрел и обнаружил, что в RK-DOS ошибка с кодом 3 выдаёт текст "NO DISK", хотя лучше было бы выдавать текст, как в MSDOS "Drive Not Ready". Сообщение "I/O ERROR" у Вас было потому, что сигнал READY был заземлён, отчего колесо при чтении не успевало раскрутиться.
А ещё один способ добиться чтения на НГМД без аппаратного сигнала READY заключается в том, чтобы в 3-4 раза увеличить число попыток чтения. Тогда надпись "I/O ERROR" будет выскакивать спустя минуту "долбёжки" дискеты. Это нехорошо тем, что тогда и при реальной дохлоте сектора, этот сектор будет пытаться считываться кучу раз, изнашивая головку дисковода.
Когда разбирался с программированием дисковода, то пришёл к следующей схеме старта. Ориентироваться на READY бесполезно, т.к. зачастую он фэйковый ("34" на GND). Два раза даётся команда инициализации (именно два раза подряд, т.к. один раз почему-то не прокатывал, обнаружено эмпирически). Далее даётся команда перехода к целевому треку и ожидается её отработка по соотв. флагу ВГ93. Отработка означает, что по факту считан целевой номер трека, т.е. шпиндель 100% раскручен до нужной скорости (с трека читаются корректные данные). Боевой код получился ещё хитрее, т.к. пришлось вводить тайм-ауты на случай если READY тупо на земле, а в дисковод дискета не вставлена (в этом случае поиск целевого трека залипает до бесконечности).
Далее даётся команда перехода к целевому треку и ожидается её отработка по соотв. флагу ВГ93
Ээээ ВГ93?
tnt23, да, КР1818.., она родимая.
Sancho45
27.07.2017, 05:10
Приведение ассемблерного фрагмента без заключения его в теги (code.../code) приводит ассемблерную программу в нечитабельный вид, похожий на исходники для ассемблера МИКРОН, когда размер объектного кода приблизился к 2.5 кб и из текста вынуждено пришлось удалить всё форматирование. Если Вы отредактируете своё сообщение, добавив тег 'code', то читатели форума, читающие эту тему в дальнейшем, будут Вам благодарны.
Сделал.
(кстати в счётчик времени ожидания HL загружается 0, т.к это было для ОРИОНА, который в 3-4 раза быстрее РК,
Нет, ноль в оригиале Седова, счетчик идет на уменьшение , т.е. от 0000h -1 при первом проходе и до 0000h
Но, если Вы в редакторе текстов выполните поиск метки 'WRSKT:', то увидите,
Да, это так при записи, при чтении такого нет !
Вы ввели паузу на 0.5 секунды
Гораздо меньше от 1FFFh до 0, в сторону уменьшения, другими словами от 0 до 1FFFh , что меньше 0.5 сек. Я так же взял в расчет, что проц выполняет и др п/п доса до проверки RDY, что тоже занимает время и в сумме с циклом дает необходимое время.
Если средний размер игры 20 кб, т.е она имеет размер в 40 секторов по 512 байт, то вызов п/п-ммы READY 40 раз при копировании этого файла затормозит работу на 0.5 сек * 43 сектора (1 сектор в каталоге, 1 сектор во VTOC и 1 сектор Track/Sector LIST плюс число секторов самого файла). на 21.5 секунды. Если копируется диск 400 кб, где 800 секторов, то копирование затормозится на 400 секунд, т.е на 7 минут.
Все это в теории, но (см. выше, цикл для RDY меньше 0.5), игрушек по 20кб не так много и записывать их один раз , а не тиражировать).Да и так все работает без тормозов и очень быстро, 7 мин я ни разу не ждал (это перебор ))). Хотя и софта который мне интересен и на дискетку то не набралось))
- - - Добавлено - - -
Sancho45, выложи свой вариант ПЗУ c задержкой перед RDY, проверю свои "нерабочие" флопы.
Пожалуйста
61816
константа для задержки со смещением 0D45 h от начала прошивки, там 00 1F, т.е. в нормальном порядке 1f00, что даже меньше чем я указал выше. можно сделать больше или меньше. Для микроши D3 C1 исправленно на D3 D1. Если кто на 86рк, то надо обратно D3 C1 со смщением 0DBE h от начала прошивки. И сигнал RDY со стороны контроллера на землю)
О результатах отпишитесь пожалуйста .
Vladimir_S
28.07.2017, 10:00
Все что хотел от платы РКшки, получил. ДОС29, FDOS, SRAM 1Мб, сменяемые процессоры, звук от ВИ53, цвет по схеме Апогея, турбо режим 1Х2Х4. Конструкция конечно не для всех, а для тех кто хочет экспериментировать. Последнее что сделал - смену процессора по директиве V. Если выбран VM85, то светодиод питания горит зеленым светом. Нажимаем V, BK светодиод начинает с частотой 2 герца моргать красным. Если не нажимать сброс, то через 20 секунд опять горит зеленым. Если нажать сброс, то светодиод загорается красным и включается в работу Z80. Ну и соответственно после выполнения директивы V происходит обратный процесс. Все это запоминается в памяти контроллера(PIC12F629 и ему подобных) и после включения питания начинает работать тот процессор, который работал до отключения питания компа.
Поздравляю! Прекрасный получился комп. У меня конечно запрос по скромнее. Хотел спросить цвет как в Апогее к простому РК можно прикрутить?
Vladimir_S
28.07.2017, 14:25
цвет как в Апогее к простому РК можно прикрутить?
Патон как то сказал - "При известной технологии можно сварить даже два березовых полена".
Вот прикрутить бы дискогрыз к Апогею....
прикрутить бы дискогрыз к АПОГЕЮ....
Так и прикрутите. Не вижу проблем. Исходник RK-DOS есть, возьмите хоть оригинал Е.Седова, хоть вариант для НГМД без READY (использующий для определения вращения колеса сигнал INDEX). Плат КНГМД как раз tnt23 изготовил новую партию, покупайте, паяйте, настраивайте, транслируйте RK-DOS и пользуйтесь. Однако Вам придётся самостоятельно решить проблему ПЗУ и выбрать какой вариант (т.е куда в ОЗУ) будете транслировать.
Т.к программы от РК86 и от МИКРОШИ нагло лезущие в экран работать не будут (хотя и на это есть варианты решения), то нет смысла заморачиваться с размещением служ.ячеек RK-DOS на 7500, т.е в середине свободного ОЗУ АПОГЕЯ. Перенесите RK-DOS на C800...DFFF, а управляющие ячейки на E000...E0FF или ещё куда-нибудь. Сразу заложите резерв объёма ДОС в 6 кб, чтобы не мучиться из-за ограничения в размер 4 кб. Т.к у Вас ОЗУ, а не ПЗУ, - это не проблема.
А вообще то входную точку в RK-DOS АПРГЕЯ я бы рекомендовал сделать в вершине ОЗУ (на DFFC), тогда не придётся вынужденно фиксировать размер RK-DOS и можно будет псотепенно делать версия всё большего и большего размера, не меняя адрес входа в BDOS, т.е избавившись от необходимости переделывать все программы при смене размера ДОС.
На АПОГЕЕ RK-DOS будет чувствовать себя ещё лучше, чем на ОРИОНЕ, т.к у ОРИОНА свободно ОЗУ только ниже C000, а у АПОГЕЯ аж до E0FF. У Вас всё-равно не получится уместиться в 4 кб, т.к вряд-ли Вы будете тратить 800H адресов на РК-КНГМД как в РК86, а значит Вам придётся позаменять все команды IN/OUT на LD, отчего объём кода разбухнет на 64 байта и уже не влезет в 4 кб. В моих листингах это как раз легко сделать, т.к эти места помечены звёздочками, достаточно закомментировать строки IN/OUT, а откомментировать строки LD (а может есть версия и с условным флагом компиляции, тогда достаточно изменить 1 цифру).
Кстати, раз из-за экранной несовместимости наплевать на диск-доктор, Track-Sector Edit и SE.COM Е.Седова , то лучше сразу использовать RK-DOS в формате 560 кб на DD-диск (или 640 кб на HD-диск), кварц (или входной такт) соответственно не 8 МГЦ, а 10.5 МГЦ и 12 (или 15 МГЦ, если HD-5.25, т.к у него колесо в режиме HD крутится быстрее). Естественно, т.к речь об ОЗУ, никто не мешает странслировать RK-DOS родным способом (BDOS на E001, ячейки на 7500) и использовать дисковый бейсик, дисковый ассемблер МИКРОН и дисковый редактор текстов (он вроде-бы не "лазиит" в экранное ОЗУ) от родной RK-DOS.
Т.к в АПОГЕЕ места в адресном пространстве для доп.ПЗУ нет, а грузить ДОС с магнитофона не смешно, придётся делать внешний ROM-диск, возможно с какой-нибудь системой там. Только не говорите об ORDOS (для запуска файлов достаточно ROM-SERVICE от РК86 с объёмом кода в 300 байт), в крайнем случае измените в ПЗУ команду 'U' на 'B' (Boot), по которой из ROM-диска будет грузиться и стартовать кусок кода из жестко фиксированных адресов ROM-диска.
Из любопытства зыркнул в местную "Вику", чтобы узнать что-нибудь об АПОГЕЕ и обнаружил, что там свободна для расширений память EB00...EBFF. Так что можно поставить дешифратор ИД7 и получить шаг в 20H. Тогда EB00 - это ППА РК-КНГМД, а EB04 регистр управления. И ещё 7 чип селектов для расширений.
Вопрос. А в АПОГЕЕ ОЗУ буферизовано? Потянет ли шина?
Однако для АПОГЕЯ лучше даже не связываться с RK-DOS, а сразу поставить CP/M. Это даже проще, т.к вообще ничего менять не надо. Подставляете свои адреса и транслируете. Если в ОРИОНЕ в банке 0 CP/M работает в ОЗУ 48К, то у АПОГЕЯ ОЗУ аж 56 кб, чего хватит даже для трансляторов ОЗУ. В ПЗУ лучше сразу прошить саму CP/M, а не её загрузчик, т.к грузится быстрее и не надо иметь системных дискет, долго ждать реинициализации BDOS по ^C и иметь бОльший полезный объём на дискетах. Я для себя всегда прошивал все ДОС для ОРИОНА в ROM-диск в виде ORDOS-файлов.
Хотя формат ORDOS для ROM-диска не оптимален, но интерфейс с ORDOS из CP/M хорошо отработан, так что файлы RK-DOS или CP/M можно хранить и в формате ORDOS в ROM-диске. В западных ЭВМ файлы в ROM-диск прошивают вовсе не впритык друг к другу, а в произвольном порядке, с любыми пустыми зазорами между файлами, начало следующего файла ищется по сигнатуре, (обычно цепочка FD FD FD), что намного удобнее для модификаций за счёт простой перестановки микросхем ПЗУ, и позволяет комплектовать программами ROM-диск для конкретной задачи (да и ROM-диск тогда не ограничен в 64К).
А лучше не мыкаться с дисководом (т.к негде брать дискеты и, кстати, долговечнее дискеты DD, а не HD), а сразу использовать старый винчестер IDE (расход деталей ППА ВВ55 и 3 микросхемы 555 серии). Причём, в тот же самый разъём, кажется, можно втыкать и CF-карту. Правда для этого у меня нет готового подходящего исходника, надо не очень сложно редактировать, чтобы заменить Z80-команды на команды КР580.
С CP/M всё давно отработано. Сделайте это и это будет полезно, т.к тогда все ретрограды владельцы РК86, принципиально нежелающие расширять ОЗУ (хотя-бы до 48 кб), увидят как Вы программируете на BDS/AZTEC-СИ и на Паскале MT+, а может быть даже и на PL/M (если когда-нибудь обнаружится его версия для CP/M). И поймут, наконец, что дополнительное ОЗУ полезно даже в РК86.
Хотя мне кажется, что утверждения, что PL1 для CP/M намного хуже, чем PL/M, т.к, якобы, он слишком крутой и наворочанный, - непроверенные домыслы тех, кто это сам не попробовал. Если наворочанные функции не использованы в исходнике, то их не будет и в объектном коде. Т.е, если использовать PL1 в объёме возможностей PL/M (т.к PL/M это подмножество PL1), то результат будет тот же самый, как и при использовании PL/M. Почему надо принимать на веру, что разработчики компилятора PL1 в 80-тые годы были намного глупее, чем Гарри Килделл в 1973-м, и не понимали, что ресурсы 8-ми разрядки невелики. Может поэтому никто и не cтранслировал PL/M для CP/M, т.к это незачем, если уже есть гораздо более мощный компилятор PL1.
CP/M для АПОГЕЯ имеет смысл оттого, что когда она "сжирает" 10 кб свободного ОЗУ, то остатка ОЗУ всё-равно хватает для загрузки всех имеющихся программ, а в CP/M на базовом РК86 можно стартовать только очень маленькие программки (к тому же ещё и ЯВУ не работают), что делает CP/M бесполезной.
цвет как в АПОГЕЕ к простому РК можно прикрутить?
Какие проблемы, это кажется всего несколько ИМС155-той серии. Их несложно припаять вторым этажом (или на отдельной платке, как рекомендуют в журнале "Радиолюбитель"). Но почему речь о цвете АПОГЕЯ. У РК86 есть свой цвет, т.к к РК86 ещё раньше, чем в АПОГЕЕ сделали цвет.
И даже, якобы, как указано в статье в ж."Радиолюбитель" 04.1992, какой-то КООП оцветил 30 игр для РК86 и сказочно обогатился продавая цветные программы пользователям РК. Не знаю, совместим ли тот опубликованный (а стало быть стандартный) цвет РК86 с цветом АПОГЕЯ? Т.е конечно он совместим по работе, т.к используются сигналы атрибутов, которые во всех ВГ75 работают одинаково. Но соместимо ли цвето кодирование, т.е R G B и ReVerseVideo (RVV) получают с тех же выходов?
Если ответ - несовместимо, то, если сделать в РК86 цвет по АПОГЕЮ, то те, уже якобы адаптированные, игры РК86 будут показывать искажённые цвета. Также могут быть отличия в работе сигнала RVV. Лично я RVV задерживал на знакоместо (от этого упрощалось программирование).
Интересный вопрос. Имеющиеся эмуляторы РК86 поддерживают цвет РК86 из журнала РАДИОЛЮБИТЕЛЬ? Это стандарт и его надо уважать. Если поддерживают, то тогда опытным путём можно определить какие игры РК уже цветные и соответственно принять обдуманное решение какой вариант цвета делать в своём базовом РК86.
Vladimir_S
29.07.2017, 16:56
У РК86 есть свой цвет, т.к к РК86 ещё раньше, чем в АПОГЕЕ сделали цвет.
Есть конечно, но по сравнению с цветом Апогея очень убогий.http://zx-pk.ru/threads/26099-radio-86rk-plyus-sozdanie-i-obsuzhdenie-versii-2016g.html?p=853583&viewfull=1#post853583
диск-доктор, Track-Sector Edit и SE.COM
А где можно взять Track-Sector Edit?
А где можно взять Track-Sector Edit?
Я получил его в дистрибутиве из ТОО "Лианозово". Но сейчас выложить его не могу, т.к в 2000 (когда у меня сдох винт), восстанавливая файлы на винте, "поднял" на PC не все программы (диски РК86 читались на ОРИОНЕ с РК-КНГМД, где одновременно, естественно был и КНГМД на ВГ93, поэтому файл командой LOADA грузился в ОЗУ, затем, после сброса, файл записывался в ORDOS-квазидиск. Затем из ROM-диска запускался MS-Commander С.Коровкина, которым ORDOS-файл с квазидиска переписывался на дискету в формате MSDOS 720К. Затем дискета вытаскивалась и ставилась на PC, где уже копировалась на винчестер PC. Это было долго и утомительно.
А т.к некоторые программы не имели для меня ценности (в частности как раз такие программы, что нагло напрямую лезут в экранное ОЗУ РК86, отчего не работают на ЭВМ с другим экраном), то, естественно, они, как ненужные и не копировались. А тем более редактор для формата в 5 секторов не трек был не нужен, т.к я использовал формат в 7 секторов на трек. Так, что даже, если бы программа работала с экраном корректно, то она всё-равно мне не годилась, ведь я использовал РК86 только как источник п/п-рамм чтения/записи сектора для CP/M на базе РК-КНГМД.
Скорее всего, этот файл (и м.быть и некоторые другие файлы, что отсутствуют сейчас на моём винчестере), у меня есть. На дисках 3.5" или 5.25"-DD в формате 560 кб. Кстати, от формата 400 кб, я отказался почти сразу же в середине 90-тых, как обнаружил, что нет проблем увеличить полезный объём диска (в коде RK-DOS меняется только п/п-мма поиска свободного сектора во VTOC, на каждый дополнительный сектор трека добавляется 2 команды [CP и JR Z], так что если 7 секторов на трек (560 кб), то код длинннее всего на 8 байтов. Но увы, нет самонастройки на формат, поэтому для каждого формата - своя версия RK-DOS.
TS-EDIT.COM (кажется так называлась) это весьма простая маленькая программа, визуально похожая на редактор дампа РК86. В начале знакомства с RK-DOS было интересно с его помощью "пошариться" по диску и посмотреть как устроен каталог, сектор VTOC (размером в 160 байт, не в 512) и список секторов занятых файлом (T/S List). Но практической пользы нет. Нажимаешь клавишу, выводится очередной блок дампа. Если происходит переход к следующему сектору или треку, то меняется надписть TRACK NN, SECTOR N. Если надо редактировать, то как и в редакторе дампа подводишь к нужному месту в дампе и вводишь HEX-цифры. При переходе к следующему сектору, если были изменения, сектор автоматически записывается на диск в то же место откуда был прочитан. Естественно можно выбрать любой трек и сектор и посмотреть (и при необходимости изменить) данные сектора.
Так, что увы, помочь достать это ПО пока не могу, поищите где-нибудь, у кого-то наверняка сохранилось. Если не найдёте, то позднее найду эту программу, когда буду иметь РК-КНГМД с дисководом. Но если срочно надо могу написать аналогичную. Думаю, что такую программу легко "нацарапать" за полтора часа, причём используя альтернативный фонт с рамками и инверсией, чтобы выглядело красивее, чем было у Е.Седова. На такой программе можно потренироваться в использовании функций RK-DOS или вспомнить что там к чему.
Эту схему в журнале РАДИО автор обозвал самоцвет
Об этом вообще слышу первый раз. Не знал, что и в журнале РАДИО была схема цвета (не читал, т.к не выписывал с 1992). Я полагал, что есть только один цвет для РК, описанный в журнале "Радиолюбитель" в 1992 (статья называется "Цветные РК86" и занимает 2 номера, в первом схема, а во втором, если МНИП, советы по программированию).
Vladimir_S
29.07.2017, 20:22
barsik, Это я ошибся, конечно в Радиолюбителе. К сожалению по этой схеме действие атрибута распространяется не только после, но и на одно знакоместо до.
Она?на Апогее что то подобное снизу нужно поднастраивать.
http://img.radiokot.ru/files/30570/thumbnail/1cacrh70gd.jpg (http://img.radiokot.ru/files/30570/medium/1cacrh70gd.jpg)
Vladimir_S
02.08.2017, 12:04
Она?
Точно.
Сегодня прикинул свою РК-шку и плату дисковода, принципе можно воткнуть в корпус от Апогея. Интересно а что там было там у Апогея.? Я просто свой под пломбами не скрывал.
http://img.radiokot.ru/files/30570/thumbnail/1ckmm23rfr.jpg (http://img.radiokot.ru/files/30570/1ckmm23rfr.jpg)
Вот тут есть фотки Апогея изнутри: http://zx-pk.com/forum/viewtopic.php?t=5507
Видимо что-то планировалось, т.к. 6 саморезов было вкручено, на месте планируемой платы
Может, как в "Импульсе", встроенный БП или кодер СЕКАМ.
Тимур а где глянуть список радио элементов и монтажу. Сижу со смартфона , это просто мука что-то искать. Обещают в августе протянуть интернет только.
Список компонентов для сборки
Микросхемы:
1x КР580ВВ55А
1x К555ЛЕ1
1x К555ИЕ7
2x К555ИЕ5
2x КС573РФ2 (РФ5)
1x К555ЛА3
1x К555ЛИ1
2x К555ТМ2
1x К555ИР13
1x К555ИР22
1x К555ЛЛ1
1x К555ЛН1
1x К555ИР23
1x К555ИД4
Резисторы (0,125Вт)
1x 200 Ом
5x 1кОм
Керамический конденсатор:
1x 100пФ
Выложил на страницу проекта
И 555ид7
Это для РКшки, да. Многие себе в РК ставили доп.дешифратор.
155-ая серия повлияет на работу контроллера? Некоторых микрух такая как 555ир13 у нас нет.
Не повлияет, можно ставить и 155, и 1533
Некоторых микрух такая как 555ир13 у нас нет.
Таких и не бывает. ИР13 есть только в 133-ей и 155-ой сериях.
Вроде 1533 есть и имп.
Сходил в магазин, все детальки есть. Кроме больших микр. обошлось 220 руб.
http://img.radiokot.ru/files/30570/thumbnail/1cp1cmhfkh.jpg (http://img.radiokot.ru/files/30570/1cp1cmhfkh.jpg)
ВВ55 в керамике? А зачем там окошко?
Там не окошко, там железочка. У всех золотых железочки. А смартфон у меня плохо фоткает.
Вчера залил 0-ую и 1-ую банки в рф5. Стерх ни вкакую не хочет шить золотые рф2. Да и бог с ними. 0-ую ставлю в кроватку?
Можно вставить и посмотреть дамп с E000 для проверки
Спасибо Тимур. Вроде со всем разобрался, осталось разобраться с доп. дешифратором D30. Там к 6 ноге необходимо подсодинить "1" я так понимаю это лог.1 где её взять?Посмотрел на D11 в самом РК там внутреннее обозначение в микросхеме отличается ноги 5 и 6 , V и &
http://img.radiokot.ru/files/30570/thumbnail/1crv591yam.png (http://img.radiokot.ru/files/30570/medium/1crv591yam.png)
Vladimir_S
19.08.2017, 10:32
это лог.1 где её взять?
Если это 155ИД7, то подать +5 вольт через резистор 3.3К - 10К. А если это серии 555 или 1533, то просто +5 вольт. А зачем использовать только половину ИД7?
Привет Владимир, спасибо. Все берём из статьи журнала, ввиду моей малообразованности делаю как советуют в журнале.
Vladimir_S
19.08.2017, 19:52
Это из Радио 1991.3.42
Владимир я проводочками все присоединю. И разьема как в микроше у меня наверное не будет . на будущее может быть.
Владимир, если я подключу по предложенной тобой схеме, fdd будет работать? Или методом экспиремента попробовать!
- - - Добавлено - - -
Тимур, резисторов 6х1кОм
Vladimir_S
20.08.2017, 09:02
если я подключу по предложенной тобой схеме, fdd будет работать?
Будет конечно.
Из-за предельной лаконичности постов, возникло недопонимание того, по какой схеме ставить ИД7. Выложено 2 разных варианта ИД7. Вариант поста #734 (http://zx-pk.ru/threads/11319-radio-86rk-podklyuchenie-diskovoda.html?p=924726&viewfull=1#post924726) - сомнитенльный.
Для чего при подключении НГМД устанавливать "доп.дешифратор" по схеме из поста #734 (http://zx-pk.ru/threads/11319-radio-86rk-podklyuchenie-diskovoda.html?p=924726&viewfull=1#post924726). В брошюре с инструкцией, что поставлялась ТОО "Лианозово" вместе с платкой РК-КНГМД и дискетами с дистрибутивом, об этом не написано и согласно этой инструкции для установки РК-КНГМД достаточно установить лишь ИД7 по схеме из поста #731 (http://zx-pk.ru/threads/11319-radio-86rk-podklyuchenie-diskovoda.html?p=924632&viewfull=1#post924632)?
проводочками все присоединю. И разъёма как в МИКРОШЕ у меня наверное не будетНо подключение в любом лучше делать через системный разъём, а не припаивая провода к плате ЭВМ намертво. Т.к иначе придётся резать провода, когда понадобится отключить РК-КНГМД. Подпаиваться на РК-КНГМД лучше не к ламелям, а к их кончикам, чтобы ламели по-прежнему могли работать как врубной разъём.
Хотя и не золочёные, ламели на плате прекрасно контачат при втыкании в слот. А значит разъём, как в МИКРОШЕ, - и не нужен. Достаточно иметь лишь слот. Причём лучше отпилить часть ламелей, сократив число контактов с 60 до 50-ти и использовать стандартный 50-ти контактный слот от Apple-II или составленный из двух концевых отпилков XT/AT-шного слота (на 12 и 13 рядов). Т.к шаг у фирменных слотов 2.54, то составление разъёма из 2-х половин выгодно (позволяет избежать несовпадения контактов). Также можно составить слот из отпилков отечественного врубного слотового разъёма СНП15-96 (http://comelsys.ru/files/store_apendix_large277_272.jpg). Надо использовать именно концевые части, чтобы плата вставлялась точно (чтобы ламели платы были точно напротив контактных пружинок слота). Я так ставил РК-КНГМД в РК86, в ОРИОН, в СПЕЦИАЛИСТ и др. Это лучше, чем разъёмы от МИКРОШИ, - вся конструкция на 3 см ниже и смотрится красивее.
Барсик, я пробовал работать с Апогеем. Без FDD это не жизнь. Единственно я пока не опредилился как я буду заканчивать игры и программы на дескету. Все равно придётся использовать магнитофон, смартфон. Ещё не ясно как записывать из редактора на FDD
Vladimir_S
20.08.2017, 16:37
для установки РК-КНГМД достаточно установить лишь ИД7 по схеме из поста #731?
А при чем здесь НГМД? Это же просто расширение А000.
А при чем здесь НГМД?
Вот именно.
Была приведена схема расширения В/У, причём не только совершенно без комментария, но и даже без чьей-либо просьбы и какой-либо связи с ходом обсуждения.
Сюжет моего поста заключался в том, чтобы убедить пишущих в форуме писать нормальные развёрнутые посты, а не из одного предложения. Было бы понятно, если бы было написано, например, так. "Раз уж Вы делаете доработки, то одновременно можно сделать и такую... что полезно тем-то и тем-то". А когда просто, без всяких комментариев приводится схема на ИД7, то логично думать, что это по теме, просто другой вариант ранее приведённой схемы.
Без FDD это не жизнь
Не поспоришь. Выручает в этом наличие в рэтро ЭВМ электронного диска и связи с IBM PC по линии. Или использование в роли НГМД винчестера, который, кстати, обходится в гораздо меньшие трудозатраты, чем пайка контроллера дисковода.
Дисковод полностью заменяется наличием в РК86 большого ОЗУ в 1-2 мб и, главное наличием скоростной связи по линии (для чего необходима установка в РК86 БИС последовательного интерфейса, причём не ВВ51, а скоростной 6850, чтобы иметь скорость загрузки в 115 кбод). Это более удобный вариант, чем НГМД или винчестер, потому что тогда файлы сразу доступны на IBM PC.
Ещё не ясно как записывать из редактора на дискетуЕсли МНИП, в дистрибутиве РК-ДОС есть редактор, который работает с файлами на дискете.
Впрочем, сейчас (благодаря легкости получения исходника с помощью IDA) легко модифицировать любую программу, изначально делающую LOAD/SAVE на ленту, так, чтобы файл писался на дискету. Если займётесь этим у меня есть готовые процедуры LOAD/SAVE, так что переделка старых МГ-программ вполне реальна.
пробовал работать с Апогеем... без НГМД неудобно
Как я понял, Вы сначала ставите RK-DOS в РК86 (т.к для этого уже есть всё готовое), чтобы затем разобравшись в ДОС и отладив на уже готовом ПО работу контроллера, затем странслировать версию RK-DOS для адресов АПОГЕЯ.
Барсик для Апогея наверное не смогу, это все равно что первокласснику попросить здать ЕГЭ. А так задумка конечно хорошая, спасибо!
Барсик, хотел спросить. Почему файлы с винтчестера доступны для IBM PC , а с дискеты нет. ? У меня есть винт 20 мВ от АТ286. Но хотя вы говорите что по линии ещё удобнее, наладить связь с РС
Почему файлы с винчестера доступны для IBM PC, а с дискеты нет
Просто потому, что во-первых, уже трудно встретить IBM PC, где бы был дисковод (да и доставать дискеты это уже давно большая проблема). Во-вторых, даже если дисковод на IBM PC стоИт, то он не может читать дискеты записанные нестандартным контроллером (нужен контроллер на ВГ93 или 8272). В третьих, надо определиться для конкретно чего нужен доступ к файлам для РК86 (МИКРОШИ, АПОГЕЯ). Тут возможны 2 варианта.
Первый вариант, когда требуется только запускать уже готовые, сделанные еще в 18-м веке программы для РК86, лишь из любопытства посмотреть антикварное ПО, т.е образно говоря "чтобы узнать как жили наши предки, древние славяне". Если не считать саму RK-DOS и её некрасивую оболочку SE.COM, то для для этого, вообще-то вместо дисковода полезнее устройство на флэш-памяти (например то, что разработал vinxru), т.к в этом случае ограниченный ресурс перезаписей 'microSD' не играет роли, а доступ к программам намного удобнее, быстрее и число хранимых файлов не ограничено в 400 кб.
В другом варианте предполагается создание собственных файлов. Т.е написание на ассемблере или на PL1 или Паскале МТ+ программ для РК86 в текстовом редакторе, затем трансляция и проверка их работоспособности на реале. Если это делать на самом РК86, и даже в RK-DOS, то это не только намного более утомительно и трудоёмко, но главное ограничивает инструментарий программами (компиляторами), написанными ещё на заре цивилизации. В частности, пакетом МИКРОН, используя который можно написать на ассемблере программу до 2 кб, но написание программы большего размера приводит к таким трудностям и неудобствам, что делает и саму такую затею бессмысленной, если есть гораздо более удобные варианты. А именно разработка на IBM PC, где более удобный текстовый редактор и доступны не только наилучший в мире ассемблер M80 от Microsoft (написанный в 1982, но до сих пор ничего лучше не придумали), но и ЯВУ, которые, увы, все работают только в CP/M или ISIS, а эти ДОС на РК86 работать не могут в силу нехватки её объёма памяти.
Поэтому и получается, что если на РК86 сами программы не разрабатываются, то и дисковод, винчестер или внешнее устройство на флэш памяти можно заменить электронным диском с объёмом от 64/92 кб и выше. 64 или 92 кб получаются, если в РК86 изначально стоит банка РУ5 и вторым этажом на неё напаивается ещё вторая банка РУ5, делая общий объём ОЗУ в 128 кб, коммутируемый цельно-полубанково в области 0...7FFF (доступ только через п/п-мы F836/39, т.е использование только для VDISK-а).
Но при этом есть проблема в скоростной линии передачи файлов. Программным путём, т.е без существенных аппаратных доработок удаётся иметь низкую скорость обмена. Чтобы это исправить надо ставить в РК86 последовательный интерфейс, позволяющий обмен на скорости 115 кбод, что соотвествет загрузке 115:8= 14.4 кб в секунду. Т.е самая большая программа РК86 объёмом в 27.5 кб загружается менее 2-х секунд. При этом для загрузки эл.диска объёмом в 1 мб требуется 70 секунд, и соответственно меньше для эл.диска в 64К.
У меня есть винт 20 мВ
Винт на 20 мб отлично подойдет для РК86. Лишь бы он был не дохлый и был бы IDE, а не MFM. RK-DOS, к сожалению не поддерживает диски большого объёма. Максимум, что мне удалось выжать из неё (без кардинальной переделки) - это 640 кб на диск (это из-за того, что во VTOC на трек выделено только 8 битов). Это заставляет разбивать винт на огромное количество маленьких дисков.
С винчестером более удобной оказывается CP/M, которая поддерживает диски гигантского размера, но которая в свою очередь не работает на РК86 в силу нехватки ОЗУ, но прекрасно подойдёт для АПОГЕЯ, где ОЗУ много.
Несложно написать для винчестера совсем примитивную ДОС, размером всего в 2 кб. Аналог Hameleon-DOS (http://lvovpc.ho.ua/forum/viewtopic.php?f=14&t=172) для "Львова" Алексея Мамонтова. Можно адаптировать, но это не интересно, интереснее написать ДОС самостоятельно и именно так, чтобы уложиться в 2 кб. До того я уже писал ДОС, но все они почему-то получились объёмом более 10 кб.
Для винта с гигантским объёмом примитивная ДОС как раз удобна, т.к в ней удалённый файл не возвращает объём диска. Новые файлы всегда нефрагментированно пишутся в конец записанной области, а чтобы освободить место надо выполнять программу SQEEZE (что долго и опасно делает схлопывание файлов на место пустот), аналогичную процедуре на ДВК и Электронике-60 (для винта это не опасно, т.к они не имеют дохлоты).
Барсик, основная задача дисковода это заменить магнитофон. Закатать побольше игр и программ. А также иногда самому что нибудь написать на дискету. В общем пока собираю, подключаю дисковод, а там посмотрим, война покажет. А почему вам не нравится вариант: память стандарт, нкмд, линия с IBM PC.
p.s. ошибся у меня винт на 120 мВ. В подписи у меня написано
А почему вам не нравится вариант: память стандарт 32К, НГМД, линия с IBM PC
Пока, так и есть. Но хочу 48К, винчестер, ЭД и скоростную линию. Большое число моих импортных НГМД 5.25" для которых большинство моих дисков, - давно сдохли. Остался только единственный дисковод 3.5", стоящий на PC (и пока там нужен). Есть ещё флоп 1*80 выпуска 1982 и флопы на 140 кб от Apple-II, которые не могу пока использовать, т.к они с программным секторированием и программным же контроллером (это решаемо и будет сделано, но пока нет времени).
Имею РК-КНГМД, но не пользуюсь и в дальнейшем в качестве массовой памяти рассчитываю на винчестер или на видео-магнитофон используемый для загрузки ЭД, если удастся добиться скорости обмена хотя-бы 1.5 кб в секунду (обычный РК МГ-формат даёт ~150 байт в секунду). Загрузка 512 кб на ЭД на скорости 1 кб в секунду занимает 512 секунд или 8.5 минут. А на базовой скорости МГ-обмена это занимает 50 минут, что совсем не оперативно.
Дисковод 5.25" работаюший с DD-дисками более перспективен, чем дисковод 3.5", т.к диски DD-5.25 от времени дохнут меньше.
Вообще не понимаю, каким боком тут нужен IBM PC (?). Если уж очень хочется работать с "винчестером", можно взять 8-битное включение IDE ATA. Минимум пайки, минимум кода (в 2К ПЗУ вполне возможно вписаться).
Но это к гибким дискам уже отношения не имеет.
Привет. Тут ситуация такая. Соберу я контроллер, а дальше? Дискет с софтом нет. Придётся через магнитофон закатывать. А если бы была возможность с РС сразу загружать в ОЗУ а потом на дискету, думаю было бы быстрее
Вообще не понимаю, каким боком тут нужен IBM PC ?
А альтернативы фактически нет. К тому же я выше объяснил, что параметры базовой РК86 не позволяют программировать на самой РК86, т.к программирование с пакетом МИКРОН это неэффективно.
У меня есть свой примитивный редактор текстов для РК86, есть и свой макроассемблер, клавиатура подключена хорошая (есть на выбор куча хороших клавиатур, КОРВЕТ, КОНСУЛ, Apple-II 56 клавиш и даже клавиатура от IBM PC, подключенная как матрица). Т.е набирать тексты и редактировать можно. Но даже если переделать РК86 кардинально, т.е ввести ОЗУ 62 кб и писать ПО в CP/M пользуясь нормальным инструментарием, это всё-равно будет намного менее удобно.
Потому что трансляция на РК с НГМД исходника в 100 кб длится 5 минут с непрерывным износом головок и дискет (а компиляция ЯВУ ещё дольше). А на IBM PC это одна десятая секунды. Проблема в том, что для того, что эффективно писать программы, цикл итерации (модификация-трансляция-прогон) должен занимать минимальное время. Самый эффективный метод разработки это не возня с отладчиком и трудоёмкая отладка, а метод очень мелких и частых модификаций. Тогда отладчик нужен редко. На PC что-то изменил в тексте, - хлоп на кнопку, автоматически странслировалось и через секунду вы Вы уже в этой программе в эмуляторе, проверяете. Т.е цикл одной итерации длится секунды вместо десятков минут.
Впрочем, винчестер может существенно ускорить обмен, если использовать имеющийся в РК86 ПДП. Я пока это делать не буду, т.к не знаю как синхронизировать два канала ПДП, да и просто лень переделывать то, что уже сделано и нормально работает.
Если уж очень хочется работать с "винчестером", можно взять 8-битное включение IDE ATA. Минимум пайки, минимум кода (в 2К ПЗУ вполне возможно вписаться).
Смысла этого высказывания вообще не понял. Потому что именно так это и делают. И я это уже сделал, ещё в прошлом веке (использовал как раз 8-ми битовый режим обмена с IDE, хотя и не уверен, что все новейшие IDE устройства до сих пор поддерживают 8-ми битность).
2 кб на код подпрограмм работающих с винтом? Или это общий объём готовой ДОС? И что за ДОС, о которой речь? Если речь о объёме подпрограмм для винта, то он меньше 1 кб. Если о ДОС, то что это за ДОС?
Неважно как физически устроена подпрограмма работы с диском. Все ДОС нуждаются только в 2-х подпрограммах - чтения и записи сектора. Поэтому имея эти 2 п/п-ммы для любого носителя, получение версии ДОС, поддерживающей конкретное устройство занимает одну минуту. В том числе для RK-DOS, CP/M или Hameleon-DOS А.Мамонтова.
Придётся через магнитофон закатывать. А если бы была возможность с РС сразу загружать в ОЗУ а потом на дискету, думаю было бы быстрее
Придётся через магнитофон. Всем пришлось это делать. Но это же делается лишь один раз и к тому же Е.Седов обеспечил специальные программы для конверсии с ленты на диск. Это отнимет всего час времени.
Если у Вас есть IBM PC с LPT-портом, то можно перекачивать и по проводной линии, но это не будет быстрее, т.к если нет БИС последовательного интерфейса, то приходится использовать программный обмен, а он даже медленнее (~100 байт в секунду), чем скорость обмена с МГ-лентой. Впрочем, с использованием специального аппаратного адаптера, скорость передачи мне удалось поднять до ~1 кб в секунду.
У меня есть три PC с СОМ портами и LPT указаны в подписи. Я почитал про НКМД из журнала Радио 93г. Довольно сложно реализация записи-считывания. Но в итоге конечно можно будет это реализовать, но в будущем.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot