Tronix, Могу дать погонять китайский 16канальный Saleae.
16 каналов будут на 16мгц сэмплиться.
Всёравно пока без дела лежит.
Забирать на м.калужской, как обычно :)
Вид для печати
Tronix, Могу дать погонять китайский 16канальный Saleae.
16 каналов будут на 16мгц сэмплиться.
Всёравно пока без дела лежит.
Забирать на м.калужской, как обычно :)
Спасибо, но наверное пока не нужно. У меня на работе тоже есть 16-ти канальник, какой-то злой, на ПЛИС, очень большие мегагерцы может снифать. Если что его возьму....Цитата:
Сообщение от piroxilin
Просуммирую мысли, в кратце, чтобы самому не забыть:
У Поиска есть две области видео-памяти по 16Kb каждая, отображаться на экране может одна из них. В графическом режиме отображается B800h, в текстовом - отображается BC000h, содержащая графическое представление текстовых символов из B800h. Происходит это в моем понимании примерно так: когда установлен текстовый режим, при записи символа в видео-память B800h срабатывают ловушки адреса (регистры-защелки), которые запоминают, по какому адресу произошла запись. Дальше вызывается обработчик NMI, который в свою очередь читает из портов 28h и 29h значение адреса (из регистров-защелок), по которому произошла запись, и отрисовывает символ в видимой графической области BC000. Сам код символа записывается в B8000h.
За отслеживание, что запись происходит в видео-память отвечает РТ4 (с небольшой помощью РТ5?), при удачной дешифрации формирующая сигнал /CRTIOM. Дальше этот сигнал вместе с некоторыми другими запускает мультивибратор, который дает длинный импульс NMI (не менее пяти тактов, наверное).
http://habrastorage.org/files/50c/ac...cccad0837b.png
По сигналу NMI происходит защелкивания текущего адреса в регистры-защелки:
http://habrastorage.org/files/00a/ca...41044139a6.png
Ну и дальше проц должен уйти на обработчик NMI, который прочтет из портов 28h,29h адрес куда писался байт и отрисует его графическое представление в отображаемый экран BC000h. Дешифрует порты РТ5, формируя сигнал /TRAPSEL, который потом разделяется на 28h (TRAPL),29h (TRAPH) и 2ah (TRAPDAT) с помощью ИД7.
Так вот, когда идет запись двух байт (mov cx,2; rep stosw), первый байт - есть сигнал /CRTIOM, затем длинный NMI и затем уже /TRAPSEL, TRAPL и TRAPH. А вот второй байт - нет сигнала /CRTIOM, соответственно нет и всего остального. Такое ощущение, что "проскакивает" он.
Я щас глянул даташит на NEC v20, увидел интересный момент. У него скважность CLK по спецификации равна двум. А на Поиске-то она равна трем. Учитывая, что переключение шин процессора происходит скорее всего по фронту сигнала, это действительно может вызывать подобную хрень.
похоже что /trapsel на v20 кривой изза другого поведения /inta? либо изза другого состояния на шине в момент формирования /trapsel
Не доходит дело до /TRAPSEL. Это я неправильно смотрел. Сначала должен сформироваться сигнал /CRTIOM, чтобы вызвать NMI и по этому же сигналу (NMI) защелкнуть текущий адрес на шине адреса в ИР23. А /TRAPSEL уже потом, его процедура обработки NMI формирует для доступа к портам 28,29h, из которых она узнает по какому адресу произошла запись. Так дело до NMI не доходит, так как нет /CRTIOM
А /CRTIOM дешифруется просто с шины адреса... Неужели на шине адреса не выставляется адрес по какому происходит запись в память? Но этого же не может быть, иначе бы вообще ничего не работало. Да и потом, физически, запись в B800h происходит, то есть байты там появляются (в памяти). Значит все-таки проц работает нормально, и адреса выставляет нужные на шину. Только если РТ4 не успевает сработать из-за короткого CLK?
Есть другая безумная идея - сделать свой дешифратор на мелкой ПЛИС для сигнала /CRTIOM и сравнить с текущим дешифратором. Если у меня сигнал будет формироваться, а у Поиска нет - то скорее всего дело в РТ4(и РТ5?). С другой стороны, как же работают остальные сигналы /PROMSEL (доступ к ПЗУ) и /RAMSEL (доступ к RAM)... Не понимаю.
Хммм... Уставшим взглядом после работы посмотрел опять на схему дешифратора и увидел, что кроме адресов и DT/R по входу еще присутствует сигнал /NMIDIS.
Рулится програмно, через 68h порт бит 3...Цитата:
Формирование сигнала немаскируемого прерывания произво-
дится при записи данных в буфер дисплея B8000Н - BBFFFН
только при наличии сигнала разрешения NMIDISABLE (потенциал
низкого уровня на выводе 1 микросхемы D42).
Вот его бы интересно взглянуть. Пока что-то не найду на схеме...Код:----------------------------------------------------
Порт ввода-вывода 68Н
----T-------------------T---------------------------
N ¦Наименование ¦ Назначение
бита¦сигнала управления ¦
----+-------------------+---------------------------
0 ¦ R (Red) ¦
----+-------------------+Цвет изображения и фона
1 ¦ G (Green) ¦
----+-------------------+
2 ¦ B (Blue) ¦
----+-------------------+---------------------------
3 ¦ NMI DISABLE ¦Запрет/разрешение формиро-
¦ ¦вания немаскируемого
¦ ¦прерывания
----+-------------------+---------------------------
4 ¦ PALETTE ¦Цветовой выбор (палитра)
----+-------------------+---------------------------
- 32 -
5 ¦ I (INTENS) ¦Интенсивность изображения
¦ ¦и фона
----+-------------------+---------------------------
6 ¦ DISPLAY BANK ¦0/1 страница видеопамяти
----+-------------------+---------------------------
7 ¦ HIRES ¦Графика высокого/среднего
¦ ¦ разрешения
D72.1 вв55Цитата:
Сообщение от Tronix
Вообщем, пока форум лежал, решил проконсультироваться тут: http://www.nedopc.org/forum/viewtopic.php?f=87&t=11189 . В итоге, были проведены ряды экспериментов: я записывал по кругу цифру "1" (mov cx,1; rep stosw) на экран и два раза цифру "2" (mov cx,2; rep stosw). В самом обработчике NMI вывожу содержимое из регистров-защелок (in ax,28h), затем значение по этому адресу в памяти символа и его аттрибута (CHR: ) и значение по этому адресу плюс два (CHR+2). Поведение на 8088 предсказуемо:
http://hsto.org/files/e30/ec7/e08/e3...be90932a4d.JPG
А вот V20:
http://hsto.org/files/151/2e7/cbf/15...25d8dd0e07.JPG
Выяснилось, что при операции прямой записи в память типа MOV CX,2; REP STOSW попадая в NMI для обработки первого символа в памяти уже находится и второй символ!
Такие дела... В итоге взял исходники BIOS 89 года, которые есть везде, и попробовал сделать следующее - при в ходе в NMI взять из стека адрес CS:IP предшествующей команды и сравнить ее на наличие префикса REP (0xF3). Если есть - значит мы попали в NMI в разрыве между REP xxxx, и значит нужно рендерить сразу два символа - текущий и по адресу текущий+2. Но пришлось сделать две проверки - когда CX=2 и rep stosw, то я получаю в NMI уже опкод команды, следующей за rep stpsw. Поэтому для такого случая приходится проверять es:[bx-2]. С другой стороны, когда CX=1 и rep stosw, я здесь зря отрисую два символа. Когда CX=3, должно сработать первое условие es:[bx].
Скомпилил и тут же словил первый баг - не правильно распознавался объем RAM. Вместо 480Кб дос рапортовала о 306Кб вроде, и CheckIt не запускался, ругаясь на нехватку памяти. Переписал процедуру определения RAM. Скомпилял. Запустил VC - работает как надо. Запустил тесты в CheckIt - ну.... снизилась видео-скорость конечно... 430 bios speed и 822 direct speed. Ну и вообще, биос 89-ого года из сорцов - уж очень ранний, что-ли. Багов много - не правильно настроена клава. Клавиша ESC - это F1, F2 - это F1, нельзя нажать Ctrl+L, потому что Ctrl - это вроде бы Alt и тд. Странно отрисовываются инверсные цвета, не так как в биосе 91-ого года (когда фон белый а сам символ черный). Не полностью работают CGA-порты, особенно на чтение, поэтому Принц Персии не запускается и ругается на отсутствие видеоадаптера. И это только на первый взгляд. Ах да, я еще выпилил полностью работу с кассетой, а то мне места не хватало. Но на всякий случай выложу здесь, в прикрепленном файле с исходниками.
А так можно попробовать подменять NMI из-под доса резидентом...
впилил дезассемблированную обработку сканирования клавиш из биоса 91-ого года. Теперь клавиши начали соответствовать своей раскладке на клавиатуре (ESC - это ESC, F1 - это F1 и тд), начали срабатывать комбинации Ctrl + буква, начал включаться синий фон при нажатии правого Ctrl (переключение на русский). Однако само переключение не происходит, символы по прежнему печатаются английские, и не выключается синий фон повторным нажатием на правый Ctrl. Видимо что-то еще там не того, наверное еще и int9 надо менять... Но все равно, уже гораздо лучше, по сравнению с самым первым вариантом.
Итого, уже пофикшено:
1) Правильное определение количества набортной памяти. По умолчанию сильно занижал, например на реальных 480Кб дос рапортовала о ~306Kb. Не стал разбираться, а переписал функцию. Сделал вывод на экран количества памяти (места много, так как выкинул кассетные функции).
2) Нормальный вывод символов, с инверсными аттрибутами. Volkov Commander стал выглядеть так-же, как и на биос 91-ой версии
3) Частично заработала клавиатура. Описано выше. Изменен SCANINT2.ASM. Старый сохранен как SCANINT2.A__
Что еще надо сделать:
1) Клавиатура - описано выше (русские символы, убирание синего фона при повторном нажатии пр. Ctrl)
2) Впилить более корректную обработку CGA портов в NMI, в том числе вроде в 91-ой версии есть возможность читать значения из CGA портов, а не только их туда писать. Добится запуска принца персии.
3) Посмотреть что с курсором - он не убирается, когда его выключают, хотя вроде бы функции такие в 89 биосе есть.
4) Посмотреть что с переключением видео-страниц. При тестировании видеостраниц в Checkit происходит не пойми что.
5) Шрифт - взять из 91-ой версии, потому что мне он больше нравится. Различаются начертанием кодов >127
6) Ну и по мелочи, оптимизация, приведение кода в человеческий вид...
Вот такие планы...
Спасибо, Tronix!
Самому очень хочется заняться BIOSом, да времени катастрофически не хватает.
А нет ли у Вас в планах - знакогенератором заняться?
Привести к привычному виду символы псевдографики?
Что имеется ввиду?Цитата:
Сообщение от Копейкин
А чем вызвана неприятная полосатость строки команд Нортона и прерывистость бордюра?Цитата:
Сообщение от Tronix
Ваши скриншоты на первой странице этой темы.
Тем, что у Поиска шрифт, фактически, 7x8 а не 8x8 как у нормальных людей. Ну то есть формально то он 8x8 конечно, да вот только первый бит (или последний, смотря откуда смотреть) отвечает за цветовой признак - либо белые пиксели, либо лиловые (зеленые). Например возьмем черточку (минус):Цитата:
Сообщение от Копейкин
00000000
00000000
00000000
01111111
01111111
00000000
00000000
00000000
Вот она в таком виде - белая. В таком:
00000000
00000000
00000000
11111111
11111111
00000000
00000000
00000000
- лиловая. И если в шрифте она так и записана, то белой она уже не станет. Будет всегда лиловой.
Спасибо за детальное изложение, я так глубоко видеоконтроллер Поиска не копал.
Чтобы полностью всё осознать, Вы не расскажете - это аппаратно реализовано?
Или можно программно привести в соответствие?
Ведь в видеорежиме 3 отдельно коды символов, отдельно атрибуты должны быть...
Я то же не копал. Все время как хочу - вылазят столько нюансов, что я опять запутываюсь и все по новой. Поэтому все что дальше - мое имхо. Поиск работает всегда в графическом режиме, текстового у него нет. При этом в графическом режиме высокого разрешения 640x200 он может работать в двух вариантах: 1) когда каждый байт раскладывается на 8 бит и каждый бит трактуется как черный или белый. То есть обычный графический ч/б режим. И второй вариант - когда каждый байт трактуется как первый бит - наличие дополнительного цвета за последующими 7 битами. Таким образом в этом режиме может быть отображено 3 различных цвета (черный,белый,лиловый), но с потерей каждого первого бита в каждом байте. Это аппаратно так.Цитата:
Сообщение от Копейкин
Как-то так.
Поборол лень и впилил все-таки дизассемблерные обработчики int 10h, int 9h, scanint и int16h из биос 91-ого года. Да, в BIOS 91 года отличия большие, по сравнению с имеющимися сорцами...
Клава - они полностью переписали обработчик scanint (который сканирует клаву). int 9h - почти байт-в-байт совпал с имеющимися сорцами BIOS от Поиск-2. Таблицу перекодировки русских букв вынесли из scanint в int 16h. И теперь это стало реально таблицей маленьких и больших букв, а раньше была маленькая табличка плюс куча условий в scanint. Меняют при нажатии на правый ctrl фон на синий, в 89 этого нет. Короче изменения внушают.
Видео - тоже они здорово переделали int 10h. Обработчики не совпадают, поэтому просто подгонял дизассемблерный листинг с правкой констант. Теперь курсор вменяем. NMI добавил чуть-чуть чтения портов, Принц персии стартует. Остальное надо проверять и доделать чуть-чуть.
Так что основные фишки из 91-ого биоса перенесены. Потестирую, если все ок, оставлю...
Спасибо Вам огромное.
А в этом варианте БИОСа поддерживается клавиатура 89 или 91 года?
Там вроде по разному было сделано.
В этом варианте клавиатура 91-ого года теперь (раньше была 89-ого).Цитата:
Сообщение от Копейкин
Вообше, немного подоптимизировал NMI, int 10h... Скорость видео с оригинальным процессором 1810ВМ88 я показывал на первой странице, но вот еще раз:
http://hsto.org/storage3/2e8/28d/440...b36099600e.jpg
А это скорость видео с оптимизацией обработчика NMI и функций вывода символов из int 10h (табличное умножение). Процессор тот же - 1810ВМ88:
http://habrastorage.org/files/21b/c3...6b49e59409.JPG
В обработчике NMI есть деление, а оно, как известно, происходит долго. Ради эксперимента попробовал заменить деление табличкой, но жертвуя 4 Кб оперативной памяти. То есть, если у Поиска 480Кб - будет 476Кб, если 96Кб - будет 92Кб соответственно. Это задается дефайном OPTIMIZE_DIV в BIOS.ASM. Вот с включенной оптимизацией на родном проце 1810ВМ88:
http://habrastorage.org/files/eca/f7...024249f39c.JPG
Что касается NEC V20 - то скорости тоже пропорционально возросли.
Всем добрый день!
В документации на "поиск" встретил упоминание, что процессор для доступа к памяти получает только 8 тактов из 16, и при частоте 15МГц это даёт скорость доступа 937500 операций в секунду. Не знаю, успевает ли он за эти 8 тактов прочитать или записать два байта или только один, но очевидно, что скорость памяти является главным тормозом. То есть, чем меньше читается кода и обращений к памяти, тем лучше. При дальнейшем развитии данной мысли, был написан обработчик NMI, который сначала жил в загрузочном секторе, а когда стало очевидно, что для разных текстовых режимов желательно иметь разные обработчики, переселился в COM-файл. Для ускорения рисования обе половины шрифта были положены рядом, чтобы не работать с указателями. Для режима 80 символов обрабатываются 2 бита атрибутов - инверсия и альтернативный цвет, они преобразуются в XOR-маску, это не совсем то, что делает биос, но его логику я не особо уловил, да и можно сделать преобразование по таблице и без проблем добавить третий признак - подчеркивание в альтернативном цвете, что позволит выводить на экране 8 различных начертаний символов. Для режима 40 символов вывод в режиме XOR отсутствует, что с ним делать в текстовом режиме не особо ясно, а графические режимы я не делал. Основная идея оптимизации была в том, чтобы снизить расход времени в NMI на сохранение регистров, для этого строки экрана были поделены на блоки по 8 или 16 символов. Обработчик NMI сохраняет регистр AX, читает куда записан символ, и если это тот же блок, то ничего не делает. Рисование блока будет произведено целиком, когда символы начнут выводиться в новый блок. Хорошо бы еще учитывать какие реально символы выводились, а незаконченный блок рисовать в обработчике прерывания от таймера, но пока этого не сделано. Для режима 80 символов блоки рисуются по 2 символа сразу. Для режима 40 символов сначала была добавлена табличка на 512 байт, для конвертирования шрифта, потом был сделан конвертированный шрифт в 4К, ну а в fast_nmi в целях эксперимента было сделано 12 копий шрифта для всех несовпадающих комбинаций цвета символа и фона. Еще был сделан resident, который должен ускорить рисование символов в других программах, но это относится только к программам, пишут напрямую в память. В NC при нажатии Ctrl+O, панельки скрываются вроде бы быстрей, а вот обратно видимо перечитывается список файлов с дискеты. Checkit зачем-то перехватывает int2, и реальную скорость рисования символов занижает раза в полтора, resident востанавливает int2 по таймеру, но checkit не работает в эмуляторе, поэтому, если у кого есть возможность - просьба проверить на реальном железе. Результаты в эмуляторе такие:
bios vs fast_nmi vs resident
268 vs 3406 vs 2909
1284 vs 4091
Если вернуться к варианту с таблицей в 512 байт, то в режиме 25x40 скорость упадёт раза в два, это тоже существенно быстрее, но упихать такую таблицу в ПЗУ будет не просто. А пока образ дискеты с тестовыми версиями:
Вложение 55014
Вы учтите такой момент, что процессор Поиск-1 работает на частоте 5МГц, причём цикл обращения к шине, если не было wait stat'тов, занимает 4 такта. Поэтому регенерация/вывод на экран должны быть "прозрачны" для процессора. Другое дело, что программная эмуляция режимов адаптера занимает много времени, это да.Цитата:
В документации на "поиск" встретил упоминание, что процессор для доступа к памяти получает только 8 тактов из 16, и при частоте 15МГц это даёт скорость доступа 937500 операций в секунду.
Копейкин
Не знаю, насколько регенерация памяти и видеосистема притормаживают процессор, интересно бы посмотреть диаграммы, но реального железа у меня нет. Если исходить из соображений, что простые инструкции занимают 2-3 байта, делают одно обращение к памяти или работают с регистрами, и в среднем читается/записывается 3 байта на 1 инструкцию, то память ограничивает производительность процессора на уровне 300000 команд в секунду. Если это поделить на 854 символа в секунду из результатов checkit, то получается 351 тактов, что несколько дофига. Чтобы нарисовать символ нужно вычислить смещение на экране, смещение в шрифте, маску для атрибутов, прочитать и записать 8 байт для режима 25x80. Если выделить по 10 команд на вычисление смещений, атрибутов, еще по 10 на чтение, наложение маски и запись, получается около 60 полезных команд, все остальные команды пользы для рисования символов не приносят. Сохранение регистров - еще 20 команд неизбежного зла, но если разбить экран на блоки можно за 10 команд убедиться что символ попадает в текущий блок и отложить его рисование на потом. Когда мы будет рисовать блок, эти 10 команд можно отыграть за счёт того, что не нужно вычислять смещение на экране для всех символов блока. То есть в теории, рисование одного символа команд за 60 одолеть можно. На практике ускорения в 351/60 мы не получаем, но в 3 раза ускорение для режима 25х80 получить можно без особых затрат. Для режима 25x40 можно получить ускорение в 5-6 раз, если делать табличку на 512 байт, и в 10 раз если занять шрифтом 4К. Расшифровка цифр из предыдущего сообщения:
1284 - примерно такую цифру должен был показать checkit, если бы не перехватил int2, а вот такое:
4091 - должен его заставить показать resident, если конечно они уживутся в реальности
привет Троникс а если залить этот биос что ты скомпилил для NEC V20 в обычный поиск с КМ1810ВМ88 (я залил но что-то он не правильно выводит приветствие нету строки F1 - работа с кассетой) у него расскладка клавы как у второй ревизии поисков 1? (то есть с украинской буквой і) ?
Если ты залил BIOS v1.7 бинарь, то он собран для 8088 процессора, без использования V20 команд. Приветствие выводит такое, потому что я выпилил работу с кассетой из BIOS. Раскладка клавиатуры для поздних Поисков, с украинской "i" и еще такая-же "и", только с двумя точками на верху (хз как она называется).Цитата:
Сообщение от Sonic_Blast
а если скомипилитть для В20 а зашить в машину с 8088 будет работать?
у меня есть ХТ-ишка одна из первых моделей она не рассчитана на работу с В20 но я поставил его и все работает))
я так понял что у тебя в этот твой биос вшит драйвер для юзания больше 608кб памяти?
Не будет.Цитата:
Сообщение от Sonic_Blast
Нет.Цитата:
Сообщение от Sonic_Blast
Подниму старую тему чтоб резюмировать. Тут выяснилось что v20 реагирует на NMI не совсем в те моменты как это делал i8088? И таким образом выходит что 2-й символ заносится раньше в память чем того ожидала схема POISK-1?
Если это все правда, то вопрос, можно ли отрубить вообще NMI и выводить графику по таймеру (типа как в эмулях) и сколько потребуется времени для пересчета всего текстового экрана в графический?
NMI отрезать нельзя. На нём вся эмуляция CGA и строится. Любое обращение к памяти или регистрам по адресам видеоадаптера вызывает прерывание, в котором всё отрисовывается в единственном реальном графическом режиме. Поэтому и текстовые режимы так тормозят.
Интересная статистика. Берем проц V20, берем BIOS by Tronix и два Поиска - один 512КБ ОЗУ, второй 128КБ.
Впаиваем панельки, поочередно ставим новый проц и биос и делаем замеры CheckIt
1)Доска 512КБ
http://s019.radikal.ru/i605/1712/69/541bfa1b4c00.jpg
http://s019.radikal.ru/i625/1712/50/c3dad081400c.jpg
2)Доска 128КБ
http://i066.radikal.ru/1712/3c/f474feaf5f31.jpg
http://s014.radikal.ru/i326/1712/c1/289d9da1c860.jpg
Теперь бы понять, почему так происходит.
Отличия в платах в прошивке РТ4 дешифратора адресов памяти и перемычках адресов.
Тоже пытаюсь разобраться. Влияние BIOS можно отбросить, только что запускал систему с родным BIOS и V20. Сквозь рассыпающиеся символы VC смог запустить CheckIt и он показал результат практически аналогичный, с минимальным отставанием.Цитата:
Сообщение от Копейкин
Уже начал думать, что может моя 128я доска какая-то модифицированная. Но вроде никаких следов не заметил. Кварц на 15000, вроде это сток?
UPDATE:
Дальнейшее расследования показало, что в этом неожиданном росте производительности явно замешана организация памяти.
С разными блоками расширения памяти CheckIt показывает разную производительность!
Максимальные результаты, которые я выкладывал выше, получены на "коротком" модуле В109/01 на 512КБ
http://s41.radikal.ru/i094/1712/df/f31b119a4d21.jpg
А когда я менял его на "длинный" модуль В108 (ОЗУ 512Kb + ИРПР-М) то производительность в CheckIt падала
http://s019.radikal.ru/i614/1712/69/e94a6b884efd.jpg
Кварц на 15 МГц штатный, частота процессора 5 МГц.
К сожалению, тест на 128 плате не запустить без платы расширения.
Тогда всё упирается в расширенную память.
В108 использует для регенерации 1810ВТ3, а короткая плата простой метод RAS при активном CAS.
512 плата может выполнять тест из встроенной памяти, конкурирующих с видео.
А 128 плата, скорее всего из внешней. Скорее причина в этом.
У меня тоже такого размера плата на 512 Кбайт, но на 1810ВТ3.
Но нет прошивки РТ4. Интересно прошивки РТ4 одинаковы с этих плат или нет? Может если будете выпаивать РТ4 со своей платы и ставить на панельку, то прошивку предоставите?
http://zx-pk.ru/threads/26450-ozu-51...kr565ru7).html
Когда-то мне купили родители поиск1 и тогда уже не выпускались версии с памятью 128кб а только 512кб (а в DOS по-моему 480кб всего остается). Помню огорчился очень когда узнал что он более тормозной чем более старый вариант со 128кб который был у моего друга (не говоря уже о том что стандартные расширители были только 256кб \ 512кб и при их подключении часть памяти просто не использовалась). А тормоза потому что видеоконтроллер читает экран с той памяти что "на борту" и тормозит процессор если тот лезет (шина то одна). В принципе тоже самое и в zx spectrum где линейка 16кб используется и ULA и процессором. Даже в PCjr таже самая история.
Может кто-нибудь сворганит upgrade на 16кб двухпортовой SRAM, но тогда половина схемы надо перекопать убрать торможение процессора и сделать скрытую регенерацию набортных ру7.
И вот еще немножко бенчмарков касательно V20
Если в XT-IDE залить Биос с расширенными инструкциями (ide_xtp.bin), то скорость прилично так выростает. С обычным 8088 выдает 250КБ/c
http://s019.radikal.ru/i634/1712/61/7f88b1957796.jpg
Да-да, точно также и на V30 в "Поиске-2": с расширенными инструкциями за 600 кб/с переваливает, а со стандартными - около 290 кб/с
Я конечно прошу прощения за оффтоп и некропостинг, но никто случайно не пробовал замену не на NEC V20, а на новодельные софт-процессоры, которые в ПЛИС? Я наткнулся на 2 проекта, Zet и S80186, правда на обоих не хватает некоторых сигналов по сравнению с реалом, но думаю вытащить их будет не очень сложно.
А как заменить 8088 на софт-процессор? Он ведь в ПЛИС синтезируется. Переходник от платы с ПЛИС в панель процессора? Но тогда проще на оценочной плате или Reverse U8/9/16 весь "Поиск" реализовать.
Такой подход весьма популярен в Амигах, но там совсем другая архитектура, позволяющая через процессорное гнездо подключать и быструю память и доп перефирию (ide, scsi, lan и тд) добиваясь многократного увеличения производительности системы.Цитата:
Сообщение от Копейкин
В данном случае даже очень быстрый проц будет зажат медленной шиной и результаты будут весьма скромными. Но все равно можно поиграться )
- - - Добавлено - - -
update:
в свое время Intel выпускала платы Inboard 386 для апгрейда оригинального IBM PC. На плате был 386й проц и память, она втыкалась в ISA и от нее шел шлейф в процессорное гнездо 8088.
https://s.ecrater.com/stores/344506/...8d_344506b.jpg
Можно, конечно, синтезировать сразу связку CPU +FPU.Это даст выигрыш для математики.
PS
Интересное решение. Но у Поиска слоты расширения развязаны с внутренней архитектурой. Сложно будет стыковать такое расширение.
Orchid 286 есть еще, работает по тому же принципу ускорителя,
Находил как-то 8088 на AVR, но проект скорее пруф концепт.