Прошивка DREAMCAST

[Rio]

Мне вот интересно, если Дримкастовский .exe-шник скремблируется (данные и команды перемешиваются в псевдо-случайном порядке), как потом Sh4 знает в каком порядке эти команды нужно потом опять выполнять?

[ValeraK]

(07.09.2012 10:27)Rio писал(а):  Мне вот интересно, если Дримкастовский .exe-шник скремблируется (данные и команды перемешиваются в псевдо-случайном порядке), как потом Sh4 знает в каком порядке эти команды нужно потом опять выполнять?

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

Кстати у SH4 данные и команды не разделяются, а сосуществуют в одном пространстве, в частности команды вызовов/переходов адреса тянут как данные за самими кодами команды...

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

[Rio]

Ясно, спасибо!
А информация о секциях хранится где-нибудь? Или их нет как таковых?

[ValeraK]

(07.09.2012 20:35)Rio писал(а):  А информация о секциях хранится где-нибудь? Или их нет как таковых?

А зачем её хранить, считываем последовательно (по моему блоки в 32 байта, давно было забыл уже) и по фиксированному алгоритму меняем их местами всегда одно и то же, что для перемешивания то и для раскладывания, алгоритм тот же...

[Rio]

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

[ValeraK]

(08.09.2012 08:58)Rio писал(а):  Не я имею в виду при загрузке образа бинарника в память наверняка же файл разбивается в разные страницы памяти, например сегмент констант только для чтения, .bss тоже свои права доступа, для кода тоже не имеет смысл устанавливать права на запись ну и т.д.

Да блин как всё запущено... Может пора сорваться с крючка некрософта, в частности у ARM была куча режимов юзвер, супервизор etc, но посмотрите к чему пришло - кортекс.
Народ давно уже понял, есть ряд задач для изоляции, но консоль тем и отличается от писюка (хорошую машину писюком не назовут), что для софта _все_ ресурсы доступны, виртуализация ни к чему, главное геймплей без тормозов.
Да я согласен с разделением архитектур классики ФонНеймана и Гарвардской, но сейчас народ объединяет лучшие стороны обеих подходов. Хотя лично мне импонирует машина Тьюринга. Hitachi SuperH очень грамотная архитектура, сочетающая/сбалансировшаяся в себе ряд подходов.
Конечно с одной стороны нехорошо иметь права на запись в область машинного кода из программы, но тем самым мы лишаем себя возможности модификации кода во время работы, а это уже снижает гибкость ПО при разработки.

IMHO общий подход прост - незачем перекладывать свои огрехи на других - разработал софт для платформы - вот и отвечай перед юзверями - ты сам полностью в ответе за всё - одна задача в один момент времени - ну уж если настолько ленив, то неси ответственность и за поставщиков моторчиков.

[Rio]

Ну хорошо, а как быть с такой ситуацией, когда программа (по ошибке) обратится в сегмент (область данных) кода и затрет там что-то, чисто случайно? Как выловить такой exception? Такие ошибки ведь очень сложно обнаружить. К примеру, выход за границы массива, без использования C++11 контейнеров вроде array или "старого" std'шного vector (где есть операторы безопасного доступа at())?
Ведь если такое случится, увидеть (найти) в коде программы это будет очень трудно, а все что ты увидишь, это (в лучшем случае) "unknown opcode" или что-то в этом духе. в худшем ход программы может измениться так, что вообще хрен поймешь что происходит.

[cybdyn]

грамотно написанная программа ничего не затрёт))) поэтому этот класс ошибок скорее на совести программера....

а так :
1 - в процах есть возможность установить эксепшн на область памяти как на доступ в неё на исполнение команд (execution) так и на при запись-чтеиние (store/load) . но я не встречал чтобы этим часто пользовались. хотя как вариант может использоваться в конструкции try-catch...

2- сырую программу никто не выкладывает - её тестируют, долго и упорно, и с опытом прогера приходит то что такое может случиться с малой вероятностью...

3- данныые в программе расположены в определённом порядке, вначале код , далее много чего, в конце динамическая область heap, какбы в ней если чё затрётся то на код не повлияет. но всё равно будет абра-катабра твориться)) кстати встречная проблема это стэк. которыы растёт с конца памяти вниз.

4- как вариант проблема локализуется при разработке в более крутой среде (IDE), котор отслеживает выход за пределы массива, переполнение стэка и т.д. но полностью автоматизировать не получиться , так как процесс динамический...

вообщем всё в руках программиста..

кстати код и данные хранящиеся в одном пространстве и у процов MIPS ,, используются в ps1, ps2, psp .... ))) народ играет, никто не жаловался пока на данную особенность )))

[ValeraK]

(09.09.2012 17:00)Rio писал(а):  а как быть с такой ситуацией, когда программа (по ошибке) обратится в сегмент (область данных)
а все что ты увидишь, это (в лучшем случае) "unknown opcode"

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

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

[SWAT]

Вот уж обленились все со временем, подавай им умный дебаг и т.п. чтоб все за программиста делалось само.
Это не то поколение, сравнивать с текущим совсем не стоит. Раньше по другому все делалось и было на совести программистов. Раньше нельзя было выпустить патч для игры (консольной), не доделок не выпускали практически, все тестировалось и загонялось до дыр, а главное без всех этих наворотов. А сейчас когда все делается за прогеров, они начинают лениться и отдаляться от "внутренностей" своей программы, он может в общем то и не знать что там происходит, он только в IDE кнопочки по нажимал.

[cybdyn]

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

[Rio]

Ой ну прям вообще, обленились все... Сват, а откуда такое знание, кто когда и как писал? Сам лично в игровой компании в то время работал, аки ассемблерные листинги ковырял?
Конечно можно и что-то в духе:
#define MAX_AR_SIZE 10
for(i=0; i<MAX_AR_SIZE; i++)
a[i] = ...;
написать, и то же выхода за границы не будет, но производительно ли такое программирование?
Конечно хорошо, что писался такой крутой сверх-оптимизированный код, без ошибок, прямо в ассемблере в дебаге многократно прогнанный и т.п., но наверное все-таки время диктует изменения?
Быстрее пишется код, быстрее деньги зарабатываются. И с этим уже ничего не поделаешь. Пускай даже и в ущерб стилю.

[SWAT]

Я ковырял SDK и примеры того времени, я думаю этого достаточно, чтобы иметь хотя бы небольшое представление о том, как и что делалось.
В общем то и сейчас программирование под дрим, далеко не ушло от этого.
На счет скорости разработки я лично как то сомневаюсь, достойные игры делать быстрей не стали, а вот качество пострадало.
Никто не говорит про сверх оптимизированный код, ошибки есть всегда и везде, не нужно утрировать. Но вот ради интереса вспомни в скольких играх на предыдущих платформах ты видел баги и сколько их сейчас в играх, которые только вышли (без учета патчей, которые потом это исправляют и то не всегда).

[Rio]

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

[SWAT]

Так об этом и речь! Что раньше не было ничего!

[Rio]

Кстати не в курсах есть ли возможность дебага с одновременной поддержкой графического вывода?

[SWAT]

В смысле?

[Rio]

Запустить свою прогу в консоли\эмуляторе, поиграть , и когда произойдет достижение какого-либо условия (к примеру, число хитпоинтов снизят с 200 до 100), выйти на точку останова в отладчике.

[SWAT]

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

[Rio]

Хех, круто, почитал, удобная шняжка этот UBC, я даже и не знал что в Sh4 есть он =)
Ну и как, не затирает?)