Я припоминаю, что для отладки шадков писал свои маленькие тестики кваза -- потому что выуживал разные частные случаи. Но по-моему у меня никаких записей этого не сохранилось.
Вид для печати
Я припоминаю, что для отладки шадков писал свои маленькие тестики кваза -- потому что выуживал разные частные случаи. Но по-моему у меня никаких записей этого не сохранилось.
Аналогично писал тесты для нового старого квазидиска, все можно найти в соответствующей теме, вот тут и немного ранее.Цитата:
Сообщение от svofski
Тесты КД, которые запускаются из под МикроДоса?
Из под монитора-отладчика, из под микродоса не получится протестировать, т.к. в процессе данные с КД удаляются.Цитата:
Сообщение от KTSerg
Ясно, поэтому у файла теста такое расширение ".m01".Цитата:
Сообщение от Improver
Пробовал "двигать" спад F2.
Укоротил F2 на ~20нс - ошибки появились через 5 минут "Дождя".
Увеличил длительность F2 на ~26нс (от нормы) - 35 минут тестировался без ошибок.
Смещение фронтов сканером пока не фиксировал.
Сканером ВУ много раз сканировал (со стандартными F1 и F2) процесс тестирования КД "Дождём" и с реальным процессором и с ПЛИСовым, визуально графики ни чем принципиально не отличаются. Конечно я не могу быть уверенным, что ловил момент сбоя. Даже скорее всего не ловил. Но так как сбои КД не постоянные, не представляю, как сканером выловить подобный момент, так как не известны признаки.
Не могут быть отличия во фронтах из-за различий в нагрузочной способности? Переходные процессы занимают разное время, вот и сместились на десяток нс тут, десяток там. К замерам, даже очень аккуратным, это тоже относится.
А я бы поставил на величину запаздывания управляющих сигналов относительно клоков. У быстрых 8080 это запаздывание меньше, чем у медленных и это может приводить к отличиям в работе в составе компа. На а у плисового vm80a с pin_clk=100 МГц наверняка эти запаздывания меньше чем у самых быстрых 8080.
Не могу найти в ядре vm80a процессы, которые могли-бы реагировать на спад F2.
Т.е. от длительности F2 ни чего не должно зависеть.
Вот фронт F2 вроде должен формироваться уже после прихода внешнего "READY".
Т.е. положение фронта F2 - критично, а спада вроде как нет...
Я говорю о внутреннем F2, который я эмулирую для ядра.
Там много мест, где важно текущее значение f2, а значит и положение и длительность f2.
Это понятно, но при clk = 100МГц, думаю эти always-ы успевают за один f2 выполниться несколько раз.Цитата:
Сообщение от ivagor
Пока не разобрался, важно-ли только первое срабатывание, или за один f2, каждый "posedge clk" в одном always происходит что-то новенькое...
И поэтому важно текущее значение f2Цитата:
Сообщение от KTSerg
конечно такЦитата:
Сообщение от KTSerg
Тогда нужно точно знать, сколько должно быть "posedge clk" за время пока f2 находится в "1".Цитата:
Сообщение от ivagor
Проблема в том, что за один f2, который является enable, проскакивает несколько posedge clk? Наверное это можно решить добавив еще один сигнал, который по posedge clk и f2 сделает disable. Но его тоже надо как-то сбрасывать. В общем это та еще возня ;)
Пытаюсь разобраться в эмуляции на плисе "580vm80a" и что-бы хоть что-то в ней найти, ещё и пытаюсь экспериментировать с modelsim...
Написал программку в несколько строк, скомпилировал для проекта "580vm80j", всё остальное в архиве уже есть для симуляции в modelsim.
Сам проект "vm80" без изменений, заменил только код программы выполняемой процессором при симуляции.
Запускаю, разглядываю графики, и ни как не могу понять, почему после команды 05h - "dcr b", на шину адреса попадает состояние регистровой пары "BC"...
Скриншот в прицепе.
С моей точки зрения, при выполнении команды "dcr b", значение пары "ВС" не должно попадать на шину адреса... или я что-то не понимаю?
А после команды 23h - "dcx h", на шину адреса вылазит значение пары "DE" (предположительно).
https://disk.yandex.ru/i/el8u23GE4oYNmg
А по какому признаку определяется валидность адреса на шине? Я позабыл. По идее все время, пока этого признака нет нет, там может быть любой мусор. А в этих процах все кишками наружу торчит.
Проверить, не попадает ли на ША содержимое регистровых пар сравнительно просто, например так
Скрытый текст
Код:loop:
lxi d,0123h
lxi h,4567h
lxi b,89ABh
lxi sp,CDEFh
dcx b
lxi d,1230h
lxi h,5674h
lxi b,9AB8h
lxi sp,DEFCh
dcx b
jmp loop
[свернуть]
Если мне не изменяет память, для декремента/инкремента регистровых пар используется то же исполнительное устройство, что и для PC, возможно это сказывается.
Особого криминала на временной диаграмме не видно, когда на ША "странные" адреса сигналы чтения и записи не активны.
В модуле процессора нашел вот такие стоки:
mxo - содержит значение регистровой пары с которой, в данный момент, идет работа.Код:module vm80a(
...
assign mxwadr = t3363 | (t4f1 & ~id_dad & ~id_hlt);
...
always @ (posedge clk)
if (f2)
begin
if (mxwadr) a <= mxo;
...
Приведённый кусок фактически говорит, что на каждом 4-ом такте, на шину адреса выкидывается содержимое текущей регистровой пары.
А 4-ый такт в моей тестовой проскакивает часто, включая команды: inx h\ inx d\ dcr b.
Посмотрел свои старые сканы ВУ, сделанные с настоящим процессором и с ПЛИС-вариантом.
ШАВВ идентична, а так как она часть шины адреса процессора, то можно считать, что и у настоящего процессора на ША выкидываются "потроха"...
Но когда совместил графики сканов ПЛИСа и реального процессора в одной анимации, то обнаружил интересную фишечку...
У ПЛИС-процессора изменения ШД, ШАВВ, ЧТЗУ - происходят по фронту CLK (6МГц), а у реального процессора - по спаду.
анимация сканов - https://disk.yandex.ru/i/QvpWt2JQWRtFsw
Пока все же остаюсь при старом мнении, что
Цитата:
Сообщение от ivagor
Цитата:
Сообщение от ivagor
Что-то я не совсем понимаю, вернее совсем не понимаю, как такое происходит...
Есть always, в котором регистру "acc" передаётся значение регистра "d".
Судя по всему acc должен получить новое значение при "posedge clk" и "f2==1" и "alu_awr==1".Код:always @(posedge clk)
begin
if (f2)
begin
if (alu_xwr) xr <= id_rst ? (i & 8'b00111000) : d;
if (alu_awr) acc <= d;
...
Но судя по графику ModelSim, "acc" меняет своё значение при "f2==0".
Инверсии "f2" в коде я не заметил.
Что я упускаю?
Запутался ещё больше.
Все процессы происходят при "инверсных" значениях сигналов "f1" и "f2", если верить графикам ModelSim.
Нужно сначала искать, где они инвертируются, в коде или при выводе в график.
Если в коде нет ветки else, то можно считать else acc <= acc;. Почему ModelSim решил показывать значение acc именно с этого posedge clk, знают только его разработчики. В принципе, если acc нигде больше не инициализируется, там должен быть мусор уже после первого posedge clk.
Можно считать, что acc больше ни где не инициализируется. В соседней строке кода есть ещё один IF, в коде так:Цитата:
Сообщение от b2m
Но второй IF в моём случае срабатывает значительно позднее.Код:...
if (alu_awr) acc <= d;
if (alu_ald) acc <= s;
...
А мусор в асс и есть до указанного момента, т.к. до него не было операций с аккумулятором.
Нельзя сказать "срабатывает". Регистр, в котором хранится acc, будет обновляться при каждом posedge clk (в таком варианте кода). Значение на входах регистра, если присутствует if, формируется при помощи мультиплексоров, а входы мультиплексоров в любом случае куда-то подключены. Если нет ветки else, то соответственно к выходу регистра acc.Цитата:
Сообщение от KTSerg
- - - Добавлено - - -
Данный код:
не содержит синтаксических ошибок, но тут не определён приоритет alu_awr alu_ald. Можно, конечно, надеяться, что приоритет последнего if выше, и код будет соответствовать следующему:Код:...
if (alu_awr) acc <= d;
if (alu_ald) acc <= s;
...
Код:if (alu_ald) acc <= s; else if (alu_awr) acc <= d; else acc <= acc;
Да, я понимаю.Цитата:
Сообщение от b2m
Я имел в виду, что значение "alu_ald" на изучаемом участке графика всегда равно "0", и код второй строки не выполняется в изучаемом интервале времени.
Подозреваю, что сигналы alu_awr и alu_ald ни когда не пересекаются. Так как отвечают за обозначение активности разных групп команд, первая активна при выполнении операций с памятью (при чтении/записи), вторая в момент выполнения арифметических операций:
assign alu_ald = t2222 & ( id_adc | id_add | id_daa | id_xra | id_sbb | id_sub | id_ana | id_ora | id_sha | id_cma);
По крайней мере, у меня создалось именно такое впечатление.
Но это уход в сторону от вопроса, почему в "асс" значение меняется не в ту фазу "f2".
До меня только недавно дошло, что частота clk = 50MHz, а частота "f1" и "f2" = 25MHz.
Если получится, попробую сначала в симуляторе снизить частоту f1 и f2, что-бы иметь графики, более приближенные к реальности.
На графике как раз видно, что асс меняется на 0 чуть раньше, чем ты поставил вертикальную линию, как раз по posedge clk (tb/clk), а в предыдущем клоке alu_awr установилось в 1.Цитата:
Сообщение от KTSerg
Вертикальную линию поставил не я, а ModelSim, который формировал график.Цитата:
Сообщение от b2m
Мне нравится, что acc меняется по posedge clk, к этому я претензий не имею.
Но на графике видно, что когда происходит "posedge clk", и асс меняется, f2==0 - что не соответствует коду.
Так как ветка в которой: "acc <= d", находится в ветке: "if (f2)" - и не должна работать, т.к. f2==0.
Вот это меня и смущает.
Ладно.
Сначала попробую уменьшить частоту сигналов f1 и f2, а потом снова буду смотреть графики... вполне возможно, что там будет ещё больше "чудес"...
Ну вот...
Модифицировал эмуляцию.
Влепил clk=100MHz (как в проекте, залитом в ПЛИСину), выставил длительности f1 и f2, приближенные к реальным (с интервалами между ними).
И сразу стало видно, какие сигналы меняются по переднему фронту f1, какие по переднему фронту f2.
И асс стал меняться как ему положено, при f2==1 (типа по переднему фронту).
Уже съедобные графики получились, можно дальше "ехать"...
Тестирую "хотелки" пока только на ModelSim-е...
Удалось упаковать 4 команды:
в одну: "ldmi" - копия байта из (de) в (m) с инкрементом указателей.Код:ldax d
mov m,a
inx d
inx h
При этом аккумулятор пока не используется и его значение не "портится".
Команда выполняется в ModelSim за 10 (4,3,3) тактов, предполагаю, что на Векторе будет выполняться за 12 тактов.
Не очень удобно, что в проекте "580vm80j" обозначение регистровых пар HL и DE - перепутаны :( сбивает с толку маненько...
Как посмотреть, xchg же их меняет (перекоммутирует)
Не, тут другое.Цитата:
Сообщение от ivagor
Например, выполняется команда: lxi d,0x0024 (11 24 00)
При этом 0x0024 записывается в регистр с именем "hl".
Соответственно, когда выполняется команда: lxi h,0x0024 (21 36 00)
значение 0x0036 записывается в регистр с именем "de".
Немного покумекал... сейчас одна команда выполняет функцию:
Регистр "di" штатно используется в процессоре, например в командах "mvi m,D8".Код:ldax d (без сохранения в аккумуляторе, читаем в "di")
mov m,di
inx d
inx h
dcr a
Тут ничего нагромождать не пришлось.
Для зацикливания достаточно:
Осталось разобраться, как "рс" вернуть назад на один адрес.Код:adr: ldmi
jnz adr
Дальше добавляем xchg и еще раз lxi d, и lxi h,Цитата:
Сообщение от KTSerg
А для чего это делать?Цитата:
Сообщение от ivagor
Вроде симулируется так как хотел.
Одна команда "ldmi" (за 10/12 тактов на байт/цикл) выполняет функцию:
Нужно загонять в ПЛИС и тестить на разных старых программах для проверки совместимости.Код:adr: ldax d (без сохранения в аккумуляторе, читаем в "di")
mov m,di
inx d
inx h
dcr a
jnz adr
А потом тестировать новый алгоритм вывода спрайта на экран.
Тест на реале показал, что моя доработка пока не совместима с командой "xchg".
Нужно разбираться.
Но если xchg не применяется, то в остальном пока тесты проходят.
В старый тест вывода спрайта (24х24 пикселя 3 плана) разными методами, добавил алгоритм с новыми командами.
https://disk.yandex.ru/i/o7WYXww9DNrz6A
Результаты "ЕВВ4" - это заглушки, так как в подпрограммах использовались xchg.
Получилось $27cd - 10189 выводов спрайта 24х24х3 за 10 секунд, это примерно 20 спрайтов за интервал между прерываниями.
Стек при выводе спрайта не используется, прерывания разрешены.
Для вывода спрайта используется аккумулятор и пары HL с DE.
Графики ModelSim показывают, что проблему с "xchg" удалось обойти.
Дело за тестами с ПЛИС на реальном Векторе.
На Альтеровской девборде с модифицированным vm80a, запустил тест скорости вывода спрайтов.
Алгоритм с моими командами копирования показал 27F8h = 10232 спрайта за 10 секунд, 20 спрайтов за одно прерывание.
https://disk.yandex.ru/i/K-VdzcM1NgSVmA
- - - Добавлено - - -
Подозреваю, что вставить в ПЛИС-процессор математику, ещё проще.
Нужно только разобраться как организовать чтение кода команды состоящего из двух байт (как у Z80), а не из одного как обычно.
Что-то я большего ускорения ожидал :(
Перелопатил тест скорости вывода ч/б текста в режиме 512*256, 80 символов в строку.
Получилось вот это, на фото.
https://disk.yandex.ru/i/Y-qN2o1AyyMDpQ
"Y" - успел вывести только в одну плоскость.
Фонты 8 байт на символ, горизонтально, одинаковые как для режима 256х256, так и для 512х256.
Предсдвиговых таблиц нет, проц сам сдвигает и маску накладывает.
Малость разочарован.
Есть какие-то стандарты по работе со спрайтам?Цитата:
Сообщение от ivagor
Типа как/какие характеристики спрайта указывать, в каком формате загружать?
Хочу попробовать загрузить спрайт 8х8х4 в М9К ПЛИСа.
Нужно ещё разобраться, как это всё отреагирует на запрос прерывания, во время выполнения такого безобразия...
По стандартам сложный вопрос. Можно сказать, что их нет, но более конструктивным будет ответ, что их определяют разработчики игр. Вспомним, кто делал последние игры - metamorpho и сейчас parallelno. В Binorum были спрайты без маски, можно сказать просто тайлы, в GameNoName - с маской.
Сам я игрушки с нуля делал только в юности, потом понял, что я не игродел и только участвовал в портировании, в первую очередь с msx. У msx есть свой стандарт представления спрайтов (даже два, если не ограничиваться первым msxом). Т.е. по оптимизации вывода специальновекторовских спрайтов - к игроделам, а я могу сравнительно квалифицированно сказать, что нужно для упрощения и улучшения конверсий с msx, но тут мы возвращаемся к тому, что я уже писал. Задача комплексная, если не ограничиваться какой-нибудь одной демонстрационной программой, то нужна не только реализация в плисе, но и поддержка эмуляторов и средств разработки. При таком подходе мне (повторюсь) кажется более-менее реалистичным вариантом только z80, при всех его недостатках. А если ограничиваться одной демкой, то надо делать так, как самому нравится и удобно. Это не совсем умозрительные рассуждения, у меня были попытки наворотов (к v06cc), например 256 цветов, но все закончилось на одном тесте, в эмуляторы не пытался добавить, кучу программ под это не написал.
Т.е. речь о реализации в ПЛИС "векторовского контроллера z80" с самим z80. Типа проц z80 с распиновкой i8080 ?Цитата:
Сообщение от ivagor