Одна безумная идея ;-) [Архив] - Speccy

CodeMaster

24.11.2010, 10:02

Чесно говоря, даже не знаю как правильно назвать тему, так как сама идея пока сумбурна :-)

Суть такова: есть ПЗУ 64КБ в которое записано системное ПЗУ спека и на адреса ОЗУ специально подготовленная программа (например игра) и есть ОЗУ, те же 64КБ. Вопрос в том, как перенести содержимое ПЗУ в ОЗУ, передать ему управление и отключить ПЗУ? Первое что приходит в голову это сигнал /М1, но только тогда в ПЗУ должен быть сначала записан копировщик, который зная аппаратуру перенесёт всё это. Причём копировать надо со смещением, что бы код самого копировщика в ОЗУ не попал. Хотя в идеале хотелось бы несложного полностью аппаратного копирования, хотя абсолютно не представляю как. И собственно второй вопрос: будет это вообще работать если ситемный код и Бейсик будут физически находится на микрухах ОЗУ?

Spectramine

24.11.2010, 11:31

Работать будет, проверено на Ореле БК08 и Робике с теневым ОЗУ. Там переключение нижней страницы делалось через отдельный порт, а копирование из ПЗУ в ОЗУ - простым LDIR-ом. Правда, во время работы бейсика в его стандартном варианте портились первые 5 ячеек ОЗУ (0000-0004), чтобы этого избежать, нужно было дорабатывать схему т.о., чтобы можно было отключать/включать запись в нижнюю страницу ОЗУ. Порча этих ячеек некритична для работы бейсика, но некоторые игры без отключения записи в нижнее ОЗУ не работали - использовали содержимое первых двух ячеек или затирали нижнюю страницу памяти.

Кстати, необязательно переключать нижнюю страницу ПЗУ на ОЗУ, достаточно переключить все остальные.

Эта идея рассматривалась для реализации игрового автомата на базе Спектрума, чтобы не нужно было каждый раз загружать игру с магнитофона.

CodeMaster

24.11.2010, 13:53

Работать будет, проверено на Ореле БК08 и Робике с теневым ОЗУ. Там переключение нижней страницы делалось через отдельный порт, а копирование из ПЗУ в ОЗУ - простым LDIR-ом.

Подробней про это где-то можно почитать?

Эта идея рассматривалась для реализации игрового автомата на базе Спектрума, чтобы не нужно было каждый раз загружать игру с магнитофона.

Я видел такой автомат с Exolon'ом, но как там загрузка проходила я х.з.

fan

24.11.2010, 14:01

http://www.speccy.org/trastero/cosas/droy/zxflash/zxflashcart_e.htm

Spectramine

24.11.2010, 16:30

Подробней про это где-то можно почитать?

Не знаю. Насколько я помню, в Орели переключение нижней страницы производилось выводом в порт 7F значения 0 - для первого ПЗУ, 1 - для дополнительного ПЗУ, место под которое было зарезервировано на плате, 2 - для ОЗУ. Запись всегда производилась в ОЗУ.
Запрет на запись был реализован доработкой платы, и включался 3-м битом порта.

В Робике кажется тот же порт, но запись в него - включала ОЗУ, а его чтение - ПЗУ, или наоборот.

CodeMaster

24.11.2010, 16:41

http://www.speccy.org/trastero/cosas...lashcart_e.htm

В принципе, наверное, вариант использования ROM-диска простейший с аппаратной точки зрения, тем более софт под это есть. А Interface II это просто пассивный вывод определённых линий с процессора?

fan

24.11.2010, 23:39

А Interface II это просто пассивный вывод определённых линий с процессора?
Да - http://www.speccy.org/trastero/cosas/droy/interface2/interface2_s.htm

CodeMaster

27.11.2010, 22:18

Вообщем ещё подумал, и решил оценить всё-таки трудоёмкость реализации этой идеи полностью аппаратными средствами. Первый вопрос в том: можно ли организовать побайтовую пересылку с помошью ПЛИС или для этого нужен МК?

Barmaley_m

29.11.2010, 01:36

Лично мне полностью аппаратная реализация видится нецелесообразной. Прямой доступ к памяти (аппаратный) целесообразен в следующих ситуациях:

1) когда требуется сверхвысокое быстродействие. Пример - видеозахват
2) когда нужно чтобы процессор был свободен во время пересылки данных на относительно медленной скорости. Пример - чтение данных с дискеты

У тебя не соблюдается ни первое условие, ни второе.

Аппаратную пересылку можно делать как на плис, так и на микроконтроллере. Я думаю, что лучше делать на микроконтроллере, так как больше гибкость. Ведь поменяв программу для микроконтроллера, можно полностью поменять работу схемы. С плис гибкость меньше, но потенциально выше быстродействие.

Jukov

29.11.2010, 16:51

а я программно устранял ошибку порчи первых 5 ячеек теневого ОЗУ нах

Spectramine

29.11.2010, 17:08

а я программно устранял ошибку порчи первых 5 ячеек теневого ОЗУ нах

А как?

Всех проблем это не снимало, некоторые игры затирали нижнее ОЗУ. Но многие бы пошли, те, что ставили в регистр I #FF.

CodeMaster

29.11.2010, 17:13

Лично мне полностью аппаратная реализация видится нецелесообразной.

Вопрос тут не в целесообразности, а в принципиальной возможности хранения и загрузки дампов памяти с двух микросхем. Вообще поняв тут, что прямого доступа к ПЗУ не будет, хранение дампов лучше сделать на какой-нибудь SPI флешке, благо на дохлых материнках их навалом (только вот они в основном 3-х вольтовые) Заодно это позволит не мультеплексировать шину, а раздельно читать дамп из ПЗУ и писАть его в ОЗУ.

