Наступна таблиця показує процес виконання програми, коли запускається програма, установлена за допомогою WHDLoad. Я сподіваюсь, що це допоможе зрозуміти, як працює WHDLoad і як WHDLoad, slave-модуль і встановлена програма взаємодіють між собою.
КОРИСТУВАЧ |
|
Операційна Система |
|
WHDLoad |
|
Slave-модуль |
|
Установлена програма |
|
КОРИСТУВАЧ |
|
Slave-модуль |
|
WHDLoad |
|
Це зовсім короткий покроковий опис того, як створити патч, що використає WHDLoad. Даний пункт пояснює найпростіший варіант. У реальності такого варіанта швидше за все не буде. У наступних главах, будуть окремо описані особливі випадки й проблеми, з якими ви можете зустрітися.
Деякі програми використовують свій власний формат диска. Це означає, що DIC не в змозі створити образ такого диска. Щоб прочитати файли з такого диска або створити його образ, рекомендується використати RawDIC. За подробицями звертайтеся до документації програми RawDIC.
Якщо програма використовує, то більше чим один диск, те slave-модуль повинен переадресувати доступи до дисків до відповідного файлу образа. Іноді це не легко. Деякі програми підтримують більше одного дисководу, так що ви можете використати номер дисководу для вибору потрібного диска. Більшість програм використовує ідентифікатор (наприклад назва) на кожному диску, щоб розрізняти їх. У цьому випадку, використайте змінну, котра містить номер диска, і при кожному зверненні до ідентифікатора диска (визначайте такий доступ, аналізуючи параметри для завантажника диска) збільшуйте змінну (а якщо досягнуто останнього диска, то зменшуйте її), у надії на те, що завантажник буде перечитувати ідентифікатори знову й знову поки не виявить потрібний диск. Деякі програми видають запит, щоб користувач вставив правильний диск - відключіть цей запит.
Ну, що тут казати. Використовуйте функцію resload_SaveFile, щоб записати відповідну область пам'яті на диск. Якщо хочете, то можете ще й зашифрувати її так, щоб "чайникам" було не легко її виправити. Не рекомендується робити запис безпосередньо в образ диска (використовуючи функцію resload_SaveFileOffset) тому, що якщо щось піде не так, як треба (наприклад, яка-небудь помилка або зависання), то можливо, що образ диска буде ушкоджений.
Запис прогресу гри здійснюється тими ж способами, що й у випадку з таблицею рекордів.
Під час роботи slave-модуль і встановлена програма не повинні мати ніяких звернень
до OS! Тому всі звернення з установленої програми повинні бути відключені або
переспрямовані. Якщо їх не так багато й вони не потрібні при роботі через WHDLoad
(типу exec.Disable() або exec.SuperState()),
то просто можна змінити їх командою NOP ($4e71).
Якщо виклики несуть важливу функцію (типу exec.DoIO()), переадресуйте
їх slave-модулю, і емулюйте їх. Також можете створити просту exec.library в
невикористаній області пам'яті (проініціалізируйте довге слово за адресою $4).
Подивитеся як це зроблено у вихідному тексті для модуля "Oscar.slave",
що емулює exec.AllocMem(). Для виявлення таких викликів OS,
виставте початковий execbase в $f0000001 з тією метою,
щоб всі програми, які можуть використовувати execbase, видали "Помилку
Адреси".
Якщо емулювати функції OS занадто складно, тоді
просто використайте один з kickemu-пакетів, які
можуть бути знайдені в дистрибутиві whdload-dev. Там
є один пакет для Kick 1.3 ('src/sources/whdload/kick13.s'') і один
для Kick 3.1 ('src/sources/whdload/kick31.s''). Ці пакети вимагають
оригінального образа кікстарта й створюють
повноцінну OS в WHDLoad. Див. також файли readme, які
поставляються в комплекті із цими пакетами
На цих процесорах адресний простір обмежено розміром 16 Мб ($000000...
$ffffff), тому що центральний процесор має тільки 24 адресні лінії. У результаті
всі доступи до більш високих адрес виконуються до адрес нижче 16 Мб, просто
ігноруючи адреси старші 8 біт. Деякі програми використовують ці біти для зберігання
даних або просто забувають очищати їх. На процесорах з повним 4Гб адресним простором,
типу 68020/680ec30/68030/68040/68060 це не відбуватиметься, тому що звернення
буде йти до повної 32-х бітної адреси.
Для рішення цієї проблеми, ви повинні підкоректувати ці виклики й перенаправляти
їх на відповідні адреси.
Іноді причиною доступу до дивних адрес може
бути непроініціалізований покажчик. У цьому
випадку може допомогти очищення $400 - ws_BaseMemSize.
Стекові фрейми, створені процесором після преривання і подій, різні для різних
процесорів класу 68ДО. На 68000 стековий фрейм становить 6 байт, за винятком
"Помилки Адреси" і "Помилки Шини". У стековому фреймі перебуває
збережене значення SR в (a7) і PC в (2,a7). На всіх інших процесорах (68010
+) мінімальний стековий фрейм становить 8 байт і додатково містить номер вектора
як слово в (6,a7). Цей формат стекового фрейму $0, що складається з чотирьох
слів, створений для "Trap #xx" і переривань на 68010-68060. Стекові
фрейми для інших подій різні на кожному процесорі. Інструкція RTE на 68000 працює
інакше чим на 68010+. На 68000 вона просто відновлює SR й PC і продовжує виконання
програми з перерваної адреси. На 68010 + вона додатково звільняє стековий фрейм
в залежності від його формату.
Деякі програми проштовхують (записують у стік?) адресу (PC) і SR, а потім виконують
інструкцію RTE. Це працює тільки на процесорах 68000, а на 68010+ результат
непередбачений.
Якщо програма працює таким чином, ви повинні
виправити це місце. Іноді буває досить
замінити RTE на RTR.
Є відмінність, якщо регістр, що використовується у випадку адресації з попереднім
зменшенням адреси, то виконання команди (RL) також утримується у списку регістрів.
На процесорах 68020, 68030, 68040 значення, записане у пам`ять є вихідним значенням
регістра, зменшеним на розмір операції. На процесорах же 68000 й 68010 записується
вихідне значення (не зменшене).
Оскільки ця інструкція рідко використовується, то на даний момент не помічено
ні однієї програми, яка б мала проблеми через описані розходження.
Іноді перед вами буде стояти вибір, що використовувати, образи дисків або файли. Обидва способи мають свої переваги. Використання образів диска, як правило, більше легкий і більше швидкий спосіб створити slave-модуль. Але реальні файли значно простіше кешувати (якщо дуже мало пам'яті або пам'ять фрагментирована). Зайнятого місця на жорсткому диску також буде менше при роботі з реальними файлами в порівнянні з використанням образів дисків. Рекомендується використати образи дисків тільки в тому випадку, якщо файлів дуже багато (більше 30-ти).