Радио-86РК: Подключение дисковода

[barsik]

Мне не нужен 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 драйвер обмена по проводной линии (используя те же порты, что для МГ обмена)

[tnt23]

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

Сообщение от tnt23
> вопрос переноса данных с РК на "большие" компьютеры

О чём речь? Насколько большие компьютеры имеются в виду? Например ОРИОН с ОЗУ 512К достаточно большой? Или требуется ATM-Turbo с 4 мб памяти? IBM PC ещё более большой компьютер.

Ну не с Ориона же и не с АТМ вы в интернет ходите?

[barsik]

нужен софт типа коммандера, который бы позволял работать с 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.

[tnt23]

Приехали платы реплики КНГМД для "Микроши".





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

Если у РК-КНГМД формат действительно MFM

Там FM, как ясно отмечено в оригинальном цикле статей.

Можно применить на РК контроллер НГМД от ПАРТНЁРА на ВГ93, который записывает в формате, что можно считать на IBM PC. Тогда можно даже написать программу для РК86 записывающую прямо в формате MSDOS 720К. Однако такой контроллер нельзя применить для RK-DOS, т.к она использует сектора нестандартного размера.

Тогда зачем предлагать заведомо неподходящее сразу по нескольким параметрам решение?

[barsik]

Приехали платы реплики КНГМД для "Микроши"

Прекрасно, больше будет пользователей РК и АПОГЕЕВ с дисководом.

Там 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 нормальный.

[tnt23]

Почему же промышленный контроллер на БИС, как и у всех остальных отечественных компьютеров - заведомо неподходящий?

Потому, что речь изначально о контроллере РК-ДОС на ВВ55 с его уникальным форматом записи. Как при наличии контроллера РК-ДОС может помочь "промышленный контроллер на БИС", я не понимаю. Куда его вешать, и, главное, зачем умножать сущности сверх необходимого? Даже если контроллер РК-ДОС сможет записать FM-трек в совместимом с IBM или ISO формате, прочитать это на типовом настольном ПК не удастся. Значит, или SD-контроллер для переноса, или сеть, или самодельный USB-контроллер дисковода для чтения конкретно РК-ДОСовских дисков.

Но хоть кому-то уже удалось считать дорожку целиком на PC? Пока нет подтверждения этому, есть сомнение, что формат РК-КНГМД совместим с промышленным стандартом.

Как появится возможность, попробую прочитать дискету РК-ДОС на Амиге, там контроллер дисковода умеет читать вообще все, что шевелится (практически втягивает поток бит).

[barsik]

Как при наличии контроллера РК-ДОС может помочь "промышленный контроллер на БИС", я не понимаю

Что значит при наличии. Естественно, новый контроллер втыкается в тот же слот, куда ранее втыкался контроллер РК-КНГМД, а последний выкидывается. Кто в здравом уме захочет иметь на дискетах вдвое меньший объём (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]

Приобрел печатную платку кнгмд для микроши. Спасибо tnt23 за труды вложенные в создание реплики и за помощь в приобритении
данной платки. Процесс сборки идет). По ряду причин решил использовать пзу большего обьема на 32 или 64 кб.Панельку прикрутил на 28 пинов.
Теперь решаю как сделать дешифратор адресов для пзу такого обьема, малой кровью.Все нужные сигналы есть на системном разьеме. Хочу сделать так
же 2 кб для монитора, что бы можо было менять его прошивку на платке контроллера, а не на основной плате, сигнал есть CS4. и окно выше 8000h для
софта. Может кто подскажет наиболее просто решение для этого дешифратора.

[barsik]

решил использовать на плате КНГМД ПЗУ большего объёма, на 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, т.к такое решение не нагружает шину.

Я предложил вариант использования ППА для формирования упр.сигналов доп.железом в РК86. Для РК86 это требует установки дешифратора ИД7 и на область F000...F7FF, что необходимо чтобы получить дополнительные чип-селекты для В/У и главное, на РК86 это позволяет иметь доступ к ППА при включении на 8000...BFFF дополнительного ОЗУ. В МИКРОШЕ применена более грамотная адресация В/У, отчего там нет проблем с расширением ОЗУ в области 8000...BFFF и процессор может обращаться к второму ППА (аналогу D14 в схеме МИКРОШИ) даже когда подключено доп.ОЗУ в этой области.

Разумнее всего и для МИКРОШИ и для РК86 использовать единый стандарт расширений ОЗУ и ПЗУ. Можно даже иметь разные адреса ППА управляющего железом, т.к совместимости и так нет и изменить в исходнике одну переменную и перетранслировать несложно (несложно это изменить и в готовом коде). Но вот биты в порту должны быть совмещены, иначе это будет совсем другая архитектура.

В вышеприведённом посте для порта 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]

Схема установки ПЗУ 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 и отличается от приведенной тут в начале темы.