Неправильно. F1 не меандр. И есть нормы на расположение фронтов. Вот официальная замена ГФ24 (выходы инверсные для подключения выходных буферов на 12в):Цитата:
Сообщение от LeoN65816
http://jpegshare.net/images/c4/71/c4...0068a19622.png
Вид для печати
Неправильно. F1 не меандр. И есть нормы на расположение фронтов. Вот официальная замена ГФ24 (выходы инверсные для подключения выходных буферов на 12в):Цитата:
Сообщение от LeoN65816
http://jpegshare.net/images/c4/71/c4...0068a19622.png
У меня на входе 25МГц от видео-части, потому и декадный делитель. И в качестве процессора будет Z80 на 20МГц (или на 10МГц, если потянет узкий фронт такта).Цитата:
Сообщение от LeoN65816
Сейчас очень сильно переработал ТГ, что бы избавиться от возможных глитчей на защёлках видео-выхода. В сухом остатке имею честные 10МГц на корке T80 (в режиме Z80) без WAIT'ов. По копированию из видеопамяти - при ширине банок в 16 бит можно сделать видеовывод из 4-х плоскостей, как в Орион-Про.
https://image.prntscr.com/image/Xehz...T-ycOISthA.png
Так же формирователь видео-сигнала переработал, опираясь на решения в Про-шке, с использованием ИР10, которые гораздо доступнее ИР13. Жду память для тестов на реальных таймингах, скоро уже придёт.
https://image.prntscr.com/image/kUeK...Dbj3ofrExw.png
И сделай. 3/4 плоскостной режим + порт FC (порт покраски экрана константой RGBIRGBI для монохромного режима). Получится так:Цитата:
Сообщение от andreil
Скрытый текст
Код:ОРГАНИЗАЦИЯ ЭКРАННОЙ ПАМЯТИ Orion-PRO, Ориона-128
-------------------------------------------------
Экранная память располагается в 0 и 1 страницах ОЗУ, при-
чем количество экранов и распределение сегментов в них зависит
от текущего цветового режима, задаваемого разрядами порта 0F8H:
D4 D3 D2 D1 D0
------------------
0 x 0 0 0 - монохромный, палитра 1
0 x 0 0 1 - монохромный, палитра 2
0 x 0 1 x - запрет видеосигнала
0 x 1 0 0 - 2-битный (4-цветный), палитра 1
0 x 1 0 1 - 2-битный (4-цветный), палитра 2
0 x 1 1 x - 16-цветный с групповым кодированием
0 1 1 1 x - псевдоцветной (цвет - в порт 0FCH)
1 x 0 x x - 3-битный (8-цветный RGB)
1 x 1 x x - 4-битный (16-цветный RGBI)
Для Ориона-128 то же, но только D0..D2. Режимы от D3,D4 недоступны
В монохромном режиме палитре 1 соответствует комбинация
цветов - (черный, зеленый), палитре 2 - (белый, зеленый). В
4-цветном (2-х битовом) режиме палитре 1 соответствуют цвета -
(черный, синий, зеленый, красный), палитре 2 - (белый, синий,
зеленый, красный).
Код палитры для псевдоцветного режима записывается в порт
с адресом 0FCH.
Выбор на отображение одного из 4-х экранов выполняется пу-
тем записи номера экрана в порт 0FAH:
D0 \ номер экрана
D1 /
D6 - выключение регенерации ОЗУ
D7 - включение широкого экрана
Разряды D2-D5 являются резервными.
Если разряд D7 установлен в единицу, то ширина экрана сос-
тавляет 512 точек (64 байта), что при высоте 256 байт соответс-
твует объему памяти 16 Кбайт. В противном случае экранная плос-
кость ОЗУ имеет ширину 384 точки (48 байт) и занимает объем 12
Кбайт.
В 3-х битном и 4-х битном (EGA-режим) цветовых режимах до-
пускается использование только двух экранов, поэтому разряд D0
порта 0FAH игнорируется.
Рассмотрим распределение сегментов экранного ОЗУ в различ-
ных цветовых режимах.
1.2.3 МОНОХРОМНЫЙ И ПСЕВДОЦВЕТНОЙ РЕЖИМЫ
----------------------------------------
В монохромном и псевдоцветном режимах возможно использова-
ние до 4-х экранов, занимающих только сегменты 0-й страницы
ОЗУ:
Стр.0 Экран 12 К Экран 16 К
--------¬ ------------ ------------
Экран 0 ->¦ 3 ¦ C000H..EFFFH C000H..FFFFH
¦=======¦
Экран 1 ->¦ 2 ¦ 8000H..AFFFH 8000H..BFFFH
¦=======¦
Экран 2 ->¦ 1 ¦ 4000H..6FFFH 4000H..7FFFH
¦=======¦
Экран 3 ->¦ 0 ¦ 0000H..2FFFH 0000H..3FFFH
L--------
В монохромном режиме единичному значению некоторого бита
экранного сегмента ОЗУ соответствует засветка изображаемой точ-
ки, нулевому - гашение.
В псевдоцветном режиме цвет отображаемых точек зависит от
кода палитры, записанного в порт 0FCH. Старшие 4 бита значения
этого порта определяют один из 16 цветов фона (для погашенных
точек), младшие 4 бита - один из 16 цветов переднего плана (для
засвеченных точек).
Заметим, что при широком экране-0 область 0F000H..0FFFFH
экрана (не путать с системной областью 0F000H..0FFFFH) доступна
только через окно. Прямой доступ к экрану возможен только по
адресам 0C000-0EFFFH. Это относится ко всем цветовым режимам.
1.2.4. 4-ЦВЕТНЫЙ РЕЖИМ
-----------------------
В 4-цветном (2-битном) режиме цвет каждой отображаемой
точки зависит от соответствующих битов двух экранных плоскостей
(сегментов), находящихся в страницах 0 и 1 ОЗУ:
Стр.0 Стр.1
--------T-------¬
Экран 0 ->¦ 3 ¦ 7 ¦
¦=======+=======¦
Экран 1 ->¦ 2 ¦ 6 ¦
¦=======+=======¦
Экран 2 ->¦ 1 ¦ 5 ¦
¦=======+=======¦
Экран 3 ->¦ 0 ¦ 4 ¦
L-------+--------
L--¬ ----
0 0 -> черный (белый)
0 1 -> красный
1 0 -> зеленый
1 1 -> синий
1.2.5. 8-ЦВЕТНЫЙ и 16-ЦВЕТНЫЙ РЕЖИМЫ ОРИОН-ПРО
-----------------------------------------------
Это новый графический режим. Функционально он тождествен
EGA режиму на IBM PC AT (был широко распространен на 286 моде-
лях). В 8-цветном (3-битном) и 16-цветном (4-битном) режимах
для формирования отображаемой точки в каждом из двух экранов
используются соответственно 3 и 4 плоскости экранного ОЗУ:
Стр.0 Стр.1
--------T-------¬
¦ 3 (G)¦ 7 (I)¦
Экран 0 ->+-------+-------+
¦ 2 (R)¦ 6 (B)¦
¦=======+=======¦
¦ 1 (G)¦ 5 (I)¦
Экран 1 ->+-------+-------+
¦ 0 (R)¦ 4 (B)¦
L-------+--------
Сегментам 3 и 1 соответствует зеленый цвет (G), 2 и 0 -
красный (R), 6 и 4 - синий (B), 7 и 5 (в 3-битном режиме не ис-
пользуются) - управление яркостью (I).
Путем записи комбинации битов в соответствующие сегменты
экрана можно получить точку заданного цвета.
1.2.6. РЕЖИМ С ГРУППОВЫМ КОДИРОВАНИЕМ ЦВЕТА
-------------------------------------------
В 16-цветном режиме с групповым кодированием каждый из 4-х
экранов формируется из содержимого двух сегментов памяти: из
плоскости изображения (0 страница ОЗУ) и плоскости цветовых ат-
рибутов (1 страница ОЗУ), причем восьми соседним точкам плос-
кости изображения, расположенным в пределах одного байта, соот-
ветствует один байт из плоскости цветовых атрибутов.
Старшие 4 бита в байте цветового атрибута определяют цвет
фона (для погашенных точек), младшие 4 бита - цвет переднего
плана (для засвеченных точек) в пределах одного экранного бай-
та.
Стр.0 Стр.1
(изобр) (цвет)
--------T-------¬
Экран 0 ->¦ 3 ¦ 7 ¦
¦=======+=======¦
Экран 1 ->¦ 2 ¦ 6 ¦
¦=======+=======¦
Экран 2 ->¦ 1 ¦ 5 ¦
¦=======+=======¦
Экран 3 ->¦ 0 ¦ 4 ¦
L-------+--------
Для всех цветовых режимов действует ограничение на исполь-
зование широкого экрана с номером 0, описанное в П.1.2.3.
Следует помнить, что экраны аппаратно привязаны к конкрет-
ным сегментам ОЗУ, а не к окнам, т.е. отображение информации
экрана не зависит от рабочей страницы ОЗУ и включения / выклю-
чения окон.
[свернуть]
Порты F8 и FA делай полными (все по 8 разрядов), т.к. нам еще нужен будет F8.D6 чтобы включать символьный режим экрана и FA.D6..D3 для номера фонта. Позже добавим ПЗУ 27W512 между памятью графики и выводящим графику регистром (половина ПЗУ прошита кодом "вход=выход" {F8.D6=A15}, половина наборами шрифтов {FA.D6..D3}=A14..A11 - выбор шрифта) и зануление младшего адреса видео-ОЗУ в режиме символьного экрана кратное 8/16 (F8.D5=0/1) строкам (чтобы выводить символы из ПЗУ).
Оно то УCЕ охота добавить, а как же несколько платок 100х100:)
На плате с процессором места ДОФИГА...Цитата:
Сообщение от OrionExt
Пока что не разводил, просто прикинул по корпусам. Нужно сперва видео-модуль с реальной памятью проверить, а так же блок с процессором пока что допиливаю - что-то из схемы Z80 Card 2 не так сделал, в итоге кроме TEST128 ничего не работает (testZ80 включает видеорежим 2 и тишина...).
- - - Добавлено - - -
"Полные" порты - не проблема.Цитата:
Сообщение от Error404
Проблема появляется при наличии символьного экрана - или "убить" часть памяти впустую, или сделать адекватный участок под "недоэкран" и на адресацию памяти придётся вешать КП12 (сейчас - КП11). что бы можно было правильно организовать переключение сканируемых участков.
Я за экран с потерями памяти, когда значимыми в видеопамяти являются строки кратные 8 (16). Ну как с потерями, память не теряется (в некратных строках процессор по-прежнему может хранить какие-то данные даже при символьном экране, некратные адреса же надо "занулять" только в цикле обращения видеоадаптера/регенерации). А то, что в 16к получается впихнуть только 1 экран размером 2к (1к) символов, так это плата за то, что эту же схему (а значит и ПО ее поддерживающее) можно "малой кровью" (т.е. не перепахиваю всю плату) реализовать и на обычных Орионах. Совместимость и реализуемость - она дороже красивости единичного специализированного решения ИМХО.Цитата:
Сообщение от andreil
Error404, не торопите автора топика.
Это да, я пока ещё добиваю интеграцию Z80, были косяки в схеме.Цитата:
Сообщение от OrionExt
Вот как добьюсь работы тестов и ORDOS, так и займусь модификацией видео-части.
А по платкам 100х100 - для видео это только на SMD-комплектующих получится, с учётом всех "хотелок" ;) Посмотрим, как оно у меня получится ещё вообще.
У кого есть схемы по Z80-Card-II, киньте их тут ;)
Тест застопорился на RAM protect - никак не могу найти схему для этого узла =/
При переезде на реальный Z80 могут возникнуть трудности. Ведь корка t80 по растактовке далека от оригинала.
Я пробовал еще две корки Z80 с более манием приближенной растактовкой к реалу.
Корка az80. В принципе работает, только у меня не получилось ее разогнать по частоте.
Корка T80pa (модернизированная корка t80). Гонится на ура и растактовка значительно ближе к реалу.
Качество не очень, но все же лучше чем ничего. Клик.Цитата:
Сообщение от andreil
Базовая схема (с ней ты уже разобрался AFAIK):Цитата:
Сообщение от andreil
Скрытый текст
Вот тут чего-то по RAM-protect есть в конце странички (см. вложение этого поста), а также ЕМНИП описано где-то в одном из пунктов в методике из вложения вот этого поста
Да, с этим разобрался. И RAM-protect в этой схеме есть, но тест не проходит этот пункт - буду смотреть причину по графикам...Цитата:
Сообщение от Error404
Вариантов было много. Суть в том, чтобы запретить сигналы /WE на динамических ОЗУ сигналом выборки ПЗУ+В/У. Это сигнал DD8.3/8, он подается на DD29/1 чтобы запрещать буфера ОЗУ. Этим же сигналом надо запрещать и /WE. Т.е при выборке ПЗУ + В/У надо запрещать и вторую половину дешифратора DD29. У меня это сделано вот так. Может и не оптимально, но работало.Цитата:
Сообщение от andreil
Кстати, ещё нужна доработка отключающая ПЗУ и В/У вообще (FULL RAM). Управление этим делается уже не портом FB, а портом FC по биту D6 с помощью ЛИ1 включённого в разрыв цепи на входе DD14.2/13.
Это есть в Z80-Card-II - бит 5 порта FB ;)Цитата:
Сообщение от barsik
А вот за первую часть спасибо - буду пробовать. У меня там часть очень сильно отличается, так что надо думать...
Точно. 20 лет не смотрел на схему Z80CARD-II и всё про неё забыл, т.к пользуюсь вариантом "голый Z80", т.к он более распространён, а Z80CARD-II была нужна только для игр.
Это я просто нашёл какую-то схему, и сам удивился, что там использован порт FC. А сейчас сообразил, что это мой личный вариант отключения ПЗУ+В/У для варианта голый Z80, т.к в моих ОРИОНАХ нет регистра на порт FB, зато стоит ТМ9 на порт FC, которым я переключаю банки ПЗУ (2 банки по 2 кб в виде двух напаянных друг на друга РФ2).
Кстати две банки ПЗУ РФ2 стояли ещё в Z80CARD-I (которая решала цветовую проблему и проблему загрузки OS без ROM-диска). Но т.к это оказалось удобно, то я использовал это и впоследствии. Во второе ПЗУ при использовании DOS в банке 0, я обычно ставлю ПЗУ с фонтом, это позволяет не тратить ценное ОЗУ банки 0. Также второе ПЗУ необходимо для эмулятора РК86 на ОРИОНЕ. Кроме того у меня открыто ОЗУ в области F600...F6FF, что очень удобно (расход 1 вентиль из ЛЛ1).
Кстати, как Вы программно переключаете Турбо/Нетурбо? Стандартов на это кажется не было. Сам я обычно использовал бесплатный STA FB00, не то битом D7, не то D0. Программное или аппаратное переключение в Нетурбо при работе с КНГМД на ВГ93 желательно, а при РК-КНГМД просто необходимо. При 10 МГЦ также надо переключаться на Нетурбо при обращении в порты, иначе ВВ55 не тянут (без WAIT).
А не хотите сделать режим SuperFont 768*256, такой же как в компьютере "Искра-1080 Тарту". Текст с символами 8*10 в этом режиме выглядит отлично, особенно, если отплющить экран заменой кварца с 10 МГЦ на 8 МГЦ, что разворачивает растр на весь экран.
Режим отключения ПЗУ+В/У позволил поднять на 4 кб уровень TPA в CP/M, хотя толку от этого оказалось мало. Для самых мощных компиляторов CP/M требуется TPA в 62 кб, а это можно сделать только перенеся весь код CP/M в другую банку, оставив в банке CP/M только входы в BDOS/BIOS.
Бит 7 порта FB в Z80-Card-II уже занят флагом MZ ;)Цитата:
Сообщение от barsik
Пока что это у меня сделано чисто аппаратно.
По поводу PIO - я вот думаю заменить их теми же ATMEGA8 или ещё чем-либо аналогичным - достать их намного проще, а порт клавиатуры тогда уместиться сразу в 1 корпус. Но это пока что только идея.
Или сделать цепочку формирования WAIT для PIO + ВГ93 - но это сильно позже.
Сильно много видеорежимов - плохо для схемы. И так уже "жирная" получается видео-часть ;)Цитата:
Сообщение от barsik
STA FB00 и OUT (FB),A это разные команды и попадают в разные порты, так что сигнал MZ (mode Z80) не пострадает. STA FB00 (цепь 91) это бесплатный и потому очень удобный строб на запись (т.к для его использования не нужна доп.логика, достаточно добавить лишь сам регистр).
Точно также OUT FC, FD, FE, FF это совсем не то же самое что STA FC00, FD00, FE00, FF00. Т.к в ОРИОНЕ упрощенный дешифратор системных регистров, то STA FC00 это то же самое, что и STA F800. И так далее, - запись на FD00, FE00, FF00 попадает в F900, FA00, FB00. При нужде удобно добавить немного логики и получить ещё 4 строба на запись по STA FC00, FD00, FE00, FF00.
Кстати, по времянкам - INT формируется от кадрового синхроимпульса. В оригинале он 50Гц, но у меня - 60/70Гц (зависит от выхода - 4:3 или 16:9).
Это на что-либо влияет существенно?
- - - Добавлено - - -
Текущий вариант схем в Квартусе:
1) Видео-модуль;
2) Процессорный модуль.
Изменения в схеме очень значительные. по сравнению с оригиналом...
Теоретически, некоторые игры, которые привязаны к прерываниям станут работать немного быстрее.Цитата:
Сообщение от andreil
Хуже, что тогда в ZX-играх, которые для того, чтобы не было мерцаний при движениях спрайтов, двигают их во время гашения по кадрам (во время обратного хода луча), это время гашения сократится. Возможно в некоторых играх возникнут мерцания, но из-за этого не стоит заморачиваться, т.к конвертированных ZX-игр мало, а конверсия все-равно изменила все времянки.
Дома с клавиатурой попробую запустить тест на быстродействие ;)
Так же напаяю панельку для реального Z80 и буду тестить с ним уже. Сегодня-завтра ещё и память будет на руках...
Вопрос по расширению памяти.
Если используется ТОЛЬКО Z80, то коммутация банок памяти идёт всё равно через 2 порта (F9 + FB)?
Просто сижу и думаю, как правильно внедрить расширение памяти, если в каждом банке по 256/512Кб памяти сразу... По схеме расширения для РУ7 - используется только порт F9, то есть оригинальная схема совместима только с ВМ80 и режимом MZ=0 для Z80.
По схеме получается, что нужны сигналы ADDR[16..19] для такого расширения. ADDR[16..17] формируются штатно обоими портами, а вот куда "впихнуть" два старших адреса - не понятно. Для порта F9 всё понятно - заменить его на ИР23 и делов-то. А Вот с FB всё сложнее - там свободны только биты 4 и 7, но поддерживается ли такое софтом? Если его расширять, то для портов FB и F8 будет использоваться ИР35 (нужен регистр с поддержкой сброса, других не нашел в либе).
ИР35 надо, ибо при сбросе должна устанавливаться нулевая банка.Цитата:
Сообщение от andreil
В оригинальной схеме не сбрасывается - там используются обыкновенные латчи без сброса, а все Мониторы при старте сразу прописывают дефолтное значение в порт.Цитата:
Сообщение от Denn
Это о ПРО что ли речь? В Орионе + Z80 кард один бит 4 (резерв для bank select) FB порта в резерве.Цитата:
Сообщение от andreil
Как так, а MB0 и MB1, они выходят наружу.Цитата:
Сообщение от andreil
А так да Z80 кард рассчитана только на 256кБ.
Нет, речь о Z80-Card-II.Цитата:
Сообщение от OrionExt
MB0, MB1 - это и есть ADDR[16..17] для памяти.Цитата:
Сообщение от OrionExt
Плохо, надо бы расширить хотя бы до 512Кб... А для активации 4-ого бита микросхему порта FB так же следует заменить на ИР35 - заодно освободится 1 элемент ТМ2, а порт звука перенесётся на другую ТМ2, где как раз половинка свободная.Цитата:
Сообщение от OrionExt
Точно! Вот это прикол. Схалявили авторы с половинкой ТМ7 :)Цитата:
Сообщение от andreil
По хорошему надо до 512кБ расширить. Там (Z80 кард) кроме замены регистра, надо еще, что то с мультиплексором адреса делать.Цитата:
Сообщение от andreil
Хотя, а надо ли? Софта я не встречал. Х.з.
Самые больные вопросы орионинга :)Цитата:
Сообщение от OrionExt
П.С. допустим, написать софт не проблема... но кому он нужен?
Пытался понять, как это сделано в Орон-Про.Цитата:
Сообщение от OrionExt
Порт F9 там расширен до 4-х бит (D114, ТМ8). Его сигналы мультиплексируются на D36 с данными от BA D80 (порт P8, часть 0 - ADDR[0..1]="00") по сигналу 1C8 (аналог MZ в карте, как понял). И тут встаёт вопрос о совместимости такого решения...
В режиме "Про" результат этого смешения дальше мешается ещё раз - с сигналами от порта P4 (D55). Это нас не интересует :)
- - - Добавлено - - -
Я пока что реализую "нечто", максимально близкое к оригиналу.Цитата:
Сообщение от Denn
Если с Z80-Card не рассчитывалось столько памяти использовать, то её и не будет...
Я бы ориентировался на Орион-ПРО, а не на О-128. Особенно, если планируется Z80. Он более универсальный и более "правильный", имхо. Также есть штатный режим совместимости с "Орион-128" с тактом "ВМ80".Цитата:
Сообщение от andreil
Возможно и так, но по части портов там вообще ужас =/ Почти все собраны на ВВ55, что не очень-то и упрощает понимание работы.Цитата:
Сообщение от Denn
D4 штатно планировался для расширения обслуживаемой диспетчером 16к памяти до 512кб. Однако есть пара НО:Цитата:
Сообщение от andreil
- продолжая критику можно сказать, что "а как же 1024кб?" (я кстати за 1024кб уже в базовом варианте, т.е. 2 ОЗУшки по 512, удобно дающие 2 плоскости "графика/цвет") или "а как же 2048кб" (ОрионПРО ЕМНИП в пределе диспетчерами 16к адресует до 2Mb хотя физически на плате только поддержка для 512). Т.е. сколько ни поставь, всегда будет мало, а потому и штатные 256кб Z80CardII это уже хлеб, особенно учитывая что диспетчер 16кб срабатывает из любой банки включенной портом F9, т.е. даже если у тебя 16Мб ОЗУ (максимум для pF9), то в любой банке к её 60к/64к можно организовать оверлей как минимум еще в 256к портом FB из четырех первых страниц (и я планировал это использовать в UZIX для shared library типа libc.so), или из любой страницы напрямую писать в экран, или "накрыть экран кодом" и комфортно работать в странице 0 включив экран с 0000h.
- по расширению битом D4 достоверно знаю что многие адаптации игр от ZX этот бит ставят некорректно и когда я добавлял в своем эмуляторе эмуляцию этого бита (т.е. расширял диспетчер по 16к на пространство 512кб), они переставали работать. Конечно, это можно отловить и поправить, но надо ли и кто этим будет заниматься? А те игры это и по сею пору едиственное что на Орионе чего-то стоит.
Добавлять порты ПРО наверное можно, если это не сильно загромоздит (придется ставить ВВ55 т.к. по стандарту ПРО из портов еще и читать их состояние можно), но пока весь интересный софт обходится без них.
- - - Добавлено - - -
Что мне в портах ПРО не нравится, так это что они сделали только 3 сегмента по 16к (0000, 4000, 8000). Все другие ПК с похожими режимами делали по 4 окна (+C000), а у ПРО приходится комбинировать и диспетчер по 16к и порт F9 для полной функциональности (что создает ощущение зоопарка и того что проектировщики понятия не имели как они это будут использовать) при этом если у Z80CardII упрощение происходило из предельного аппаратного минимализма, то на аэродроме ПРО с его полутора сотнями корпусов эти недоработки довольно сложно понять.
Есть такая фигня. Однако, они доставаемые, стоят копейки, так что проблемы не вижу. При желании "односторонние" порты (типа джамперов конфига) можно смело заменить на АП6, а линии "только на запись" - на ИР35. Зато получаем отлаженную платформу с корректным Z80 "без секаса", прерываниями, диспетчером и прочими плюшками. Но самое главное, имхо, это конечно 10 МГц и 512к ОЗУ.Цитата:
Сообщение от andreil
Ну, 100% 10МГц у меня уже и так есть :) А вот с портами - да, придётся передирать с Прошки, судя по всему, как и участок с Z80...Цитата:
Сообщение от Denn
Я у себя буду такие ВВ55 ставить на тестовых платках ;)
Тем более. Однако, их паябельность в домашних условиях под вопросом ((Цитата:
Сообщение от andreil
Поверь, паябельность у них высочайшая, по сравнению с привычными мне TQFP с шагом 0,5мм. главное - жало нормальное, 1 с узкой "лопаточкой" для пайки и 1 "игольчатое" для ликвидации соплей.Цитата:
Сообщение от Denn
А тут шаг 0,8 - более чем нормально.
- - - Добавлено - - -
Блин, опять что-то перемудрил в пятницу - Z80-Test опять не принимает диспетчер памяти =/
Есть у кого-либо исходники этого теста, что бы понять как оно должно работать?
Ну, оно даже немного удобно - 1 корпус сразу на 3 порта.Цитата:
Сообщение от Error404
Но если нужна будет скорость, то да - надо ставить те же ИР35 с дополнительными дешифраторами (один на всё, но нужен, хотя бы на мелкой логике, "2-в-4").
Вот схема модуля. Что-то я намудрил и диспетчер в тесте теперь не работает =/ Сверил со схемой карты Z80 - вроде бы всё норм. Остальное норм (ну кроме защиты области, потом добью).
С портами на ВВ55 про честные 10МГц можно забыть. Думаю, даже 82С55 т.е. с индексом С - не потянут. Для этого на ПРО при обращении к ВВ55 вводятся такты WAIT (не помню точно - то ли 4 то ли 8 тактов). Самый главный вопрос - стоит воспроизводить порты (причем с существенными тратами) которыми никто не пользуется?Цитата:
Сообщение от andreil
- - - Добавлено - - -
никогда и не было. только дисасмом еслиЦитата:
Сообщение от andreil
Что за новые сущности в виде сигналов mem_addr_hi[] на элементах inst2,3,54,55?Цитата:
Сообщение от andreil
У Z80 card сигнал RD (DBIN) выходил с инверсией, а сейчас прямой - это далее учитывается?
Сигнал F4xx не учитывает A11 а значит будет активироваться и при обращении к FCxx?
1) В оригинале - это входные сигналы ИД4 для банок памяти, по сути являются ADDR[16..17] из порта.Цитата:
Сообщение от Error404
2) У меня везде только инверсные WRN и RDN используются.
3) Этот участок схемы взят 1:1 с оригинальной схемы, без изменений.
По всем цепям просто дал "нормальные" имена сигналам, вместо непонятного набора цифр. Ну и схему несколько изменил, из-за всех изменений в сигналах, но без изменения логики основных сигналов.