Аппаратную пересылку можно делать как на плис, так и на микроконтроллере.

Минимально необходимые кристалы? Я так понимаю надо где-то на 32 I/O-ноги, 16+8 адрес+данные, ну и ещё 8 на SPI-интерфейс или мультиплексирование при использовании параллельного ПЗУ и управление процом.

Я думаю, что лучше делать на микроконтроллере, так как больше гибкость. Ведь поменяв программу для микроконтроллера, можно полностью поменять работу схемы. С плис гибкость меньше, но потенциально выше быстродействие.

В ПЛИС прошивку тоже можно сменить, МК конечно функциональней, но тут вопрос даже не в этом, а в цене/доставаемости и простоте/удобстве программирования ПЛИС или МК. Крейне желательно чтобы у кристалла была возможность внутрисхемного программирования.

Всех проблем это всё равно не снимало, некоторые игры затирали нижнее ОЗУ.

Для меня это не проблема, если самой программе эти ячейки не нужны, при каждом старте образ ПЗУ будет перезаливаться заново.

Spectramine

29.11.2010, 20:52

Для меня это не проблема, если самой программе эти ячейки не нужны, при каждом старте образ ПЗУ будет перезаливаться заново.

В том-то и дело, что некоторые программы устанавливают вектор прерывания на $FFFF, а там стоит код JR или JP, что вместе с содержимым ячеек 0000-0001 даёт команду перехода. Если эти ячейки испорчены, программа валится. И таких программ немало.
(Я ранее ошибся - не в регистр I заносится $FF, а вектор прерывания IM 2 указывает на $FFFF, хотя случай с I=$FF тоже фатален, если нулевая ячейка будет затёрта. В общем, если программа так или иначе использует ячейки 0000-0004, она слетит). Так что проще сделать так, чтобы после копирования нижняя страница ПЗУ не переключалась.

Barmaley_m

29.11.2010, 21:12

Вопрос тут не в целесообразности, а в принципиальной возможности
Так тогда может собрать схему на золотых деталях? В этом вроде как тоже нет необходимости, но раз принципиально возможно - почему нет? Будет приятно на нее смотреть, желтенькие такие.

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

но тут вопрос даже не в этом, а в цене/доставаемости и простоте/удобстве программирования ПЛИС или МК.
А что, разве МК сложнее достать или запрограммировать, чем ПЛИС???

Крейне желательно чтобы у кристалла была возможность внутрисхемного программирования.
Да все современные МК это позволяют, возьми любой из свежих PIC от Microchip, можно даже 16-разрядный - по цене одно и то же. У них у всех есть не только внутрисхемное программирование, но и самопрограммирование, когда МК под управлением программы-загрузчика может считать новую прошивку, например, из флешки, и самопрошиться. Куда тут можно еще удобнее!

Для меня это не проблема, если самой программе эти ячейки не нужны, при каждом старте образ ПЗУ будет перезаливаться заново.
Зачем его перезаливать в ОЗУ, если он может оставаться в ПЗУ и работать оттуда? Просто ради красоты? Так никакой здесь нет красоты, а есть потеря совместимости программ. Как уже много раз говорили, некоторые игры просто затирают всю область ПЗУ. Что, все будем переделывать, ломать?

CodeMaster

30.11.2010, 08:04

Так тогда может собрать схему на золотых деталях? В этом вроде как тоже нет необходимости, но раз принципиально возможно - почему нет? Будет приятно на нее смотреть, желтенькие такие.

Ты наверное не в курсе, но некоторые так и делают, причём безо всякой необходимости. Вообще тебя явно не туда заносит, и не понимаю что ты мне хочешь доказать.

Но в твоем же случае никаких преимуществ от аппаратной пересылки нет!

Есть, и я тут уже говорил про это (но ты слишком увлёкся отстаивая свою идею, что оппонентов не слышишь), это использование только одного чипа для всего этого.

А что, разве МК сложнее достать или запрограммировать, чем ПЛИС???

Не сравнивал, поэтому и уточняю

Зачем его перезаливать в ОЗУ, если он может оставаться в ПЗУ и работать оттуда? Просто ради красоты?

Опять ты не слышишь что тебе говорят, к ПЗУ не будет прямого доступа.

Так никакой здесь нет красоты, а есть потеря совместимости программ. Как уже много раз говорили, некоторые игры просто затирают всю область ПЗУ.

Придётся тогда ПЛИС или МК после заливки дампа использовать для блокировки записи в область ПЗУ

Что, все будем переделывать, ломать?

Если понадобится, значит будем ломать.

Barmaley_m

30.11.2010, 13:07

Ты наверное не в курсе, но некоторые так и делают, причём безо всякой необходимости. Вообще тебя явно не туда заносит, и не понимаю что ты мне хочешь доказать.
Ну, мы же здесь вроде пытаемся решить задачу разработки электронной схемы рациональным способом, а не "кто сложнее", так?

А рациональный способ - это максимум функциональности при минимуме затрат на разработку, сборку, наладку.

Есть, и я тут уже говорил про это (но ты слишком увлёкся отстаивая свою идею, что оппонентов не слышишь), это использование только одного чипа для всего этого.
Экономится один чип ПЗУ, но из-за этого надо решать проблему аппаратной инициализации ОЗУ при включении системы. А в этой системе что-то другое есть, видеоконтроллер например? Он на чем реализован?

Не сравнивал, поэтому и уточняю
Достать МК или ПЛИС примерно одинаково, если заказывать у фирм-дистрибьютеров. Но выбор МК у дистрибьютеров обычно гораздо богаче, да и цены отличаются раз в 5. Если FPGA со скромными параметрами будет стоить $10-15, то 16-битный МК со скоростью 40млн операций в секунду - $2.50.

Выбор между одним и другим зависит главным образом от требований к решаемой задаче. Если не требуется высокого быстродействия - то обычно МК предпочтителен. А вот задача блокировки ОЗУ на запись - это для аппаратной логики или ПЛИС, МК здесь не справится.

Придётся тогда ПЛИС или МК после заливки дампа использовать для блокировки записи в область ПЗУ
Ну да, только так, блокировка записи. Я довольно долго жил на "Орель БК-08", где нет блокировки записи, и поэтому очень хорошо знаю, насколько много программ портят содержимое по адресам 0000-3FFF.

Если понадобится, значит будем ломать.
Ломать - это шаг отчаяния. Сравни сам, сколько времени у тебя займет разработка и реализация блокировки записи по адресам ПЗУ, и сколько времени займет взлом и переделка всех программ, которые в этом нуждаются!

CodeMaster

30.11.2010, 16:04

Ну, мы же здесь вроде пытаемся решить задачу разработки электронной схемы рациональным способом, а не "кто сложнее", так?

Абсолютно так, только один ньюанс, ты не знаешь какую схему я хочу разработать.

Экономится один чип ПЗУ,

И обвязка - если это будет например ROM-диск

но из-за этого надо решать проблему аппаратной инициализации ОЗУ при включении системы. А в этой системе что-то другое есть, видеоконтроллер например? Он на чем реализован?

Т34ВГ1, ОЗУ статическое

А вот задача блокировки ОЗУ на запись - это для аппаратной логики или ПЛИС, МК здесь не справится.

Ну вот видишь, полегоньку что-то вырисовывается. И безо взякой категоричности :-)

Ломать - это шаг отчаяния.

Возможно это признак прогресса ;-)

Сравни сам, сколько времени у тебя займет разработка и реализация блокировки записи по адресам ПЗУ, и сколько времени займет взлом и переделка всех программ, которые в этом нуждаются!

Вот без понятия пока. Хотя могу предположить, что если программирование ПЛИС мне ещё интересно, то взлом программ точно нет.

Barmaley_m

30.11.2010, 17:08

Абсолютно так, только один ньюанс, ты не знаешь какую схему я хочу разработать.
Насколько я понял по твоему описанию, ты хочешь сделать клон, способный запускать 48К игры, считывая их с флеш-карточки, так?

И обвязка - если это будет например ROM-диск
А что мешает поставить для бейсика традиционное ПЗУ с параллельным доступом, 27128 например?

Один чип ПЗУ и один корпус логики (ЛЕ1) в качестве обвязки на выборку между ПЗУ и ОЗУ. А если аппаратно инициализировать ОЗУ - то это получается один чип ПЛИС как минимум.

Вот без понятия пока. Хотя могу предположить, что если программирование ПЛИС мне ещё интересно, то взлом программ точно нет.
Вот, чтобы оценить трудоемкость - попробуй взломай хотя бы бейсик, чтобы он не портил ячейки 0-4. А еще бейсик иногда портит содержимое знакогенератора, если работает из ОЗУ. Я сам лично исправлял бейсик в этих местах, ну и желаю тебе тоже удачи!

CodeMaster

30.11.2010, 17:13

Насколько я понял по твоему описанию, ты хочешь сделать клон, способный запускать 48К игры, считывая их с флеш-карточки, так?

Это следствие, я хочу сделать максимально миниатюрный клон.

Barmaley_m

01.12.2010, 00:33

Так тогда может всё в ПЛИС? И процессор, и видеоконтроллер, и остальное, кроме ПЗУ и ОЗУ?

CodeMaster

01.12.2010, 08:23

Так тогда может всё в ПЛИС? И процессор, и видеоконтроллер, и остальное, кроме ПЗУ и ОЗУ?

Такой вариант уже есть, и даже несколько, да и мне он не интересен.

Jukov

01.12.2010, 15:42

А как?

Всех проблем это не снимало, некоторые игры затирали нижнее ОЗУ. Но многие бы пошли, те, что ставили в регистр I #FF.

Ессесно не снимало, но при редактирование ПЗУ в теневом ОЗУ это создавало определенные удобства. Отловил я эту процедуру с помощью монитора STS - поставил там в отладчике условие остановки при отладке, если портились эти ячейки. Виновата во всем оказалась какая-то процедура калькулятора. Я её немного переделал. Если нужны подробности - могу скинуть исходник в формате аласма с прогой устраняющей ошибку.

Barmaley_m

01.12.2010, 17:25

Отловил я эту процедуру с помощью монитора STS - поставил там в отладчике условие остановки при отладке, если портились эти ячейки.
Да, такие места найти очень сложно, и мониторы-эмуляторы, пожалуй, только и могут здесь помочь. Молодец!

Я это место нашел не сам, а изучал отличия прошивки Бейсик-Орель и оригинальной Синклер-82. То есть кто-то из авторов Бейсик-Орель в 1992г нашел это место без STS. Возможно, им был доступен дизассемблер бейсика от Яна Логана. Там по-моему эта проблема была описана.

Spectramine

01.12.2010, 18:13

Ессесно не снимало, но при редактирование ПЗУ в теневом ОЗУ это создавало определенные удобства. Отловил я эту процедуру с помощью монитора STS - поставил там в отладчике условие остановки при отладке, если портились эти ячейки. Виновата во всем оказалась какая-то процедура калькулятора. Я её немного переделал. Если нужны подробности - могу скинуть исходник в формате аласма с прогой устраняющей ошибку.
Может, здесь выложишь исходник? Владельцам Орелей и Робиков он может быть полезен.

