А как?Сообщение от Jukov
Всех проблем это не снимало, некоторые игры затирали нижнее ОЗУ. Но многие бы пошли, те, что ставили в регистр I #FF.
А как?
Всех проблем это не снимало, некоторые игры затирали нижнее ОЗУ. Но многие бы пошли, те, что ставили в регистр I #FF.
Последний раз редактировалось Spectramine; 29.11.2010 в 17:11.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Ессесно не снимало, но при редактирование ПЗУ в теневом ОЗУ это создавало определенные удобства. Отловил я эту процедуру с помощью монитора STS - поставил там в отладчике условие остановки при отладке, если портились эти ячейки. Виновата во всем оказалась какая-то процедура калькулятора. Я её немного переделал. Если нужны подробности - могу скинуть исходник в формате аласма с прогой устраняющей ошибку.
Оригинальные ZX-Spectrum 48, 48 PLUS+BDI, ZX-INTERFACE 1 bis, KAY-1024, Кворум-192, Кворум-128 CP/M, Кворум-64, ZS-Scorpion 256 Turbo+&Caro ZX_MC, Мастер48К
Да, такие места найти очень сложно, и мониторы-эмуляторы, пожалуй, только и могут здесь помочь. Молодец!
Я это место нашел не сам, а изучал отличия прошивки Бейсик-Орель и оригинальной Синклер-82. То есть кто-то из авторов Бейсик-Орель в 1992г нашел это место без STS. Возможно, им был доступен дизассемблер бейсика от Яна Логана. Там по-моему эта проблема была описана.
Может, здесь выложишь исходник? Владельцам Орелей и Робиков он может быть полезен.
Вопрос тут не в целесообразности, а в принципиальной возможности хранения и загрузки дампов памяти с двух микросхем. Вообще поняв тут, что прямого доступа к ПЗУ не будет, хранение дампов лучше сделать на какой-нибудь SPI флешке, благо на дохлых материнках их навалом (только вот они в основном 3-х вольтовые) Заодно это позволит не мультеплексировать шину, а раздельно читать дамп из ПЗУ и писАть его в ОЗУ.
Минимально необходимые кристалы? Я так понимаю надо где-то на 32 I/O-ноги, 16+8 адрес+данные, ну и ещё 8 на SPI-интерфейс или мультиплексирование при использовании параллельного ПЗУ и управление процом.
В ПЛИС прошивку тоже можно сменить, МК конечно функциональней, но тут вопрос даже не в этом, а в цене/доставаемости и простоте/удобстве программирования ПЛИС или МК. Крейне желательно чтобы у кристалла была возможность внутрисхемного программирования.
Для меня это не проблема, если самой программе эти ячейки не нужны, при каждом старте образ ПЗУ будет перезаливаться заново.
"Во времена всеобщей лжи говорить правду - это экстремизм" - афоризм.
В том-то и дело, что некоторые программы устанавливают вектор прерывания на $FFFF, а там стоит код JR или JP, что вместе с содержимым ячеек 0000-0001 даёт команду перехода. Если эти ячейки испорчены, программа валится. И таких программ немало.
(Я ранее ошибся - не в регистр I заносится $FF, а вектор прерывания IM 2 указывает на $FFFF, хотя случай с I=$FF тоже фатален, если нулевая ячейка будет затёрта. В общем, если программа так или иначе использует ячейки 0000-0004, она слетит). Так что проще сделать так, чтобы после копирования нижняя страница ПЗУ не переключалась.
Так тогда может собрать схему на золотых деталях? В этом вроде как тоже нет необходимости, но раз принципиально возможно - почему нет? Будет приятно на нее смотреть, желтенькие такие.
Реализация прямого доступа к памяти, хоть на микроконтроллере, хоть на плис, является затратной как по усилиям на разработку, так и по деталям. Если бы эти затраты были оправданы, например, необходимостью высокой скорости пересылки данных или освобождением процессора - тогда да. Но в твоем же случае никаких преимуществ от аппаратной пересылки нет!
А что, разве МК сложнее достать или запрограммировать, чем ПЛИС???
Да все современные МК это позволяют, возьми любой из свежих PIC от Microchip, можно даже 16-разрядный - по цене одно и то же. У них у всех есть не только внутрисхемное программирование, но и самопрограммирование, когда МК под управлением программы-загрузчика может считать новую прошивку, например, из флешки, и самопрошиться. Куда тут можно еще удобнее!
Зачем его перезаливать в ОЗУ, если он может оставаться в ПЗУ и работать оттуда? Просто ради красоты? Так никакой здесь нет красоты, а есть потеря совместимости программ. Как уже много раз говорили, некоторые игры просто затирают всю область ПЗУ. Что, все будем переделывать, ломать?
Ты наверное не в курсе, но некоторые так и делают, причём безо всякой необходимости. Вообще тебя явно не туда заносит, и не понимаю что ты мне хочешь доказать.
Есть, и я тут уже говорил про это (но ты слишком увлёкся отстаивая свою идею, что оппонентов не слышишь), это использование только одного чипа для всего этого.
Не сравнивал, поэтому и уточняю
Опять ты не слышишь что тебе говорят, к ПЗУ не будет прямого доступа.
Придётся тогда ПЛИС или МК после заливки дампа использовать для блокировки записи в область ПЗУ
Если понадобится, значит будем ломать.
"Во времена всеобщей лжи говорить правду - это экстремизм" - афоризм.
Ну, мы же здесь вроде пытаемся решить задачу разработки электронной схемы рациональным способом, а не "кто сложнее", так?
А рациональный способ - это максимум функциональности при минимуме затрат на разработку, сборку, наладку.
Экономится один чип ПЗУ, но из-за этого надо решать проблему аппаратной инициализации ОЗУ при включении системы. А в этой системе что-то другое есть, видеоконтроллер например? Он на чем реализован?
Достать МК или ПЛИС примерно одинаково, если заказывать у фирм-дистрибьютеров. Но выбор МК у дистрибьютеров обычно гораздо богаче, да и цены отличаются раз в 5. Если FPGA со скромными параметрами будет стоить $10-15, то 16-битный МК со скоростью 40млн операций в секунду - $2.50.
Выбор между одним и другим зависит главным образом от требований к решаемой задаче. Если не требуется высокого быстродействия - то обычно МК предпочтителен. А вот задача блокировки ОЗУ на запись - это для аппаратной логики или ПЛИС, МК здесь не справится.
Ну да, только так, блокировка записи. Я довольно долго жил на "Орель БК-08", где нет блокировки записи, и поэтому очень хорошо знаю, насколько много программ портят содержимое по адресам 0000-3FFF.
Ломать - это шаг отчаяния. Сравни сам, сколько времени у тебя займет разработка и реализация блокировки записи по адресам ПЗУ, и сколько времени займет взлом и переделка всех программ, которые в этом нуждаются!
Абсолютно так, только один ньюанс, ты не знаешь какую схему я хочу разработать.
И обвязка - если это будет например ROM-диск
Т34ВГ1, ОЗУ статическое
Ну вот видишь, полегоньку что-то вырисовывается. И безо взякой категоричности :-)
Возможно это признак прогресса ;-)
Вот без понятия пока. Хотя могу предположить, что если программирование ПЛИС мне ещё интересно, то взлом программ точно нет.
"Во времена всеобщей лжи говорить правду - это экстремизм" - афоризм.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
