Просмотр полной версии : Эмуляция двухъядерного спектрума
Вопрос-предложение-идея к писателям эмулей.
Хотелось бы иметь такой эмулятор.
В железе наверное такого не бывает, но сымитировать можно.
Основная мысль
Запуская какую-либо прогу в таком эмуляторе получаем не одно спектрум-окно, а два.
Которые работают синхронно.
Первое - отображает то, что отображалось бы и работало как обычно.
А вот второе - это как-бы ещё один Z80, имеющий то-же самое адресное пространство, экран, порты и т.д. но выполняющий то, чем занимается прерывание.
Т.е. если запустить в таком эмуляторе какую-нибудь программу - она работает как должна, но если приходит прерывание - то "первый" Z80 просто игнорирует его (т.е. сразу делает RETI и продолжает исполнять код так, будто никакого прерывания не было).
А "второй" Z80 наоборот - едва пришло прерывание - начинает исполнять то, что указано в векторе прерываний и так до тех пор пока не дойдёт до RETI.
Зачем это нужно?
Возникает вопрос такой?
Я скажу зачем.
Не знаю кто как, а мне в процессе создания чего-либо под Спек очень не хватает диагностики.
Т.е. на экране происходит что-либо (ну допустим какой-нибудь эффект отлаживаю) - а мне нужно видеть какие-либо его характеристики которые представляют из себя несколько чисел печатаемые на тот-же экран.
Можно этот своеобразный "монитор-дебагер" повесить на те-же прерывания, но ведь ЭТО ТОРМОЗИТ САМ ЭФФЕКТ И ПОРТИТ ЭКРАН!
(т.е. не даёт оценить ни скорость, ни внешний вид).
А с эмуляцией 2-х Z80 можно было-бы повесить "монитор-дебагер" на IM2 и тогда в одном окне - то что будет на реал-спеке, а в другом - нужная инфа (динамически обновляемая, конечно, если бы речь шла просто об одноразовом выводе чего-либо - то не стоит и огород городить).
Итак:
Господа-товарищи эмульписатели!
Может кого заинтересует данная идея и поддержите?
А ведь чем чёрт не шутит, может и железячники слепят такой агрегат? Ничего принципиально невозможного тут нет. Хотя я думаю что вряд-ли кому такой спек в реале понадобится.
Но такой эмуль был-бы очень кстати.
Итог
Всё это только мои мечты, но если кто хочет себя попробовать в таком необычном деле (написании такого эмуля) я лично буду очень рад.
А может окажется что не я один такой, быть может и другие хотели бы иметь возможность следить за параметрами отлаживаемой программы.
(например AloneCoder в последнем движке Wolfa выводил количество фреймов в левом верхнем углу. Я думаю что ему хотелось бы видеть и многое другое относящееся к его программе, но скорость бы упала ещё меньше)
И как главный козырь - в такой концепции все программы под спек уже существующие, будут вполне себе работать и на "двухъядрах".
Такое вот пожелание.
где-то тут уже есть топик про платформу ZX-Poly, где трудятся четыре зетника в параллель... Эмулятор есть, но до железа так и не дошло...
сразу делает RETI
и все синхронизации завязанные на прерывание идут лесом? замечтательно...
нафиг это не нужно и делать не будут. есть проще решение: добавить реалтайм-окно watch, т.е. показ содержимого нужных ячеек памяти. посчитал, в память записал - увидел. а городить два проца и такое сомнительное управление.......
можно пойти дальше и каждую инструкцию выполнять своим процессором. Т.е. NOP выполняется одним процессором, а остальные инструкции этот процессор игнорирует. XOR A - дургим процессором, который игнорирует все остальные инструкции. И так далее... :D
Mad Killer/PG
03.11.2012, 09:03
Хорошaя идeя.Нeчто похожee дeлaeт vlad в Reversy.
добавить реалтайм-окно watch, т.е. показ содержимого нужных ячеек памяти
Ну хотя - бы так.
Хотя иной раз нужно не только показывание содержимого ячеек, но и графическое представление (график в текуще точке времени например, ну типа как в протракере индикатор AY) и т.п
Т.е. исполняемый код.
и все синхронизации завязанные на прерывание идут лесом? замечтательно...
А много ли их таких?
Да даже если много - такой эмуль нужен только для комфортного написания/отладки.
В железе наверное такого не бывает, но сымитировать можно.
Я прошу прощения конечно. Токо возник вопрос - а нафига? Ну если в природе не существует?
Ветку не читал, извините.
---------- Post added at 13:37 ---------- Previous post was at 13:30 ----------
Может кого заинтересует данная идея и поддержите?
Лично я - никогда! Почему - на Спеке есть два Z80. Один в самом Спеке, другой - в General Sound.
Ну давайте будем что-то делать под эмулируемые девайсы. Описание дадут. И - вперёд. Возникает вопрос - кто это будет воспринимать на реалах? Даже на той-же Pentevo!?
Давайте как-то под железо делать.
---------- Post added at 13:39 ---------- Previous post was at 13:37 ----------
Ну хотя - бы так
Это радует, если честно.
---------- Post added at 13:41 ---------- Previous post was at 13:39 ----------
И как главный козырь - в такой концепции все программы под спек уже существующие, будут вполне себе работать и на "двухъядрах".
А хоть схема такого Спека у тебя есть? С двумя Z80?
Николай, почитай ветку и поймешь.
Если кратко - то такого железа не существует (да оно и не нужно), а эмуль такой был-бы полезен при отладке.
(ну например ты ковыряешь бордерный эффект - все такты заняты, а второй Z80 может тебе на своем экране отображать нужную тебе инфу).
Destr, решаемая задача определенно имеет смысл, но решать ее надо 1000% не так.
Destr, решаемая задача определенно имеет смысл, но решать ее надо 1000% не так.
Не спорю, я не железячник и следовательно могу лоханутся (не зная как решаются такие дела - неправильно и думаю про эмуль).
Подскажи как надо?
да, окно watch и логи/некий интерфейс для внешней проги. во втором случае можно любых анализаторов нагородить, хоть графических, хоть каких. а чтобы не тормозить наблюдаемую прогу - сделать псевдокоманды (EDxx?), которые, например, занимают 0 тактов, а в лог бахают счетчик тактов + идентификатор события (например, начало отрисовки, конец, ...).
а не проще ли просто окно Watch добавить - гораздо удобней смотреть будет, чем писать Z80 код для наблюдения за переменной
Други!
Чтоб не было больше ненужных разговоров - вот вам живой пример, который позволит понять зачем я хочу такой эмуль:
http://zx-pk.ru/showthread.php?t=17106&highlight=%F2%E0%ED%E3%E5%ED%F1&page=8
Смотрим пост #79
Там получается либо бегать по лабиринту, либо тоже бегать, но с мини-картой.
Что замедляет очень.
А вот такой (2-х ядерный) эмуль позволил бы и видеть мини карту (и очень много чего ещё полезного для отладки) и видеть экран как он на реале должен быть.
Так понятней?
Други!
Чтоб не было больше ненужных разговоров - вот вам живой пример, который позволит понять зачем я хочу такой эмуль:
http://zx-pk.ru/showthread.php?t=17106&highlight=%F2%E0%ED%E3%E5%ED%F1&page=8
Смотрим пост #79
Там получается либо бегать по лабиринту, либо тоже бегать, но с мини-картой.
Что замедляет очень.
А вот такой (2-х ядерный) эмуль позволил бы и видеть мини карту (и очень много чего ещё полезного для отладки) и видеть экран как он на реале должен быть.
Так понятней?
попробуй вривести пример - где в памяти что лежит и что бы ты хотел увидеть из этих данных, может чтото и придумаем :)
попробуй вривести пример - где в памяти что лежит и что бы ты хотел увидеть из этих данных, может чтото и придумаем
Я хотел увидеть мини-карту НЕЗАВИСИМО от основного действа (ну там где сама 3д).
Т.е. код, который рисует эту самую мини-карту должен исполнятся отдельно от основного (3д) чтоб не мешать.
(в конечном варианте эта мини-карта нафик не нужна, но на процессе отладки очень трэба, для контроля правильно-ли отображается 3д)
Destr, проще миниплагин к эмулю на Си написать, который будет брать значения откуда надо и уже рисовать что надо...
Я хотел увидеть мини-карту НЕЗАВИСИМО от основного действа (ну там где сама 3д).
Т.е. код, который рисует эту самую мини-карту должен исполнятся отдельно от основного (3д) чтоб не мешать.
(в конечном варианте эта мини-карта нафик не нужна, но на процессе отладки очень трэба, для контроля правильно-ли отображается 3д)
а в каком виде эта карта в памяти представляется? по каким адресам? нужно ли переключение страниц памяти?
проще миниплагин к эмулю на Си написать, который будет брать значения откуда надо и уже рисовать что надо...
Может быть.
Я в принципе подумывал о том-же (только на PureBasic, но не суть - это то-же самое).
Реализуемо, да...
Но всё-таки эмуль такой который брал - бы IM2 и обрабатывал отдельно - это всё-таки более TRUE :)
Ну и если даже откинуть мои личные притязания - всё равно это (вроде как) новый шаг к более удобной среде разработки (даже если это только "мёртвая 8-ми битная платформа, тупиковая ветвь")
---------- Post added at 18:46 ---------- Previous post was at 18:45 ----------
а в каком виде эта карта в памяти представляется?
Я ведь ссылу на пост давал, и описание и т.д.
Я ведь ссылу на пост давал, и описание и т.д.
по ссылке нашел только сам снэпшот. Я спрашивал про то в каком виде эта карта в памяти хранится и что нужно нарисовать.
Я ждал приметно такой ответ:
Адрес Длина Тип Назначение
#7FAB 4 float Текущий угол вращения взгляда
#8512 4 float Текущая координата X наблюдателя
#8513 4 float Текущая координата Y наблюдателя
#85AC - - Карта, представлена в памяти в таком-то и таком-то формате...
по ссылке нашел только сам снэпшот. Я спрашивал про то в каком виде эта карта в памяти хранится и что нужно нарисовать.
Я ждал приметно такой ответ:
Адрес Длина Тип Назначение
#7FAB 4 float Текущий угол вращения взгляда
#8512 4 float Текущая координата X наблюдателя
#8513 4 float Текущая координата Y наблюдателя
#85AC - - Карта, представлена в памяти в таком-то и таком-то формате...
Мы видимо друг-друга не поняли.
Нужно НЕ ИМЕННО КОНКРЕТНОГО ОТОБРАЖЕНИЯ, а другое - ВТОРОЕ ЯДРО КОТОРОЕ В ТОМ-ЖЕ адресном пространстве может исполнять СВОЙ КОД.
---------- Post added at 19:07 ---------- Previous post was at 19:05 ----------
Т.Е. это не частный случай (под него я бы мог запилить захват)
А именно чтоб был "альтернативный ZX80"
Чтоб мог отображать то что надо (ну что там кодер загадал)
Т.е. новый шаг к комфорт-программингу...
Я так понял, что реально удовлетворит следующее решение: дебаггер/watch с исполнением скриптов по событиям (конкретное событие процессора: прерывание, исполнение конкретной команды, исполнение команды по адресу, проверка логического условия (равенство ячейки заданному значению).
Скрипты можно делать на LUA или других предназначенных для встраивания языках. (Скрипт мог бы иметь доступ как к адресному пространству самого процессора, так и к какой-либо watch-информации, canvas (для отображения графики) или ещё чего-нибудь.)
(Смежная идея была реализована в ПРОФ-ПЗУ теневого монитора-отладчика Scorpion ZS 256 Turbo+, в "анализаторе" можно было написать программу на форте, отрабатываемую по событиям и проверяющую какие-либо условия и выполняющую произвольные манипуляции.)
Резюме: встройте LUA в дебаггер UnrealSpeccy (Portable) =)
Пример в треде\посте - это частный случай.
Проявление.
А вот сам "двухъядрёный эмуль" - это инструмент который поможет в написании/отладке подобных дел.
Т.е. грубо говоря = это как-бы STS (дебаг, монитор, лукмем) - который полностью подчинён кодеру (для которого кодер и пишен на том-же самом языке-асме инструкции) и который работает синхронно с "основным кодом" (т.е. в том-же адресном пространстве).
---------- Post added at 19:40 ---------- Previous post was at 19:39 ----------
Я так понял
Нет.
Совсем не то
---------- Post added at 19:40 ---------- Previous post was at 19:40 ----------
Я видимо зря тред завёл.
---------- Post added at 19:44 ---------- Previous post was at 19:40 ----------
Только что ко мне в гости заходил знакомый спектрумист (весьма слабый) - и мне пришлось очень подробно ему рассказывать о чём, собственно, звук.
Он сказал так:
- Старина! Раз уж ты мне так разжёвывал при личном общении и я более-менее осознал чего ты хочешь, то подумай сам, сколько времени\постов\тредов это займёт у тебя, когда ты обращаешся с невидимойпередлицом публикой. Идея хорошая, но обрисовать на пальцах в тексте - это вряд-ли выйдет...
---------- Post added at 19:44 ---------- Previous post was at 19:44 ----------
Видимо он прав :(
---------- Post added at 19:53 ---------- Previous post was at 19:44 ----------
Просто нужен (ну как нужен? ОЧЕНЬ помог-бы ещё один эмулируемый Z80, который отображал-бы то что нужно (что накодиш) ).
Т.е. ещё один, следующий шаг после сервис-монитора на ZS (а это был такой тру и руль в своё время, что могу взять на себя смелость сказать такую фразу: "Кто не юзал S-монитор на Scorpion`е - тот много потерял!"
Я просто предлагаю сделать следующий шаг.
Ну конечно если это кому-то надо. чтоб разработка и отладка прог под спек стала более удобной, ну и выглядела посовременней :)
то подумай сам, сколько времени\постов\тредов это займёт
Мне если надо было что то в таком духе выводилось, брал zxmak.net делал плагин который открывает окошко и выводит отладочную инфу, к нему можно писать на бейсике, правда не на PureBasic, а на vb.net, причем каркас плагина отладчика это что то под 50 строк. API эмуля позволяет многие события перехватывать, чтение/запись в порты/память, прерывания сброс, выборка кода операции, начало/конец кадра итд
Просто нужен (ну как нужен? ОЧЕНЬ помог-бы ещё один эмулируемый Z80, который отображал-бы то что нужно (что накодиш) ).
Т.е. ещё один, следующий шаг после сервис-монитора на ZS (а это был такой тру и руль в своё время, что могу взять на себя смелость сказать такую фразу: "Кто не юзал S-монитор на Scorpion`е - тот много потерял!"
Я просто предлагаю сделать следующий шаг.
Ну конечно если это кому-то надо. чтоб разработка и отладка прог под спек стала более удобной, ну и выглядела посовременней :)
насколько я понимаю, ты хочешь прикрутить еще один Z80, в задачи которого будет входить только чтение кода из текущего адресного пространства и запись в это-же пространство результатов работы. Не вмешиваясь при этом в работу основного процессора. Адресное пространство портов ввода вывода он использовать не будет. Верно?
Это несложно сделать, вопрос только в том - когда этот второй Z80 должен начать исполнение кода и с какого адреса? Правда есть еще проблемка с тем что нужно будет корректно рисовать то что второй Z80 будет писать в память в обход первого.
насколько я понимаю, ты хочешь прикрутить еще один Z80, в задачи которого будет входить только чтение кода из текущего адресного пространства и запись в это-же пространство результатов работы.
Нет.
Не вмешиваясь при этом в работу основного процессора.
Да.
Адресное пространство портов ввода вывода он использовать не будет. Верно?
Не верно.
когда этот второй Z80 должен начать исполнение кода и с какого адреса?
Я это в первом-же посте обозначил - IM2 (можно просто IM, но ведь это гвоздями прибито на дефолт - им1 если).
Правда есть еще проблемка с тем что нужно будет корректно рисовать то что второй Z80 будет писать в память в обход первого.
Никаких обходов.
Просто - 2 (два) Z80 обрабатывают одно и то-же адресное пространство, одни и те-же порты, всё (ВСЁ!) паралельно.
Только один из них - работает как обычно (т.е. реал).
А второй - тупо ловит IM!
И обрабатывает его так-же как работал бы реал!
ТО-ЖЕ САМОЕ ДЕЛАЕТ!
А ведь "первый" (ну скажем так нуль-ядро, обычный z80) процессор занимается дальше (ему пришло INT-сигнал, а он его типа за RETI принял и гонит дальше свои дела, по коду!), а второй (наш псевдо-"second"- исполняет прерыванчискую программу, ту что на IM`е!)
Т.е. как-бы исполняет ТО-ЖЕ САМОЕ что исполнял бы "осносвной" проц (а ведь ему уже "было RETI" и он уже дальше код исполняет).
А тут как-бы "второй" Z80 прерыванчискую программу (по вектору) выполняет. До победного конца! (до комады RETI - это для него как-бы HALT, т.е. ждёт пока "первый" ему скажет: Ко мне пришёл INT - мне недосуг - займись-ка им пожалуста?)
Так ясней?
---------- Post added at 20:33 ---------- Previous post was at 20:31 ----------
ОБА-ДВА процессора работают с одним и тем-же полем ОЗУ, всё одно и то-же, только ИНТ у них в противофазе.
Ну как ещё понятней?
---------- Post added at 21:00 ---------- Previous post was at 20:33 ----------
В общем это всё - как-бы следующий шаг к облегчению писания под спек.
А если кто будет сказать что мол "писали по-старинке и было гут и true" - я скажу так:
- Да, но ведь прогресс! А иначе не то что sjasm по-вашему оказывается не нужен, но и Alasm, и Storm! А уж Zeus и тем паче Gens - фтопку!
Если уж нужно "чистый код/разработка" - то есть один человек, который всю жизнь писал программы В МАШИННОМ КОДЕ!
Да! Именно! Битами 0 и 1! Через 22 ферритовых колечка пропускал проволоку (это команда и операнд к ней + контрольные 2 бита), и жал кнопку ввода (в ячейку кидалось). потом следующее. И так далее...
Мы ведь не хотим (да и не сумеем) кодить на таком уровне?
Вот и пытаемся как-то задачу себе облегчить?
Нет.
Просто - 2 (два) Z80 обрабатывают одно и то-же адресное пространство, одни и те-же порты, всё (ВСЁ!) паралельно.
Только один из них - работает как обычно (т.е. реал).
А второй - тупо ловит IM!
И обрабатывает его так-же как работал бы реал!
ТО-ЖЕ САМОЕ ДЕЛАЕТ!
А ведь "первый" (ну скажем так нуль-ядро, обычный z80) процессор занимается дальше (ему пришло INT-сигнал, а он его типа за RETI принял и гонит дальше свои дела, по коду!), а второй (наш псевдо-"second"- исполняет прерыванчискую программу, ту что на IM`е!)
Т.е. как-бы исполняет ТО-ЖЕ САМОЕ что исполнял бы "осносвной" проц (а ведь ему уже "было RETI" и он уже дальше код исполняет).
А тут как-бы "второй" Z80 прерыванчискую программу (по вектору) выполняет. До победного конца! (до комады RETI - это для него как-бы HALT, т.е. ждёт пока "первый" ему скажет: Ко мне пришёл INT - мне недосуг - займись-ка им пожалуста?)
ну а что делать второму ядру, если оно еще предыдущее прерывание обрабатывает, а первому ядру уже второй INT пришел?
А если кто будет сказать что мол "писали по-старинке и было гут и true" - я скажу так:
- Да, но ведь прогресс! А иначе
прогресс-то прогресс, и делать надо тоже прогрессивно, а не как в 20 веке;) идеальный вариант - внешний скриптовый язык (я бы предложил не луа, а питон), который может обращаться к эмулятору и делать все, что угодно (читать/писать память, порты, ресеты, инты и все что угодно).
тогда, надо тебе карту - вытащил сам в своем темпе данные, в своем формате и нарисовал так, как тебе надо. и не в 256х192, а нормальную картину.
это бы, кстати, была киллер-фича эмулятора:)
---------- Post added at 02:57 ---------- Previous post was at 02:51 ----------
а 2 ядра порождают больше вопросов, чем ответов...
Нет.
Совсем не то.
Абсолютно то же самое. Но не "внутри", а "снаружи" и не на асме Z80, а на чём-то более высокоуровневом. Никакой разницы чем ты будешь выводить содержимое ячеек, или выводить графику на основной экран - нет.
Однако налицо намного более высокая гибкость: в твоём варианте - событие только одно - INT, а тут событий может быть множество (указатель команды равен какому-то значению или содержимое памяти). Рисовать можно как внутри спектрумовского экрана, так и где-нибудь снаружи.
Если цель именно удобство отладки, "умная отладка" с контролем внутренностей, а не создание 2-х процессорного эмулятора, то мы говорим о решении одной и той же проблемы.
Если пугает необходимость знать что-то кроме асма z80 (ты как-то на нём зациклился, пытаясь все отладочные процедуры сделать на нём), то страх нужно преодолеть =)
- Старина! Раз уж ты мне так разжёвывал при личном общении и я более-менее осознал чего ты хочешь, то подумай сам, сколько времени\постов\тредов это займёт у тебя, когда ты обращаешся с невидимойпередлицом публикой. Идея хорошая, но обрисовать на пальцах в тексте - это вряд-ли выйдет...
Вот то-то и оно. А ко мне тоже друг заходил и сказал: "о! то, о чём ты говоришь — эквивалентно двухпроцессорному эмулятору-отладчику! но не ломает хода выполнения программы, не даёт побочных эффектов, и отлаживаемая и анализируемая программа не заметит разницы исполняется ли она на реальном спектруме или под отладчиком со скриптом. В отличие от двухпроцессорного варианта, где и растактовка и обработка прерываний будут отличаться и могут привести к трудновылавливаемым глюкам. Но, старик, у тебя так и не получилось объяснить это мне, представь как трудно будет объяснить это человеку, увлечённому своей взлелеянной идеей о двупроцессорном отладчике. Ты ничего не сможешь ему объяснить!" =)
P.S. У тебя объяснить получилось. Двупроцессорная идея милая, по своему революционная, но для умной отладки и контроля за внутренним состоянием программы - не подходящая, так как отладочная часть имеет побочные эффекты на отлаживаемую программу. Задача умной отладки на других платформах решается по-другому: контроль за состоянием эмулятора, отработка скриптов по событиям (см. выше). Скрипты могут показывать всё то же самое, что и твои z80-процедуры на виртуальных прерываниях, только проще, эффективнее и менее пагубно для отлаживаемой программы =)
ну а что делать второму ядру, если оно еще предыдущее прерывание обрабатывает, а первому ядру уже второй INT пришел?
Работать как нужно (ну это как-бы ситуация на обычном z80 когда прерывания приходят чаще чем успевают обрабатыватся - т.е. это трабл кодера)
Никакой разницы чем ты будешь выводить содержимое ячеек, или выводить графику на основной экран - нет.
Есть разница! ("Непг`равда! Есть такая парг`тия!" (С) ВИЛ)
Пробовал я так, но ведь современные среды оперируют не байтами и даже не словами - а сразу (ух ты!) восмибайтовами блоками которые с плав-запятой.
Корректно сэмулировать то что надо - получается с натяжкой. Да и не всегда.
(это не повод срач разводить, а просто мои выводы когда я мучался по этой теме уже пару лет наверное, кто не верит - спосите у неварта).
Двупроцессорная идея милая, по своему революционная, но для умной отладки и контроля за внутренним состоянием программы - не подходящая
Ок, не подходящая и всё такое.
Может быть.
Я просил только об одном: ЕСЛИ КТО ЗАИНТЕРЕСУЕТСЯ - ДАЙТЕ МНЕ ТАКОЙ ЭМУЛЬ! (ну или давайте вместе разработаем, если я чем могу помочь).
А дальше - видно будет.
Ведь шлёпали раньше в железе всякую ересь типа "спринтер"ов и т.д. (на голом энтузиазме по сути!)
А тут ведь проще - эмуль тока...
ЕСЛИ КТО ЗАИНТЕРЕСУЕТСЯ - ДАЙТЕ МНЕ ТАКОЙ ЭМУЛЬ!
Кто будет инициализировать память второго проца, кто будет инициализировать стек, указатель таблицы векторов, как быть с MMU, не пори чушь в общем. SMP системы даже на восьмибитке это не тривиально
И эмулировать что то на ПЦ не надо из алгоритмов, можно смыкнуть процедуру из отапливаемой проги, причем так что бы не было side effect
И про байты не пори, все мейнстримовые процы умеют байтами оперировать
Кто будет инициализировать память второго проца, кто будет инициализировать стек, указатель таблицы векторов, как быть с MMU, не пори чушь в общем. SMP системы даже на восьмибитке это не тривиально
Не пори чушь, было сказано что второй проц работает с теми-же начальными данными что и первый.
Вообще с точки зрения проги - как был один проц так и остался, а уж кто там занимается обработкой кода - не её собачье дело. Работает - и слава Богу!
И эмулировать что то на ПЦ не надо из алгоритмов, можно смыкнуть процедуру из отапливаемой проги, причем так что бы не было side effect
Вот вообще не понял ни строчки.
О чём ты?
И про байты не пори, все мейнстримовые процы умеют байтами оперировать
Если я херню порю - ну подскажи как надо (с разъяснениями для деревни).
А если нет желания разжевать валенку всё по полкам - то чего тогда в теме появился/отписался?
начальными данными что и первый
ума нет... пришло прерывание и погнали в один стек писать, друг друга перетирая
---------- Post added at 17:13 ---------- Previous post was at 17:10 ----------
Если я херню порю - ну подскажи как надо
не телепат, что тебе надо, факт в том что процессоры с байтами работают на раз
ума нет... пришло прерывание и погнали в один стек писать, друг друга перетирая
Ну блин, ещё раз:
Два проца z80
Первый работает код.
Второй тупо ждёт INT
Пришёл INT.
Первый проц шпарит дальше (игнорит INT)
Второй - очнулся, взял адрес куда вектор и побежал обрабатывать код.
До победного конца. (команды RETI)
А первый и в ус не дует, у него как-бы и не было прерывания (ему нулёво до них).
И вся эта тема в одном и том-же адресном пространстве.
И пофик на стек, банки и т.д. (это уже проблема кодера как он напишет, если конфликт - сам виноват)
Так ясней?
Так ясней?
И твой второй проц не будет вызывать подпрограммы, юзать push pop?
И твой второй проц не будет вызывать подпрограммы, юзать push pop?
Это проблемы кодера - как напишет - так и будет.
Ты ведь не удивляешся что например вывод стрелочки на экране (при EI и выборкой спрайтов со стека - ЧВ например) сопряжён с хитрым кодом иначе косяки появляются?
---------- Post added at 17:29 ---------- Previous post was at 17:26 ----------
Как вариант - у z80 есть флаговый регистр (в котором есть и неиспользуемые биты) и ещё есть куча неиспользуемых (по-сути - пустых!) команд (которые нафик не нужны, ну по типу LD C,C)
Их можно заюзать для корректного общения между двумя процами.
Дават ты без попытки поставить ТЗ, на уровне функциональных требований объяснишь что тебе надо, в смысле не второй проц, а зачем тебе второй проц.
Люди по максиму пытаются уйдти от ассемблера там где это можно, а ты же предлагаешь еще и отладочный код пихать в асм (грубо говоря превратить отладку из ненавязчивого процесса, в еще один геморой с асмом), соратников будет очень тяжело найти в этом мероприятии.
предлагаешь еще и отладочный код пихать в асм (грубо говоря превратить отладку из ненавязчивого процесса, в еще один геморой с асмом), соратников будет очень тяжело найти в этом мероприятии.
Destr, подумай, не придётся ли для отладки отладочной программы для второго проца пристыковывать третий проц? =)
Пробовал я так, но ведь современные среды оперируют не байтами и даже не словами - а сразу (ух ты!) восмибайтовами блоками которые с плав-запятой.
byte ram[65536]; - займёт 64k и обрабатываться будет как массив из 65536 байт, главное чтобы скриптовый движок в отладчике поддерживал типизацию.
Andrey_Korabelev
04.11.2012, 19:33
Ну блин, ещё раз:
Два проца z80
Первый работает код.
Второй тупо ждёт INT
Пришёл INT.
Первый проц шпарит дальше (игнорит INT)
Как итог, первый проц выполняет больше команд за единицу времени, чем в обычный ZX.
Второй - очнулся, взял адрес куда вектор и побежал обрабатывать код.
До победного конца. (команды RETI)
Этот код включает то, что делает обработчик прерывания на ZX обычно?(опрос клавиш, отчет временных интервалов...). Если да, то к черту летит вся синхронизация - под такой отлад-системой она не соответствует оригиналу.
А первый и в ус не дует, у него как-бы и не было прерывания (ему нулёво до них).
Это как? Т.е. никакого опроса клавиатуры/джойстиков, никаких временных задержек? А!
Все на высчитывании количества тактов!
Круто! Но вроде ведь не про г-леты демовые речь была (карты уровней ведь?)
И что-то мне кажется, что очень толсто...
Но... Как-то так можно сделать такое из UnrealSpeccy:
1. Найти там основной цикл. Он эмулит процессор. Синхронизация с реальным временем происходит за счет выполнения всех команд одного фрейма(который 50 раз в секунду) с максимальной нативной скоростью x86, затем происходит ожидание начала следующего кадра. Но, это так, к сведению, если не в курсе;)
Так вот, процессор выполнен в виде некоего объекта... или экземпляра структуры. Надо создать такой второй и исполнять алгоритм эмуляции второго процессора после первого в основном цикле.
2. Подправить диалог настроек. Добавить там галку старта/останова второго процессора, а также задание значения счетчика команд, стека и значение регистра I.
3. Пусть каждый из процессоров выполняет вход в обработчик прерываний. Просто у первого будет обработчик из одной команды(reti), а второй после обработчика делает halt.
Как-то так...
Alex Rider
04.11.2012, 21:04
Запуская какую-либо прогу в таком эмуляторе получаем не одно спектрум-окно, а два.
Которые работают синхронно.
Первое - отображает то, что отображалось бы и работало как обычно.
А вот второе - это как-бы ещё один Z80, имеющий то-же самое адресное пространство, экран, порты и т.д. но выполняющий то, чем занимается прерывание.
Если видеопамять общая, как могут картинки в окнах отличаться?
---------- Post added at 20:54 ---------- Previous post was at 20:50 ----------
пришло прерывание и погнали в один стек писать, друг друга перетирая
Тут все хитрее ;) У каждлго Z80 свой SP. Кстати, и IFF1, IFF2, режим прерывания, и регистр I. И, да, инициализировать второй Z80 придется отдельно - либо псевдоинструкцией, либо портом.
---------- Post added at 21:04 ---------- Previous post was at 20:54 ----------
Скрипты могут показывать всё то же самое, что и твои z80-процедуры на виртуальных прерываниях, только проще, эффективнее и менее пагубно для отлаживаемой программы =)
Смех смехом, а скрипты не вон-то нарисуют спрайт из памяти в окошке (каком?) так, как этот спрайт выведется на спековский экран. Но если уж в этом духе рассуждать, то сейчас нет возможности послушать сэмпл из памяти на бипере/AY/и т.д., напечатать строку из памяти как на ZX-принтере, отправить пакет из памяти в модем и т.п.
Смех смехом, а скрипты не вон-то нарисуют спрайт из памяти в окошке (каком?)
да ладно? если будет прикручен, например, стандартный питон, то под него готовых библиотек (кроссплатформенных!) и для окошек, и для звука и для всего чего хошь - полно.
как пример использования питона могу привести IDA Pro. для иды есть idapython, который позволяет делать плагины (которые анализируют/патчат память), поддержку новых процессоров, загрузчики новых форматов. в иде изначально был "самопальный" скриптовый язык IDC, затем прикрутили питон, имхо, питон пользуется куда большей популярностью (да и в целом очень популярный язык для "набросать чего-нибудь быстренько"), чем IDC и C/C++.
Alex Rider
04.11.2012, 21:30
под него готовых библиотек (кроссплатформенных!) и для окошек, и для звука и для всего чего хошь - полно
Не искал, каюсь, но есть ли готовые библиотеки, которые нарисуют в окошке байт так же, как видеоконтроллер Спектрума, с атрибутами желательно? Или библиотека, которая а-ля AY пропищит дамп регистров?
Понятно, что сделать можно все. Только какова цена отладки получится?
Хотя, идея со скриптовой отладкой в эмуляторе очень даже здравая. Особенно, если эмулятор предоставляет скритпу сервисы по эмуляции девайсов.
Q-Master
04.11.2012, 21:43
да ладно? если будет прикручен, например, стандартный питон, то под него готовых библиотек (кроссплатформенных!) и для окошек, и для звука и для всего чего хошь - полно.
Единственный недостаток питона - нет типизации. 8) А так язык-весч!
Два проца z80
Первый работает код.
Второй тупо ждёт INT
Пришёл INT.
Первый проц шпарит дальше (игнорит INT)
Второй - очнулся, взял адрес куда вектор и побежал обрабатывать код.
До победного конца. (команды RETI)
А первый и в ус не дует, у него как-бы и не было прерывания (ему нулёво до них).
И вся эта тема в одном и том-же адресном пространстве.
И пофик на стек, банки и т.д. (это уже проблема кодера как он напишет, если конфликт - сам виноват)
Т.е., если это аппаратно реализовать, то должен быть еще модуль - CPU1 с доступом к системным ресурсам:
1) контекст всех регистров CPU0;
2) память;
3) ввод/вывод;
... .
У CPU1 должны быть свои порта:
1) управления страницами памяти (где находятся его данные и код);
2) состояния;
3) управления (системным ресурсами...);
4) отладки;
... .
Так же желательно сделать:
1) виртуализацию портов в/в CPU0 для эмуляции работы периферийных устройств (прерывание при записи/чтении порта);
2) приоритетный контроллер прерываний (обработка запросов от CPU0, периферийных устройств, виртуальных портов...);
3) защищенный режим;
4) прямой доступ к памяти;
5) cache (возможность работы CPU1 на максимальной частоте, без тактов ожидания на доступ к системной памяти);
6) ловушка (компаратор точек останова для CPU0);
7) расширенный набор команд CPU1;
...
Думаю, сейчас такое возможно реализовать и на реальном железе.
Сигнал INT# для CPU0 в режиме отладки отключен, т.е. CPU0 уже не реагирует на запросы. Зачем это делать? Ведь для корректной работы отлаживаемой программы потребуется вносить изменения в код ISR.
Не искал, каюсь, но есть ли готовые библиотеки, которые нарисуют в окошке байт так же, как видеоконтроллер Спектрума, с атрибутами желательно? Или библиотека, которая а-ля AY пропищит дамп регистров?
думаю, что нет таких, ибо сильно уж узкозаточенно... но будет нужда - они появятся.
Если уж делать то что-то типа ICU64
вот например рисуем карту игры отдельно от самой игры
http://www.youtube.com/watch?v=1TdaoOluq0A&feature=plcp
и вот
http://www.youtube.com/watch?v=inWsuWEy3mQ&feature=relmfu
карта ЦЕЛОГО уровня boulderdash
http://www.youtube.com/watch?v=tjcvR5McmSg
и имхо эт самый правильный путь расширения
прям мечта хакера ;)
---------- Post added at 23:00 ---------- Previous post was at 22:11 ----------
вот еще прикольное видео про ICU64 и как в нем дема работает
http://www.youtube.com/watch?v=1bk0AYilPrg
вот еще прикольное видео про ICU64 и как в нем дема работает
это просто ШИКАРНО!!! Всегда мечтал посмотреть, как ОНО работает....
это просто ШИКАРНО!!! Всегда мечтал посмотреть, как ОНО работает....
шикарно не то слово, эт просто новое осмысление эмуляторов
с таким подходом, многие вещи, понятные только мегакодерам, можно будет показывать "на пальцах".
вот рабочее место демомейкера ;)
http://www.youtube.com/watch?v=RsimQURnjFE
esl, а что справа за картинка?
Эти модули в ICU64 отдельно пишутся и подключаются как плагины, или реализуются скриптами?
или реализуются скриптами?
скрипты не потянут, тормоза.
и на окнах значек студийный .net по умолчанию
скрипты не потянут, тормоза.
и на окнах значек студийный .net по умолчанию
ну, сами скрипты такую графику не потянут, это да. но если прекомпилированные объекты отвечающие за различные графические представления использовать — то вполне себе справятся с заданием различных параметров представления и т.п. (всё проще чем плагины по каждому поводу делать).
ну, сами скрипты такую графику не потянут, это да. но если прекомпилированные объекты отвечающие за различные графические представления использовать — то вполне себе справятся с заданием различных параметров представления и т.п. (всё проще чем плагины по каждому поводу делать).
так это окошко ICU64 с отображением игрового поля, насколько видно из видео, это и есть плагин на C# написаный :)
Mad Killer/PG
05.11.2012, 19:01
Нe осилил вeсь трeд,но идeя хорошa,дaжe большe нaдо виртуaльных ядeр.Мeняeш пeрeмeнныe(процeдуры) в кaждом кодe и видиш гдe лучшe.Многопоточнaя отлaдкa.Мнe нрaвится идeя,помня гeмморой нa рeaлe,сколько врeмeни убивaлось нa отлaдку и выбор лучшeго рeзультaтa..
скрипты не потянут, тормоза.
а нужен ли там реалтайм в этих окошках с памятью? зачем?
Мeняeш пeрeмeнныe(процeдуры) в кaждом кодe и видиш гдe лучшe.Многопоточнaя отлaдкa.Мнe нрaвится идeя,помня гeмморой нa рeaлe
здесь будет еще больший геморрой;) на реале, 20 лет назад, может и стоило мутить 2е ядро, но сейчас это бессмысленно.
а нужен ли там реалтайм в этих окошках с памятью? зачем?
да мне всеравно, я говорю то что на видео не добиться скриптовыми языками,
я вообще в качестве скриптового языка юзаю C# и быстрый и типизированый
Мда...
Ребята-други-господа-товарищи!
Видимо меня никто толком не понял что я собственно хочу.
Напрашиваются два вывода-альтернативы:
1. Либо я загадал настолько революционную мысль, что никак не умея выразить её доступными словами - она ни у кого в голове и не укладывается.
2. Либо я просто дебил и желаю странного.
В любом разе получается что придётся мне-таки самому грызть C++ до тех пор пока не сумею написать такой эмуль.
Раз уж те люди которые имеют в этом опыт - не отозвались.
Буду видимо изобретать велосипед...
Хотя наверное справедливо...
"Иш чего захотел! Загадал, блин, два проца - дайте ему на тарелочке! А вот ты сам, ручками-ручками! Помучайся, поразбирайся! Потрать, сволоч, полжизни - это тебе не фигушки из-за угла воробъям показывать"
Как-то так, видимо...
Не взлетит. Мультипроцессорная система с периодом синхронизации в 20мс - не смешите мои тапочки. ТС, похоже, ни разу не писал многопоточные приложения - советую попробовать, много интересного. Ну и замена расширяемого, сопровождаемого и универсального скриптинга на одноразовый *****код на асме- это, конечно, по-современному. Если интересно, готов аргументировать свою позицию по каждому пункту.
Mad Killer/PG
05.11.2012, 20:36
Тeбя понял прeкрaсно.Просто рaзвил идeю eщё дaльшe,или в ту сторону,гдe eщё eсть пользa)
Тeбя понял прeкрaсно.Просто рaзвил идeю eщё дaльшe,или в ту сторону,гдe eщё eсть пользa)
Да, Мад, я приметил что ты просёк о чем я.
Остальные отписавшиеся - по-ходу не въехали.
Объясни ты, если сможешь :)
---------- Post added at 19:47 ---------- Previous post was at 19:43 ----------
А вообще было бы гораздо труёвей если бы кто-нибудь шарящий во внутренностях эмуля (ну например Unreal`а) - просто взял и попробовал реализовать.
Т.е. для начала всё по-старому, тока INT обрабатывается отдельно (не нагружая основной проц).
Это был-бы первый шаг в том пути который либо окажется тупиком (т.е. покажет что ненужное затеяли - отрицательный результат=тоже результат) либо подскажет в каком направлении дальше двигать (если всё-таки полезную штуку удумали).
В любом разе получается что придётся мне-таки самому грызть C++ до тех пор пока не сумею написать такой эмуль.
ага, а сразу как разгрызешь, поймешь, что тебе предлагают взамен и почему;)
ага, а сразу как разгрызешь, поймешь, что тебе предлагают взамен и почему
Это видимо так, но вот только я к тому времени стану седой как лунь, а большинство присутсвующих - во земле сырой...
Ничего перспективка, ага?
Andrey_Korabelev
06.11.2012, 13:52
Это видимо так, но вот только я к тому времени стану седой как лунь, а большинство присутсвующих - во земле сырой...
Ничего перспективка, ага?
Ничего так самомнение, а? ;)
Бери исходники us035b2-src.rar, последние на sourceforge. На новодел типа 0.37.6 не смотри, там сильно код усложнен.
В папке Z80 в файле DEFS.H описана struct Z80.
Создание экземпляра этой структуры в глобальной памяти:
Z80 cpu;
в файле VARS.CPP. Этот файл включается перед другими в EMUL.CPP. С помощью #include, не очень красивый стиль;/
Соответственно, везде, где видишь cpu.что-тотам - это работа с процом.
Основной цикл - функция mainloop() в файле mainloop.cpp. Она вызывает spectrum_frame() в том же файле. А та вызывает z80dbg::z80loop() или z80fast::z80loop(), в зависимости от переменной dbgchk. Где z80dbg и z80fast - это namespaces(смотри z80.cpp) - по сути откомпиленный с включенным и выключенным макросом Z80_DBG файл Z80_MAIN.CPP...
...
Все больше убеждаюсь в значении такого параметра, как толстота;) Смотри мой пост выше... Даже скажу на какой странице: на 4-ой. Даже номер поста: 39-ый. Даже ссцылку приведу: http://zx.pk.ru/showpost.php?p=549887&postcount=39
Разбирайся, изучай, если ты серьезно. Никто за тебя ничего делать такого не будет, это не очень правильный подход.
Вот за то что в созданной тобой дискуссии упомянуты ZX-Poly и ICU64 - это спасибо! Давно были такие мысли... Типа добавить в эмулятор автоматический(ну полуавтоматический) анализатор памяти на основе текущих исполняемых эмулятором алгоритмов. Для выявления спрайтов, карт и т.д. У ICU64, как я понял, все это вручную ищется, ну в данной версии, пока что... Верх совершенства был бы автоматический проходитель игр... или автоматический исправлятель ошибок эмуляции;)
Ничего так самомнение, а?
(и далее...)
Какое там самомнение, я наоборот имел в виду что не сумею освоить это раньше пенсии ( а скорей всего - и вообще не сумею).
А про "толстоту" - не понял вообще о чём ты, но закралась мысль что ты меня в троллинге подозреваешь.
Это не так.
"Двуядреный" эмуль мне нужен не как гипотеза чтоб тред/срач завести, а действительно - мучаюсь с написанием сложной проги (ну для меня это сложная штука) - и прикинул что могло бы мне облегчить.
Тред и завёл (ну мало-ли ещё кто того-же инструмента желает? вдруг чего сообща и придумали).
---------- Post added at 23:35 ---------- Previous post was at 23:31 ----------
Верх совершенства был бы автоматический проходитель игр... или автоматический исправлятель ошибок эмуляции
"В это вpемя известный иностpанный писатель виpусов посетил
Москву (все еще не пеpеименованную) и, находясь под впечатле-
нием от всего увиденного, написал новый виpус. Благодаpя шиpоко-
му набоpу команд нового пpоцессоpа Decium, он уместил его всего
в 10 байт. Виpус взбудоpажил миpовую общественность, ибо тепеpь
самовозникновение виpусов в pезультате случайных сбоев стало из
невозможного пpосто маловеpоятным. Идеологи ВКП(П) усмотpели в
этом шиpокую пеpспективу: настанет вpемя, когда пpогpаммы будут
писаться сами собой, а пpогpаммисты будут только игpать в DOOM и
Beholder, пить пиво и спать." (с) - где-то тут http://www.zxpress.ru/article.php?id=12223
"Двуядреный" эмуль мне нужен не как гипотеза чтоб тред/срач завести, а действительно - мучаюсь с написанием сложной проги (ну для меня это сложная штука) - и прикинул что могло бы мне облегчить.
"Если у вас есть проблема, и вы думаете, что можете ее решить с помощью регулярных выражений, то у вас есть две проблемы" :)
Andrey_Korabelev
08.11.2012, 11:46
Какое там самомнение, я наоборот имел в виду что не сумею освоить это раньше пенсии
А ты начни. Потом опубликуй хоть что-нибудь. Так больше шансов, что подхватят;)
В unreal0.35, кстати, уже есть еще один Z80:
Z80 gscpu;
в том же VARS.CPP.
И работа с ним идет в GS.CPP и gsz80.cpp - всего 290 строк(реально меньше, так как еще эмуляция звуковой карты).
Лучше спрашивай про конкретные алгоритмы в unreal, думаю на такие вопросы отвечать к многих будет интерес! Ломать - не строить;)))
А автоматическая проходилка...
Есть доказательство, что невозможно написать алгоритм, который будет исследовать другой подсунутый ему алгоритм(заранее неизвестный - типа аргумент функции) и выдавать его результат, при этом не исполняя самого алгоритма.
Если же исполнять, утыкаемся в комбинаторный взрыв.
Но народ воюет.
Можно как-то считать что-то типа энтропии программы, т.е игра еще продолжается или нет. Можно строить длиннющие причинно-следственный связи и отматывать время назад(почему-то все забывают, какой вагон памяти у нас, если не хранить в нем HD-video...).
Но суть в том, что надо отсекать лишние ветви, уменьшать количество вариантов. Но это оффтоп все...
По твоей же пр... теме. Представь что у тебя черный ящик. Дак вот, вместо того, чтобы изучать его извне, без последствий для черного ящика(а ты это можешь, если работаешь на любом PC, а не на самом ящике) - ты пытаешься его распилить, взять половинку от другого и склеить их...
Короче, эффекта "двупроцессорного эмулятора", ты, Destr, можешь добиться очень просто: поставить в UnrealSpeccy 200 000 тактов в прерывании и выводить на прерываниях всё, что тебе хочется. Не будет успевать в прерывание - поставь 300 000 тактов. Меньше побочных эффектов на программу (в случае если она синхронизированна с INT'ом). И не надо ломать себе моск.
нужен еще отдельный экран, например, для всей карты в мелком масштабе...
Alex Rider
08.11.2012, 17:21
нужен еще отдельный экран, например, для всей карты в мелком масштабе...
А как на нем рисовать-то отдельно от основного?
---------- Post added at 17:21 ---------- Previous post was at 17:18 ----------
Кстати, хороший реквест авторам эмуляторов: а можно как-то сделать (опционально) одновременное отображение в разных окнах картинок из 5-й и 7-й банки? Пригодилдось бы гигаскринщикам, демописателям, да и мож правда в отладке кому еще полезно будет?
Короче, эффекта "двупроцессорного эмулятора", ты, Destr, можешь добиться очень просто: поставить в UnrealSpeccy 200 000 тактов в прерывании и выводить на прерываниях всё, что тебе хочется.
Да, пока что так и делаю. В точку!
нужен еще отдельный экран, например, для всей карты в мелком масштабе...
Вот именно :)
А как на нем рисовать-то отдельно от основного?
---------- Post added at 17:21 ---------- Previous post was at 17:18 ----------
Кстати, хороший реквест авторам эмуляторов: а можно как-то сделать (опционально) одновременное отображение в разных окнах картинок из 5-й и 7-й банки? Пригодилдось бы гигаскринщикам, демописателям, да и мож правда в отладке кому еще полезно будет?
Сам и ответил на свой вопрос!
Всё так и представлялось когда я заводил тему.
Вижу наконец народ начал догонять ЧТО хотелось-бы и ЗАЧЕМ это всё :)
Andrey_Korabelev
08.11.2012, 17:33
поставить в UnrealSpeccy 200 000 тактов в прерывании...
Кстати, да! Вот, наверное, самое элегантное решение... :v2_cheer:
нужен еще отдельный экран
Исходя из напрашивается само собой: использовать расширенный режим экрана какого-либо клона... Рендерить для двух норм режимов в буфере, выводить в начале +100500-прерывания ;)
P.S. Эх, когда любишь преодолевать самодельные трудности, немного грустно с высоты решенных задач смотреть в неизведанные облака... )))
Вижу наконец народ начал догонять ЧТО хотелось-бы и ЗАЧЕМ это всё
да давно это же поняли, практически с самого начала. только мнение осталось прежним;) я бы такое юзать не стал, а вот скрипты бы - стал.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot