Орион-128: Перспективы развития

[Denn]

Error404, спасибо за ответ! С igor_t общаюсь по аське, в курсе его разработок. Уход в "виртуал" (ПЛИС, Альтера и т.п.) меня не привлекает, хочется именно на рассыпухе, типа тряхнуть стариной Заказал таки 20-мегагерцовый Z80C (конкретно - Z84C0020PEG), 10-наносекундную память (CY7C1049D-10VXI), курю устройство формата SVGA (тайминги). Если возникнут трудности, то попробую списаться с Mick'ом (спасибо за наводку ).

На написание нового софта у меня как раз порох имеется, наверное даже больше, чем на создание железа. Но писать хочется именно под 20-мегагерцовую версию Ориона, ибо 2.5 МГц - это слишком неадекватно для орионовской экранной области (даже с "хитростями" вроде использования стековых супер-пупер-быстрых операций вывод на экран происходит с заметными и раздражающими тормозами). Поскольку обратная совместимость - изначальное обязательное условие, режим 2.5 МГц должен присутствовать, возможно даже программно переключаемый (наверное даже устанавливаемый по-умолчанию после сброса, а турбированный режим активизируется новым ПО, которое заточено под 20 МГц).

Хотелось бы ещё иметь опциональный альтернативный вариант расширенной экранной области, особенности которой хотел бы обсудить с заинтересованными людьми. Также рассматриваю вариант подключения стандартной IBM'овской клавиатуры напрямую (без эмулятора клавиатуры RK86).

Память думаю ставить статическую, ибо нынче доступна с достаточным быстродействием и не нужно заморачиваться с регенерацией (что упрощает схемотехнику). Объём памяти - 1 Мб (16 страниц, две ИМС 512х8 - чётные и нечётные страницы для простоты реализации экранного вывода) с возможностью расширения до теоретических 16 Мб (256 страниц - максимальное кол-во, поддерживаемое портом переключения страниц).

Пока не очень понимаю что делать с портами, т.к. стандартные ххх55 микросхемы работают максимум до 5 МГц, но это из тех, которые я знаю.

Предстоит разобраться с форматом SD (SDHC) карт и как их "красиво" аппаратно коннектить к Ориону. В общем, некий фронт работ уже имеет достаточно чёткие очертания, теперь всё упирается в наличие свободного времени на это дело, ну и в группе сочувствующих (а в идеале - участвующих!).

[Error404]

Error404, спасибо за ответ! С igor_t общаюсь по аське, в курсе его разработок. Уход в "виртуал" (ПЛИС, Альтера и т.п.) меня не привлекает, хочется именно на рассыпухе, типа тряхнуть стариной Заказал таки 20-мегагерцовый Z80C (конкретно - Z84C0020PEG), 10-наносекундную память (CY7C1049D-10VXI), курю устройство формата SVGA (тайминги). Если возникнут трудности, то попробую списаться с Mick'ом (спасибо за наводку ).

На написание нового софта у меня как раз порох имеется, наверное даже больше, чем на создание железа. Но писать хочется именно под 20-мегагерцовую версию Ориона, ибо 2.5 МГц - это слишком неадекватно для орионовской экранной области (даже с "хитростями" вроде использования стековых супер-пупер-быстрых операций вывод на экран происходит с заметными и раздражающими тормозами). Поскольку обратная совместимость - изначальное обязательное условие, режим 2.5 МГц должен присутствовать, возможно даже программно переключаемый (наверное даже устанавливаемый по-умолчанию после сброса, а турбированный режим активизируется новым ПО, которое заточено под 20 МГц).

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

Хотелось бы ещё иметь опциональный альтернативный вариант расширенной экранной области, особенности которой хотел бы обсудить с заинтересованными людьми. Также рассматриваю вариант подключения стандартной IBM'овской клавиатуры напрямую (без эмулятора клавиатуры RK86).

По расширению зкрана надо определиться с целью. Если просто получить более-менее читаемый символьный режим 25х80, то можно применять стародавние простые схемы расширения до 480 или 512 точек -в этом случае все цветные режимы остаются прежними и остается обратная совместимость (для игр, которые уже никто более не напишет, и старописного софта). Вот пример: http://zx.pk.ru/showpost.php?p=212461&postcount=1

Если планируются какие-то доработки для новых режимов, то тут никак прокомментировать не могу - надо конкретные варианты рассматривать.

IBM'овскую клавиатуру напрямую проще всего подключать по "Векторовской" методике (публиковалась тут в векторовской ветке) - потребуется всего 4 линии порта ВВ55 и несколько диодов-резисторов. Но потеряется возможность играть в игры, которые работают мимо Монитора.

Память думаю ставить статическую, ибо нынче доступна с достаточным быстродействием и не нужно заморачиваться с регенерацией (что упрощает схемотехнику). Объём памяти - 1 Мб (16 страниц, две ИМС 512х8 - чётные и нечётные страницы для простоты реализации экранного вывода) с возможностью расширения до теоретических 16 Мб (256 страниц - максимальное кол-во, поддерживаемое портом переключения страниц).

Отказ от регенерации (статические ОЗУ) схему сильно не упростит, т.к. схема регенерации на 80 процентов еще одновременно и схема сканирования для вывода на экран. Уменьшится количество корпусов собственно мсх ОЗУ - это да. Кстати, а CY7C1049D-10VXI - в каком корпусе идут? Паябельные?

Пока не очень понимаю что делать с портами, т.к. стандартные ххх55 микросхемы работают максимум до 5 МГц, но это из тех, которые я знаю.