KPOTOB

03.12.2010, 09:13

Это следствие, я хочу сделать максимально миниатюрный клон.

Если эмуляцией не гнушаться то LPC17xx для 48к/LPC18xx для 128к

Я летом считал что на DMA можно сделать ТВ выход. Возможно что если с LCD контроллером чип взять то и HDMI выйдет (правда придется еще один чип приделать)

Вот девкит почти подходящий http://www.micro4you.com/store/ARM-LPC1768-Development-Board/prod_115.html

CodeMaster

03.12.2010, 16:40

Если эмуляцией не гнушаться

Эмуляция не приемлема по религиозным убеждениям ;-)

KPOTOB

04.12.2010, 13:10

CodeMaster,
Поставь Z84 в LQFP, заведи его полностью на LPC и будет тебе счастье ))

CodeMaster

04.12.2010, 20:38

Поставь Z84 в LQFP, заведи его полностью на LPC и будет тебе счастье ))

Не, всё равно не будет, и давай уже завяжем с этим направлением.

SoftFelix

05.12.2010, 17:36

Отловил я эту процедуру с помощью монитора STS - поставил там в отладчике условие остановки при отладке, если портились эти ячейки. Виновата во всем оказалась какая-то процедура калькулятора. Я её немного переделал. Если нужны подробности - могу скинуть исходник в формате аласма с прогой устраняющей ошибку.
Мне тоже очень интересно. Ибо как-то намучался при расширении памяти: http://zx.pk.ru/showpost.php?p=279231&postcount=18

Jukov

16.01.2011, 07:23

Вот программа исправления ошибки порчи 5 ячеек теневого ОЗУ в формате Alasm'a 2.8

SoftFelix

16.01.2011, 10:58

Вот программа исправления ошибки порчи 5 ячеек теневого ОЗУ в формате Alasm'a 2.8
А можно сразу в тело мессаги вставить в txt-виде этот мизерный фрагмент?

Jukov

16.01.2011, 12:38

ORG 13311
DEFW ERRSRAM

ORG 14446
ERRSRAM CALL 13225
EXX
LD A,(HL)
AND 192
RLCA
RLCA
INC A
INC A
LD D,0
LD E,A
LD A,(HL)
AND 63
SUB 1
ADC HL,DE
EXX
XOR A
LD B,A
RET

SoftFelix

16.01.2011, 13:42

Ещё вопрос: это fix оригинальной прошивки? А какой? BASIC_48 или BASIC_128?

Jukov

16.01.2011, 14:10

Ещё вопрос: это fix оригинальной прошивки? А какой? BASIC_48 или BASIC_128?

BASIC-48. fix для оригинальной прошивки 82-го года.

CodeMaster

04.03.2011, 11:37

во всем оказалась какая-то процедура калькулятора.

Может я туплю, но какой калькулятор в BASIC-48?

ZEK

04.03.2011, 11:45

тупишь, покури доки про синклер басик

CodeMaster

04.03.2011, 11:52

тупишь, покури доки про синклер басик

ОК, верю на слово :-) Но блокировка области ПЗУ нужна полюбому, т.к. для некоторых игр это будет критично.

HardWareMan

04.03.2011, 11:59

В этом вашем спектруме такая вещь Z80, как BUSR/BUSA свободна? Если да - то я вообще не вижу проблемы в вашей дискуссии. Поставьте камень типа ATMega128 параллельно процессору, сигнал сброса Z80 пропустите через этот камень, на этот камень заведите необходимые сигналы и повешайте карту SD/MMC на его SPI. Если не хотите ковыряться в vFAT - гуглите готовые библиотеки под AVR, они есть. А дальше, все просто: приходит сигнал сброса (поверап или юзер нажал), мега удерживая сброс захватывает шину (напомню, что Z80 при сбросе лапками вверх лежит, так что даже BUSR/BUSA и не потребуется), становлясь мастером шины, заполняйте ОЗУ любым мусором, которым захотите (в том числе и считанным с карты), а потом освободите шину (все выводы просто на ввод у камня) и спустите процессор. Реализация копеешная (в случае с DRAM возможно придется как-то синхронизировать обращения к сигналу тактов процессора) а возможности неограниченные. И да, никакого ПЗУ на борту, а Мегу можно обновлять и с карты, используя самопрограммирование и бутлодырь...

Кстати, если и BUSR/BUSA свободны, то можно напрягать мегу на загрузку данных в ОЗУ уже в процессе работы Z80, причем, возможно, и по его указу. Например: в ОЗУ выделить несколько ячеек для команды и параметров (можно по принципу ATAPI). И на порту выделить 1 сигнал, который будет формировать запрос прерывания камня. Заполняем структуру, делаем однократное обращение к порту - запрос пошел. Мега захватывает шины, смотрит в ОЗУ - есть ли там месадж ей или нет, если есть начинает исполнять (например загрузка сектора N по адресу XXXX), потом освобождает шины до следующего раза. Копеешная доработка предыдущей идеи и уже интеллектуальный контроллер карты на борту. А таблица параметров где угодно, в том числе и перемещаемая может быть...

CodeMaster

04.03.2011, 12:51

а потом освободите шину (все выводы просто на ввод у камня) и спустите процессор.

Ещё как бы вопрос по блокировку в ОЗУ области ПЗУ Спека на запись, можно ли это сделать средствами МК? Было мнение, что для этого нужна ПЛИС.

Кстати, если и BUSR/BUSA свободны, то можно напрягать мегу на загрузку данных в ОЗУ уже в процессе работы Z80

Для моей идеи это лишнее, тут не планируется новый софт который сможет это использовать. Если только трансформировать её в реализацию магнитофонного интерфейса для подгрузки оверлеев, но для начала это слишком сложно.

HardWareMan

04.03.2011, 13:39

Ещё как бы вопрос по блокировку в ОЗУ области ПЗУ Спека на запись, можно ли это сделать средствами МК? Было мнение, что для этого нужна ПЛИС.
Сам камешек слабоват, чтобы налету маскировать сигнал записи, а вот маску делать легко. Если у тебя ПЗУ строго первые 16КБ, как в оригинале, тогда можно сигнал записи в ОЗУ пропустить через схему маскирования, которая будет при выборке сигнала ROM и сигнала с меги блокировать прохождение. Сам камень может отменять блокировку на момент подгрузки данных в область "ПЗУ". Таким образом, со стороны Z80 эта область действительно будет казаться ПЗУ, хотя реально там ОЗУ. Если учесть, что активный сигнал записи Z80 - это 0, и ПЗУ находится в 0, то я думаю схема будет не сложной: (NOT (A15 | A14 | BLOCK)) | WR.

ArtemKuchin

10.04.2012, 21:17

Black_Cat

10.04.2012, 21:42

тема Refresh-а DRAM самого спектрума и всплываетВ Спектруме память регенерит видеосканер а не процессор, поэтому процессор можно останавливать хоть навсегда, на памяти это не скажется

Orionsoft

10.04.2012, 22:38

видел в 95 подобный автомат - игрухи грузились с пзу но они были все модифицированы .
долгое время игрался на ленинграде 1 теневым озу с стс ом вместе .
в итоге вылилось все в приблуду(програмную) для скорпиона
мод+русик 48 прошивы с трдосом живет в озу .
http://zx.pk.ru/attachment.php?attachmentid=2448&d=1138433119

BASIC128
usr 0
clear 32767
radomize usr 15616
load "ROMrus"code
return
randomize usr 32768
а вобще через ресет любым любимым микроконтроллером набивать озу
это верное дело .

ArtemKuchin

10.04.2012, 23:00

В Спектруме память регенерит видеосканер а не процессор, поэтому процессор можно останавливать хоть навсегда, на памяти это не скажется

Я полагал, что рефрешит ULA, но для этого она использует регистр R, который Z80 выдает на шину, когда ничего не делает. Это нет так? R не используется и Z80 реально можно остановить и все будет очень хорошо?

А в z80 абсолютно случайно нет возможности по шине выдоить содержимое всех регистров?

Black_Cat

10.04.2012, 23:10

Это нет так? R не используется и Z80 реально можно остановить и все будет очень хорошо?да

А в z80 абсолютно случайно нет возможности по шине выдоить содержимое всех регистров?"абсолютно случайно" пиши в обработчике NMI вывод всех регистров, и не забудь что для снапшота ещё требуется сохранять дамп ОЗУ и содержимое системных портов

ArtemKuchin

11.04.2012, 00:31

да

"абсолютно случайно" пиши в обработчике NMI вывод всех регистров, и не забудь что для снапшота ещё требуется сохранять дамп ОЗУ и содержимое системных портов

Ооо. видно человек понимает, о чем я говорю и для чего надо :D

С NMI то понятно как делать, я думал может какой отладочный интерфейс в Z80 все-таки есть (в даташите не нашел), чтобы считывать регистры при останове процессора. Тогда можно было бы вообще код Z80 не писать, а все реализовать на внешнем мк. Ну видать не судьба.

Ну коли вы так хорошо в этом разбираетесь, то еще один вопрос, который меня волнует. На 48К (оригианльном) мапировать свою память (RAM) можно в область адресов ROM через ROMCS или в другие адреса как-то хитро тоже можно смапировать?

С портами сранно: по факту же на 48К почти нечего из портов и сохранять. Бипер прога сама дергает когда надо, клаву сохранять с джойстиком глупо. Итого остается только порт ULA 0xfe и то, только из-за бордюра. Я тут прав?

Black_Cat

11.04.2012, 01:30

Итого остается только порт ULA 0xfe и то, только из-за бордюра. Я тут прав?да, если для 48го

или в другие адреса как-то хитро тоже можно смапировать?низзя, а зачем тебе больше?

HardWareMan

11.04.2012, 09:36

Ооо. видно человек понимает, о чем я говорю и для чего надо :D
А что, Мэджик Батон уже отменили? Была такая в TR-DOS. :3

"абсолютно случайно" пиши в обработчике NMI вывод всех регистров, и не забудь что для снапшота ещё требуется сохранять дамп ОЗУ и содержимое системных портов
Добавлю лишь то, что этот самый обработчик можно подключать самому (сигнал M1+IORQ будет ключевым), взамен стандартного ПЗУ или ОЗУ, что позволит не вмешиваться в оригинальный софт. ;)

ArtemKuchin

11.04.2012, 21:05

А что, Мэджик Батон уже отменили? Была такая в TR-DOS. :3

Добавлю лишь то, что этот самый обработчик можно подключать самому (сигнал M1+IORQ будет ключевым), взамен стандартного ПЗУ или ОЗУ, что позволит не вмешиваться в оригинальный софт. ;)

я полагал, что наиболее важно для этого romcs +mni, чтобы вообще свой блок подрубить. т.е выставляем romcs, отключая пзу и делаем нми, z80 переходит на 66 но уже в нашей памяти. к чему m1 и iorq?

у меня тут еще одна идея возникла и один вопрос

идея: срам чип который слушает шину памяти и все что пишется - пишет в себя, т.е. там всегда копия памяти.

вопрос: а как сохранить состояние звукового чипа на 128? там же вроде важна последовательность команд идущих в один и тот же порт.

Black_Cat

12.04.2012, 00:39

идея: срам чип который слушает шину памяти и все что пишется - пишет в себя, т.е. там всегда копия памяти.а зачем, если можно и так всё считать?

вопрос: а как сохранить состояние звукового чипа на 128? там же вроде важна последовательность команд идущих в один и тот же порт.никак, да и смысла нет, т.к. AY и так заработает, но токо на долю секунды позже, что на слух неразличимо.

ArtemKuchin

12.04.2012, 01:12

зачем: так все равно а и d линии подводить чтобы ром подменить, пусть делом занимается, че простаивать.

по AY: на сколько я знаю, его можно запрограммироваь, например, играть один тон автоповтором. Если программирование не повторить, то возможны два варанта а) тона не будет где надо б) он останется от предыдущего состоянии и будет где ненадо.
Если б) можно решить сбросом, то как решить а)

И еще со 128К дебильная проблема. Регистр мэппинга памяти 0x7ffd не читабелен.
Как узнать какая страница активна в данный момент? Не факт, что добрый программер положит знаечние по адресу 23388. В голову приходит тольвао два варианта:
1) Мониторить шину и отслеживать out по этому порту и помнить его
2) Тупой вариант - посчитать что-от вроде MD5 содержимого памяти, перебрать все банки и найти с таким же дайджестом. Проблеме в том, что это на на 100% работает, если два банка забиты нулями, то и дайджест совпадет.

И еще этот тупой ЛОК бит. Что с ним делать, если он установлен???

HardWareMan

12.04.2012, 07:03

я полагал, что наиболее важно для этого romcs +mni, чтобы вообще свой блок подрубить. т.е выставляем romcs, отключая пзу и делаем нми, z80 переходит на 66 но уже в нашей памяти. к чему m1 и iorq?
К тому, что вам следует раскурить доку по Z80. Любое прерывание происходит не сразу, а только в определенный машинный цикл, это раз, затем идут долгие телодвижения по сохранению текущего состояния и только потом происходит подтверждение прерывания. И если ты отключишь ПЗУ до подтверждения прерывания а прерываемая программа была в ПЗУ крах неизбежен. Подключать свое ПЗУ надо только в момент подтверждения, и согласно идеологии самого Z80, который не имеет вывода INTA в отличии от ВМ80, подтверждение любого прерывания есть чтение опкода из порта, т.е. M1+IORQ. Только наличие этого сигнала + изначальный сигнал NMI (на случай если произошел IRQ, который подтверждается точно так же).
http://savepic.su/1707410.png

Black_Cat

12.04.2012, 08:37

по AY: на сколько я знаю, его можно запрограммироваь, например, играть один тон автоповтороми сколько времени он играет один тон автоповором? Секунда, полторы максимум. Ничего страшного если при загрузке снапа этой секунды не будет.

И еще со 128К дебильная проблема. Регистр мэппинга памяти 0x7ffd не читабеленты же вроде собирался снап 48к делать, дык зачем тебе #7FFD?

---------- Post added at 08:37 ---------- Previous post was at 08:21 ----------

и только потом происходит подтверждение прерываниянету в Z80 аппаратного подтверждения NMI, и переключать ПЗУ можно по NMI, единственно, что Magic в этом случае низзя юзать

HardWareMan

12.04.2012, 09:57

нету в Z80 аппаратного подтверждения NMI, и переключать ПЗУ можно по NMI, единственно, что Magic в этом случае низзя юзать
А, да, комбо IORQ+M1 только для IRQ. Тем не менее, триггер NMI обрабатывается только в последнем машинном цикле текущей команды, поэтому, подключать свое ПЗУ нужно аккуратно, желательно к следующему первому машинному циклу.

ArtemKuchin

12.04.2012, 10:16

По поводу NMI:
Согласен, даташит "курил" поверхностно, однако:

"Non-Maskable Interrupt (input, negative edge-triggered). NMI has a
higher priority than INT. NMI is always recognized at the end of the current
instruction, independent of the status of the interrupt enable flip-flop, and
automatically forces the CPU to restart at location 0066H."

Т.е. NMI самим процом всегда определяется в конце инструкции. Оно само о себе позаботилось. Конечно, до MNI надо переключить ПЗУ и при этом надо непопасть в середину выборки памяти процессором. Для поиски этого моменты можно использовать M1+ MREQ (указывает на получение инструкции их памяти), но это выглядит не очень надежно как-то. Может лучше на BUSA смотреть? Но точно не M1+IORQ. Конкретно в разделе по NMI сказано "The CPU response
to a non-maskable interrupt is similar to a normal memory read operation." И далее прекрасная диаграма в которой IORQ вообще не упоминается.

Из это диаграма, есть идея, что надо выставить NMI и ждать M1, как только M1, сменить ROMCS.

Касательно 128: ну. ээ. аппетит приходит во время еды.

О! Пока писал Hardwareman ответил.

Black_Cat

12.04.2012, 22:40

Из это диаграма, есть идея, что надо выставить NMI и ждать M1, как только M1так сразу снять NMI и ессно со снятием NMI переключить ПЗУ :)

Касательно 128: ну. ээ. аппетит приходит во время едыКакую однокристалку предполагаешь юзать? И ты не ответил:

или в другие адреса как-то хитро тоже можно смапировать?низзя, а зачем тебе больше?

ArtemKuchin

13.04.2012, 00:10

так сразу снять NMI и ессно со снятием NMI переключить ПЗУ :)

