dlcorp.nedopc.com (ZX-Форум) (21+, запрещено для детей)

deathsoft wrote: Еще пара есть ADSP-21065L в обычных pqfp, тоже хз что с ними делать.

у меня такие есть тоже. МРЗ плеер на них сделай.

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

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

Но это ДСП и тут кодинг "нашару" не прокатывает, сорец надо затачивать под конкретные особенности архитектуры, зато и производительность будет соответствующая.

lvd wrote:у меня такие есть тоже. МРЗ плеер на них сделай.

Да там ног дофига чуть ли не 240.

deathsoft wrote:Это какой ТИ на 300МГц? на 300МГц только 5502, а 67ххх от 700 МГц и выше. И 5502 - не VLIW там максимум 2 инструкции за такт.

имею ввиду камень tms320c6745 котрый есть в qfp176 на 300 мгц.

а в CCS можно выбрать ближайший c67x+ - сопоставимо или нет?

deathsoft wrote:TFT_DATA наверняка объявлена как volitile long * и на этом сразуже тормоза.

ну так это ж регистр данных LCD... они все ж с volatile ...

deathsoft wrote:P.S. А вообще надо было листинг генерировать а не асм, чтобы куски сишного осрца шли в пермешку с асмом и было видно что во что преобразовалось.

понятия не имею как в CCS это сделать =) пока глубоко не разбирался...

deathsoft wrote:типы никто так не объявляет #define u32 unsigned long int, надо писать так typedef unsigned long int u32;

ну это я для себя макросы такие юзаю, а то неудобно писать
тогда зачем их определять typedef'ами?

deathsoft wrote:Естественно код самого эмулятора приставки придется поменять, чтобы он рендерил в массив соответствующим образом, в один массив одни строки в другой другие. Но это ДСП и тут кодинг "нашару" не прокатывает, сорец надо затачивать под конкретные особенности архитектуры, зато и производительность будет соответствующая.

во-во! если дальше такое направление развивать - то прийдем к необходимости переписывания ядер эмуляции z80, m68k и др. на DSP-ассемблере

deathsoft wrote:Да там ног дофига чуть ли не 240.

Ну а для мрз-плеера тебе придётся зацепить сдрам, бутфлеш, сдкарту и т.д., вполне себе МП-система получится.

Romanich wrote:ну это я для себя макросы такие юзаю, а то неудобно писать
тогда зачем их определять typedef'ами?

Макросы экспандятся с пробелами, а тайпдеф - как просто новый тип. В результате и зза макросов можешь нарваться на неожиданые глюки.

Romanich wrote:во-во! если дальше такое направление развивать - то прийдем к необходимости переписывания ядер эмуляции z80, m68k и др. на DSP-ассемблере

Асемблер там нах не нужен, все можно написать на Ц, но также как под х86 для использования ССЕ надо программу писать особым образом - также и под ДСП и его архитектуру, а иначе никаких гигагерцев не хватит если писать так что юзается 1/8 производительности и большинство блоков процессора просто простатвают.

lvd wrote:Ну а для мрз-плеера тебе придётся зацепить сдрам, бутфлеш, сдкарту и т.д., вполне себе МП-система получится.

С такимже успехом можно купить у ЧРВ VSxxxx как у вас в нгс и сделать все на 1й микросхеме.

deathsoft wrote:С такимже успехом можно купить у ЧРВ VSxxxx как у вас в нгс и сделать все на 1й микросхеме.

C ещё большим успехом можно юзать эмуляторы на пц, а не паять бляцфины на 400 мгц на 4слойках.