Как я понимаю, 82с55 от этого недостатка свободны [до некоторого опять же порога] (а 8255 уже и не укупишь - только 82с55 продают). Также, есть другое решение - в 90-хх при разгоне z80 до 10МГц, если порты не успевали, то ставили несложную доработку, которая давала пару тактов /WAIT на Z80 при каждом обращение к портам ВВ55, это помогало.

Предстоит разобраться с форматом SD (SDHC) карт и как их "красиво" аппаратно коннектить к Ориону.

Если подключать SD напрямую (например, к ВВ55), то будет неприемлимо медленно (в разы медленнее дисковода) из-за последовательного интерфейса с картой и программной реализации SPI. Если подключать через контроллер, то обмен будет работать быстрее, но надо проектировать непростой девайс (непростой главным образом в части ПО). У меня для этой цели куплен готовый фабричный девайс - преобразователь SD->IDE (фактически "преобразователь последовательного в параллельное").

В общем, некий фронт работ уже имеет достаточно чёткие очертания, теперь всё упирается в наличие свободного времени на это дело, ну и в группе сочувствующих (а в идеале - участвующих!).

Сочувствую
Насчет поучаствовать, я тут в орионовской ветке типа ЧерногоКота - знаю как надо (точнее, как хотелось бы мне), только сделать не могу.

[Ewgeny7]

IBM'овскую клавиатуру напрямую проще всего подключать по "Векторовской" методике (публиковалась тут в векторовской ветке) - потребуется всего 4 линии порта ВВ55 и несколько диодов-резисторов. Но потеряется возможность играть в игры, которые работают мимо Монитора.

Неа, лучше перенести 8255 в альтеру туда же вписать модуль работы с ПЦ клавиатурой. Так сделано у igor_t, так же и я сейчас начинаю париться. Т.е. клава будет напрямую подключена к альтере в обход тормозов контроллера и ВВ.

[Error404]

Неа, лучше перенести 8255 в альтеру туда же вписать модуль работы с ПЦ клавиатурой. Так сделано у igor_t, так же и я сейчас начинаю париться. Т.е. клава будет напрямую подключена к альтере в обход тормозов контроллера и ВВ.

Это если есть Альтера. Кстати, если принять что магнитофонный интерфейс выкидываем, тогда и упростить можно - эмулировать не полностью ВВ55 \ 8255, а только как набор регистров - F400 на запись, F401 и F402 (половинка) - на чтение, F403 на запись+чтение.

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

[b2m]

А в случае компа на россыпухе - только вариант с внешним микроконтроллером

Ну почему-же, есть варианты
Например сделать прерывание при обращении к "несуществующим" портам (старой клавы) плюс теневое ПЗУ и ОЗУ, обрабатывающее это прерывание по своему усмотрению. Т.е. при возникновении такого прерывания автоматически включать теневой режим, а в качестве команды подсовывать например 0FFh (RST 7). Работу со стеком сделать как квазидиск в Векторе, но наоборот, т.е. при обращении к стеку из теневого режима работаем с основной памятью, иначе с теневой ОЗУ. Заморочки со стеком позволят упростить вход/выход в теневой режим. Выход из теневого режима осуществлять примерно так:

OUT exit_shadow_port
RET

при этом выход нужно отложить на одну команду, чтобы успел выполниться RET в теневом режиме.

[Error404]

Ну почему-же, есть варианты
Например сделать прерывание при обращении к "несуществующим" портам (старой клавы) плюс теневое ПЗУ и ОЗУ, обрабатывающее это прерывание по своему усмотрению. Т.е. при возникновении такого прерывания автоматически включать теневой режим, а в качестве команды подсовывать например 0FFh (RST 7). Работу со стеком сделать как квазидиск в Векторе, но наоборот, т.е. при обращении к стеку из теневого режима работаем с основной памятью, иначе с теневой ОЗУ. Заморочки со стеком позволят упростить вход/выход в теневой режим. Выход из теневого режима осуществлять примерно так:

OUT exit_shadow_port
RET

при этом выход нужно отложить на одну команду, чтобы успел выполниться RET в теневом режиме.

Но ведь игры (а несовместимость клавы проявится главным образом на них) при запуске сами перепрограммируют режимы перываний. Т.е. единственный вариант - NMI.
Кстати, подобное решение на россыпухе в середине 90-х уже существовало на Орионе для программно-аппаратной эмуляции ZX-спектрума. По сложности представляло собой примерно 50% от Ориона и сравнимо с целым Лениградом-1.

[Advertiser]

[b2m]

Т.е. единственный вариант - NMI.

Уговорил. Согласен.

[Error404]

Кстати, про SD-карточки на Орионе.
Вот тут готовое решение компа такого же класса по использованию SD-карточек в CP/M на основе программной реализации SPI. Есть все схемы (простейшие, цена вопроса - один регистр, стабилизатор 3,3V и несколько резисторов) и исходники доработанной CP/M:
http://n8vem-sbc.pbworks.com/browse/...SD%20Interface

[pvlad]

Кстати, про SD-карточки на Орионе.
Вот тут готовое решение компа такого же класса по использованию SD-карточек в CP/M на основе программной реализации SPI.

Может быть стоит попробовать перенести на Орион? Возможно окажется быстрее (или не намного хуже!) IDE! Мне кажется Вам это по плечу, если появится желание.

[Error404]

Может быть стоит попробовать перенести на Орион? Возможно окажется быстрее (или не намного хуже!) IDE! Мне кажется Вам это по плечу, если появится желание.

Я уже думаю на эту тему. Смотрю исходники, схему, и тоже склоняюсь к тому, что сделать можно и нужно. Первая задача (и самая сложная) - доработать эмулятор до эмулирования MMC/SD. Тут придется много читать спецификации на SD, и на реализацию SD в эмуляторе придется затратить больше усилий, чем на эмуляцию более простого алгоритма работы IDE.