Эмуляция двухъядерного спектрума

[Destr]

по ссылке нашел только сам снэпшот. Я спрашивал про то в каком виде эта карта в памяти хранится и что нужно нарисовать.

Я ждал приметно такой ответ:
Адрес Длина Тип Назначение
#7FAB 4 float Текущий угол вращения взгляда
#8512 4 float Текущая координата X наблюдателя
#8513 4 float Текущая координата Y наблюдателя
#85AC - - Карта, представлена в памяти в таком-то и таком-то формате...

Мы видимо друг-друга не поняли.
Нужно НЕ ИМЕННО КОНКРЕТНОГО ОТОБРАЖЕНИЯ, а другое - ВТОРОЕ ЯДРО КОТОРОЕ В ТОМ-ЖЕ адресном пространстве может исполнять СВОЙ КОД.

---------- Post added at 19:07 ---------- Previous post was at 19:05 ----------

Т.Е. это не частный случай (под него я бы мог запилить захват)
А именно чтоб был "альтернативный ZX80"
Чтоб мог отображать то что надо (ну что там кодер загадал)

Т.е. новый шаг к комфорт-программингу...

[siril]

Я так понял, что реально удовлетворит следующее решение: дебаггер/watch с исполнением скриптов по событиям (конкретное событие процессора: прерывание, исполнение конкретной команды, исполнение команды по адресу, проверка логического условия (равенство ячейки заданному значению).

Скрипты можно делать на LUA или других предназначенных для встраивания языках. (Скрипт мог бы иметь доступ как к адресному пространству самого процессора, так и к какой-либо watch-информации, canvas (для отображения графики) или ещё чего-нибудь.)

(Смежная идея была реализована в ПРОФ-ПЗУ теневого монитора-отладчика Scorpion ZS 256 Turbo+, в "анализаторе" можно было написать программу на форте, отрабатываемую по событиям и проверяющую какие-либо условия и выполняющую произвольные манипуляции.)

Резюме: встройте LUA в дебаггер UnrealSpeccy (Portable) =)

[Destr]

Пример в треде\посте - это частный случай.
Проявление.

А вот сам "двухъядрёный эмуль" - это инструмент который поможет в написании/отладке подобных дел.

Т.е. грубо говоря = это как-бы 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`е - тот много потерял!"

Я просто предлагаю сделать следующий шаг.
Ну конечно если это кому-то надо. чтоб разработка и отладка прог под спек стала более удобной, ну и выглядела посовременней

[ZEK]

то подумай сам, сколько времени\постов\тредов это займёт

Мне если надо было что то в таком духе выводилось, брал zxmak.net делал плагин который открывает окошко и выводит отладочную инфу, к нему можно писать на бейсике, правда не на PureBasic, а на vb.net, причем каркас плагина отладчика это что то под 50 строк. API эмуля позволяет многие события перехватывать, чтение/запись в порты/память, прерывания сброс, выборка кода операции, начало/конец кадра итд

[ZXMAK]

Просто нужен (ну как нужен? ОЧЕНЬ помог-бы ещё один эмулируемый Z80, который отображал-бы то что нужно (что накодиш) ).
Т.е. ещё один, следующий шаг после сервис-монитора на ZS (а это был такой тру и руль в своё время, что могу взять на себя смелость сказать такую фразу: "Кто не юзал S-монитор на Scorpion`е - тот много потерял!"

Я просто предлагаю сделать следующий шаг.
Ну конечно если это кому-то надо. чтоб разработка и отладка прог под спек стала более удобной, ну и выглядела посовременней

насколько я понимаю, ты хочешь прикрутить еще один Z80, в задачи которого будет входить только чтение кода из текущего адресного пространства и запись в это-же пространство результатов работы. Не вмешиваясь при этом в работу основного процессора. Адресное пространство портов ввода вывода он использовать не будет. Верно?
Это несложно сделать, вопрос только в том - когда этот второй Z80 должен начать исполнение кода и с какого адреса? Правда есть еще проблемка с тем что нужно будет корректно рисовать то что второй Z80 будет писать в память в обход первого.

[Destr]

насколько я понимаю, ты хочешь прикрутить еще один 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 бита), и жал кнопку ввода (в ячейку кидалось). потом следующее. И так далее...

Мы ведь не хотим (да и не сумеем) кодить на таком уровне?

Вот и пытаемся как-то задачу себе облегчить?

[ZXMAK]

Нет.
Просто - 2 (два) Z80 обрабатывают одно и то-же адресное пространство, одни и те-же порты, всё (ВСЁ!) паралельно.
Только один из них - работает как обычно (т.е. реал).
А второй - тупо ловит IM!
И обрабатывает его так-же как работал бы реал!
ТО-ЖЕ САМОЕ ДЕЛАЕТ!

А ведь "первый" (ну скажем так нуль-ядро, обычный z80) процессор занимается дальше (ему пришло INT-сигнал, а он его типа за RETI принял и гонит дальше свои дела, по коду!), а второй (наш псевдо-"second"- исполняет прерыванчискую программу, ту что на IM`е!)
Т.е. как-бы исполняет ТО-ЖЕ САМОЕ что исполнял бы "осносвной" проц (а ведь ему уже "было RETI" и он уже дальше код исполняет).
А тут как-бы "второй" Z80 прерыванчискую программу (по вектору) выполняет. До победного конца! (до комады RETI - это для него как-бы HALT, т.е. ждёт пока "первый" ему скажет: Ко мне пришёл INT - мне недосуг - займись-ка им пожалуста?)

ну а что делать второму ядру, если оно еще предыдущее прерывание обрабатывает, а первому ядру уже второй INT пришел?

[psb]

А если кто будет сказать что мол "писали по-старинке и было гут и true" - я скажу так:
- Да, но ведь прогресс! А иначе

прогресс-то прогресс, и делать надо тоже прогрессивно, а не как в 20 веке идеальный вариант - внешний скриптовый язык (я бы предложил не луа, а питон), который может обращаться к эмулятору и делать все, что угодно (читать/писать память, порты, ресеты, инты и все что угодно).
тогда, надо тебе карту - вытащил сам в своем темпе данные, в своем формате и нарисовал так, как тебе надо. и не в 256х192, а нормальную картину.

это бы, кстати, была киллер-фича эмулятора

---------- Post added at 02:57 ---------- Previous post was at 02:51 ----------

а 2 ядра порождают больше вопросов, чем ответов...

[siril]

Нет.
Совсем не то.

Абсолютно то же самое. Но не "внутри", а "снаружи" и не на асме Z80, а на чём-то более высокоуровневом. Никакой разницы чем ты будешь выводить содержимое ячеек, или выводить графику на основной экран - нет.

Однако налицо намного более высокая гибкость: в твоём варианте - событие только одно - INT, а тут событий может быть множество (указатель команды равен какому-то значению или содержимое памяти). Рисовать можно как внутри спектрумовского экрана, так и где-нибудь снаружи.

Если цель именно удобство отладки, "умная отладка" с контролем внутренностей, а не создание 2-х процессорного эмулятора, то мы говорим о решении одной и той же проблемы.

Если пугает необходимость знать что-то кроме асма z80 (ты как-то на нём зациклился, пытаясь все отладочные процедуры сделать на нём), то страх нужно преодолеть =)

- Старина! Раз уж ты мне так разжёвывал при личном общении и я более-менее осознал чего ты хочешь, то подумай сам, сколько времени\постов\тредов это займёт у тебя, когда ты обращаешся с невидимойпередлицом публикой. Идея хорошая, но обрисовать на пальцах в тексте - это вряд-ли выйдет...

Вот то-то и оно. А ко мне тоже друг заходил и сказал: "о! то, о чём ты говоришь — эквивалентно двухпроцессорному эмулятору-отладчику! но не ломает хода выполнения программы, не даёт побочных эффектов, и отлаживаемая и анализируемая программа не заметит разницы исполняется ли она на реальном спектруме или под отладчиком со скриптом. В отличие от двухпроцессорного варианта, где и растактовка и обработка прерываний будут отличаться и могут привести к трудновылавливаемым глюкам. Но, старик, у тебя так и не получилось объяснить это мне, представь как трудно будет объяснить это человеку, увлечённому своей взлелеянной идеей о двупроцессорном отладчике. Ты ничего не сможешь ему объяснить!" =)

P.S. У тебя объяснить получилось. Двупроцессорная идея милая, по своему революционная, но для умной отладки и контроля за внутренним состоянием программы - не подходящая, так как отладочная часть имеет побочные эффекты на отлаживаемую программу. Задача умной отладки на других платформах решается по-другому: контроль за состоянием эмулятора, отработка скриптов по событиям (см. выше). Скрипты могут показывать всё то же самое, что и твои z80-процедуры на виртуальных прерываниях, только проще, эффективнее и менее пагубно для отлаживаемой программы =)

[Destr]

ну а что делать второму ядру, если оно еще предыдущее прерывание обрабатывает, а первому ядру уже второй INT пришел?

Работать как нужно (ну это как-бы ситуация на обычном z80 когда прерывания приходят чаще чем успевают обрабатыватся - т.е. это трабл кодера)

Никакой разницы чем ты будешь выводить содержимое ячеек, или выводить графику на основной экран - нет.

Есть разница! ("Непг`равда! Есть такая парг`тия!" (С) ВИЛ)
Пробовал я так, но ведь современные среды оперируют не байтами и даже не словами - а сразу (ух ты!) восмибайтовами блоками которые с плав-запятой.
Корректно сэмулировать то что надо - получается с натяжкой. Да и не всегда.
(это не повод срач разводить, а просто мои выводы когда я мучался по этой теме уже пару лет наверное, кто не верит - спосите у неварта).

Двупроцессорная идея милая, по своему революционная, но для умной отладки и контроля за внутренним состоянием программы - не подходящая

Ок, не подходящая и всё такое.
Может быть.
Я просил только об одном: ЕСЛИ КТО ЗАИНТЕРЕСУЕТСЯ - ДАЙТЕ МНЕ ТАКОЙ ЭМУЛЬ! (ну или давайте вместе разработаем, если я чем могу помочь).
А дальше - видно будет.
Ведь шлёпали раньше в железе всякую ересь типа "спринтер"ов и т.д. (на голом энтузиазме по сути!)
А тут ведь проще - эмуль тока...