Просмотр полной версии : Реверс-инжиниринг Z80
Чета вообще все просто
полторы штуки рублей цена вопроса для опытов, и можно собирать проц, ну и спек.
Тут можно реализации глянуть (кроме Т80 конечно, он и так всюду есть)
https://github.com/gdevic/A-Z80
не совсем точный z80, но спек запускает точно!
https://github.com/Time0o/z80-verilog
этот не пробовал, но на первый взгляд замороченный, много "двойных" сигналов...
Да, вот еще а дна реализация на верилоге
https://github.com/MiSTer-devel/MegaDrive_MiSTer/blob/main/rtl/nuked-md/z80.v
это звук в MD сделали на ём, говорят очень точная модель, но тоже какая-то замороченная, опять же много двойных сигналов. Похоже это потранзисторная реализация.
это звук в MD сделали на ём, говорят очень точная модель, но тоже какая-то замороченная, опять же много двойных сигналов. Похоже это потранзисторная реализация.
Да, похоже, что списывали с какой-то транзисторной модели. Не знаю, с NMOS или нет, хотя учитывая то, что передают благодарность проекту Visual6502 team, наверное с нашей. А учитывая, что линии не подписаны, переписывали не причесывая схему и не подписывая логику работы.
Странно, что все CLK в схеме только по положительному фронту.
мне там очень непонятны доп.сигналы типа ADDRESS_z. DATA_z, MREQ_z, IORQ_z, RD_z, WR_z - их то куда разруливать, ежели еще где применять ?(:
Повторю:
https://github.com/MiSTer-devel/MegaDrive_MiSTer/blob/main/rtl/nuked-md/z80.v
"тут" два клока: Один основной, а второй как бы моделирует фазы первого (или на оборот). в "нашем" варианте тоже всё можно перевести на "положительный фронт" но за счёт удвоения тактовой...
- - - Добавлено - - -
мне там очень непонятны доп.сигналы типа ADDRESS_z. DATA_z, MREQ_z, IORQ_z, RD_z, WR_z - их то куда разруливать, ежели еще где применять ?(:
*_Z это сигналы обозначающие что на соответствующих "сигналах" якобы присутствует Z-состояние.
- - - Добавлено - - -
https://github.com/gdevic/A-Z80
тамошняя реализация проца достаточно мутная. якобы написанная "по транзисторам", но как-то вообще не понятно. да и автор мутноват - отвечает "типо работает да и ладно" (дело лет 5 назад было)
Я с неё начинал. она вообще не "разгонялась" максимум на 20МГц работало
"тут" два клока: Один основной, а второй как бы моделирует фазы первого (или на оборот)
Где там второй клок?
Титус, а какая конечная цель сего занятия, ковыряния в потрохах з80?
Титус, а какая конечная цель сего занятия, ковыряния в потрохах з80?
Я уже писал об этом в теме.
1. Понять все нюансы работы Z80.
2. Можно эти знания использовать, чтобы сделать точный потактовый эмулятор и/или симулятор.
Где там второй клок?
MCLK, видимо глобальный, 107,39 МГц
ну и собственно CLK - по идее реальная частота работы z80 в собственно MD.
В Т80 (Sorgelig-ом допиленный) похоже сделано. Могу ошЫбаЦЦа.
Алексей конечно не с нуля Т80 делал, на за эти годы многое что допилил в части таймингов, увы, не все...
https://github.com/MiSTer-devel/ZX-Spectrum_MISTer/tree/master/rtl/T80
Поэтому в основном его реализацией пользуются, а не 10-ти летней давности ориг. ядром.
Да, похоже, что списывали с какой-то транзисторной модели. Не знаю, с NMOS или нет, хотя учитывая то, что передают благодарность проекту Visual6502 team, наверное с нашей. А учитывая, что линии не подписаны, переписывали не причесывая схему и не подписывая логику работы.
https://github.com/emu-russia/SEGAChips/tree/main/Z80
"Живите с этим!"
Я уже писал об этом в теме.
1. Понять все нюансы работы Z80.
2. Можно эти знания использовать, чтобы сделать точный потактовый эмулятор и/или симулятор.
Фпга или эмулятор для ПК ?
Фпга или эмулятор для ПК ?
Симулятор - это ФПГА, эмулятор - это ПК.
Простор для творчества большой.
Получается точных эмуляторов не существует, как и симуляторов?
Получается точных эмуляторов не существует, как и симуляторов?
Эмуляторов, думаю, точно не существует.
А симуляторы может быть, если модели были написаны на основе транзисторной схемы от Z80 Explorer'a, на которой и я базировался.
- - - Добавлено - - -
https://github.com/MiSTer-devel/ZX-S...master/rtl/T80
Ааа! Это же не Verilog, a VHDL.
- - - Добавлено - - -
https://github.com/emu-russia/SEGAChips/tree/main/Z80
"Живите с этим!"
Только я все равно не понял, с чего делали.
- - - Добавлено - - -
По мере причесывания схемы, проверяю RS-триггеры, не могут ли они встать 'враскоряку', когда на обоих входах 1, а на выходах, соответственно, будут нули. Один такой триггер нашел. При сочетании ресета, данного во время последнего цикла команды, триггер может на пол-такта как раз так раскорячиться, выдав два нуля. Этот триггер в цепи управления BUSRQ - BUSACK. Впрочем, это третье состояние все равно ни к каким особым последствиям не приводит.
Где там второй клок?
Ну как тот так...
CLK - обычный сигнал
MCLK реальный клок.81282
Еще обратил внимание, что по BUSRQ в высокоомное состояние принудительно переводится только шина адреса.
Шина данных тоже находится в Z-состоянии потому что останавливается выполнение команды.
А вот шины управления /MREQ,/IORQ,/RD,/WR умеют отключать только верхние транзисторы, а нижние не отключаются, и чтобы шина управления была в Z-состоянии, процессор должен подать на эти линии единички. Впрочем, так и получается, т.к. выполнение команды останавливается. Хотя, надо внимательно посмотреть, нет ли команд, у которых между M-циклами остается активной хотя бы одна из вышеописанных линий.
Barmaley_m
13.09.2024, 00:24
Еще обратил внимание, что по BUSRQ в высокоомное состояние принудительно переводится только шина адреса.
В FPGA можно использовать высокоомное состояние, но только на внешних выводах. Для этого их надо подключать через специальные блоки (tri-state buffer) и отдельно подавать на них сигнал управления, включающий или отключающий выходные транзисторы. Впрочем, возможно, что компилятор FPGA может и сам понять, что человек хочет сделать выводы с третьим состоянием, и автоматически включить эти буферы и логику управления ими в схему.
Тут кинули вот такую ссылку работы команд, можешь разъяснить как оно там в реале?
https://spectrumcomputing.co.uk/forums/viewtopic.php?t=10555
HardWareMan
13.09.2024, 10:51
Только я все равно не понял, с чего делали.
С собственного декапа. Это же в рамках Сеги было сделано командой Эмураша. Я, правда, не участвовал, только советовал всякое и консультировал.
Вопрос вероятно был NMOS или CMOS ?
С собственного декапа. Это же в рамках Сеги было сделано командой Эмураша. Я, правда, не участвовал, только советовал всякое и консультировал.
Если делали собственное, чего же они не опубликовали в виде транзисторной схемы или чего-то подобного?
- - - Добавлено - - -
Вопрос вероятно был NMOS или CMOS ?
И это тоже.
- - - Добавлено - - -
Тут кинули вот такую ссылку работы команд, можешь разъяснить как оно там в реале?
https://spectrumcomputing.co.uk/forums/viewtopic.php?t=10555
Блочные команды inir/indr/otir/otdr пока не разбирал.
HardWareMan
13.09.2024, 11:47
Вопрос вероятно был NMOS или CMOS ?
Если делали собственное, чего же они не опубликовали в виде транзисторной схемы или чего-то подобного?
Эм... Там есть https://github.com/emu-russia/SEGAChips/tree/main/Z80/netlist, открывайте его Дероутом (в соседней репе). А на главной в этой репе есть вот:
https://i.postimg.cc/pX1KmzRp/image.png
А там...
https://i.postimg.cc/8Pqj8HTB/image.png
Я херею с вас, дорогая редакция...
PS Часть инфы на личной репе одного из участников группы. https://github.com/nukeykt/
Я херею с вас, дорогая редакция...
Могли бы хоть подсказать, кто в теме, что кто-то уже это делал и публиковал.
- - - Добавлено - - -
Если это Z84C00, значит он CMOS?
- - - Добавлено - - -
Судя по датам - 2023 год, это было сделано совсем недавно.
- - - Добавлено - - -
По ПЛИСам еще такой вопрос.
Как поступить в случае, когда какие-то триггеры тактируются фронтом не глобального CLK, а каким-то другим сигналом, например, T1 (им тактируется счетчик фаз M1, M2 и т.д.). Такое нормально?
- - - Добавлено - - -
Как правильно сделать, вот так:
always @(posedge T1) begin
...
end
Либо же во так:
always @(posedge clk) begin
if (T1 = 1) begin
...
end
end
HardWareMan
13.09.2024, 13:13
Судя по датам - 2023 год, это было сделано совсем недавно.
Верно. Буквально осень 2023 - весна 2024. А модельки тестировались на экзорцисте. Там и М68К тоже свой, кстати. Хотя изначально брали сторонний.
- - - Добавлено - - -
Как правильно сделать, вот так:
always @(posedge T1) begin
...
end
Либо же во так:
always @(posedge clk) begin
if (T1 = 1) begin
...
end
end
Первый верный, будет чёткий posedge. А второй не верный, особенно, если CLK > T1 то условие будет стрелять несколько раз. Если CLK < T1 то вообще работать не будет. Так надо делать если ты пишешь общий дизайн, тактируемый повышенной частотой (например, 50МГц).
Там и М68К тоже свой, кстати.
Вот это круто. Может и клон амиги сделают наконец)
- - - Добавлено - - -
А второй не верный, особенно, если CLK > T1 то условие будет стрелять несколько раз.
Несколько раз не будет, потому что T1 синхронен с CLK и имеет длительность импульса равную ровно одному периоду CLK.
В идеальном дизайне будет только вот такое
always @(posedge clk)
и надо стремиться к такому виду...
пс: это если речь идёт о "работе" по фронтам сигнала-клока.
и надо стремиться к такому виду...
пс: это если речь идёт о "работе" по фронтам сигнала-клока.
Но в моем случае, когда надо по фронтам T1 получить M1,2,3 - что лучше будет?
Для какого "куска" на схеме.pdf ?
ПС к сожалению смогу ответить не раньше воскресения..
Малость теории.
Пусть есть клок CLK и по его фронту некий тригер запоминает сигнал. По оному сигналу (выход триггера) формируется на логике некий сигнал фронт, которого "нам нужен" для формирования чего либо. И если вот это "что либо" должно появиться к следующему фронту CLK, то делаем однозначно так
always @(posedge clk) begin
if (T1 == 1) begin
А если "что либо" используется "через следующий" фронт, то применяется ClockEnable методика. по сути это "накрывашка" на нужный фронт тактовой, когда "T1" имеет актуальное значение.
always @(posedge clk) begin
if ((T1 == 1) & CE) begin
Для какого "куска" на схеме.pdf ?
Вот для этого фрагмента (кстати, я его уже переписал на полностью синхронные триггеры):
https://pic.maxiol.com/images2/1726231892.2997897951..png
RES_TCLK равна последнему такту в команде, например, T4. А Т4 синхронно с CLK и длится один период CLK.
|-----| - T4
|__|--| - CLK
RES_MCLK равна последнему циклу в команде, например M2, и тоже синхронна с CLK.
- - - Добавлено - - -
Проще на графике посмотреть:
https://pic.maxiol.com/images2/1726232331.2997897951..png
Вот для этого фрагмента ...
always @(negedge CLK) begin
if (RES_TCLK) begin
M1 <= RES_MCLK;
M2 <= U30_out;
M3 <= U31_out;
end
end
always @(negedge CLK) begin
То есть все же лучше тактироваться по CLK, чем по выходу U263? Почему?
То есть все же лучше тактироваться по CLK, чем по выходу U263? Почему?
Это я предложил вариант (не уверен что лучший), где только один клок и работаем и по переднему, и по заднему фронту, при этом не увеличиваем тактовую. А сигналы тактирующие другие триггеры заменяем на аналоги CS и EN.
Почему тактировать от U263 не лучше - я не скажу, так как не спец. Выше вроде пытались разъяснить.
P.S. Изучал тут проект Breaknes, так вот там есть изначальная verilog-модель и APU, и PPU на защёлках и прочем, с тактированием от всего подряд. А в конце уже синхронная (тут на форуме выкладывалась) на частоте х12 от частоты проца. Может сначала всё-таки перенести в верилог модель z80 как есть, со всеми защёлками, а потом её уже причесать под один клок?
Может сначала всё-таки перенести в верилог модель z80 как есть, со всеми защёлками, а потом её уже причесать под один клок?
Нет смысла делать двойную работу.
Может и клон амиги сделают наконец)
А что с ним не так??? в ФПГА как бы давно есть
А что с ним не так??? в ФПГА как бы давно есть
Потактово точный, основанный исключительно на реверсе всех чипов, от процессора до кастомных чипов.
Вот для этого фрагмента (кстати, я его уже переписал на полностью синхронные триггеры):
Разобрался с этим фрагментом, скорректировал, вопросов по нему больше нет)
Малость теории.
1) В плисах есть два типа сигналов: дата и тактовый. они разводятся каждый по своим дорожкам. Дата условно "абы кабы". Тактовый по своим "чтоб тактовый был там где надо вовремя" (очень условное описание). Дата - потому что длина цепей относительно мала, а тактовые по всей плисе на тысячи триггеров "одновременно".
2) К примеру асинхронный счётчик на Д-триггере
https://studfile.net/html/2706/245/html_ihso6NxaDx.cp7Z/img-7f5rW6.png
его быстродействие равно длительности распространения от первого C до последнего Q. Пока сигнал "бежит" - выход счётчика может принимать все фантастические значения. А если по этим выходам формируются "обратные связи" на эти же триггера - результат вообще не предсказуемый.
Посему делают только синхронные счётчики - это на С поступает только тактовый сигнал. на Д - через "внешнюю логику, описывающую поведение счётчика".
Другой случай когда на тысячу триггеров заводят "тактовый с выхода Q" - а так как он будет разводится абы кабы (однако есть способы как сделать более правильно - но это будет "грязно выглядеть") - то и поведение такой схемы будет "очень волшебным", а быстродействие упадёт на порядок другой...
Сиё максимально упрощённое описание...
ПС: Особый кайф, это когда берут выход условной К155ЛР3 и подают на С-вход. Пока логика устаканится - выход 100500 раз поменяет своё значение - а триггер (или даже синхронный счётчик) всё ЭТО посчитает... 8-0
HardWareMan
14.09.2024, 22:29
AlexG, всё верно. И именно поэтому надо смотреть в условный TimeQuest на Clock Skew или хотя-бы Fmax чтобы понимать, что фиттер положил насинтезированное так, что задержки укладываются в твой такт. Тогда проект будет работать на всех указанных тобой чипах в любых условиях, а не глючить в зависимости от фазы луны и желанию твоей левой пятки.
https://i.postimg.cc/zfkj5k7Q/image.png
Побольше синих и отсутствие красных. И ещё, если попытаешься комбинаторику в такты зарулить без правильного преобразования оно тебе прокричит про ripple clock.
И ещё, если попытаешься комбинаторику в такты зарулить без правильного преобразования оно тебе прокричит про ripple clock.
Что такое 'правильное преобразование'?
HardWareMan
15.09.2024, 09:38
Что такое 'правильное преобразование'?
Есть несколько методов разного рода, когда действительно надо сформировать вторичный тактовый домен. Например, синхронизация через общую тактовую частоту. Но чаще проще просто оставаться в одном тактовом домене используя условия. Тогда при правильном описании синтезатор сам вместо муксов заюзает специальный сигнал ENA.
https://i.postimg.cc/CxPShJpQ/image.png
PS В самом примитивном варианте, такты должны выходить из триггера. Точка.
В общем, что касается правильного тактирования схемотехнически, мне все более-менее понятно.
В плане реализации этого на Verilo'е могут быть вопросы, но это спрошу, если понадобится.
п.с.: Никто так и не заметил, что я накосячил, и случайно обьединил все 8-битные половинки регистров в 16-битные, из-за чего нельзя записывать половинки) Ну да, кому нужны схемы-то) Всем нужна готовая модель или эмулятор) Или какие-то вскрытые тайны и особенности простым языком)
такие вещи взглядом не заметишь. Это как программа написанная, но ни разу не скомпилированная. Смотришь вроде все правильно, а начнешь компилировать и дебажить и вылезут ошибки.
такие вещи взглядом не заметишь. Это как программа написанная, но ни разу не скомпилированная. Смотришь вроде все правильно, а начнешь компилировать и дебажить и вылезут ошибки.
Да, я думаю, если сконвертировать на верилог текущее состояние логической схемы (не транзисторной, с ней на 99.999% все ок), то это сразу не заработает)
Barmaley_m
17.09.2024, 21:08
Как поступить в случае, когда какие-то триггеры тактируются фронтом не глобального CLK, а каким-то другим сигналом, например, T1 (им тактируется счетчик фаз M1, M2 и т.д.). Как правильно сделать, вот так:
always @(posedge T1) begin
...
end
Либо же во так:
always @(posedge clk) begin
if (T1 = 1) begin
...
end
end
Однозначно второй вариант. По возможности надо делать так, чтобы все триггеры схемы тактировались одной частотой. Если какие-то части схемы работают на половине или других долях от этой частоты - то следует использовать вход триггеров Clock Enable (CE), описав его на HDL в виде команды if, наподобие твоего второго варианта, для достижения поставленной цели.
Деление тактовой частоты триггером и использование результата для тактирования какой-то части схемы имеет следующие недостатки:
1) Расходуются глобальные тактовые буферы (в примере Spartan6 - BUFG)
2) Поделенная тактовая частота будет из-за задержек элементов схемы и разводки выхода триггера на тактовый буфер и обратно сдвинута по фазе относительно исходной. Эти сдвиги затронут также все сигналы от триггеров, работающих от половины тактовой частоты. Все эти задержки будут отниматься от "бюджета времени" при переходе сигналов данных от триггеров, тактируемых полной тактовой частотой, на триггеры, тактируемые ее половиной, и обратно. В результате будет труднее обеспечить выполнение Timing constraints, снизится максимальная тактовая частота проекта.
Если какие-то части схемы работают на половине или других долях от этой частоты - то следует использовать вход триггеров Clock Enable (CE),
До того, как Hardwareman про это написал, я не знал, что у триггеров в ПЛИС есть входы разрешения тактирования. Так-то оно конечно, логичнее. Другой вопрос - на всех ли современных ПЛИС у триггеров есть входы CE?
- - - Добавлено - - -
1) Расходуются глобальные тактовые буферы (в примере Spartan6 - BUFG)
Сколько их в среднем бывает?
И прям на каждый клок триггера расходуется свой буфер, если клок не совпадает с уже имеющимися?
- - - Добавлено - - -
Вот в этом примере что, на каждый следующий каскад расходуется глобальный тактовый буфер?
https://studfile.net/html/2706/245/html_ihso6NxaDx.cp7Z/img-7f5rW6.png
1) У всех xilinx ( упоминал ранее UG768 v14.7) есть CE у триггеров.
2) К примеру плиса о 200 выводов 53200 LUT (универсальная логика) + 106400 FF (триггера) имеют всего 32 BUFG (глобального буфера для распределения тактовой).
3) зависит от настроек "компилятора" (наверное - я такое не практикую от слова совсем. посмотрел один раз на результат - ужаснулся, перекрестился, сплюнул три раза и зарёкся ТАК делать).
ПС: не надо заморачиваться специально про СЕ. Достаточно писать
always @(posedge clk) begin
if (T1 == 1) begin
....
синтезатор "сам придумает" схему как сделать лучше (через СЕ или через комбинационную схему или ...). Конечно есть специальные "указания/прагмы/аттрибуты" которые указавают КАК хочется автору (но это надо иметь экспириенс от 58).
----------------------------------------
Триггеры:
FDCE Primitive: D Flip-Flop with Clock Enable and Asynchronous Clear
FDPE Primitive: D Flip-Flop with Clock Enable and Asynchronous Preset
FDRE Primitive: D Flip-Flop with Clock Enable and Synchronous Reset
FDSE Primitive: D Flip-Flop with Clock Enable and Synchronous Set
3) зависит от настроек "компилятора"
Это ответ на какой вопрос?
"каждый следующий каскад расходуется глобальный тактовый буфер?" - наверно зависит от настроек "компилятора" .
НО Я ТАК НИКОГДА НЕ ДЕЛАЮ (как на рисунке) - за это пожизненный эцих с гвоздями.
HardWareMan
18.09.2024, 13:45
Однозначно второй вариант. По возможности надо делать так, чтобы все триггеры схемы тактировались одной частотой. Если какие-то части схемы работают на половине или других долях от этой частоты - то следует использовать вход триггеров Clock Enable (CE), описав его на HDL в виде команды if, наподобие твоего второго варианта, для достижения поставленной цели.
Деление тактовой частоты триггером и использование результата для тактирования какой-то части схемы имеет следующие недостатки:
1) Расходуются глобальные тактовые буферы (в примере Spartan6 - BUFG)
2) Поделенная тактовая частота будет из-за задержек элементов схемы и разводки выхода триггера на тактовый буфер и обратно сдвинута по фазе относительно исходной. Эти сдвиги затронут также все сигналы от триггеров, работающих от половины тактовой частоты. Все эти задержки будут отниматься от "бюджета времени" при переходе сигналов данных от триггеров, тактируемых полной тактовой частотой, на триггеры, тактируемые ее половиной, и обратно. В результате будет труднее обеспечить выполнение Timing constraints, снизится максимальная тактовая частота проекта.
В общем и целом я полностью согласен - один законченный IP блок должен быть запитан от одной тактовой частоты, чтобы однозначно уложить его в прогнозируемые тайминги. Но бывают случаи, когда просто необходимо разделять тактовые домены. Например, из самого редкого это вот такой, есть у меня в модуле работы с FT245R:
https://i.postimg.cc/TYKcwmTw/image.png
Он собирается вот так:
https://i.postimg.cc/DyRPbZzc/11.png
https://i.postimg.cc/jSNQ6bwY/22.png
Смысл: использование nRD как такты для регистра хранения данных на шине данных гарантирует наличие актуальных данных в самый последний момент, как того гласит датащит. То же самое касается и сэмплирования сигнала TDO у JTAG: его следует синхронизировать именно к результирующему TCK, который по факту выходит наружу.
Ну и в конце концов разные IP могут работать на разных тактовых частотах, чтобы сэкономить несколько регистров и PIA, например. Поэтому, нужно просто подходит с умом и осознанно. С учётом синхронизации сигналов при переходе в другой тактовый домен. Ну а что касается вышеупомянутого асинхронного счётчика то это не для ПЛИС. Забудьте про 555ИЕ5, 555ИЕ10 должен быть ваш выбор.
Barmaley_m
18.09.2024, 19:50
имеют всего 32 BUFG (глобального буфера для распределения тактовой).
32 BUFG - это еще много. По-моему вся серия Spartan6 имеет только 16 BUFG. Но это не такое страшное ограничение, как может показаться. Даже в крупных проектах хватает за глаза. Не надо только без серьезной необходимости тактировать триггеры разной частотой.
В моем большом проекте использовались следующие крупные области с разной тактовой частотой:
1) Процессор и основная периферия, а также внутренние шины - 80 МГц
2) Спец интерфейс - 960МГц (самые внешние его блоки ISERDES2), а связанная с ними FPGA-логика - 120МГц
3) Ethernet MAC (та его часть, которая непосредственно связана с интерфейсом GMII) - 125МГц
Если бы я использовал интерфейс HDMI - то там бы была еще область 1080МГц (для ISERDES2/OSERDES2). и 135МГц для "нормальной" связанной с этим FPGA-логики.
В том чипе, с которым я работал, частоту выше 80МГц для основной схемы использовать не удавалось - ругался компилятор из-за расхождения Timing Constraints. На относительно высоких частотах в моем проекте (120 и 125МГц) работали только небольшие части всей схемы, где данные частоты были обусловлены требованиями к интерфейсам ввода-вывода.
Не надо только без серьезной необходимости тактировать триггеры разной частотой.
Что делать, если выход одного триггера является тактовым сигналом для некоторых последующих участков схемы в данном процессоре.
Но я уже понял, что там, где возможно, использовать CE для разрешения CLK.
Что делать, если выход одного триггера является тактовым сигналом для некоторых последующих участков схемы в данном процессоре.
По CLK защёлкиваем предыдущее значение и формируем сигнал CE логикой: CE = (Q AND NOT Qprev)
HardWareMan
19.09.2024, 13:57
Перепад ловится обычным синхронизатором:
https://i.postimg.cc/FHL81xsN/image.png
Понятное дело, что CLK должно быть как можно выше, скорости смены уровней на DAT. Фронт или спад ловится соответствующим заданием инверсии у логического И.
Всего в процессоре 14 16-битных регистров.
забыл про SP, два IFF1|2 и ещё момент где храниться какой IM (режим прерывания) вкл?
два IFF1|2 и ещё момент где храниться какой IM (режим прерывания) вкл?
В соответствующих защелках) Все расписано на схеме, если ее открыть)
из интересного (http://www.primrosebank.net/computers/z80/z80_special_reset.htm)
из интересного (http://www.primrosebank.net/computers/z80/z80_special_reset.htm)
Да, это известная вещь.
И действительно оно так и работает, судя по схеме.
Titus у тебя есть ТГ, можешь в лс (https://t.me/DeadlyKom) постучаться?
Titus у тебя есть ТГ, можешь в лс (https://t.me/DeadlyKom) постучаться?
Все вопросы лучше задавать публично, здесь, если они относятся к теме. А если нет, то в личку на форуме.
из интересного (https://floooh.github.io/2021/12/06/z80-instruction-timing.html)
- - - Добавлено - - -
форум это очень медленно, мне нужна оперативность общения, по теме но в большей степени, в любом случае печально это видеть
из интересного
Судя по описанию, человек анализировал работу симулятора извне, не понимая логики работы системы изнутри, и не приводя в логическую схему.
Судя по описанию, человек анализировал работу симулятора извне, не понимая логики работы системы изнутри, и не приводя в логическую схему.
это не шибко важно, там достаточно неплохо расписаны команды, что позволит мне опираться на эти знания
- - - Добавлено - - -
всё достаточно неплохо, есть вопросы конечно, но думаю найду и на них ответы из других блок схем и диаграмм сигналов
про "специальный RESET" лет 10 как известно, даже в эмуле есть. В специальном.
Вот кратенько по годам, что-когда раскопали:
* 2006 - [MEMPTR](https://zxpress.ru/zxnet/zxnet.pc/5909)
* 2012 - [Q: Zilog](https://worldofspectrum.org/forums/discussion/41704)
* 2014 - [Special Reset](https://github.com/redcode/Z80/wiki/Z80-Special-Reset)
* 2018 - [Additional flag changes of the block instructions](https://github.com/hoglet67/Z80Decoder/wiki/Undocumented-Flags)
* 2018 - [Q: NEC / ST](https://github.com/hoglet67/Z80Decoder/wiki/Undocumented-Flags)
* 2021 - [`reti` and `retn` reject INT when IFF1 != IFF2](https://floooh.github.io/2021/12/17/cycle-stepped-z80.html#the-ei-di-and-retiretn-instructions)
* 2022 - [MEMPTR during the additionaal flag changes of `otir` and `otdr`](https://github.com/hoglet67/Z80Decoder/issues/2)
* 2022 - [NMI rejection](https://spectrumcomputing.co.uk/forums/viewtopic.php?t=7086)
* 2023 - [MEMPTR during the additional flag changes of all I/O block instructions](https://spectrumcomputing.co.uk/forums/viewtopic.php?t=10555)
* 2024 - [Unstable flag behavior of `ccf` / `scf`](https://github.com/hoglet67/Z80Decoder/wiki/Unstable-CCF-SCF-Behaviour)
Если в ноере такта присутствует точка (T1.1 или T1.2), это означает, что имеется в виду 1-й или 2-й полутакт.
Номер полутакта может быть больше 2 вследствие прохождения сигналом промежуточных триггеров. Например, T1.3 обозначает третий полутакт от начала такта T1. Не смотря на то, что по времени он может совпадать с T2.1, правильнее обозначать его именно T1.3, т.к. он инициирован тактом T1.
В первом цикле любой команды в такте Т1.1 активны сигналы READ_PCR и SEL_PC, по которым регистр PC читается из регистрового файла и записывается в регистр PCR.
В такте T1.2 регистр PCR записывается в регистр адреса REG_ADR, содержимое которого выставляется на шину адреса AB0..15.
В этом же такте инкрементированное значение PCR записывается в регистр PCR2.
По переднему фронту такта T1.3 (T2.1) устанавливаются сигналы MREQ и RD, выдавая внешней схеме запрос чтения памяти.
Также в такте T1.3 (T2.1) происходит запись регистра PCR2 обратно в регистр PC.
По переднему фронту такта T2.2 устанавливается сигнал DP_DL, по которому данные с DB0..7 через шину DLATCH0..7 записываются в регистр REG_DATA.
По переднему фронту такта Т2.3 (Т3.1) устанавливается сигнал LOAD_IR, по которому данные с шины DBUS0.7 записываются в регистр команды REG_COMMAND. При этом в течение такта T2.3 (T3.1) на шине DBUS0..7 удерживается ноль.
Также в этом такте активны сигналы READ_PCR и SEL_IR, по которым регистр IR читается из регистрового файла и записывается в регистр PCR.
По переднему фронту такта Т3.2 снимается сигнал DP_DL, прекращая запись внешних данных в регистр REG_DATA.
В такте Т3.2 на шине DBUS0..7 появляется значение регистра REG_DATA и остается там до следующего такта T2.2.
Так же в этом такте данные с шины DBUS0..7 продолжают записываться в регистр REG_COMMAND.
Фактически фронт T3.2 - это момент защелкивания данных с шины DB0..7 в регистре REG_COMMAND.
Таким образом, с момента выставления сигнала RD и до момента защелкивания данных в REG_COMMAND отводится чуть менее 1.5 тактов.
В этом же такте регистр PCR записывается в регистр адреса REG_ADR, содержимое которого выставляется на шину адреса AB0..15.
В этом же такте инкрементированное значение PCR (инкрементируются младшие 7 бит) записывается в регистр PCR2.
В этом же такте сбрасывается сигнал MREQ.
По переднему фронту такта T3.3 (T4.1) сбрасывается сигнал LOAD_IR, прекращая запись регистра REG_DATA в REG_COMMAND.
В этом же такте происходит запись регистра PCR2 обратно в регистр IR.
В этом же такте устанавливается сигнал MREQ,
По переднему фронту такта T4.3 (T5.1) сбрасывается сигнал MREQ.
Таким образом, длительность цикла чтения - 1.5 такта (и более, если активен WAIT), длительность цикла регенерации памяти - 1 такт.
почему то RFSH не указан
почему то RFSH не указан
Что значит почему? )
На диаграмме указан)
Все, что интересно, можно посмотреть по схеме. Я рисую графики смотря на схему) И вы так сможете, я верю в вас)
Все, что интересно, можно посмотреть по схеме. Я рисую графики смотря на схему) И вы так сможете, я верю в вас)
назвался груздём, ....
не всегда понимаю твою логику, ты выложил диаграмму, мол смотрите, ок принимается.
дублируешь текстом, но в тексте упущены важные сигналы, о чём упоминул.
реакция, ну типа, смотри туда, а на текст не смотри! так получаетс?
назвался груздём, ....
Никуда я полезать не собираюсь)
- - - Добавлено - - -
не всегда понимаю твою логику, ты выложил диаграмму, мол смотрите, ок принимается.
Я выкладываю фрагменты диаграмм и описаний для привлечения внимания интересующихся лиц.
И для того, чтобы люди могли ознакомиться в ОБЩЕМ, как процессор работает.
А диаграммы работы всех команд я составлять не собираюсь)
А диаграммы работы всех команд я составлять не собираюсь)
моё почтение...
Основная проблема подобных проектов - это то что автор зачем-то пытается "понять" как оно работает. Это является основным тормозом, в результате чего проект может длиться годами. Так и у нас было.
Но потом оказалось что достаточно получить netlist, а понимать вовсе не обязательно. Ведь полученные результаты рано или поздно захотят практического применения (программный эмулятор / HDL реализация), а если делать точно, то оно и будет работать как исходная схема и то что ты "понял" как оно работает никакой пользы не доставит. Главное понимать как в целом логика работает - основные приёмчики, подходы к реализации (регистры, счётчики, автоматы), а распутывать лапшу комбинаторно-последовательной логики это бессмысленно и беспощадно. Но не могу запретить автору продолжать, читаем с интересом.
Основная проблема подобных проектов - это то что автор зачем-то пытается "понять" как оно работает.
Я люблю понимать суть процессов)
Без точного понимания невозможно с материалом ничего сделать интересного. Только клонировать, да и там можно ошибиться, именно из-за того, что не понимаешь нюансов.
Кроме того, представьте себе программный эмулятор, эмулирующий на уровне вентилей? Это сверхизбыточность.
Также, понимание сути позволяет найти скрытые нюансы, ошибки, неизвестные подводные камни. Это все очень интересно.
Видимо, тут говорит мой дух хакера и оптимизатора)
- - - Добавлено - - -
Так и у нас было.
У нас - это у кого, и с каким проектом?
- - - Добавлено - - -
в результате чего проект может длиться годами.
Тут могу согласиться)
У нас - это у кого, и с каким проектом?
Наши приключения с фамиком:
https://github.com/emu-russia/breaks
https://github.com/emu-russia/breaknes
А вот пример чего можно добиться за месяц, без особого "понимания":
https://github.com/nukeykt/Nuked-MD
https://github.com/nukeykt/Nuked-MD-FPGA
Рекомендую таки сделать нетлист и проект сразу завершится. "Понимать" можно не вдумчиво вглядываясь в вентили, а анализируя вейвы при прогоне модели HDL в том же Icarus Verilog + GTKWave.
Рекомендую таки сделать нетлист и проект сразу завершится. "Понимать" можно не вдумчиво вглядываясь в вентили, а анализируя вейвы при прогоне модели HDL в том же Icarus Verilog + GTKWave.
Это будет опять же наблюдение за последствиями извне, не понимая причин.
Как, например, преобразовать схему в синхронную, избавиться от проходных буферов (обьединяющих две шины) не понимая всех нюансов работы?
Да и чтобы найти какую-то хитрую ошибку во флагах, нужно начинать изнутри, а не 'тупо' перебирать все комбинации, наблюдая за последствиями снаружи, вдруг чего попадется интересного.
- - - Добавлено - - -
Думаю, что K-MOS-овская версия Z80 в этом плане попроще, т.к. посовершеннее.
Ну не знаю, как ещё лучше донести мысль что иметь на руках нетлист гораздо полезнее чем "из одной картинки делать другую" (из фото чипа - картинку схемы).
CMOS Z80 уже на подходе, скоро будет купаться в кислоте, думаю в эти выходные.
скоро будет купаться в кислоте, думаю в эти выходные.
мб через тебя полуиться получить ответы по работе з80, которые у меня назрели
мб через тебя полуиться получить ответы по работе з80, которые у меня назрели
Через меня вряд ли быстро получится, т.к. я планирую реверсить только блоки с кастомным дизайном (АЛУ предположительно CLA, а также блок регистров).
Остальным будет заниматься nukeykt
Купаемый в кислоте CMOS з80 - это от тошибы: https://siliconpr0n.org/map/toshiba/t84c00am-8-crop/marmontel_mz_gf50x-1.25/ (Фотки сделаны Борисом onidev, но только металл, чего нам не достаточно).
У меня есть в процессе восстановления масок "другой" CMOS Z80, родной зилоговский (https://github.com/emu-russia/SEGAChips/tree/main/Z80), но пока им заниматься лень. С ним не очень гладко всё прошло, delayer получился очень "грязный".
Через меня вряд ли быстро получится
ты как и титус только через форум, или можно связаться в ТГ ?
CMOS Z80 уже на подходе, скоро будет купаться в кислоте, думаю в эти выходные.
В смысле на подходе? А из чего же тогда отреверсен Z80, который используется в проекте Сега?
- - - Добавлено - - -
Ну не знаю, как ещё лучше донести мысль что иметь на руках нетлист гораздо полезнее чем "из одной картинки делать другую" (из фото чипа - картинку схемы).
Я думаю, все зависит от цели. Если цели утилитарные, повторить в ФПГА в каком-то конкретном проекте, то может быть.
ты как и титус только через форум, или можно связаться в ТГ ?
Заходи в дис ему раша https://discord.gg/BMNEQWnDpW
А из чего же тогда отреверсен Z80, который используется в проекте Сега?
выше пост с инфой.
выше пост с инфой.
Я не совсем понял. Если с тем прошло не все гладко, то как из него получилась FPGA-версия?
Заходи в дис ему раша https://discord.gg/BMNEQWnDpW
уже там!
ЕМНИП nukeykt реверсил NMOS версии 68к и z80. Cmos версии более совершенны по дизайну, вот их и захотели копнуть. Нюк обещал даже в логисиме модельку Z80 зарисовать. Можно будет потыкать в нее палкой, аналогичным образом как это было с MOS 6502. В NMOS дизайне очень много интересных мест, например те же двусторонние соединения между шинами. В транзисторах эти PASS FETы выглядят примитивно, однако это доставляет при описании и переводе всего этого добра в синхронный дизайн ПЛИС. Я немало времени потратил на шины нмос 6502 год назад, работая над его синхронным дизайном. Тут к сожалению без понимания как оно работает не обойтись. Хотя при программной симуляции наверное это все можно описать достаточно простым способом.
Я не совсем понял. Если с тем прошло не все гладко, то как из него получилась FPGA-версия?
nukeykt перегонял NMOS версию, вроде как ту же самую что и ты ковыряешь =)
CMOS Z80 тоже хотим (точнее хочет nukeykt), т.к. делать больше нечего, все чипы сэги "декомилированы". Есть ещё правда сэга ЦД, но она нафиг никому не нужна, хотя ХВМ и засылал под неё чипы. Пока интереса ни у кого нет реверсить эту лажу)
CMOS Z80 тоже хотим (точнее хочет nukeykt)
Было бы интересно. Тем более, что некоторые особенности работы, которые описывают на форумах, например, непонятное поведение флагов 5 и 3 после команд SCF и CCF, на NMOS не прослеживаются. Во всяком случае, при логическом анализе схемы. Ну просто копируются значения флагов 5 и 3, и все. Во всяком случае, я на беглый взгляд этого не вижу.
непонятное поведение флагов 5 и 3 после команд SCF и CCF,
А уж как мне это интересно)) Так никто внятно мне и не сказал, от чего зависит, от самого проца, или от обвязки вокруг него. Приблизительно третья часть моих процессоров может похвастать этим синдромом)) Если от обвязки вокруг - тогда почему при смене на другой, хороший:), процессор - этот синдром пропадает напрочь?
Так никто внятно мне и не сказал, от чего зависит, от самого проца, или от обвязки вокруг него.
Как это может зависеть от обвязки, если содержимое флагов 5 и 3 - это исключительно заряд на шине LBUS, оставшийся от пересылки через нее флага F в данном случае, или же, например, регистра A в более классическом случае.
Это я про NMOS.
Каким именно синдромом хвастаются твои процессоры? В каких тестах и как?
В недокументированных конечно. в том то и дело, что все остальное работает идеально. а, ну раз не-документированные - значит можно работать кто-в-лес-кто-по-дрова?))) я то всегда думал, что даже такие мало-документированные вещи должны работать у всех одинаково. или нет))
Я выше приводил ссылки на тесты от Патрика, с картинками паттернов.
Я выше приводил ссылки на тесты от Патрика, с картинками паттернов.
Вот это?
ну почему же.
есть тесты CCF\SCF, причем в зависимости от производителя\мануфактуры - аж три различных варианта поведения этих самых недокументированных флагов. Вернее есть и 4 вариант("синдром"), что-то похожее на утечку, но пока это малоповторимо и точно никто из причастных не может сказать, с чем связано 4-е поведение, говорят - невоспроизводимый глюк :) Тесты от Патрика же, с картинками...
https://github.com/raxoft/z80test/tree/master/img
это результаты, других вариантов по паттернам не бывает.
Но бывает, что картинка "дрожит", как буд-то флаги произвольно меняются, что в принципе не должно быть. Может это та самая утечка?))
https://github.com/raxoft/z80test/blob/master/src/z80ccfscr.asm
как бы сам тест, десяток строк
- - - Добавлено - - -
Непонятно, был ли в тестах процессор NMOS.
- - - Добавлено - - -
я то всегда думал, что даже такие мало-документированные вещи должны работать у всех одинаково. или нет))
Я выше приводил ссылки на тесты от Патрика, с картинками паттернов.
Лучше прогони тест на своих заведомо NMOS-процессорах.
Да, по сути это программа в статике!! графически показывает содержимое этих самых регистров. в зависимости от производителя оно несколько отличается. Это нормально. Не нормально - это когда картинка вовсе не статическая. Это что значит? что регистры меняют свое содержимое? от вспышек на Солнце??
Не нормально - это когда картинка вовсе не статическая. Это что значит? что регистры меняют свое содержимое? от вспышек на Солнце??
Это может быть все, что угодно. Надо смотреть, что за процессор. В NMOS-е я таких моментов в формировании 3 и 5 флагов в SCF/CCF не вижу. А что там в CMOSах, надо их реверсить для этого.
Сделай тест на NMOS, и посмотри, бегает что-то, или нет.
Непонятно, был ли в тестах процессор NMOS.
этим тестом не один десяток процев проверяли и не один человек. и cmos и nmos. тут без разницы, только от производителя паттерн зависит. Ну кроме случаев синдрома - паттерн тот же самый, но отдельные пиксели меняют свое значение.
Можешь в любом эмуле спековском запустить. Буудет один из трех вариантов, но картинка будет неподвижная.
- - - Добавлено - - -
Сделай тест на NMOS, и посмотри, бегает что-то, или нет.
такой косяк чаще всего в NMOS и был. ЗлойКиллер документировал, что за проц, мне это не надобно было
этим тестом не один десяток процев проверяли и не один человек. и cmos и nmos. тут без разницы,
Это все общие слова) Мне нужны тесты только на NMOS. Потестил, проверил, бегают или нет, и сказал, что за процессор, когда выпущен.
- - - Добавлено - - -
такой косяк чаще всего в NMOS и был.
Хм. Пока не вижу, с чего бы там чему-то бегать.
я не могу сказать точно, NMOS\CMOS, это было много лет назад.
Вот Sharp!!! кпримеру
https://drive.google.com/file/d/1lxIZyMH8RA7aREc7f9jTTrrG0iNawfoX/view?usp=sharing
так же себе NEC фигово вел, и наш Т34 вроде, который трудно заподозрить что он не NMOS
вот тот же комп, но с процессором ST - идеальная картинка
https://media.discordapp.net/attachments/689220116801650811/935560215665967174/unknown.png?ex=66f823d9&is=66f6d259&hm=a4dae43e43b67b6305a0ccb2821b60f976cc1342ee43ed7 528e635569cc5f3e3&=&format=webp&quality=lossless&width=754&height=424
а вот ST - с синдромом, справа видно
https://drive.google.com/file/d/1Z-TKGgVpG3lHD4BFDROQM3IS9M7AEC3z/view?usp=sharing
Lethargeek
27.09.2024, 22:00
* 2022 - [NMI rejection](https://spectrumcomputing.co.uk/forums/viewtopic.php?t=7086)
авоткстате - как оно конкретно реализовано? то же самое касаемо и EI
можно ли сказать, что в z80 помимо iff1 и iff2 есть аналогичный флажок iff3 (iff4) ?
или там какой-то целый отдельный блок (или несколько), который издевается над iff1?
вот тот же комп, но с процессором ST - идеальная картинка
ST - это что за процессор? Полная маркировка какая?
Это может быть все, что угодно. Надо смотреть, что за процессор. В NMOS-е я таких моментов в формировании 3 и 5 флагов в SCF/CCF не вижу.
Рассмотрев внимательнее, стало видно, что особенности есть!
В отличие от классических АЛУ-команд, команда SCF в такте T3 не устанавливает результат работы АЛУ на обьединенную шину HBUS/LBUS (например, содержимое регистра A), в связи с чем при записи флагов 5 и 3 с шины LBUS в регистр F в такте T4, происходит запись заряда, оставшегося там с предыдущего состояния LBUS, которое следует рассмотреть более подробно.
Как уже упоминалось, если команда в конце своей работы обновляет регистр F, то следующая за ней команда не перечитывает F из регистрового файла, а читает его прямо с шины LBUS, т.к. в этот момент на шину LBUS выдаются флаги. Что же касается флагов 5 и 3, то от предыдущего такта (Т3) на шине LBUS остается сильный заряд (например, значение регистра А), который и попадает во флаги 5 и 3.
Говоря еще проще по шагам: В такте T3 шины LBUS и HBUS обьединены, на них находится содержимое регистра A. В такте T4 шины LBUS и HBUS разьединяются, и с шины LBUS происходит запись в регистр F, а на шину HBUS читается регистр A из регистрового файла.
Теперь рассмотрим отличие работы команды SCF от классической АЛУ-команды.
Рассмотрим такую последовательность команд ALU A,r; SCF; SCF; SCF и т.д.
В такте T3 на шине LBUS было какое-то значение, т.е. оставшееся с предыдущей команды (ALU A,r) значение регистра A. В такте T4 оно записывается фо флаги 5 и 3, и также в этом такте читается значение регистра А на HBUS. В такте T1 следующего цикла шины HBUS и LBUS обьединяются, но на них ничего не выдается, т.к. команда SCF не использует АЛУ. И тут возникает вопрос, какой заряд сильнее? 0 или 1? Если 0 сильнее, то на обьединенной шине HBUS/LBUS будет содержимое A & F. Если 1 сильнее, то будет A | F. В течение тактов T1, T2, T3 ничего не меняется. А далее в такте T4 шины HBUS и LBUS снова разьединяются, на шину HBUS читается регистр A для следующей команды, а вот шина LBUS все еще сохраняет заряд A & F, и в таком виде записывает его в регистр флагов (мы тут рассматриваем только флаги 5 и 3). Далее в такте T1 следующего цикла шины HBUS и LBUS опять обьединяются, и на шине HBUS мы имеем сильный обновленный заряд (регистр A), и электрически соединяясь с шиной LBUS, на которой заряд более слабый, оставшийся от соединения шин 4 такта назад, что мы получим в сумме?
Вот это вопрос. Шина HBUS сильно заряжена, а шина LBUS осталась с прежним зарядом, являющимся электрической суммой LBUS и HBUS предыдущего цикла. Если мы рассматриваем последовательность команд SCF, то регистр A не изменяется, значит HBUS подзаряжается одинаковым значением, которое постепенно (за сколько команд SCF) пересилит ослабевающий заряд LBUS, и в итоге через несколько итераций содержимое F (5 и 3 флаги) будет равняться не электрической сумме A и F, а только A, не зависимо от того, что сильнее, 0 или 1.
Вот такие теоретические рассуждения, которые требуют проверки на практике.
Если теория верна, то последовательность команд типа:
LD HL,$FFFF($0000,$FF00,$00FF)
PUSH HL
POP AF
SCF
LD HL,$FFFF($0000,$FF00,$00FF)
PUSH HL
POP AF
SCF(100 раз)
долнжны давать разное значение флагов 5 и 3 (пока это тестить не надо, надо подумать о нормальном тесте).
- - - Добавлено - - -
Поискал в интернете, и нашел здесь (https://github.com/hoglet67/Z80Decoder/wiki/Undocumented-Flags#scfccf) подтверждение моих предположений для родного NMOS:
if <previous instruction modified the flags> then
YF = A.5
XF = A.3
else
YF = YF | A.5
XF = XF | A.3
endif
- - - Добавлено - - -
Все-таки OR, а не AND (т.е. 1 более сильные).
Если предыдущая команда не модифицирует флаги, то перед выполнением команды, регистр F читается на LBUS из регистрового файла, и заряд сильный, равноценный заряду на HBUS, куда читается A. Поэтому получается некая электрическая сумма по OR.
А вот если предыдущая команда модифицирует флаги, то перед выполнением команды, регистр F (5 и 3 биты) читаются с LBUS, где остались слабо заряжены от предыдущей команды, поэтому хорошо заряженный HBUS (регистр A) их пересиливает.
- - - Добавлено - - -
Итак, почему же плавают значения? Да потому что после обьединения HBUS и LBUS пртивоположные заряды дают нечто среднее, не 0 и 1, а 0.5. И в зависимости от чувствительности затворов, это может прочитаться как 0, а может как 1. Судя по всему, тяготеет ближе к 1, но т.к. все же на грани порога, то любой чих, примесь в кристалле, нюансы производства, наводки на процессор с платы, температура, могут сместить эту шаткую границу, поэтому и нестабильность, как я думаю.
Ввиду того, что загадка установки 5 и 3 флагов в командах SCF/CCF для NMOS Z80 наконец-то разгадана, написал несколько тестов шума SCF для реалов (тестировать CCF нет смысла ввиду абсолютно одинаковой внутренней реализации этих команд).
В отличие от этого (https://github.com/raxoft/z80test/blob/master/src/z80ccfscr.asm) теста, все более наглядно, нет индикации бит, никак не участвующих в формировании 5 и 3 флагов. Заполнение экрана предполагаемым шумом более однородное и визуально понятное.
Верхняя треть экрана отображает тест бита 3 (черный с белым), средняя треть экрана отображает тест бита 5 (синий с голубым).
Также каждая треть разделена на несколько зон с разными комбинациями начальных флагов для теста.
В архиве три теста:
1. Классический SCF после команды 'не влияющей на флаги'.
2. Тоже самое, но два SCF подряд.
3. Классический тест, но перед SCF выполняется команда, влияющая на флаги.
На эмуляторах поля будут однородные.
На реалах исходя из теоретических предположений, некоторые поля на некоторых процессорах будут шуметь. Вот это самое интересное и нужное.
Расчехляйте ваши реалы и запускайте тесты!
Пример картинки из теста на эмуляторе:
https://pic.maxiol.com/images2/1727539901.2997898589.01.png
- - - Добавлено - - -
p.s.: Можете тестировать на любом реале, не обязательно на NMOS.
p.p.s: Тест убран, как устаревший. Используете Test SCF 9 (https://zx-pk.ru/threads/34173-revers-inzhiniring-z80.html?p=1204427&viewfull=1#post1204427).
Ну что, я то готов тестировать. Но...
Проц сейчас стоит тот, что нестабильный, что надо.
но надо или исходники тестов или с загрузчиком под ТР-ДОС. Тап-ку грузить сильно проблемно.
NEC D780C-1 https://www.cpu-world.com/CPUs/Z80/NEC-D780C-1.html
https://pic.maxiol.com/thumbs2/1727552327.3645248241.dscf9050.jpg (https://pic.maxiol.com/?v=1727552327.3645248241.dscf9050.jpg&dp=2)
https://pic.maxiol.com/thumbs2/1727552347.3645248241.dscf9051.jpg (https://pic.maxiol.com/?v=1727552347.3645248241.dscf9051.jpg&dp=2)
https://pic.maxiol.com/thumbs2/1727552365.3645248241.dscf9052.jpg (https://pic.maxiol.com/?v=1727552365.3645248241.dscf9052.jpg&dp=2)
https://www.cpu-world.com/CPUs/Z80/NEC-D780C-1.html
Шумы были, или картинка стабильная?
- - - Добавлено - - -
но надо или исходники тестов или с загрузчиком под ТР-ДОС. Тап-ку грузить сильно проблемно.
В тапке обычный кодовый блок, бейсик грузится только для запуска кода. Все предельно просто.
Шумы были, или картинка стабильная?
всё было стабильно.
понятно, что там предельно просто, но с исходниками я бы быстрее трд сделал.
а так то пока один сделал и запустил :))
ну сейчас, неспеша сделаю все три и озвучу результат :))
- - - Добавлено - - -
2. Тоже самое, но два SCF подряд.
два SCF подряд - я думаю не имеют смысла, но это так, мысли вслух.
Вобщем второй и третий тест стабильно, не шумят.
Авот первый очень интересно шумит. Если считать по полоскам сверху вниз, то шумит нижняя вторая половина первой белой полосы и
первая верхняя половина последней синей полосы..
Там натуральные иероглифы в динамике!! возможно кЕтайцы или корейцы что-то знакомое точно узнали бы!!
https://s1.hostingkartinok.com/uploads/images/2024/09/39bb47e786e678ca6fffaa8cc5fa5ab8.jpg
сорри, что ч\б, но результат и так виден))
всё было стабильно.
Немножко странновато, если верить тому, что этот процессор NMOS.
- - - Добавлено - - -
два SCF подряд - я думаю не имеют смысла, но это так, мысли вслух.
Для чистоты эксперимента надо было сделать и такие варианты.
- - - Добавлено - - -
Авот первый очень интересно шумит. Если считать по полоскам сверху вниз, то шумит нижняя вторая половина первой белой полосы и
первая верхняя половина последней синей полосы..
Это очень радует. Значит теория совпала с практикой.
Обязательно нужно записать видео этого шума.
Во втором и третьем тесте что на месте шума? Белое или черное?
- - - Добавлено - - -
И еще, какая полная маркировка процессора?
- - - Добавлено - - -
шумит нижняя вторая половина первой белой полосы и
первая верхняя половина последней синей полосы..
Рисунок наводит на некоторые дополнительные мысли о перекрестном влиянии некоторых линий. Нужно видео, и нужны еще тесты с разных процессоров. А еще интересно, не будет ли меняться картина, если потрогать процессор пальцем, или слегка нагреть его.
интересно, не будет ли меняться картина, если потрогать процессор пальцем, или слегка нагреть его.
на тесте Патрика картинка менялась после каких нибудь манипуляций :)
Обязательно нужно записать видео этого шума.
https://drive.google.com/file/d/1amuIvVsb4XMdSEjAFCOt8b5O2goUcGAQ/view?usp=sharing
Во втором и третьем тесте что на месте шума? Белое или черное?
- - - Добавлено - - -
И еще, какая полная маркировка процессора?
второй третий перепроверю. С процем сложнее, у меня Профи (я не думаю, что это имеет значение при тесте процессоров?)), и проца не видно, но точно не Т34, он на другой плате стоит..
упд - на втором-третьем тесте полоски ровно такие же, как у goodboy, даже фотографировать нет смысла
С процем сложнее, у меня Профи (я не думаю, что это имеет значение при тесте процессоров?))
Не имеет. Только разве что качество питания, напряжение и фильтрация от шумов.
- - - Добавлено - - -
и проца не видно, но точно не Т34, он на другой плате стоит..
Надо посмотреть название обязательно)
- - - Добавлено - - -
https://drive.google.com/file/d/1amu...ew?usp=sharing
Очень интересная динамика.
Очевидно, что когда состояние входов пограничное, любой перекрестный чих может иметь какое-то влияние. В данном случае, видно, что влияет содержимое регистра HL. Чем ближе к правому краю байта, тем разреженней шум. И чем ближе к правому краю экрана, тем тоже шум разреженней.
Та же картина видна с битом 5 (средняя треть экрана).
Изменю тест, переставлю местами маски, чтобы понять, какие еще перекрестные помехи влияют.
- - - Добавлено - - -
Добавил тест 4.
По сути это тот же тест 1, но изменен порядок полос.
Не имеет. Только разве что качество питания, напряжение и фильтрация от шумов.
ну да, а другой проц ставлю - сразу и питание улучшается, и шумы пропадают )) АТХ-БП
Разбирать Профи-к не самое благодарное дело. Посмотрел процессор - Z8400AB1 Z80ACPU 29038
Это точно NMOS
А, ну и мануфактура ST
тест4
https://s1.hostingkartinok.com/uploads/images/2024/09/db4738c5e51f6278caac57ed89ee51ff.jpg
ну да, а другой проц ставлю - сразу и питание улучшается, и шумы пропадают ))
Дело не в улучшается/ухудшается. Дело в сдвиге порога срабатывания. Твой процессор не глючный, просто его порог 0/1 затворов транзисторов находится именно в той зоне, в какой образуются средние состояния при сложении сигналов с шин LBUS/HBUS. Причем, при данном напряжении питания. Если поставишь в другой компьютер, где другие условия, вполне возможно, что картина теста будет совсем иной.
- - - Добавлено - - -
тест4
Понял, значит хоть результат в какой-то мере зависит от состояния HL, но основная зависимость окружения, похоже, от комбинаций других линий на LBUS. Значит надо сделать более подробный тест для твоего процессора. Ну и вообще.
- - - Добавлено - - -
Сделал подробные варианты тестов.
В них каждой из 65536 комбинаций начальных значений AF соответствует лишь одна точка на экране.
Т.к. рабочая зона экрана охватывает лишь 16384 точки для бита 3 и бита 5, пришлось тест разделить на 4 части (5, 6, 7, 8).
Скорее всего все 4 теста будут показывать одинаковую картинку, но если она все же немного отличается, то это тоже важно.
Обязательна запись на видео, т.к. в иных местах может телепаться лишь 1 пиксель.
- - - Добавлено - - -
Посмотрел процессор - Z8400AB1 Z80ACPU 29038
Это точно NMOS
Как определил, что NMOS?
Ходил по ссылкам которые на прошлой странице выкладывали, наткнулся на это:
https://floooh.github.io/visualz80remix/
Подскажите, что это за эмулятор - это отреверсили схему и уже эмулятор к ней сделали?
https://i.imgur.com/5IDokbf.jpeg
Первый прогон в кислоте Toshiba T84C00AM-5.
Датасеты: https://drive.google.com/drive/folders/1JufzBJ4V05Jy3nRASpeoE-OqmpvBYRzj
Выяснилось что декодер и некоторые "нестандартные ячейки" с имплантацией.
Борис выложил более качественные фото старой ревизии T84C с фокус-стакингом: https://ic.onidev.fr/map/toshiba/T6A43/60S/T84C00-CORE.html
Как определил, что NMOS?
по широко известномуу в узких кругах багу out (c),0, который в CMOS однозначно поправили (что мне не нравиЦЦа :)
Скорее всего все 4 теста будут показывать одинаковую картинку, но если она все же немного отличается, то это тоже важно.
Обязательна запись на видео, т.к. в иных местах может телепаться лишь 1 пиксель.
5й тест и 8й - шевелятся, 6,7 - статично. Видео надо, или хватит картинок 5,8 ?
ZjoyKiLer
29.09.2024, 08:46
Товарищ Titus, пожалуйста, прочтите это:
https://github.com/hoglet67/Z80Decoder/wiki/Unstable-CCF-SCF-Behaviour
https://github.com/redcode/Z80_XCF_Flavor/issues/2
YF и XF нестабильны в инструкциях CCF/SCF, вероятно, по тем причинам, которые вы теоретизировали.
Насколько нам удалось выяснить:
1. все модели Zilog NMOS и CMOS ведут себя так, как описал Патрик Рак, за исключением Z0840004PSC, где мы увидели, что некоторые устройства ведут себя как NMOS NEC.
2. NEC NMOS копируют YF и XF из A.
3. Модели NEC CMOS ведут себя по-разному.
4. По крайней мере, некоторые модели ST CMOS (не старые NMOS от SGS или SGS-Thomson, а модели ST CMOS от STMicroelectronics) ведут себя иначе, чем Zilog и NEC.
Не исключено, что есть и другие варианты поведения, которые пока не обнаружены. Скорость процессора напрямую и явно влияет на стабильность YF и XF в этих двух инструкциях.
5й тест и 8й - шевелятся, 6,7 - статично. Видео надо, или хватит картинок 5,8 ?
Видео надо. Но и картинки тоже.
Говорить словами, что было в тесте - это просто кощунство)
- - - Добавлено - - -
YF и XF нестабильны в инструкциях CCF/SCF, вероятно, по тем причинам, которые вы теоретизировали.
Судя по уже проведенным новым тестам, именно по этим причинам.
- - - Добавлено - - -
Не исключено, что есть и другие варианты поведения, которые пока не обнаружены. Скорость процессора напрямую и явно влияет на стабильность YF и XF в этих двух инструкциях.
В случае, когда среднее значение на линиях близко к порогу срабатыванию затворов транзисторов, на результат может влиять все, что угодно, и скорость, разумеется тоже. Хотя бы потому, что от нее зависит длительность такта, а, следовательно, время за которое заряжаются/разряжаются затворы.
- - - Добавлено - - -
1. все модели Zilog NMOS и CMOS ведут себя так, как описал Патрик Рак, за исключением Z0840004PSC, где мы увидели, что некоторые устройства ведут себя как NMOS NEC.
2. NEC NMOS копируют YF и XF из A.
Я думаю, что-то интересное прояснится в новых тестах, если найдутся желающие их проводить на реалах.
- - - Добавлено - - -
Выяснилось что декодер и некоторые "нестандартные ячейки" с имплантацией.
С имплантацией - это как?
- - - Добавлено - - -
Посмотрел по схеме, какие еще команды влияют на флаги, но при этом не используют стандартные механизмы чтения/записи регистра источника/приемника через шины. Думаю, что эти команды надо будет рассмотреть внимательнее в плане формирования флагов 5 и 3.
Вот список:
SCF/CCF (с ними все понятно)
BIT
ADD/ADC/SBC HL,dd
LDI/LDD/LDIR/LDDR
CPI/CPD/CPIR/CPDR
INI/OUTI/IND/OUTD
INIR/OTIR/INDR/OTDR
Говорить словами, что было в тесте - это просто кощунство)
https://drive.google.com/file/d/1bHDU4-3IMD0BtzkylY9vylkl3ByoI3zR/view?usp=sharing
говорю словами - сперва запускается 5й тест, потом 6-7 и далее со всеми остановками.
p.s. Делай тогда все тесты с запуском c #9000h. Хотя с 8000h было бы интереснее, но пусть как будет, чтобы добавлять леХХче мне..
p.s. Делай тогда все тесты с запуском c #9000h. Хотя с 8000h было бы интереснее, но пусть как будет, чтобы добавлять леХХче мне..
Так и так все тесты запускаются с 9000 же.
А с 8000 не делаю, т.к. с 8000 по 8FFF таблицы.
- - - Добавлено - - -
говорю словами - сперва запускается 5й тест, потом 6-7 и далее со всеми остановками.
Ты, видимо, перепутал.
На видео видно, что это запускаются тесты 1-4 и т.д.
Тесты 5-8 выглядят иначе.
Да, с копи-пастой промахнулся. Действительно это были 1-2-3-4.
Да не может показывать такого 5-8 тест)
У него совсем другие паттерны)
На эмуляторах это выглядит так:
https://pic.maxiol.com/images2/1727606965.2997898830.02.png
Или так:
https://pic.maxiol.com/images2/1727606994.2997898830.03.png
А то, что у тебя на видео - это все еще тесты 1-4.
SJAsm+ сам по себе отличный ассемблер, но вот бейсик-загрузчики в нем собирать - это особое, м-м-м-м, удовольствие :)))
https://drive.google.com/file/d/1I6t3qOqjlrwiWPPPvcoeHzWvzY5VEG4T/view?usp=sharing
быстрее с tap2wav запустить.
SoftLight
29.09.2024, 15:04
На эволюшене реальный z80 но все тесты проходят как на эмуле без каких-либо артефактов. Шах и мат тем кто доказывал, что эволюшен это НЕ эмулятор XD
На эволюшене реальный z80 но все тесты проходят как на эмуле без каких-либо артефактов. Шах и мат тем кто доказывал, что эволюшен это НЕ эмулятор XD
Нужна точная маркировка процессора, которая там стоит.
- - - Добавлено - - -
https://drive.google.com/file/d/1I6t...ew?usp=sharing
Вот это я понимаю - результат. Именно это я и хотел увидеть) Все очень здорово)
Подумаю над общим более наглядным тестом, чтобы не кусочками запускать.
SoftLight
29.09.2024, 16:32
Нужна точная маркировка процессора, которая там стоит.
На эво прогнал все тесты с 1 по 8 - никаких артефактов
проц: Z84C0020FEC в исполнении QFP
На Ленинград 2012 прогнал тест 1, 5 и 8. Аналогичнно никаких отклонений идеальные полоски и квадратики
проц: Z84C0006PEC
https://i.ibb.co/7p0f5rj/image.png
интересно что я делаю не так и как увидеть знаменитые баги )
Есть разные Z80 могу их в Ленина позапихивать
ннада?
https://i.ibb.co/VJDVZbW/image.png
как увидеть знаменитые баги
знаменитых багов не существует, увы... Это все синдром имени моего имени и плод воображения моего компьютера.
Поменял на другой процессор, убил полчаса из жизни :((
На тесте Патрика синдром присутствует , но гораздо в меньшем количестве, чем на предыдущем проце.
Но вот новое видео. Сперва тест CMOS\NMOS. Бордер черный - значит NMOS. Потом меняю образ ТРД и запускаю все восемь тестов по очереди.
И в конце снова запускаю 5й тест.
Уточняю, тут точно правильные 5-6-7-8 тесты!
https://drive.google.com/file/d/1pBUE_N3f13iD7-Rdj86zZEGg49eNW4gn/view?usp=sharing
упд - согласно паттерну - это NEC. на самом проце написано Zilog, красивым шрифтом. Явный перемарк.
так то процев у меня тоже не сказать, чтобы мало, ну еще неск есть мимо этой картинки.
https://s1.hostingkartinok.com/uploads/images/2024/09/aba7709d82578adce368da7de884a911.jpg
Проверял почти все. Говорю же, где то третья часть с синдромом, которого нет, остальные - без него.
а так то все процы проходят все тесты. На максимальную частоту не гонял, мне оно не надо.
ЧЯНТД??
ах да, сейчас установлен второй справа сверху. Zilog же типа.
SoftLight
29.09.2024, 16:57
Кароч GoldStar у меня на ленине не завелся. Зато проверил тесты 4- 8 на Toshiba и тож ничего. Может дело не только в z80 а еще как-то со схематехникой компа вцелом связано?
https://i.ibb.co/1qqBpg2/IMG-20240929-164930-394.jpg
ST тоже не завелся. Скорее всего в Ленинград-2012 просто процы ниже Z84C0006 не работают так что вытащенные из оригинальных спеков я как раз проверить и не смог. Но ок сейчас резинку найду.
На Ленинград 2012 прогнал тест 1, 5 и 8. Аналогичнно никаких отклонений идеальные полоски и квадратики
Нужны скриншоты, т.к. полоски тоже могут отличаться у разных моделей.
- - - Добавлено - - -
Есть разные Z80 могу их в Ленина позапихивать
ннада?
Конечно надо, вдруг найдется шумный.
- - - Добавлено - - -
И в конце снова запускаю 5й тест.
Я думаю, достаточно запустить 5-й тест. Если на нем нет шума, то и на другие тесты нет смысла запускать.
- - - Добавлено - - -
Надо будет сделать один единственный тест, который заменит все остальные.
SoftLight
29.09.2024, 18:26
резинка, цвет по где-то в тв-тюнере потерялся
https://disk.yandex.ru/i/SYOLgepZE1nZUA
Если найду видеокабель потом еще на фениксе попробую, там тоже кроватка под проц
резинка, цвет по где-то в тв-тюнере потерялся
Надо точную маркировку процессора указывать, а то никакой статистики не соберем.
Может дело не только в z80 а еще как-то со схематехникой компа вцелом связано?
вполне возможно берутся данные со свободной шины данных, если она шумная, то будет мусор.
вполне возможно берутся данные со свободной шины данных, если она шумная, то будет мусор.
Ааа! Для кого я пишу описания? Не берутся они с шины данных.
Сделал обобщенный тест, заменяющий все предыдущие, и, как надеюсь, более наглядный.
Сперва надо проверить на волшебном процессоре товарища zebest, и если все норм, то у всех остальных.
Пример работы на эмуляторе:
https://pic.maxiol.com/images2/1727685769.2997898642.01.png
Z8400AB1
https://pic.maxiol.com/thumbs2/1727688572.92868234.img20240930162418.jpg (https://pic.maxiol.com/?v=1727688572.92868234.img20240930162418.jpg&dp=2)
Karabas-128
https://rutube.ru/video/ffedf199c8348bd60f6b16edbdfa95f1/
Z8400AB1
Прекрасно и наглядно!
Сравним с результатами zebest, когда они будут.
можно в нормальном архиве выложить, чтобы можно было в linux открыть?
81332
можно в нормальном архиве выложить, чтобы можно было в linux открыть?
81332
Куда уж нормальнее в RAR'e)
Хорошо, сейчас заменю на .zip.
Куда уж нормальнее в RAR'e)
Хорошо, сейчас заменю на .zip.Нормальный это = .7z ;)
Нормально - это сперва в .zip, потом в .rar, и что получилось уже в .7z. Всемъ сёстрам - по сёрьгам.
Сравним с результатами @zebest, когда они будут.
Сейчас сравним, ТРД уже собрал, со второго раза, блин :)
Это фиаско! (с)
Я же говорил, что это зависит от солнечной активности, нейтрино, етс..
Тот же компьютер, тот же АТХ БП, тот же проц, второй.
Все тесты с 1 по 9 - стабильны, даже пятый, даже видео делать не с чего.
НО!!
На тесте Патрика (паттерн) все же мигают, оочень редко, три-четыре точки.
9й тест этого не отлавливает.
Такая вот фигня.
Может все же вернемся к мысли, об внешних сигналах?? Что=кто так может влиять на эти чертовы регистры, нафик никомууу не нужные))
Откуда такая метастабильность, если не снаружи??
https://s1.hostingkartinok.com/uploads/images/2024/09/e0aedf5a286956d4c7cda11d6889576c.jpg
На тесте Патрика (паттерн) все же мигают, оочень редко, три-четыре точки.
9й тест этого не отлавливает.
Потому что на шум влияет все, что угодно. Содержимое любых линий, регистров и т.д., которые не предусмотришь.
Если в тесте патрика мигает, значит граница все же прям на грани, где-то рядом. Просто уехала по каким-то причинам слегка.
- - - Добавлено - - -
Все тесты с 1 по 9 - стабильны, даже пятый, даже видео делать не с чего
Фотку стабильности сделай на 9м.
Кстати, в 9-м тесте, записанном creator'ом верхнее правое поле тоже ровное, но иногда пробегают отдельные точки.
Всё на том же Karabas-128.
Z0840006PSС
https://pic.maxiol.com/thumbs2/1727710307.92868234.karabas128z0840006pc.jpg (https://pic.maxiol.com/?v=1727710307.92868234.karabas128z0840006pc.jpg&dp=2)
https://rutube.ru/video/426821421f5c174c7155b8e2029567dc/
KP1858BM1
https://pic.maxiol.com/thumbs2/1727710508.92868234.karabas128kp1858bm1t.jpg (https://pic.maxiol.com/?v=1727710508.92868234.karabas128kp1858bm1t.jpg&dp=2)
https://rutube.ru/video/89e7a40186fedeff6f3c4508fbeec449/
80H-CPU
https://pic.maxiol.com/thumbs2/1727710605.92868234.karabas12880hcputest.jpg (https://pic.maxiol.com/?v=1727710605.92868234.karabas12880hcputest.jpg&dp=2)
https://rutube.ru/video/1473bb4cf52479fc9db4552bb3b180b4/
Z84C0020PEC
https://pic.maxiol.com/thumbs2/1727710722.92868234.karabas128z84c0020pe.jpg (https://pic.maxiol.com/?v=1727710722.92868234.karabas128z84c0020pe.jpg&dp=2)
https://rutube.ru/video/e234cef8fb2b71e0e2679fbebf2e5519/
Кстати, в 9-м тесте, записанном creator'ом верхнее правое поле тоже ровное, но иногда пробегают отдельные точки.
но там нижнее правое все нестабильно. Или нет??
ну вот, и на другом видео точки есть.
Значит я не одинок с синдромом??
Эх, сейчас запущу UMT, проверю памИть на стабильность
но там нижнее правое все нестабильно. Или нет??
Да.
На разных процессорах все может быть индивидуально.
Но надо понимать, что в принципе, любое из 4-х полей может быть нестабильно, если оно вошло в зону порога затворов. Если порог выше, то будет получаться A and F, если порог ниже, то будет получаться, A or F.
- - - Добавлено - - -
Всё на том же Karabas-128.
Классные шумы на 80H-CPU. Это что за процессор?
Если на картинке все стабильно, то не обязательно записаывать видео, можно просто скриншот.
- - - Добавлено - - -
Z84C0020PEC
Получается только этот один процессор CMOS, а все остальные NMOS.
ZjoyKiLer
30.09.2024, 19:34
Всё на том же Karabas-128.
Z0840006PCS
https://pic.maxiol.com/thumbs2/1727710307.92868234.karabas128z0840006pc.jpg (https://pic.maxiol.com/?v=1727710307.92868234.karabas128z0840006pc.jpg&dp=2)
https://rutube.ru/video/426821421f5c174c7155b8e2029567dc/
Это наглядный пример того, о чем я говорил в своем предыдущем комментарии: Z0840004PSC ведет себя как NEC NMOS. Однако твоя модель - Z0840006PSC, а не Z0840004PSC. Может ли быть так, что "PSC" были изготовлены по другому технологическому процессу?
Кстати, для справки, вот что выдает мой эмулятор:
https://i.postimg.cc/JhkCK3cK/Test-SCF-9-Zilog-NMOS.png
https://i.postimg.cc/9Q29c1zw/Test-SCF-9-Zilog-CMOS.png
https://i.postimg.cc/HWJXzVfn/Test-SCF-9-NEC-NMOS.png
Это наглядный пример того, о чем я говорил в своем предыдущем комментарии: Z0840004PSC ведет себя как NEC NMOS. Возможно, многие Z0840004PSC были изготовлены по более совершенному техпроцессу или на лучших литографических машинах?
Стабильные NMOS-модели не обязательно имеют какую-то усовершенствованную начинку. Вполне возможно, что чуть изменен техпроцесс, и пороги уехали выше или ниже линии нестабильности. Попробуйте позапускать такие процессоры на несколько другом напряжении питания (чуть ниже или выше), возможно, будут сюрпризы.
- - - Добавлено - - -
Кстати, для справки, вот что выдает мой эмулятор:
Что за эмулятор?
ZjoyKiLer
30.09.2024, 19:58
Стабильные NMOS-модели не обязательно имеют какую-то усовершенствованную начинку. Вполне возможно, что чуть изменен техпроцесс, и пороги уехали выше или ниже линии нестабильности. Попробуйте позапускать такие процессоры на несколько другом напряжении питания (чуть ниже или выше), возможно, будут сюрпризы.
- - - Добавлено - - -
Что за эмулятор?
Я обновил свой предыдущий комментарий.
Это мультиэмулятор, он эмулирует в том числе и ZX Spectrum. Я еще не опубликовал его официально. Ядро Z80 можно найти здесь: https://github.com/redcode/Z80.
В репозитории есть вики с кучей тестов и документов, если хочешь, посмотри.
https://github.com/redcode/Z80/wiki/Tests
https://github.com/redcode/Z80/wiki/Technical-literature
https://github.com/redcode/ZXSpectrum/wiki/Tests
Классные шумы на 80H-CPU. Это что за процессор?
А это тот легендарный Z80H, который типа "турбо 7 MHz может", как говорили в 90х. Я купил на всякий пожарный. ;)
А фактически производства Квазар (Киев). Шаг ног 2.5мм, частота 11..14MHz. Здесь (https://speccy.info/Zilog_Z80) упоминается.
blackinwoman
30.09.2024, 20:58
creator, ATM TURBO 1, в то время без КМОП процов, мог запускаться стабильно только с ним
мои пять копеек.
"Z0840006PCS, а не Z0840004PCS"
первый умеет в 6МГц а второй в 4МГц (капитан очевидность нервно курит). Это как бы намекает что в первом проце всякого рода переходные процесс быстрее заканчиваются. Другими словами в при фиксированном проце и разной тактовой - "глючить" может по разному.
ПС: или я зверско ошибаюсь в "логических суждениях" ?
Другими словами в при фиксированном проце и разной тактовой - "глючить" может по разному.
ПС: или я зверско ошибаюсь в "логических суждениях" ?
Частота, температура, напряжение питания, помехи по питанию и т.д. - все это может влиять на шум SCF/CCF.
Но я бы не назвал это глюками. Это просто особенности команды.
- - - Добавлено - - -
Все тесты с 1 по 9 - стабильны, даже пятый, даже видео делать не с чего.
НО!!
Все прогрессивное человечество все еще ждет запуска 9-го теста на твоем процессоре.
Уговори его пошуметь)
Нормально - это сперва в .zip, потом в .rar, и что получилось уже в .7z. Всемъ сёстрам - по сёрьгам.
Откуда такая метастабильность, если не снаружи??
попробуйте палец к процессору подносить, не влияет?
Ну что, перевелись желающие проверить тест на реале?:v2_dizzy_coder:
SoftLight
01.10.2024, 17:01
Ну что, перевелись желающие проверить тест на реале?:v2_dizzy_coder:
Ща все будет. Видео огонь
GoldStar Z8400A PS
https://i.ibb.co/7CfMcLs/1.jpg
https://rutube.ru/video/67d1dfbde208f4fa172d21125e29c50c/
Тестировано на ZXM Phoenix 5 ревизии. Пальцем везде тыкал никак не влияет на рисунки. Сорян за качество, кабель для видео потерял и пришлось на коленке композит собирать.
Всякое новье CMOS типа Z84C0020PEC можно не тестить ни на одном экземляре из 5 я не поймал ничего. Оно вот такое:
https://i.ibb.co/Prfwp7d/2.jpg
https://rutube.ru/video/8de4250394991487886626c9147b5619/
а ZXM Phoenix 5 ревизии
авот что со схемотехникой подключения например сигнала WAIT в Пхениксе?? В Профи он точно задейстован
SoftLight
01.10.2024, 18:05
авот что со схемотехникой подключения например сигнала WAIT в Пхениксе?? В Профи он точно задейстован
http://micklab.ru/file/zxm_phoenix/zxm_phoenix_05a.pdf
Ща все будет. Видео огонь
Шикарно. Прекрасное видео)
- - - Добавлено - - -
GoldStar Z8400A PS
А дата изготовления?
SoftLight
01.10.2024, 19:13
А дата изготовления?
9305 это же наверное 93 год?
Добавил в этот (https://zx-pk.ru/threads/34173-revers-inzhiniring-z80.html?p=1204427&viewfull=1#post1204427) пост еще и TR-DOS версию теста 'Test SCF 9', специально для тех, кому лениво запускать .TAP :)
- - - Добавлено - - -
9305 это же наверное 93 год?
Да.
А остальные процы пробовал?
SoftLight
01.10.2024, 19:17
Добавил в этот (https://zx-pk.ru/threads/34173-revers-inzhiniring-z80.html?p=1204427&viewfull=1#post1204427) пост еще и TR-DOS версию теста 'Test SCF 9', специально для тех, кому лениво запускать .TAP :)
- - - Добавлено - - -
Да.
А остальные процы пробовал?
Первый который ST похоже мертвый - комп не стартует рисует всякие квадратики на экране. На остальных картинка в тесте как во втором видео, без артефактов.
На остальных картинка в тесте как во втором видео, без артефактов
Подождем еще кого-нибудь с шумным процессором. Если обьявятся.
ZjoyKiLer
01.10.2024, 19:34
Ща все будет. Видео огонь
GoldStar Z8400A PS
https://rutube.ru/video/67d1dfbde208f4fa172d21125e29c50c/
Так, так... кажется, мы нашли еще одну модель процессора, у которой та же... "проблема", что и у PSC. Твой GoldStar Z8400APS ведет себя как NEC NMOS, а у моего друга Рикардо - как Zilog:
https://github.com/redcode/Z80/wiki/Zilog-Z80-CPU-Test-Suite#v12-goldstar-z8400aps--zx-spectrum-48k-issue-3b-recreated
Пожалуйста, сделай как creator и приложи фотографию процессоров, которые ты тестируешь. Так будет проще все задокументировать.
Ну пока никто не объявился - значит снова я.
Второй проц практически совсем исправился, даже на тесте Патрика почти не мигал.
Нуштош, поставил снова первый(ставить правда проблематично, панелька цанговая советская, с шагом 2,5мм, а процы импортныена, с шагом 2,54, ну и цанга - это не для экспериментов:(
Сперва оба проца во всей красе
https://s1.hostingkartinok.com/uploads/images/2024/10/58878b21ba60db39197ea27816f3d584.jpg
Нижний, типа Зайлог - да фигушки, скорее всего перемарк NEC, нифига он не CMOS
https://www.cpu-world.com/CPUs/Z80/Zilog-Z84C0020PEC.html
Поставил первый, тот , что сверху
https://s1.hostingkartinok.com/uploads/images/2024/10/7ca67548245d1b4380cb2fdd0aa1be1d.jpg
Поставил первый, тот , что сверху
Нужно видео
ZjoyKiLer
01.10.2024, 20:05
https://s1.hostingkartinok.com/uploads/images/2024/10/7ca67548245d1b4380cb2fdd0aa1be1d.jpg
Я не совсем правильно тебя понял. Чтобы уточнить, это результаты, полученные на ST Z8400AB1, верно?
Я не совсем правильно тебя понял. Чтобы уточнить, это результаты, полученные на ST Z8400AB1, верно?
Sí, es correcto, estos son los resultados obtenidos en el ST Z8400AB1.
Hola!
Нужно видео
https://drive.google.com/file/d/1TOux5dpdq4hi6DQa4E19gbXnkEwwzba0/view?usp=sharing
HardWareMan
01.10.2024, 21:10
Что это за тесты? Ошибки регенерации верхнего банка ($8000-$FFFF) процессором?
Что это за тесты? Ошибки регенерации верхнего банка ($8000-$FFFF) процессором?
Да, они самые)))
- - - Добавлено - - -
en el ST Z8400AB1.
Интересно, что в тестах от creator'а тоже был такой же процессор, и давал в целом похожую картинку, но с другим порогом.
- - - Добавлено - - -
На текущий момент, мы имеем тесты для следующих NMOS с пограничным порогом:
ST Z8400AB1 - Z80ACPU 29038 (zebest)
ST Z8400AB1 - Z80ACPU 28831 (creator) - распределение на обоих процессорах похожее
Zilog Z0840004PSC - Z80 CPU 9040 LJ (П321) - распределение такое же, как и у ST Z8400AB1
GoldStar Z8400A PS - 9305 KOREA (SoftLight) - распределение другое, чем на ST, видимо, и другая разводка кристалла.
Kvazar TSL 80H-CPU - 1194 (creator) - эффект едва-едва виден в левом поле. Про распределение сказать невозможно.
Angstrem Т34ВМ1 - 9206 ОП (SoftLight) - распределение такое же, как и у GoldStar Z8400A PS.
Стабильные стандартные NMOS:
Zilog Z0840004PSC - Z80 CPU 9112 CT (SoftLight)
Zilog Z0840006PSC - Z80 CPU 9402 1S (creator)
Angstrem КР1858ВМ1 - 9503 (creator)
И стабильные стандартные CMOS:
Zilog Z84C0020PEC - Z80 CPU 9420 IP (creator)
Zilog Z84C0020PEC - Z80 CPU 9511 CU (SoftLight)
Zilog Z84C0020PEC - Z80 CPU 9515 J9 (SoftLight)
Zilog Z84C0010PEC - Z80 CPU 9511 1N (SoftLight)
Zilog Z84C0006PEC - Z80 CPU 0550 E9 (SoftLight)
Zilog Z84C0006PEC - Z80 CPU 9908 J6 (SoftLight)
Стабильный нестандартный CMOS, у которого поле F5=0,A5=1 - равно нулю, вместо 1.
Toshiba TMPZ84C00AP-6 - JAPAN9908EFI (SoftLight)
HardWareMan
02.10.2024, 08:21
Да, они самые)))
А в чём заключается фундаментальная ошибка? В таймингах сигнала RFSH или кривой схеме использования?
А в чём заключается фундаментальная ошибка? В таймингах сигнала RFSH или кривой схеме использования?
попробуй почитать тему ( с поста №343)
HardWareMan
02.10.2024, 11:22
попробуй почитать тему ( с поста №343)
А зачем тогда Титус меня нае... обманул? Если вы там портите флаги, вместо ОЗУ. Просто где-то тут в теме промелькивало что-то про RFSH сигнал и я подумал речь за оригинал (или клон с двумя полями), где верхнее поле рефрешит сам Z80.
А зачем тогда Титус меня нае... обманул?
Я тебя не обманывал) Я офигал, что ты же несколько постов не почитал выше текущей точки) Ну нельзя же так лениться)
Вот мои результаты теста.
Процессор вот такой
https://pic.maxiol.com/thumbs2/1727871010.1437563691.cpu.jpg (https://pic.maxiol.com/?v=1727871010.1437563691.cpu.jpg&dp=2)
Тест выглядит так
https://pic.maxiol.com/thumbs2/1727871039.1437563691.test.jpg (https://pic.maxiol.com/?v=1727871039.1437563691.test.jpg&dp=2)
Видео не снимал потому как ничего нового там нет.
HardWareMan
02.10.2024, 18:40
Я тебя не обманывал) Я офигал, что ты же несколько постов не почитал выше текущей точки) Ну нельзя же так лениться)
Я не обязан вычитывать все 100500 сообщений. А то, что было на этой же странице не обьясняло ничего, я пропустил несколько ибо между посещениями вы нагенерировали 3шт.
Вот мои результаты теста.
Процессор вот такой
Первый Zilog в нашем тесте, который дает такой результат.
И распределение абсолютно такое же, как и у ST Z8400AB1.
Значит они сделаны по одной технологии.
значит они сделаны по одной технологии.
Неплохо бы еще и паттерн от Патрика на этих процах увидеть.
Неплохо бы еще и паттерн от Патрика на этих процах увидеть.
Для меня он не показательный, там много лишнего мусора.
ZjoyKiLer
02.10.2024, 23:01
Titus, не мог бы ты добавить в свой тест поддержку обнаружения бага Zilog NMOS, который приводит к сбросу флага P/V при приеме маскируемого прерывания во время выполнения команд ld a,{i|r}?
У процессоров ST CMOS, например, есть такой баг.
Эти тесты обнаруживают данный баг. Исходный код последнего из них доступен:
https://github.com/redcode/Z80/wiki/IFF2-Bug
https://github.com/redcode/Z80/wiki/IFF2-Bug-128K
https://github.com/redcode/Z80/wiki/Z80-INT-Skip
Titus, не мог бы ты добавить в свой тест поддержку обнаружения бага Zilog NMOS, который приводит к сбросу флага P/V при приеме маскируемого прерывания во время выполнения команд ld a,{i|r}?
Пока что еще этот баг по реверсу не изучал.
Как дойдет до него, посмотрю, нужно ли делать специальный тест, или из схемы будет понятна его работа на 100%.
а меня интересует недокументированная команда #ED71 OUT (C),0
и вроде так она выполняется на NMOS, на CMOS в порт засылается #FF
а меня интересует недокументированная команда #ED71 OUT (C),0
и вроде так она выполняется на NMOS, на CMOS в порт засылается #FF
Да, надо с ней разобраться.
Но думаю, что там все просто. Ни один регистр не выдается на шину, и она остается заряженной до логической 1. А так как линия инверсная, вот и получается в итоге 0.
Но проверю.
- - - Добавлено - - -
Titus, не мог бы ты добавить в свой тест поддержку обнаружения бага Zilog NMOS, который приводит к сбросу флага P/V при приеме маскируемого прерывания во время выполнения команд ld a,{i|r}?
Где подробно описан этот баг?
https://web.archive.org/web/20141208225700/http://code-zx.zxnet-archive.ru/id/465
https://web.archive.org/web/20141208225700/http://code-zx.zxnet-archive.ru/id/465
Это немного староватая информация.
Я о новых, современных исследованиях)
иследуй что то полезное:
LDI CPI INI OUTI
LDD CPD IND OUTD
LDIR CPIR INIR OTIR
LDDR CPDR INDR OTDR
OUTD
тут я помню что сначала уменьшается B, а потом идёт вывод в порт.
во многих справочниках указан обратный порядок.
Милорд, народ требует зрелищ! Где схемота, где картинки чипов? То что вы делаете последние несколько страниц - это вообще Clean Room эксперименты, которые вполне можно считать за оффтоп и удостоить отдельного топика. ХВМ прав тем что вы отходите от темы и потом тут найти что-то полезное будет сложно.
Милорд, народ требует зрелищ! Где схемота, где картинки чипов?
Вообще-то я выкладывал в теме и потранзисторную схему, и схему логическую.
ZjoyKiLer
03.10.2024, 21:14
Это немного староватая информация.
Я о новых, современных исследованиях)
Ты можешь протестировать его с помощью Visual Z80 Remix: https://floooh.github.io/visualz80remix/
http://z80.info/zip/ZilogProductSpecsDatabook129-143.pdf (Стр. 130)
Q: I don't seem to get the correct state of the interrupts when using the LD A,l and LD A,R instructions to read the state of IFF2. Why is this? How can I get around this?
A: On CMOS Z80 CPU, we've fixed this problem. On NMOS Z80 CPU, in certain narrowly defined circumstances, the Z80 CPU interrupt enable latch, IFF2, does not necessarily reflect the true interrupt status. The two instructions LD A,R and LD A,l copy the state of interrupt enable latch (IFF2) into the parity flag and modifies the accumulator contents (See table 7.0.1 in the Z80 CPU technical manual for details). Thus, it is possible to determine whether interrupts are enabled or disabled at the time that the instruction is executed. This facility is necessary to save the complete state of the machine. However, if an interrupt is accepted by the CPU during the execution of the instruction -- implying that the interrupts must be enabled -- the P/V flag is cleared. This incorrectly asserts that interrupts were disabled at the time the instruction was executed.
Zilog (1989-01). "Z80 Family Data Book", Стр. 412-413
https://zxe.io/depot/documents/technical/Z80%20Family%20Data%20Book%20%281989-01%29%28Zilog%29%28%2300-2490-01%29%28en%29.pdf
Q: I don't seem to get the correct state of the interrupts when using the LO A,I arid LO A,R instructions to read the state of IFF2. Why is this? How can I get around this?
A: On CMOS Z80 CPU, we've fixed this problem. On NMOS Z80 CPU, in certain narrowly defined circumstances, the Z80 CPU interrupt enable latch, IFF2, does not necessarily reflect the true interrupt status. The two instructions LO A,R and LO A,I copy the state of interrupt enable latch (IFF2) into the parity flag and modifies the accumulator contents (See table 7.0.1 in the Z80 CPU technical manual for details). Thus, it is possible to determine whether interrupts are enabled or disabled atthetime that the instruction is executed. This facility is necessary to save the complete state of the machine. However, if an interrupt is accepted by the CPU during the execution of the instruction -- implying that the interrupts must be enabled -- the PN flag is cleared. This incorrectly asserts that interrupts were disabled at the time the instruction was executed.
This paradox can be traced to the internal timing of the CPU. The problem is that the interrupt flip-flop (IFF2) is cleared before it is actually transferred to the PN flag. The state of the interrupt enable latch is not copied into the parity flag until after the interrupt time, occurring during the execution of the instruction, has been accepted. Since the acceptance of the interrupt automatically clears the interrupt enable latch, the parity flag is also cleared, despite the fact that interrupts were enabled when the instruction started executing.
A neat solution to this anomaly relies on the fact that at least one item--the old PC value -- is saved on the stack when an interrupt is accepted. The "next entry" position on the stack (the word below the address currently held in the stack pointer) may be cleared before execution of LO A, I (or LD A,R). If that zero value has changed by the time that the next instruction in the routine is executed, then an interrupt must have been accepted. This implies that interrupts were enabled,. even if the state of the parity flag suggests that they were not. Of course, if the parity flag is found to be set after LO A,R (LO A,I) has been executed, there is no need to check the stack top. Interrupts are definitely enabled if the parity flag is in this state.
Two routines are listed here. Both return carry clear if interrupts are enabled, set otherwise. Both corrupt the A register; it does not contain the value in the I (or R) register on exit The status of all flags except the carry flag are undefined on exit.
The first routine may be loaded anywhere in memory except "page zero" -- 0000h to 00FFh. This small restriction comes about because the routine checks only the most significant byte of the "next" stack entry. This byte will be non-zero afteran interrupt has occurred if and only if the routine itself is not on page zero. The second routine tests both bytes of the "nexf' entry and, therefore, overcomes this restriction.
Caution, these routines presume that the service routine for any acceptable interrupt will re-enable interrupts before it terminates. This is almost always the case. They may not return the correct result if an interrupt service routine, which does not re-enable interrupts, is entered after the execution of LD A,I (or LD A,R).
Listing 1 : This routine may not be loaded in page zero
(OOOOh to OOFFh).
GETIFF:
XOR A ;C flag, acc. := O
PUSH AF ;stack bottom := OOxxh
POP AF ;Restore SP
LD A,I ;P flag := IFF2
RET PE ;Exit if enabled
DEC SP ;May be disabled.
DEC SP ;Has stack bottom been
POP AF ;overwritten ?
AND A ;If not OOxxh, INTs were
RET NZ ;actually enabled.
SCF ;Otherwise, they really are
RET ;disabled.
END
Listing 2: This routine may be loaded anywhere in memory.
GETIFF:
PUSH HL ;Save HL contents
XOR A ;C flag, acc. := 0
LD H,A ;HL :=0000h
LD L,A
PUSH HL ;Stack bottom := OOOOh
POP HL ;Restore SP
LD A,I ;P flag := IFF2
JP PE,
POPHL ;Exit if isn't enabled
DEC SP ;May be disabled.
DEC SP ;Let's see if stack bottom
POP HL ;is still OOOOh.
LD A,H ;Are any bits set in H
OR L ;or in L?
POP HL ;Restore old contents.
RET NZ ;HL <> O : isn't enabled.
SCF ;Otherwise, they really are
RET ;disabled.
POPHL:
POP HL ;Exit when P flag is
RET ;set by LD A,I
END
Ты можешь протестировать его с помощью Visual Z80 Remix: https://floooh.github.io/visualz80remix/
Мне не нужно его тестировать на модели, мне нужно теоретическое описание, чтобы проверить, почему оно так происходит по схеме реверса.
Кстати, на основе чего создан visualz80remix? На основе Z80 Explorer'а?
Вообще-то я выкладывал в теме и потранзисторную схему, и схему логическую.
И действительно, даже нашёл что я тут уже и раньше писал. Пожелание собрать все полученные результаты (транзисторные и логические схемы, находки) и скомпилировать их как документ или оформить как вики. Читать форум вперемешку с сообщениями не удобно.
Также хотелось бы понять -- тут реверсится только конкретная модель Z80 (та на которой базируется VisualZ80) или уже началось всё подряд (кмос-шмос)?
ZjoyKiLer
03.10.2024, 22:59
Мне не нужно его тестировать на модели, мне нужно теоретическое описание, чтобы проверить, почему оно так происходит по схеме реверса.
Кстати, на основе чего создан visualz80remix? На основе Z80 Explorer'а?
Я думаю, что он использует тот же нетлист, но является более продвинутым и исправляет некоторые ошибки. Это независимая разработка, эволюция Visual Z80 (http://www.visual6502.org/JSSim/expert-z80.html). Visual Z80 Remix - лучший симулятор, и если вы обнаружите ошибку, ее автор быстро ее исправит, если вы ему сообщите.
С помощью этого симулятора мы открыли новые вещи. Например, что процессор не принимает второй NMI, пока отвечает на NMI, или что MEMPTR модифицируется во время дополнительного цикла, который декрементирует PC в инструкциях блока ввода-вывода, или что RETI и RETN не принимают маскируемое прерывание, если IFF1 и IFF2 не имеют одинакового состояния перед выполнением этих команд.
Также хотелось бы понять -- тут реверсится только конкретная модель Z80 (та на которой базируется VisualZ80) или уже началось всё подряд (кмос-шмос)?
Он основан на одной модели, на нетлисте Zilog Z80 NMOS, векторизованном много лет назад людьми из Visual 6502, кажется, я помню.
- - - Updated - - -
Titus, я обновил комментарий на предыдущей странице о ld a,{i|r}, я включил официальное объяснение Zilog.
Пожелание собрать все полученные результаты (транзисторные и логические схемы, находки) и скомпилировать их как документ или оформить как вики. Читать форум вперемешку с сообщениями не удобно.
Пока идет процесс причесывания реверса, познавания тайн процессора, схемы модифицируются, переподписываются и перегруппируются. Поэтому финального варианта с точкой еще нет.
- - - Добавлено - - -
Visual Z80 Remix - лучший симулятор, и если вы обнаружите ошибку, ее автор быстро ее исправит, если вы ему сообщите.
Этот эмулятор воспроизводит шум команд SCF/CCF в 5 и 3 флагах?
ZjoyKiLer
04.10.2024, 12:28
Этот эмулятор воспроизводит шум команд SCF/CCF в 5 и 3 флагах?
Нет. Он дает детерминированный и стабильный результат. YF и XF берутся из значения битов 5 и 3 результата (Q ^ F) | A.
https://i.postimg.cc/MKmcVbwg/ccf.png
Titus
Есть идеи по реализации плавающих битов SCF/CCF в HDL?
Есть идеи по реализации плавающих битов SCF/CCF в HDL?
Легко. Генератор случайных чисел с регулируемой интенсивностью в зависимости от бит окружения, наиболее влияющих на результат. Очень хорошо по моему тесту видно, как надо сделать. И он же может проверить.
- - - Добавлено - - -
(Q ^ F) | A.
Зачем делается Q ^ F?
ZjoyKiLer
04.10.2024, 13:27
Зачем делается Q ^ F?
Именно формула, открытая Патриком, используется для вычисления этих флагов. Коэффициент Q - это абстракция, представляющая собой защелки внутри АЛУ, в которых процессор вычисляет новые обновленные значения флагов, которые будут переданы в регистр F во время T3 следующего цикла M1. Инструкции, которые не изменяют флаги, устанавливают Q в 0, а те, которые изменяют флаги, копируют F в Q. Ты также можешь использовать QFF, который будет представлять собой фиктивный флип-флоп, указывающий, модифицировала ли предыдущая инструкция флаги или нет. Это зависит от тебя и от того, как ты хочешь это реализовать.
Объяснение:
https://github.com/redcode/Z80_XCF_Flavor
https://worldofspectrum.org/forums/discussion/41704
Инструкции, которые не изменяют флаги, устанавливают Q в 0, а те, которые изменяют флаги, копируют F в Q.
Про буферный регистр флагов я знаю, я его на схеме вижу. Но содержимое из него никогда не xor'ится с содержимым F.
ZjoyKiLer
04.10.2024, 15:26
Про буферный регистр флагов я знаю, я его на схеме вижу. Но содержимое из него никогда не xor'ится с содержимым F.
Это способ обозначить, модифицировала ли предыдущая инструкция флаги. Если она их изменила, то новые значения будут взяты только из A. В противном случае они будут взяты из F | A. Когда F копируется в Q, результат Q ^ F равен 0, поэтому значение будет взято только из A, так как 0 | A - это A.
Не знаю, что именно имел в виду Патрик под буферным регистром флагов, но мне кажется, что не то, что есть в реальности.
На самом деле реальный буферный регистр флагов работает несколько иначе.
Его отдельные биты в зависимости от ситуации могут либо копировать текущее содержимое флага, либо принудительно сбрасывать какой-то флаг, либо принудительно устанавливать, либо устанавливать в зависимости от результата работы АЛУ, либо устанавливать в зависимости от каких-то еще состояний (тригера IFF2 и т.д).
А вот уже этот буферный регистр потом переписывается в основной регистр флагов. Причем, 5 и 3 биты в буферном регистре отсутствуют.
SoftLight
05.10.2024, 00:12
Т34ВМ1 (https://ru.wikipedia.org/wiki/%D0%A234%D0%92%D0%9C1_%D0%B8_%D0%A234%D0%92%D0%931 )
Процессор разработан в НИИТТ. Главным конструктором назначили Юрия Леонидовича Отрохова, который и ранее выступал с инициативой такой разработки. Открывая ОКР, он изволил пошутить: будучи по гороскопу рыбой, он и ОКР присвоил шифр "Рыба", а вспомнив танкистскую молодость, микропроцессор назвал Т34. Но Отрохов, как и его коллеги по отделению, умели разрабатывать оригинальные микропроцессоры, а воспроизводить аналоги им еще не приходилось. Поэтому в состав разработчиков были включены специалисты подразделений НИИТТ, умеющие восстанавливать электрическую схему ИС по ее топологии. За 9 месяцев после четырех итераций им удалось сделать n-MOP микропроцессор Т34ВМ1 (КМ1858ВМ1, КР1858ВМ1) – полный аналог микропроцессора Z80А, выполненный по 2-мкм технологии. В ходе проектирования, благодаря тому, что в группе разработчиков были специалисты и по созданию новых ИС, и по воспроизводству аналогов, были выявлены и расшифрованы хитрости компании Zilog, направленные на защиту от копирования. Например, обнаруживались ложные логические связи, заблокированные при помощи оптически не видимых встроенных каналов. В результате тополог видел, например, элемент 3И-НЕ, а работал он как 2И-НЕ. Выявить такие ловушки, убедившись в неработоспособности схемы, сначала удавалось, только исследуя элементы схемы внутри кристалла при помощи зондовых анализаторов. Но поняв принцип построения ловушек, отработали и механизм их обнаружения. В результате удалось сделать полный функциональный аналог Z80, хотя электрическая схема и топология Т34ВМ1 имели некоторые отличия.
made in USSR так сказать :v2_dizzy_punk:
https://i.ibb.co/kyzdT40/image.jpg
https://rutube.ru/video/6af89a2e3f08e77472eb618fdeeeed5c/
Т34ВМ1
Интересно.
Распределение точно такое же, как и у GoldStar Z8400A PS, а не такое, как у ST Z8400AB1 и Zilog Z0840004PSC.
Распределение точно такое же, как и у GoldStar Z8400A PS
видимо копировали с GoldStar Z8400A :)
видимо копировали с GoldStar Z8400A
Ну да. Или с какого-то ему подобного.
А если точнее, то с линейки, с которой сделан восточногерманский U880/5.
Тогда как КР1858ВМ1 сделан с другой маски - U880/6, площадь кристалла уменьшена, переработана разводка, да и по тестам не шумит.
Но у нас мало статистики (https://zx-pk.ru/threads/34173-revers-inzhiniring-z80.html?p=1204503&viewfull=1#post1204503), люди тесты на реалах не делают особо)
- - - Добавлено - - -
Если ориентироваться по фоткам кристаллов с сайта zeptobars'а, то мы имеем как минимум три варианта NMOS-разводки:
Оригинальный GoldStar Z80, фотография взята из документа 'Searching traps in Zilog Z80 CPU' за авторством Сергея Скоробогатова. Судя по внешнему виду, именно подобный кристалл использовался для проекта Z80 Explorer, из которого я делал реверс.
https://pic.maxiol.com/images2/1728131563.531452695.goldstarz80mini.jpg
Т34ВМ1, он же восточногерманский U880/5. Судя по дате на кристалле, разводка 1984 года, размер кристалла 4513x4251 µm, нормы 5 µm. По тестам шума сходен с GoldStar Z8400A.
https://pic.maxiol.com/images2/1728107471.531452695.zeptobars3419112451.jpg
Следующее поколение - КР1858ВМ1, он же восточногерманский U880/6. Разводка уже 1990 года, размер кристалла 3601x3409 µm. По тестам не шумит, так же как и Zilog Z0840006 PSC (но вовсе не обязательно, что разводка одна и та же).
https://pic.maxiol.com/images2/1728107724.531452695.zeptobarskr1858vm1h.jpg
И, наконец, Z0840004PSC. Размер кристалла 3545x3350 µm. Тесты шумят так же, как и у ST Z8400AB1.
https://pic.maxiol.com/images2/1728107928.531452695.zeptobarsz80z084000.jpg
- - - Добавлено - - -
Хорошо бы понять, с какой версии кристалла делался проект Z80 Explorer. И наш реверс, соответственно.
ну у меня ставки что это был
http://visual6502.org/wiki/index.php?title=Chips_in_our_collection
Zilog Z80 8453 Z8400PS DIP40 7:capture
ПС:
7: Modeling, capturing, vectorizing components
----------------------------------------
смотреть на
/web.archive.org
в районе 2020г
- - - Добавлено - - -
Несколько не стандартно расписан проц
How to Program Z80 - Zaks.pdf
https://disk.yandex.ru/i/dM9qZntNHHqyMQ
А этопро "ловушки"
Z80_traps.pdf
https://disk.yandex.ru/i/KnhyycW1ygmlww
Zilog Z80 8453 Z8400PS DIP40 7:capture
ПС:
7: Modeling, capturing, vectorizing components
Хорошо, возьмем за рабочую гипотезу, что это был именно он. Но еще нужна фотка кристалла для сравнения с остальными.
Если это именно Z8400PS, то тогда наш самый ранний корейский в статистике и есть он. Или его германский аналог U880/5 и наш Т34ВМ1.
Или его германский аналог U880/5 и наш Т34ВМ1.
у меня подозрение, что U880 и Т34 - вообще одно и то же, наши корпусировали то, что немцы напекли(ну или наеборот - немцы пекли то, что наши отреверсили). Несмотря на сказки, импортозамещение на старте, чО. (личное мнение, имхо:))
Так то есть и то и другое (Т34 в керамике) и третье КР1858ВМ. Проверить на том же самом компе что?? но только одно, ибо лапки, т.е. цанги, будь они не ладны :)
Так то есть и то и другое (Т34 в керамике) и третье КР1858ВМ. Проверить на том же самом компе что?? но только одно, ибо лапки, т.е. цанги, будь они не ладны
Обязательно все надо проверить.
- - - Добавлено - - -
А этопро "ловушки"
Z80_traps.pdf
https://disk.yandex.ru/i/KnhyycW1ygmlww
Добавил в список кристаллов (https://zx-pk.ru/threads/34173-revers-inzhiniring-z80.html?p=1204622&viewfull=1#post1204622) фотографию из документа.
- - - Добавлено - - -
Несколько не стандартно расписан проц
В чем нестандартность?
Это симулятор.
http://www.visual6502.org/JSSim/expert-z80.html
у него на "схеме" справа (там где пады для выводов) по середине есть буковки "8400"
Вот здесь фото "original Zilog's Z80"
здесь тоже есть буковки "8400"
-------------------------------
August 26, 2013
Zilog Z80 Z0840004PSC : weekend die-shot
After taking photos of Z80-compatible CPU's from DDR and USSR we finally got the original Zilog's Z80. This chip had datecode 9012.
http://s.zeptobars.ru/z80-Z0840004PSC-HD.jpg
--------------------------------
пс: ааааа про это уже было сказано выше....
пспс: не стандартно : это в блок схемах процессора указаны относительно подробнее чем в других "книжках". Я если что про 2 главу.
пспс: не стандартно : это в блок схемах процессора указаны относительно подробнее чем в других "книжках". Я если что про 2 главу.
Ну только это не имеет никакого отношения к реальной внутренней структуре Z80) Как и в других документациях с упрощенным описанием внутренностей Z80.
- - - Добавлено - - -
Тайна команды OUT (C),0 также раскрыта!
а меня интересует недокументированная команда #ED71 OUT (C),0
и вроде так она выполняется на NMOS, на CMOS в порт засылается #FF
Как и ожидалось, никаких особых подводных камней в этой команде нет. Все происходит так, как и предполагалось.
Из-за того, что регистра с кодом 110 не существует, в такте M4.T1.3 хоть и активизируется сигнал SEL_REG_SRC, но ни один из регистров не выбирается.
Каждый положительный полутакт (CLK = 1) комплементарные шины блока регистров REGBIT0..15, /REGBIT0..15 заряжаются до плюса питания, а уже во время отрицательного полутакта (CLK = 0) с инверсной части шины на HBUS и/или LBUS читается значение регистра. Так как чтение происходит только с инверсной шины /REGBIT0..15 (обе шины используются только при записи), то заряженная до плюса питания инверсная шина /REGBIT0..15 при чтении нам дает 0. Вот и все загадки.
Тот же самый эффект используется в команде INF. Из порта значение читается в никакой регистр по тем же самым причинам. И остается побочное явление - одни только флаги.
Кстати, я сперва не посмотрел часть схемы с выбором регистра WZ.
А ведь он выбирается всегда, когда не выбран никакой другой регистр!
Ну еще он не выбирается в такте M1.T3 и М1.Т4, когда регенерируется память.
Так что, возможно, записывается в порт не 0, а он)
- - - Добавлено - - -
Посмотрел еще блок формирования сигнала READ_REG и выбора половинки регистров.
Если я правильно анализирую схему, то работа происходит со старшей частью регистра - W.
Придется сделать тест, чтобы выяснить, не являются ли команды OUT (C),0 и INF на самом деле командами OUT (C),W, и IN W,(C)
- - - Добавлено - - -
А тест очень простой.
Сделать в цикле такое:
LD BC,$F7FE // порт клавиатуры, клавиши 1-5
INF (предполагаем, что это IN W,(C))
OUT (C),0 (предполагаем, что это OUT (C),W)
цикл
Если при нажатии клавиш 1, 2, 3 будет меняться цвет бордюра, значит моя теория верна.
Если не будет, значит надо анализировать дальше.
- - - Добавлено - - -
Все, отбой.
Сигнал SEL_REG_SRC всегда блокирует выборку WZ.
А такая хорошая теория получалась)
Так что описание в предыдущем посту остается верным.
Lethargeek
05.10.2024, 21:40
а меня интересует недокументированная команда #ED71 OUT (C),0
и вроде так она выполняется на NMOS, на CMOS в порт засылается #FF
заряженная до плюса питания инверсная шина /REGBIT0..15 при чтении нам дает 0. Вот и все загадки.
?
?
Вопрос по CMOS-версии пока что не ко мне, т.к. нет реверса.
Только по NMOS-версии.
Но думаю, что просто-напросто шина в CMOS не инверсная, а прямая, поэтому и записывается FF, а не 00.
Но варианты могут быть и другие.
Когда там команды подойдут блочные?
Когда там команды подойдут блочные?
Как до них дойдет время.
кстати-некстати, но недокументированные блочные команды (и флаги) в эмулях осилили, в ФПГА - не очень, Алексей сказал - нафиг, не стоит овчинка - выделки. "Неаккуратненько как-то, доктор(с)"
Алексей сказал - нафиг
Алексей - это кто? )
- - - Добавлено - - -
кстати-некстати, но недокументированные блочные команды (и флаги) в эмулях осилили, в ФПГА - не очень
Надо посмотреть природу этих флагов.
- - - Добавлено - - -
Посмотрел по схеме, какие еще команды влияют на флаги, но при этом не используют стандартные механизмы чтения/записи регистра источника/приемника через шины. Думаю, что эти команды надо будет рассмотреть внимательнее в плане формирования флагов 5 и 3.
Вот список:
SCF/CCF (с ними все понятно)
BIT
ADD/ADC/SBC HL,dd
LDI/LDD/LDIR/LDDR
CPI/CPD/CPIR/CPDR
INI/OUTI/IND/OUTD
INIR/OTIR/INDR/OTDR
У нас пока что стоят в очереди.
Алексей - это кто? )
Алексей - это основной допиливатель Т80 за последние годы. Sorgelig, автор MiSTer
Вот последний допилинг в конце декабря не этого года
https://github.com/MiSTer-devel/ZX-Spectrum_MISTer/commit/5a4a3e3c53fa550d8888c429afad5b28a15ae296
Осталось буквально пару команд недоделанных))
Напомню, что Test SCF 9 (https://zx-pk.ru/threads/34173-revers-inzhiniring-z80.html?p=1204427&viewfull=1#post1204427) еще не провели на:
NEC D780C-1 (@goodboy)
Z84C0006PEC (@SoftLight)
Z804C0010PEC (@SoftLight)
Toshiba TMPZ84C00AP-6 (@SoftLight)
U880, T34 в керамике и КР1858ВМ (@zebest)
И вообще, у народа реалов хоть отбавляй, а тесты для статистики и изучения процессора делать ленятся.:v2_dizzy_facepalm:
- - - Добавлено - - -
Алексей - это основной допиливатель Т80
T80 - вообще не вариант. Никакого отношения к реальной структуре Z80 не имеет, как я понял.
T80 - вообще не вариант. Никакого отношения к реальной структуре Z80 не имее
If it looks like a duck, swims like a duck and quacks like a duck, then it probably is a duck
Выложил первые результаты по Toshiba T84C00:
https://github.com/emu-russia/SEGAChips/tree/main/T84C
Контент правится и дополняется в текущий момент, но можно кинуть "глаз" на обновления.
Моя часть исследования кастомного дизайна (АЛУ и регблок) будет в репе SEGAChips, остальное лично для меня интереса не представляет т.к. просто ну "какая-то логика" :) Не хочу показаться пренебрежительным, но что-то меня не штырит уже от стандартных ячеек, хочется прям в фотошопе порисовать дичь какую-то :)
Моя часть исследования кастомного дизайна (АЛУ и регблок)
Какой смысл рисовать только АЛУ и регистры? Без остальной логики оно не даст информации о работе процессора почти никакой. АЛУ примитивен и прост. Все нюансы как раз в логике.
- - - Добавлено - - -
О, оказывается на siliconpr0n.org полно качественных фоток кристаллов, как NMOS процессоров, так и CMOS.
T80 - вообще не вариант. Никакого отношения к реальной структуре Z80 не имеет, как я понял.
А и не надо в FPGA повторять внутреннюю структуру. Надо, чтобы команды выполнялись одинаково. И чтобы такого недетерминированного поведения, которое тут исследуют, не было. Ибо это первородное зло для процессора.
О, оказывается на siliconpr0n.org полно качественных фоток кристаллов, как NMOS процессоров, так и CMOS.
А и не надо в FPGA повторять внутреннюю структуру. Надо, чтобы команды выполнялись одинаково. И чтобы такого недетерминированного поведения, которое тут исследуют, не было. Ибо это первородное зло для процессора.
Как их выполнить одинаково, если ты не знаешь, почему они так выполняются, т.к. не знаешь внутреннюю структуру процессора?
Отсюда только два варианта - или полностью повторять структуру, даже если не знаешь, как оно работает. Или узнать как работает, и повторить, но более оптимизированно, не тупо в лоб.
Что же касается плавающих состояний - их вовсе не обязательно повторять. Да и пока что кроме 5 и 3 бит в команде SCF/CCF их обнаружено не было.
Какой смысл рисовать только АЛУ и регистры? Без остальной логики оно не даст информации о работе процессора почти никакой. АЛУ примитивен и прост. Все нюансы как раз в логике.
Ну а мне и не требуется. Интересует именно АЛУ и регблок, т.к. они custom design.
Serg6845
06.10.2024, 12:17
Напомню, что Test SCF 9 (https://zx-pk.ru/threads/34173-revers-inzhiniring-z80.html?p=1204427&viewfull=1#post1204427) еще не провели на:
NEC D780C-1 (@goodboy)
Z84C0006PEC (@SoftLight)
Z804C0010PEC (@SoftLight)
Toshiba TMPZ84C00AP-6 (@SoftLight)
U880, T34 в керамике и КР1858ВМ (@zebest)
TMPZ84C00AP-6 - картинка статичная, бордер белый, верхняя половина черная, нижняя - слева голубая, справа - синяя
Z84C0004PEC - картинка статичная, бордер белый, верхняя половина черная, нижняя - синяя
И вообще, у народа реалов хоть отбавляй, а тесты для статистики и изучения процессора делать ленятся.:v2_dizzy_facepalm:
ну ситуации разные бывают... у меня например реал "доработан" до такой степени что в нем NMOS не работают. а второй реал - в нем проц впаян (обычный Z0840004PSC, его уже тестироавли)
у меня например реал "доработан" до такой степени что в нем NMOS не работают.
Это из-за чего он может не работать? Высокая частота?
- - - Добавлено - - -
обычный Z0840004PSC, его уже тестироавли
Один экземпляр может показать шум, другой нет, если пороги где-то на грани.
SoftLight
06.10.2024, 14:23
Z84C0006PEC (@SoftLight)
Z804C0010PEC (@SoftLight)
Toshiba TMPZ84C00AP-6 (@SoftLight)
А результатов по этим процессорам и нет:
- На ZXM Phoenix 9-ый тест на всех остальных процессорах ничего не показал, особо и снимать нечего.
- На Ленинграде-2012 тест начинает отрисовывать верхний правый прямоугольник и зависает. При старте теста в динамиках щелчок:
https://rutube.ru/video/ae8d258c2fe5b1952940a6348fad1b71/
Пробовал на разных процессорах, остальные тесты работают норм. От прошивки Спектрума не может как-то зависеть?
Пробовал на разных процессорах, остальные тесты работают норм. От прошивки Спектрума не может как-то зависеть?
Крайне неожиданно.
Нет, прошивка используется только чтобы напечатать сообщения на экране, а потом прерывания запрещаются и все.
- - - Добавлено - - -
При старте теста в динамиках щелчок
Щелчок это из-за OUT (C),0/$FF, чтобы бордюр окрасить.
Видимо, на CMOS щелкает, т.к. $FF выдается в порт.
Надо, чтобы команды выполнялись одинаково. И чтобы такого недетерминированного поведения, которое тут исследуют, не было. Ибо это первородное зло для процессора.Если речь про плавающие состояния каких-то флагов в некоторых командах, то почему же это зло? Имхо наоборот - очень полезная фича. Её можно использовать для true-random-number-генератора.
Особенно это полезно в нынешнее время. Из-за широкого распространения разного рода криптографии.
Если речь про плавающие состояния каких-то флагов в некоторых командах, то почему же это зло? Имхо наоборот - очень полезная фича.
Но только не в разных командах, а только в SCF/CCF пока что.
Но это да, реально генератор случайных чисел. Хотя, считать криптографию на Z80 как-то... )
Впрочем, на FPGA никак не получить именно реальную случайность, если нет специального блока генератора реальных случайных чисел. Впрочем, это вряд ли и нужно.
- - - Добавлено - - -
- На ZXM Phoenix 9-ый тест на всех остальных процессорах ничего не показал, особо и снимать нечего.
Хотя бы сказать цвет бордюра (NMOS/CMOS) и раскраску полей.
- - - Добавлено - - -
Пробовал на разных процессорах, остальные тесты работают норм. От прошивки Спектрума не может как-то зависеть?
Может быть в Ленинграде-2012 нельзя выдавать в порт $FE значение $FF?
Lethargeek
06.10.2024, 16:43
If it looks like a duck, swims like a duck and quacks like a duck, then it probably is a rubber likeaduck
FTFY :D
+ у T80 няп еще проблемы были и с кривыми таймингами на выходах (сейчас, может, уже исправили)
Особенности работы команды BIT n,r:
Хотя, проще будет описать отличия работы команды BIT n,r от ALU A,r:
1. В такте T3 в ALUB и ALUA загружается не регистр A, а байт маски.
2. В такте T4 в ALUA загружается регистр r.
Говоря проще, в командах ALU A,r в ALUA находился регистр A, а в ALUB регистр r.
А в команде BIT n,r в ALUA регистр r, а в ALUA байт маски.
3. Далее происходит работа АЛУ в режиме AND.
Напомню, что в режиме AND все биты переноса форсируются в установленные. Поэтому входящий флаг переноса, который берется из бита H в начале команды устанавливается в 1.
По итогу работы команды флаги устанавливаются точно так же, как и после команды AND, за исключением флага C. Немного странно, что биты S и P почему-то считаются недокументированными.
Так как запись результата на шину HBUS в этой команде блокируется, то флаги 5 и 3 устанавливаются согласно последнему содержимому шины HBUS. А последним через шину передавался регистр r.
Вот и все загадки.
Serg6845
06.10.2024, 17:28
Это из-за чего он может не работать? Высокая частота?
частота стандартная, просто слишком много доработок (Ленинград1 из подписи) - в какой-то момент NMOS перестали работать. разбираться пока нет времени.
Один экземпляр может показать шум, другой нет, если пороги где-то на грани.
кстати да - с матюками загрузил туда TAP (там CF имени Pera Putnik) - и получил совершенно статичную картинку в точности как здесь
https://zx-pk.ru/threads/34173-revers-inzhiniring-z80.html?p=1204427&viewfull=1#post1204427
Ленинград-2 опять же из подписи
SoftLight
06.10.2024, 17:57
Хотя бы сказать цвет бордюра (NMOS/CMOS) и раскраску полей.
Ниже кино с тестом сразу 7 процессоров:
https://rutube.ru/video/ad1e228527940c87584dbdaebb4a7b89/
Как до них дойдет время.
как то медленно идёт...
Ниже кино с тестом сразу 7 процессоров:
CMOS процессор Toshiba TMPZ84C00AP-6 - JAPAN9908EFI выбился из общей линейки.
Он почему-то показывает поле F5=0,A5=1 - равно нулю, вместо 1.
А еще процессор Zilog Z0840004PSC - Z80 CPU 9112 CT - оказался стабильным,
хотя Zilog Z0840004PSC - Z80 CPU 9040 LJ (от П321) - глючит стандартно. Видимо, разные условия работы (напряжение и т.д.)
- - - Добавлено - - -
Обновил список (https://zx-pk.ru/threads/34173-revers-inzhiniring-z80.html?p=1204503&viewfull=1#post1204503) статистики.
- - - Добавлено - - -
Кстати, обнаружил в реверсе ошибку из-за того, что потерял два транзистора в транзисторной схеме. Как я уже упоминал, это, пожалуй, единственный способ накосячить при переводе - потерять транзистор. Других ошибок наделать сложно. И когда стал разбирать команду BIT, получалось, что она работать никак не может. Ошибку нашел, транзисторы вернул на место.
По итогу работы команды флаги устанавливаются точно так же, как и после команды AND, за исключением флага C.
и как же выставляются флаги после команды AND?
Titus ты бы вынес бы всё что косается расписывания команд в одельное место (так что бы не срали), а то в 100500 страничках что то найти крайне проблемотично, а следовательно и нет никакой необходимости (это если ты хочешь что бы твоими наработками пользовались)
кстати, да.
для подобного на форуме есть раздел дневники.
SoftLight
08.10.2024, 00:08
@Titus (https://zx-pk.ru/member.php?u=748) ты бы вынес бы всё что косается расписывания команд в одельное место (так что бы не срали), а то в 100500 страничках что то найти крайне проблемотично, а следовательно и нет никакой необходимости (это если ты хочешь что бы твоими наработками пользовались)
Меня всегда поражает на форуме одна и та же повторяющаяся ситуация. Вот, допустим, кому-то интересна какая-то тема. Человек исследует и делится откртытиями с сообществом. И вот в тему приходит другой человек и пишет ПОЛТОРА ДЕСЯТКА сообщений о том, как ему это все неинтересно и какая вообще это все ненужная никому фигня. Да все все поняли, не нужная тебе это ерунда. Ну чего ходить в эту такую неинтересную тему и писать как это все отвратительно.
В смысле не нужно? Яж написал что нужно компактная выписка, а не поиск в 100500 страниц?
- - - Добавлено - - -
Ты попутал с ccf и scf в соседней теме, не путай. А то всегда найдется чел, который не разобравшись, делает выводы
- - - Добавлено - - -
Титус вот ты написал как в and, а как оно в нем я хз, где искать, я хз, не перелистывать же 48 страниц. Но ты проигнорил мой вопрос, а потом вы обижайтесь..
Титус вот ты написал как в and, а как оно в нем я хз, где искать, я хз, не перелистывать же 48 страниц. Но ты проигнорил мой вопрос, а потом вы обижайтесь..
Команда AND описана всеми, кому не лень, и в фирменной документации тоже.
Понятно, что ничего не понятно.
Документация полная и детальная, но не полная и не детальная...
Согласен с предыдущими ораторами, форум это древний и неудобный формат общения.
Мы все результаты выкладываем на гитхаб и оформляем как Markdown (быстро, просто и красиво получается).
А всё обсуждение происходит в чате, т.к. по сути оно только уточняет формализацию, а после просто "замусоривает" контент.
Не призываю к революции, можно же и альтернативный вариант -- выложить результаты куда-то в компактном скомпилированном виде (хоть в .txt файл), а обсуждение продолжить как и раньше в этой ветке.
Но формализация результатов в отдельном виде нужна. Т.к. нет форума - нет и информации (мало ли что, хостинг упал, ддос и проч.)
выложить результаты куда-то в компактном скомпилированном виде
Понятное дело, что финальные результаты надо выложить компактно, чтобы никто не собирал информацию по тысячам страниц форума.
Где их можно уже лицезреть, хотя бы то что накопано?
Где их можно уже лицезреть, хотя бы то что накопано?
Мне нечего сказать стоящему в воде, который не может напиться.:v2_dizzy_botan:
Все только в этой теме.
Хотя, есть чего - постарайся поменьше флудить)
Хотя, есть чего - постарайся поменьше флудить)
я могу не заходить, жаль что ты воспринимаешь это ка флуд...
Выполнена основная часть исследования по регблоку TOSHIBA Z80 MPU (CMOS).
https://github.com/emu-russia/SEGAChips/blob/main/T84C/regblock.md
Выкладываю также пдф для (более комфортного?) чтения: https://github.com/emu-russia/SEGAChips/releases/tag/toshiba-regblock-rev1-pdfs
Синопсис: работа регблока почти не отличается от эталонной NMOS реализации, которая тут ковыряется. Если что-то обнаружим подозрительное описание будет дополнено.
Выполнена основная часть исследования по регблоку TOSHIBA Z80 MPU (CMOS).
Я так понял, потранзисторную схему всего чипа никто рисовать не будет?
- - - Добавлено - - -
Тошиба случайно не TMPZ84C00AP-6?
Она в тестах SCF9 давала другие результаты, чем все остальные Zilog'овские CMOS.
Я так понял, потранзисторную схему всего чипа никто рисовать не будет?
Транзисторные схемы мы уже давно не делаем для всего чипа, сразу переходим к модульному дизайну (вентили целиком, стандартные ячейки). Для некоторых хитрых модулей трансы иногда используются для уточнения работы ячеек.
Тошиба случайно не TMPZ84C00AP-6?
T84C00AM-5.
Транзисторные схемы мы уже давно не делаем для всего чипа, сразу переходим к модульному дизайну (вентили целиком, стандартные ячейки).
Не больше ли шансов накосячить, пропуская этап транзисторной схемы? Я понимаю, для регулярных структур, типа регистров, можно не рисовать все. Но для всякой разнообразной мелкой нерегулярной логики, которой бывает изрядно много?
Не больше ли шансов накосячить, пропуская этап транзисторной схемы? Я понимаю, для регулярных структур, типа регистров, можно не рисовать все. Но для всякой разнообразной мелкой нерегулярной логики, которой бывает изрядно много?
Шанс накосячить в трансах гораздо выше чем в ячейках, но да, ошибки случаются, исправляются. Цифровая логика она, знаешь ли, очень логичная :) Если где-то косяк, то его сразу видно на прогоне в тест бенче или логисиме.
- - - Добавлено - - -
P.S. Если интересно какой у нас workflow, то его можно наблюдать из раздела по IDU CLA: https://github.com/emu-russia/SEGAChips/blob/main/T84C/regblock.md#idu-carry-lookahead
1. Получается топология (необязательно, если вместо кастомного дизайна используются стандартные ячейки)
2. Из топологии выделяются логические элементы (в IDU CLA это куча nand, not, nor)
3. Определяются порты (input, output) исследуемого куска схемы
4. В утилите Deroute получается netlist. Этот шаг можно представить по аналогии с дизассемблированием программ - получается как бы "исходник" (дизасм)
5. Утилита Deroute умеет экспортировать готовый к употреблению Verilog исходник ( https://github.com/emu-russia/SEGAChips/blob/main/T84C/netlist/idu_cla.v )
6. Полученный верилог можно запихать куда угодно (для симуляции например). В частности верилог был запихнут в Xilinx PlanAhead и она сама "нарисовала" логическую схему которую можно вдумчиво вкурить, разобрать на части, проверить в логисиме. Или сразу использовать верилог в прикладных целях.
Такой подход мы используем где-то последние два года и он МЕГА эффективный для изучения микросхем.
2. Из топологии выделяются логические элементы (в IDU CLA это куча nand, not, nor)
Т.е. базовым элементом отреверсенной схемы является логический n-входовый элемент?
Ну это тоже неплохо.
- - - Добавлено - - -
Цифровая логика она, знаешь ли, очень логичная Если где-то косяк, то его сразу видно на прогоне в тест бенче или логисиме.
В основном да. Но могут быть нюансы, если, например, перепутал полярность тактового сигнала, и что-то сдвинулось на пол-такта. Вроде и работает по скорости так же, а тайминг чуть нарушен.
Т.е. базовым элементом отреверсенной схемы является логический n-входовый элемент?
Ну это тоже неплохо.
- - - Добавлено - - -
В основном да. Но могут быть нюансы, если, например, перепутал полярность тактового сигнала, и что-то сдвинулось на пол-такта. Вроде и работает по скорости так же, а тайминг чуть нарушен.
Не обязательно один логический, это может быть композитная ячейка составленная из кучки nand,nor,mux и часто повторяющаяся (например DFF). Тут применяется подход, схожий с "макро-программированием" (макросы).
Про полярность сигнала это старая боль, нужно просто глаз набить на это. Есть простое правило как не запутаться в полярности - если сигнал проходит not, nor или nand, то не важно с какими другими сигналами он замешивается - на выходе полярность поменяется.
То есть если условно на вход какой-то схемы пришёл сигнал "a" с точно известной полярностью и нужно узнать полярность выходных сигналов, нужно всего-лишь пробежаться по цепочке элементов и каждый раз менять полярность после прохода через not,nand,nor.
(причём это можно делать и задом-наперёд)
Предварительное описание особенностей работы M-циклов:
Каждый M-цикл отвечает за новый доступ к памяти. Поэтому, собственно, он и называется M-циклом.
M1 отвечает за выборку кода операции. В общем случае длится 4 такта, но может увеличиваться до 6 тактов. Во время этого цикла выполняется текущая и завершается предыдущая стандартная АЛУ-операция.
M2 отвечает за выборку байта смещения для индексной адресации. В общем случае длится 3 такта. Он используется как в методах адресации с индексными регистрами, так и в командах относительного перехода (JR, DJNZ). Если цикл используется в команде условного перехода, и условие не соблюдено, то является последним циклом команды.
В этом цикле после чтения байта смещения из памяти происходит его загрузка в ALUB, а младший байт адреса (PC.L или IDX.L) загружается в ALUA. После чего складывается младшая часть адреса и байт индекса. Далее устанавливается знак для следующей АЛУ-операции (плюс или минус) в зависимости от старшего бита байта смещения, если это команда относительного перехода.
M3 отвечает за продолжение вычисления исполнительного адреса для индексной адресации. Обычно длится 5 тактов.
Так как этот цикл используется для вычисления исполнительного адреса, в нем блокируется доступ к внешней памяти по адресу, автоматически загруженному в PCR в предыущей команде.
В этом цикле полученный в АЛУ младший байта адреса сохраняется PC.L или WZ.L, затем в АЛУ загружается старшая часть адреса, и константа 0, для сложения со старшей частью адреса, и снова складывается и записывается в PC.H или WZ.H.
В результате, если это команда перехода, в регистре PC получаем новый адрес. Если же это команда индексной адресации, то в регистре WZ получаем исполнительный адрес.
Циклы M2 и M3 могут быть пропущены, если команда не использует индексную адресацию.
M4 отвечает за байтовый доступ к памяти в стандартных командах типа ADD A,(HL) или ADD A,(IX+nn). Обычно длится 3 такта.
M5 пока не изучался, но, похоже используется в 16-битных командах, таких как ADD HL,dd, PUSH/POP HL, LD (nn),dd и т.д.
- - - Добавлено - - -
p.s.: Небольшая ремарка. Некоторые действия могут инициироваться в одном M-цикле, а завершаться в следующем, т.к. чуть ли не большая часть активности процессора всегда задержана на пол-такта или такт относительно такта, инициировавшего ее.
M-цикл это "машинный цикл", из официального программинг мануала от создателей: https://www.zilog.com/docs/z80/um0080.pdf
M-цикл это "машинный цикл", из официального программинг мануала от создателей:
И так так тоже подходит по смыслу)
- - - Добавлено - - -
Про полярность сигнала это старая боль, нужно просто глаз набить на это.
Как не набивай глаз, невнимательность никто не отменял. Особенно при работе с большими схемами. У меня это почти единственный тип ошибок при переводе транзисторной схемы в логическую. И да, 99% таких ошибок, если не 99.99% приведут к неработоспособности того или иного участка схемы и будут замечены.
Как не набивай глаз, невнимательность никто не отменял. Особенно при работе с большими схемами. У меня это почти единственный тип ошибок при переводе транзисторной схемы в логическую. И да, 99% таких ошибок, если не 99.99% приведут к неработоспособности того или иного участка схемы и будут замечены.
Не очень понял как можно сломать схему, если перепутать название (полярность) сигнала, ну да ладно :)
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot