DreamShell 4.0 RC 2

[TeX]

(16.07.2014 08:05)SWAT писал(а):  

(15.07.2014 22:28)TeX писал(а):  Кстати попробовал записать boot_loader_wsc_bfont_sd.bios - после того как нажимаешь там SD (в менюшке где оранжевая спиралька) идет Loading и после 100 процентов черный экран. На SD карте лежит папка DS, пробовал и просто в корень все кидать. Карта кингстон 8 гб, фат 32, может в ней беда? gdi ориг образы тож не запускаются. ISO некоторые идут

Ну не знаю на счет SD, она же загружает что-то
Так если с диска грузишься, то тоже ничего толком не работает? А есть другая SD? Какой класс у этой?

Если с диска, ситуация поярче, НО по сути тоже самое, класс у карты 4, карту 10 класса на 8 гиг не видит вообще. Вот у тебя на видео ты запускал Sonic 2, но у меня не работает и когда я нажимаю оптимизировать образ - эта консоль на секунду выскакивает и всё. Я пробовал ложить gbi и в корень к исо мейк и в папку data, почему то не нашел инструкции по оптимизации gbi.

[SILENT_Pavel]

(16.07.2014 20:55)TeX писал(а):  Я пробовал ложить gbi и в корень к исо мейк и в папку data, почему то не нашел инструкции по оптимизации gbi.

GDI надо вкладывать в КОРЕНЬ папки iso_make затем следовать инструкции под спойлером что называется "Конвертируем gdi игры под dreamshell 4.0 RC 1" в факе, либо следовать как Сват написал, еще не проверял как именно лучше, но старый способ традиционный и до сих пор хуже работать не стал.

data папка только для cdi
---
SWAT, чего-то вдруг любая версия (и cdi и gdi и регионы) skies of arcadia зависает во время первой заставки в процессе, чего раньше кажется не было (или я забыл как обошел этот висяк и какой версией), в общем может быть так что в RC1 работает, а в RC2 нет? Тормоза кстати лёгкие пропали, позже попробую загрузиться с RC1 на всякий случай перепроверить.

[SWAT]

Разница между оптимизированным GDI и его репаком (с помощью repack_gdi) довольно большая:

1) Оптимизированный GDI всегда будет больше размером, чем репак в ISO, так как там сохраняется вся структура диска, с пустым местом в том числе, которого там обычно предостаточно.
2) Репак можно сжать в CSO, а GDI пока нет, я думал над тем чтобы это сделать, но не знаю стоит ли заморачиваться.
3) Репак хакает LBA в бинарниках, а оптимизация не трогает ничего, все остается в оригинальном виде. Хак LBA в некоторых случаях может не сработать, если в игре есть какие то кастомные заморочки с TOC. Для проблемных игр эшелон встраивали загрузчик в бинарник на сколько я знаю, так что не любую игру можно легко и просто хакнуть, хотя это работает в большинстве случаев конечно.
4) Оптимизация GDI происходит на порядок быстрее, чем его репак, буквально минута и все готово. Скорость аналогична методу bin2iso.

5) Старый метод для конвертирования 3-х трекового GDI (с помощью bin2iso), где нужно лишь сконвертировать track03.bin в ISO, фактически является тем же самым, что и оптимизация GDI, это тот же самый процесс, в котором выкидываются субканалы из секторов. Отличие только в том, что bin2iso не трогает сам .gdi файл, в котором прописаны форматы треков. Но так как в этом случае трек с данными только один, то этим можно и пренебречь и запускать его напрямую, так как TOC для таких образов генерируется автоматически и в GDI файле нет необходимости как таковой. Но в целом оптимизация GDI, это просто развитие метода bin2iso, основное преимущество которого как раз и заключается в том, чтобы не заниматься репаком образов, у которых больше 3-х треков и сохранить все в девственном виде как и в случае c методом bin2iso.
Кстати SILENT_Pavel, в твоем факе не написано что для метода bin2iso нужен только track03.bin, не обязательно все конвертировать (и загрузчику остальное не нужно), да и вдруг кто решит запустить первый трек вместо третьего, всякое бывает И если будешь править текст для RC 2+ то можно исправить еще требования к именованию файлов, теперь они могут быть с пробелами.

6) Для будущей версии ISO Loader, если нужно будет проигрывать CDDA треки, нужен формат образа с описанием всех треков, а такими являются только CDI и GDI из поддерживаемых в данный момент. Хотя конечно будет возможность положить CDDA треки и рядом с обычным ISO образом, но в этом случае эмуляция будет не совсем полноценной. В ответе на одну из команд в системных вызовах, не будет информации о текущем LBA проигрываемого CDDA трека, хотя это не критично в большинстве случаев, я думаю мало игр за этим вообще следят. Есть вариант конечно брать информацию из TOC оригинального IP.BIN, но к сожалению много образов уже сделаны либо с одним и тем же IP.BIN, либо вообще с пустым TOC в нем, поэтому я на него не могу ориентироваться. Хотя возможно я что нибудь придумаю в довесок, по крайне мере буду проверять что там есть TOC вообще и пытаться в нем найти CDDA треки, а может и нет, пока не знаю в общем.
Но в целом конечно GDI в этом случае лучший выбор. В нем гораздо проще будет сконвертировать для SD допустим (хотя возможно в исключительных случаях и для HDD придется) PCM треки в ADPCM или просто их заменить на свои, да и форматы PCM можно использовать разные (загрузчик к слову ищет заголовок RIFF WAVE в файлах .raw и .wav и по нему определяет иной формат), в зависимости от требовательности игры к ресурсам и тому, на чем вы вообще эту музыку слушаете. Допустим если звук подключен к старенькому ЭЛТ телевизору, то можно из стерео сделать моно и сократить в 2 раза тем самым нагрузку.
Хотя наверное лучше уж в ADPCM сконвертировать, это в 4 раза уменьшает нагрузку даже в стерео, а в моно так вообще, можно его хоть с VMU проигрывать При этом разницу в качестве звука вряд ли можно будет ощутить через динамики старого телевизора (да и нового тоже, если слушать не громко). Я ее лично только в наушниках ощущаю, либо на более менее нормальной акустике, так как музыка в этом формате немного теряет сочность и увеличиваются посторонние шумы.
А вообще с конвертацией CDDA в основном придется возиться только пользователям SD. Так как HDD в большинстве случаев позволяет с не значительными потерями FPS слушать оригинальные RAW треки в формате Stereo PCM 16 bit 44100 Hz. Я на HDD вот пока только у Vigilante 8 2nd offense заметил появление небольших лагов затрудняющих управление, которые там появляются в силу корявости порта этой игры с PS1 на DC я думаю. У остальных игр которые я пробовал подобных проблем нет.

По поводу Skies of Arcadia, она точно работала на версии загрузчика 0.4.0 (SD/HDD) и на 0.4.1 (HDD), zolwikwkurwik видео снимал. Надо бы проверить еще раз на SD, возможно с в версии 0.4.1 она перестала работать именно с нее (хотя вряд ли конечно).
Какая кстати версия этой игры поддерживает VGA вообще? А то я скачал одну, а она только с композитом дружит Не хочется переподключать провода туда-сюда

[SILENT_Pavel]

@SWAT, за развёрнутую информацию благодарю, рано или поздно обновлю фак в любом случае, но вот возник такой вопрос.

Можно ли каким-то образом организовать захват изображения при игре с диска или с sd карты через ну как бы дримшелл или если от него что-то в памяти остаётся после загрузки игры? Т.е. обычный скриншот сделать в режиме vga и записать его на sd карту без потерь типа bmp или может таки pvr (?), дело в том что эмуляторы это не то, нужно получить дампы vga изображения с реальной консоли в некоторых играх, но нечем выходит. Готов смириться с жуткими тормозами во время дампа экрана, с тем что снимать можно будет только при игре с диска если и даже к крашам готов если это хоть как-нибудь криво-косо бы организовать было бы круто. Понятно что в публичной версии дримшелл загрузчика это не нужно, так сказать отдельную сборку бы можно даже старой версии.

[SWAT]

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

[SILENT_Pavel]

(24.07.2014 22:00)SWAT писал(а):  В новой версии, из за доп. функционала, запаса места вообще не осталось. В общем если будет возможность, я обязательно сделаю, вещь то прикольная и может многим понравится.

Подозревая об этом я и написал выше что может попробовать со СТАРОЙ версии дримшелл, если она меньше весила в памяти и пусть запускает полтора игры, какой там был до RC1 или даже еще раньше, даже так будет очень интересно. Успехов в работе!

апд: или вот придумал - может можно полностью из RC2 вырезать поддержку любого звука (и GD-DA и любых других) и видео MPEG вообще - освободится место в памяти без звука норм скрины снимать на отдельной сборке, а публичная версия продолжит развитие без этих фишек. говорю без знания дела, не знаю можно ли это на самом деле вырезать или оно по умолчанию внутри

[SWAT]

(24.07.2014 23:06)SILENT_Pavel писал(а):  апд: или вот придумал - может можно полностью из RC2 вырезать поддержку любого звука (и GD-DA и любых других) и видео MPEG вообще - освободится место в памяти без звука норм скрины снимать на отдельной сборке, а публичная версия продолжит развитие без этих фишек. говорю без знания дела, не знаю можно ли это на самом деле вырезать или оно по умолчанию внутри

Тут ты немного напутал. Не важно что поддерживает сама DS, у нее дополнительный функционал в модулях, которые можно загрузить и выгрузить в любой момент.
Я же говорю о загрузчиках. Это такая микропрограмма, которая загружается в системную область памяти (в большинстве случаев) и эмулирует работу системных вызовов GD-ROM, которыми пользуются игры. Вот для него то как раз место очень ограничено, не больше 32 Кб на все. Когда запускается игра, то всю работу выполняет именно этот загрузчик, самой DS в памяти уже нету. Поэтому весь функционал, который доступен во время игры, должен быть размещен именно в загрузчике. Будь то чтение данных из образа или проигрывание CDDA, или распаковка CSO образов и т.п.
Многое из загрузчика образов я вынес в ядро DS, допустим тот же модуль isofs (появился в версии 0.3.0), который парсит образы разных форматов, предоставляет загрузчику уже конечную, минимальную информацию для его работы. Или например инициализация SD карты, с версии 0.4.0 уже тоже отсутствует в загрузчике, так как ее и так инициализирует ядро DS, повторно это делать нет необходимости, а кода там для этого довольно много (по меркам загрузчика конечно). В общем загрузчик и ядро DS уже давно неотъемлемы друг от друга, но работают они по очереди, а не одновременно.

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

[shadow]

SWAT, почему именно 32 Кб, а не 64? Что это за цифра такая магическая

[SWAT]

(25.07.2014 12:04)shadow писал(а):  SWAT, почему именно 32 Кб, а не 64? Что это за цифра такая магическая

Никакой магии здесь нет
Все очень просто... ну почти
Основное место загрузчика, находится в области так сказать системной памяти (та что ниже 0x8c010000).
Как можно заметить, размер всей этой области равен 64 Кб. Но в ней находятся еще и другие данные.
Допустим первые 16 Кб (0x8c000000 - 0x8c004000) заняты системными вызовами и некоторыми параметрами, трогать их пока нельзя, так как я эмулирую только для GD, а они там в середине.
В области 0x8c00f400 - 0x8c010000 у KATANA находится таблица для прерываний, а в области 0x8c00C000 - 0x8c00f400 находится stack.
Простой арифметикой мы получаем область 0x8c004000 - 0x8c00C000, размер которой равен 32 Кб ровно.
Конечно если размещать загрузчик в high memory, то там можно больше разгуляться, но эта область не надежна, поэтому я не могу расчитывать на нее полноценно.
Более того, некоторые игры используют и пространство 0x8c004000 - 0x8c008000 (до IP.BIN) для своих нужд, поэтому такие игры приходится запускать размещая загрузчик в конце памяти, вместо начала. Так же это приходится делать если игра запускается с IP.BIN, так как он "откусывает" половину пространства для загрузчика, а в 16 Кб его уместить уже просто нереально.
Не все игры, которые используют эту область, используют ее полностью. Некоторые используют всего пару килобайт, поэтому загрузчик можно просто немного сместить, если он занимает меньше чем 32 Кб. Поэтому 32Кб для загрузчика это предел, который лучше вообще не достигать, а иметь запас в пару-тройку килобайт для подобных случаев, да и свободное пространство за загрузчиком, которые он не занял, используется для некоторых других нужд (не обязательных правда, но все же).
В общем вот такая картина пока. Нужно заняться эмуляцией всех системных вызовов для того чтобы получить дополнительную память. Но сколько ее в итоге получится, если по сути нужно повторить тот же функционал (за исключением GD), я пока затрудняюсь ответить, может и не стоит овчинка выделки, хотя в данный момент даже пара килобайт была бы кстати.

В общем я сейчас ужал загрузчики как мог, но все равно не влезает запись на файловую систему (для сохранения скриншотов), она прибавляет для загрузчика веса почти на 5 Кб, а это выходит за рамки дозволенного примерно на 2 Кб. Поэтому скорее всего данный функционал я не сделаю до момента создания эмуляции всех системных вызовов. А лепить отдельный "толстый" загрузчик, который будет размещаться только в конце памяти и именно для этих целей я наверное не буду, так как это потянет за собой еще другие доработки. Лучше уж взяться за остальные системные вызовы и сделать все как надо. К тому же у меня есть еще и другие идеи, для которых тоже нужно свободное место

[TeX]

(25.07.2014 13:13)SWAT писал(а):  

(25.07.2014 12:04)shadow писал(а):  SWAT, почему именно 32 Кб, а не 64? Что это за цифра такая магическая

Никакой магии здесь нет
Все очень просто... ну почти
Основное место загрузчика, находится в области так сказать системной памяти (та что ниже 0x8c010000).
Как можно заметить, размер всей этой области равен 64 Кб. Но в ней находятся еще и другие данные.
Допустим первые 16 Кб (0x8c000000 - 0x8c004000) заняты системными вызовами и некоторыми параметрами, трогать их пока нельзя, так как я эмулирую только для GD, а они там в середине.
В области 0x8c00f400 - 0x8c010000 у KATANA находится таблица для прерываний, а в области 0x8c00C000 - 0x8c00f400 находится stack.
Простой арифметикой мы получаем область 0x8c004000 - 0x8c00C000, размер которой равен 32 Кб ровно.
Конечно если размещать загрузчик в high memory, то там можно больше разгуляться, но эта область не надежна, поэтому я не могу расчитывать на нее полноценно.
Более того, некоторые игры используют и пространство 0x8c004000 - 0x8c008000 (до IP.BIN) для своих нужд, поэтому такие игры приходится запускать размещая загрузчик в конце памяти, вместо начала. Так же это приходится делать если игра запускается с IP.BIN, так как он "откусывает" половину пространства для загрузчика, а в 16 Кб его уместить уже просто нереально.
Не все игры, которые используют эту область, используют ее полностью. Некоторые используют всего пару килобайт, поэтому загрузчик можно просто немного сместить, если он занимает меньше чем 32 Кб. Поэтому 32Кб для загрузчика это предел, который лучше вообще не достигать, а иметь запас в пару-тройку килобайт для подобных случаев, да и свободное пространство за загрузчиком, которые он не занял, используется для некоторых других нужд (не обязательных правда, но все же).
В общем вот такая картина пока. Нужно заняться эмуляцией всех системных вызовов для того чтобы получить дополнительную память. Но сколько ее в итоге получится, если по сути нужно повторить тот же функционал (за исключением GD), я пока затрудняюсь ответить, может и не стоит овчинка выделки, хотя в данный момент даже пара килобайт была бы кстати.

В общем я сейчас ужал загрузчики как мог, но все равно не влезает запись на файловую систему (для сохранения скриншотов), она прибавляет для загрузчика веса почти на 5 Кб, а это выходит за рамки дозволенного примерно на 2 Кб. Поэтому скорее всего данный функционал я не сделаю до момента создания эмуляции всех системных вызовов. А лепить отдельный "толстый" загрузчик, который будет размещаться только в конце памяти и именно для этих целей я наверное не буду, так как это потянет за собой еще другие доработки. Лучше уж взяться за остальные системные вызовы и сделать все как надо. К тому же у меня есть еще и другие идеи, для которых тоже нужно свободное место

У меня возник вопросеГ, а какие файлы должны лежать на SD, чтобы запустился дримшел, когда в биосе лежит boot_loader_wsc_bfont_sd.bios? У меня там лежит папка DS и Boot_loader скачанные с твоего сайта, почему то не запускает дримшелл вот это - boot_loader_wsc_bfont_sd.bios, черный экран после того как нажму Load from SD. И не важно есть ли что-то на SD или нету, такое впечатление, что не хватает файла какого-то. Ради этого даже SD адаптер сделал без проводов, USB разъем вместо Serial вставил. Тоже самое.

[SWAT]

(26.07.2014 15:16)TeX писал(а):  У меня возник вопросеГ, а какие файлы должны лежать на SD, чтобы запустился дримшел, когда в биосе лежит boot_loader_wsc_bfont_sd.bios? У меня там лежит папка DS и Boot_loader скачанные с твоего сайта, почему то не запускает дримшелл вот это - boot_loader_wsc_bfont_sd.bios, черный экран после того как нажму Load from SD. И не важно есть ли что-то на SD или нету, такое впечатление, что не хватает файла какого-то. Ради этого даже SD адаптер сделал без проводов, USB разъем вместо Serial вставил. Тоже самое.

А с sd_loader_with.bios загружается?
Прогресс-бар не появляется я так понял, а сразу черный экран что-ли? На какую кнопку жмешь?

И сразу в догонку, скорее всего ты пытаешься загрузить ядро в котором есть инициализация устройств на шине G1. Так как ты используешь BIOS не проходящий проверку Holly, то и ядро тебе нужно загружать, которое не использует шину G1. Это SD_DS_CORE.BIN, который тебе нужно переименовать в DS_CORE.BIN и заменить им оригинальный DS_CORE.BIN.

[TeX]

(27.07.2014 08:03)SWAT писал(а):  

(26.07.2014 15:16)TeX писал(а):  У меня возник вопросеГ, а какие файлы должны лежать на SD, чтобы запустился дримшел, когда в биосе лежит boot_loader_wsc_bfont_sd.bios? У меня там лежит папка DS и Boot_loader скачанные с твоего сайта, почему то не запускает дримшелл вот это - boot_loader_wsc_bfont_sd.bios, черный экран после того как нажму Load from SD. И не важно есть ли что-то на SD или нету, такое впечатление, что не хватает файла какого-то. Ради этого даже SD адаптер сделал без проводов, USB разъем вместо Serial вставил. Тоже самое.

А с sd_loader_with.bios загружается?
Прогресс-бар не появляется я так понял, а сразу черный экран что-ли? На какую кнопку жмешь?

И сразу в догонку, скорее всего ты пытаешься загрузить ядро в котором есть инициализация устройств на шине G1. Так как ты используешь BIOS не проходящий проверку Holly, то и ядро тебе нужно загружать, которое не использует шину G1. Это SD_DS_CORE.BIN, который тебе нужно переименовать в DS_CORE.BIN и заменить им оригинальный DS_CORE.BIN.

Блин, я вот этого то и не понял как раз, где взять этот SD_DS_CORE.BIN, можешь скинуть? После того как переименую, его закинуть в корень SD, в папку DS или прошить в биос? С SD_Loader_with тоже самое, а вот с ядра DS, грузит на ура. Процесс бар есть в boot_loader_wsc_bfont_sd.bios, доходит до 100% и усё, потом чет там думает секунду и черный экран сразу же. Объясни плиз, я нигде не могу инфы найти по этой теме.

[SWAT]

(28.07.2014 00:48)TeX писал(а):  Блин, я вот этого то и не понял как раз, где взять этот SD_DS_CORE.BIN, можешь скинуть? После того как переименую, его закинуть в корень SD, в папку DS или прошить в биос? С SD_Loader_with тоже самое, а вот с ядра DS, грузит на ура. Процесс бар есть в boot_loader_wsc_bfont_sd.bios, доходит до 100% и усё, потом чет там думает секунду и черный экран сразу же. Объясни плиз, я нигде не могу инфы найти по этой теме.

Да очевидно у тебя проблема именно с ядром. В общем этот SD_DS_CORE.BIN есть и на GitHub и в архиве DreamShell 4.0 RC 2 + Boot Loader
Положить его надо вместо оригинального DS_CORE.BIN, ничего прошивать больше не нужно, если прошит Boot Loader.

[TeX]

(28.07.2014 08:18)SWAT писал(а):  

(28.07.2014 00:48)TeX писал(а):  Блин, я вот этого то и не понял как раз, где взять этот SD_DS_CORE.BIN, можешь скинуть? После того как переименую, его закинуть в корень SD, в папку DS или прошить в биос? С SD_Loader_with тоже самое, а вот с ядра DS, грузит на ура. Процесс бар есть в boot_loader_wsc_bfont_sd.bios, доходит до 100% и усё, потом чет там думает секунду и черный экран сразу же. Объясни плиз, я нигде не могу инфы найти по этой теме.

Да очевидно у тебя проблема именно с ядром. В общем этот SD_DS_CORE.BIN есть и на GitHub и в архиве DreamShell 4.0 RC 2 + Boot Loader
Положить его надо вместо оригинального DS_CORE.BIN, ничего прошивать больше не нужно, если прошит Boot Loader.

ЕССССССССССССССССС, Огромное тебе спасибо!!!!!!!!!!!!! Всё отлично работает!! Соник работает, не вылетает!! А где нибудь есть статья по решению этой проблемы, ибо я с горем пополам и с тобой ели разобрался, а если кто нибудь столкнется с этой проблемой, может и прекратить искать решение, но я не из таких, как видишь . Еще раз огромное СПАСИБО!!!! У тебя есть вебмани кошелек? Я бы тебе подкинул деньжат, с зарплаты

[SWAT]

Пожалуйста.
Так то нигде это не описано кроме комментов к релизу DS на сайте, просто наделся что проблема с биосом быстрее решится, но не тут то было.

Кошелек есть (Click to View)

R229139561638
Z154525812765

[TeX]

(29.07.2014 15:43)SWAT писал(а):  Пожалуйста.
Так то нигде это не описано кроме комментов к релизу DS на сайте, просто наделся что проблема с биосом быстрее решится, но не тут то было.

Кошелек есть (Click to View)

R229139561638
Z154525812765

Привет еще раз, тут такое дело обнаружил, у меня 2 дрима, один целый, у другого нету механики на GD роме и драйвера на плате и вот он стоит на дриме у которого прошитой биос (sd_loader_with.bios или boot_loader_wsc_bfont_sd.bios ) и игры либо запускаются с раза 50-го, либо не запускаются. А вот если поставить привод хороший, со всей механикой и драйвером, то все игры идут с 1 го раза. Так вот что интересно, если я запаяю туда драйвер, ситуация нормализуется или нет, привод этот был рабочий, но мои эксперименты его давненько сожли)) Драйвер у нас найти не просто, доставка дорогая, не хотелось бы лишнюю копейку выкидывать на ветер)) Еще вот видал статью о перемычке между тест поинтами, что думаешь по этому поводу, нельзя такое делать?

[SWAT]

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

[shadow]

Игры с 50-го раза запускаются потому что на гд-ром плате полетел кварц на 33.8688 Мгц. А так да, видел то что кидают перемычку на плате дримкаста и кварц уже не нужен. Если найду то обязательно скину.

[SWAT]

Ааа так перемычка для кварца, я думал для драйвера )
Ну это да, я в общем то поэтому и спрашивал, есть ли задержка при старте дрима, если есть, то это однозначно не работает генератор для AICA ака кварц 33.8688 Мгц (только это не просто кварц, а активный кристалл).
На материнской плате он не совсем того номинала, что нужен, поэтому я бы не советовал так делать, звук будет немного другим, да и проблемы с запуском все же будут, хоть и меньше.

[TeX]

(01.08.2014 14:52)SWAT писал(а):  Ааа так перемычка для кварца, я думал для драйвера )
Ну это да, я в общем то поэтому и спрашивал, есть ли задержка при старте дрима, если есть, то это однозначно не работает генератор для AICA ака кварц 33.8688 Мгц (только это не просто кварц, а активный кристалл).
На материнской плате он не совсем того номинала, что нужен, поэтому я бы не советовал так делать, звук будет немного другим, да и проблемы с запуском все же будут, хоть и меньше.

А где он находится здесь, именно тот кварц который полетел. Предполагаю под номером 1, но не уверен.