Какую однокристалку предполагаешь юзать? И ты не ответил:

NMI определяется в конце инструкции (из документации, что маразм, скорее всего речь идет о конце машинного цикла), определился он и перед следующей инструкцией идет переход на 66H. Вопрос: а когда деактивировать NMI? Ведь когда мы его устанавливали это могла быть середина другого цикла, а могла быть середина этого цикла, т.е. пересекли ли мы границу обработки NMI?. Можно деактивировать по подъему M1, что означает что новый машинный цикл уже идет и менять ПЗУ нельзя, так как могут быьт еще обращения к памяти в пределах этой инструкции. НО! Ведь не факт что мы попали перед низким уровнем на M1 при активации NMI, т.е. NMI могло быть просто не определено.

Т.е. вопроса три:
1) Когда подать NMI чтобы он точно был пойман
2) Когда снять NMI, чтобы он УЖЕ был точно пойман в этот момент
3) Когда сменить ROM чтобы не было каши в голове в проца

И получается, тогда, что надо смотреть на M1, когда M1 - низкий можно подать NMI, тогда в конце этого цикла NMI будет точно пойман, Далее, как только мы видим еще раз опущение M1 (после подъема), это означает начало нового INSTRUCTION FETCH и будет совсем мало времени, чтобы сменить ROM и снять NMI, тогда все будет точно поймано и пройдет чисто. Там реально маленький зазор по времени совсем, полтакта где-то.

Можно было бы просто блокировать процессор сигналом WAIT. Проблема с ними, что он не опрашивается не в начале или конце машинного цикла, в активен сразу (по крайне мере в доке нет ни слова о месте, когда ижет опрос этой линии). Т.е. выставив его мы можем просто приостановить выполнение текущей команды и сменим ROM получить кашу, так как выполнение ее продолжится и только потом сработает NMI.

Можно попробовать через BUSREQ. Оно срабатывает в конце машинного цикла. Т.е. можно активировать BUSREQ, подождать BUSACK. Сменить культурно ROM, выдать NMI, деактивировать BUSREQ, подождать активации M1 и деактивировать NMI. Здесь все операции не требуют быстрой реакции. Я посмотрел, вроде ULA на линии BUSREQ/BUSACK у процеса не завязано никак, так что конфликта нет.

Касательно МК - неважно, эта часть все равно будет на CPLD

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

sergey2b

13.04.2012, 02:12

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

ArtemKuchin

13.04.2012, 03:06

на 48К только RAM в адреса ПЗУ

HardWareMan

13.04.2012, 07:15

так сразу снять NMI и ессно со снятием NMI переключить ПЗУ :)
Сигнал NMI детектится по спаду (1=>0), в то время как IRQ по уровню (=0). В описании сказано, что это сделано для того, чтобы процессор не зациклился в вызовах NMI. Так что снимать не обязательно, но является признаком хорошего тона, да.

ArtemKuchin

13.04.2012, 19:42

Все, я понял как на самом деле надо, как я и говорил но с одной тонкостью. Как я и писал активировать ROMCS надо между началом M1 (low) и MREQ. Там около 140нс, для CPLD, более чем хватит. При этом надо смотреть, что на шине адреса, и делать это когда там PC=66H, но в самом начале M1 адрес PC не стабильный там еще, надо врубать активацию ROMCS по нему, но если ближе к MREQ выяснится, что адрес не тото, то отрубить ROMCS и ничего не делать. Единственное, я думаю, что вполне можно
просто подождать около 50нс от M1 и взять адрес, там глюков не должно быть уже никаких. Но в программировании CPLD проще сделать первый вариант, да к тому же он и надежнее.

А NMI вообще независимо подключается.

Чтиво: http://spectrum.alioth.net/doc/index.php/Spectranet_CPLD

HardWareMan

13.04.2012, 19:53

ЕМНИП, сигналы MREQ/IORQ являются стробирующими (как сигнал AS у М68К), в активности которых сигнал адреса уже стабилен. Так что мешает заюзать перепад 1=>0 для защелкивания адреса?

ArtemKuchin

13.04.2012, 20:05

"сигнал AS у М68К" - эт мне ничего не говорит :)

Использовать MREQ нельзя, ибо после него RD наступает ОЧЕНЬ БЫСТРО (быстрее, чем время задержки на cpld) и процессор ожидает инструкцию по адресу, в итоге к RD я CPLD не успеет ROMCS переключить и внешний чип активировать.

В итоге и MREQ и RD провалятся чипу спектрума, а не мне, начнется выбора в ПЗУ, а тут я меняю ROMCS и начинаю свою выбору, хрен знает че выйдет.

BYTEMAN

13.04.2012, 20:15

и сколько времени он играет один тон автоповором? Секунда, полторы максимум. Ничего страшного если при загрузке снапа этой секунды не будет.
а если плеер не перегрузит регистры громкости? (как делает куча плееров под сид?)

ArtemKuchin

13.04.2012, 20:18

а если плеер не перегрузит регистры громкости? (как делает куча плееров под сид?)

Да надо, надо все это мониторить и хранить ИЛИ по крайней мере ресетить в тишину при загрузке потом.
Даже долбаный бордюр на 48К на самом деле не читается, его тоже мониторить надо.

HardWareMan

13.04.2012, 20:26

"сигнал AS у М68К" - эт мне ничего не говорит :)
AS - Address Strobe.

Использовать MREQ нельзя, ибо после него RD наступает ОЧЕНЬ БЫСТРО (быстрее, чем время задержки на cpld) и процессор ожидает инструкцию по адресу, в итоге к RD я CPLD не успеет ROMCS переключить и внешний чип активировать.
Можно. Мой Специалист МХ2 же взлетел (http://zx.pk.ru/showpost.php?p=388300&postcount=220). У тебя есть 1,5 такта в цикле М1 и 2 такта в обычном. Тебе мало? Это при стандартных 3,5МГц получается 428нс и 571нс соответственно.
http://savepic.su/1768799.png

В итоге и MREQ и RD провалятся чипу спектрума, а не мне, начнется выбора в ПЗУ, а тут я меняю ROMCS и начинаю свою выбору, хрен знает че выйдет.
А тебе в любом случае придется развязывать стандартный ROMCS от своего. И вообще, мэджик батон работает, можешь подсмотреть там.

ArtemKuchin

13.04.2012, 20:31

мы друг друга не поняли видать.

Смотрим на диаграммы.
MREQ ушел вниз, RD ушел вниз почти сразу же после него. CPLD должна теперь сменить ROMCS и включить чип SRAM. НО! MREQ и RD уже пойманы ПЗУ и ПЗУ формирует свой ответ. Т.е. наше SRAM формирует свой ответ на шине, ПЗУ пытается свой. Никаких 100-500 нс нет, они делают это одновременно. ПЗУ дольше, SRAM быстрее. Че будет в итоге - хрен знает.

ради справедливости надо отметить, что такая преблуда как SOFT-ROM работает именно так, но почему она работает - для меня загадка. Ну хотя не совсем. ROMCS я так понимаю на OE ПЗУ завязан, так что выбора из ПЗУ просто обламывается и OUTPUT ПЗУ выключается. И счатье приходит. Но как-то некрасиво, блин, обламывать пзу в середине цикла чтения, я уж не говорю о том, что там на шине может творится, если на SRAM бит будет 1, а на ПЗУ 0. резюками что ли все линии заполнять.

HardWareMan

13.04.2012, 20:38

ради справедливости надо отметить, что такая преблуда как SOFT-ROM работает именно так, но почему она работает - для меня загадка. Ну хотя не совсем. ROMCS я так понимаю на OE ПЗУ завязан, так что выбора из ПЗУ просто обламывается и OUTPUT ПЗУ выключается. И счатье приходит. Но как-то некрасиво, блин, обламывать пзу в середине цикла чтения.
Читай мою приписку. И чего плохого в обломе ПЗУ? Я тогда вообще не понимаю, как ты собирался захватывать шину, не отключая стандартного дешифратора...

ArtemKuchin

13.04.2012, 20:44

HardWareMan

13.04.2012, 20:56

Я же писал, смена ROMCS между началом M1 и MREQ, т..е в пзу еще запрос на чтение просто не пришел. Никто на шину еще ничего не пишет. Путо на шине то еще. Я там один! А после смену ROMCS, когда приходит MREQ/RD ПЗУ уже их не получит и шина все еще моя.
Но КАК?! (С) Moss
Т.е., ты подменяешь конечный сигнал ROMCS со стандартного ПЗУ на свое, правильно? Тогда ваще не понятно, чего ты боишься. Инертность буферов одного ПЗУ покроется инертностью буферов другого ПЗУ. Конфликта как такового не будет, данные успеют к часу Х. Чего мудрить то?

ArtemKuchin

13.04.2012, 23:29

Но КАК?! (С) Moss
Т.е., ты подменяешь конечный сигнал ROMCS со стандартного ПЗУ на свое, правильно? Тогда ваще не понятно, чего ты боишься. Инертность буферов одного ПЗУ покроется инертностью буферов другого ПЗУ. Конфликта как такового не будет, данные успеют к часу Х. Чего мудрить то?

Тык, что я не понимаю о чем мы говорим. Что за коненый сигнал ROMCS? В чем его конечность? Я лично говорю про линию на шине ROMCS которая активирует встроенное ПЗУ или наоборот блокирует его, линия котрая подтянута пулапом по умолчанию и идет как в пзу, так и в ула.

И что значит "КАК"? Да просто, поднимаем ту линию и все, тогда ула уже включить вывод ПЗУ не может и читается наше пзу.

Еще раз объясню чего боюсь: того, что MREQ и RD проскочать на ПЗУ и она начнет формировать вывод ДО того как будет установлен ROMCS, тогда, мождет быть, на шину выйдут какие-то данные ПЗУ (формирование ответа начнется) и тут же после ROMCS выйдут данные данныз из моего SRAM. Если у пзу на выходе будет 0, а у меня 1, то по этой линии будет фактически КЗ. Очень непродолжительная коза, но все-таки будет. А линий 8, т.е. худший вариант это у меня 255, а в пзу 0 или наоборот.
Для уверенности, что такое не будет, надо знать точно, что в чипе пзу происходит, если данные запросили, а потом резко обрубили выход. И еще надо учесть что не у всех ПЗУ одинаковые.

---------- Post added at 23:29 ---------- Previous post was at 22:45 ----------

Есть еще дополнение касательно того, что можно остановить проц и работать с памятью напрямую, а рефрешить ее будет УЛА.
Вот выдержка из документации по спектруму:

3.9 Dynamic Memory Refresh. The CPU incorporates built-in dynamic RAM
refresh circuitry. As part of the instruction OP code fetch cycle,
the CPU performs a memory request after first placing the refresh
address on the lower eight bits of the address bus. At the end of the
cycle the address is incremented so that over 255 fetch cycles, each
row of the dynamic RAM is refreshed. This mechanism only applies to
the optional 32k expansion RAM in the 48k Spectrum.

Так, что нет, помрет память без проца. Не вся, только верхние 32К, но этого хватит.