[repstosw 18]

И сколько получилось? 40+15 FPS? И это по 16-битной шине?? Это всё равно очень медленно.

 

Это FPS всего эмулятора, а не экранный FPS:

 

while(!quit)
{
// эмуляция процессоров Z80, M68020
// эмуляция видео-подсистемы (4 графических слоя)
// эмуляция звуковой системы (FM синтезатор + ADPCM + Wav sound*4 канала)
// эмуляция системы ввода
// эмуляция памяти
//эмуляция ROM-set-а

// отрисовка на дисплей
// вывод звука
// считывание клавиш
}

 

Вот это всё ВМЕСТЕ - 55 FPS !

Изменено 8 сентября, 2017 пользователем repstosw

[_pv 52]

Это FPS всего эмулятора, а не экранный FPS:

 // эмуляция процессоров Z80, M68020}

да как-то всё равно не очень-то быстро.

Z80 на АВРах даже как-то эмулируется, 68к с его 5мипсами не особо сложнее должно быть.

а тут целый блэкфин на 550МГц.

 

[jcxz 184]

да как-то всё равно не очень-то быстро.

Z80 на АВРах даже как-то эмулируется, 68к с его 5мипсами не особо сложнее должно быть.

а тут целый блэкфин на 550МГц.

Не просто "не быстро", а ОЧЕНЬ медленно.

Лет уже почти 20 назад писал подобный эмулятор только для КР580ВМ80 3МГц-ового и на компе с CPU = i486 работающем на 100МГц (или 120?).

FPS у меня получался (если без задержек и без эмуляции реалтайма) в несколько раз выше чем на эмулируемой системе.

Так, что я даже сделал потом эмуляцию реалтайма: для каждой эмулируемой команды суммировал её время выполнения и периодически делал задержку для компенсации лишнего времени. И графика у меня тоже эмулировалась (2 режима: 256*256*4 бита или 512*256*2 бита с регистрами палитры) и звуковой синтезатор (3 + 1 канала) и прочая периферия.

И (если не вносить задержки) всё летало в несколько раз быстрее чем на эмулируемой системе.

Да и как иначе - процессор эмулятора уже был на порядки быстрее эмулируемого.

А у автора ещё в разы более мощная система.

[repstosw 18]

Если критические участки в программе переписывать на Ассемблере (эмуляция процессоров, эмуляция графики / звука), то производительность должна вырасти.

Это выходит за рамки моей задачи, так как было нужно портировать эмулятор (автором которого я НЕ являюсь) на устройство с ADSP BF533.

 

В целом результатом доволен, быстродействие вышло таким:

 

45 - 55 FPS при эмуляции CPS1

30 - 40 FPS при эмуляции CPS2.

 

При этом показывается каждый кадр, звуковой поток не рвётся (темп плавно понижается).

 

Система CPS слишком наворочена, так как графика/звук у неё заточены под игры(быстрые).

И не надо сравнивать какой-то допотопный КР580ВМ80 в связке с убогой графикой (Спектрум небось? )

 

Ну и вдогонку: телефон с процессором ARM9 800 МГц воспроизводит данный эмулятор хуже (не мой порт), и КПК на 300 МГц ещё хуже!

 

Замерял количество полных отрисовок экрана за 1 секунду (Буфер 320x224x2 из SDRAM + конвертация 16-битной палитры + вывод на дисплей) - 188 раз.

 

Мерял этим:

 

static __inline__ enable_cycles(void)
{
__asm__ __volatile__ ("R2=SYSCFG;");
__asm__ __volatile__ ("BITSET(R2,1);");
__asm__ __volatile__ ("SYSCFG=R2;");
}

static __inline__ disable_cycles(void)
{
__asm__ __volatile__ ("R2=SYSCFG;");
__asm__ __volatile__ ("BITCLR(R2,1);");
__asm__ __volatile__ ("SYSCFG=R2;");
}

static __inline__ start_cycles(void)
{
__asm__ __volatile__ ("R2=0;");
__asm__ __volatile__ ("CYCLES=R2;");
__asm__ __volatile__ ("CYCLES2=R2;");
}

static __inline__ u64 get_cycles(void)
{
u32 t0,t1;
__asm__ __volatile__ ("%0=cycles;%1=cycles2;":"=d"(t0),"=d"(t1));
return t0|((u64)t1<<32);
}

 

 

да как-то всё равно не очень-то быстро.

Z80 на АВРах даже как-то эмулируется, 68к с его 5мипсами не особо сложнее должно быть.

а тут целый блэкфин на 550МГц.

 

Это типа троллинг? :santa2:

Полный перечень того что делается:

 

// эмуляция процессоров Z80, M68020

// эмуляция видео-подсистемы (4 графических слоя)

// эмуляция звуковой системы (FM синтезатор + ADPCM + Wav sound*4 канала)

// эмуляция системы ввода

// эмуляция памяти

//эмуляция ROM-set-а

 

// отрисовка на дисплей

// вывод звука

// считывание клавиш

 

[_pv 52]

Это типа троллинг?

вовсе нет, просто на первый взгляд ресурсов там более чем достаточно для этой задачи. и то что просто использование ДМА для вывода в дисплей на треть подняло fps просто намекает на не очень оптимальное этих ресурсов использование.

но тут да, надо допиливать код под блэкфин.

 

 

> Полный перечень того что делается:

// эмуляция процессоров Z80, M68020

Z80 вполне эмулируется на avr, 68к не особо сложнее, арифметика только по разрядности не для 8ми битного авр.

 

// эмуляция видео-подсистемы (4 графических слоя)

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

 

// эмуляция звуковой системы (FM синтезатор + ADPCM + Wav sound*4 канала)

с этим в оригинале вроде как Z80 и справлялся.

 

// эмуляция памяти return mem[addr]

//эмуляция ROM-set-а return rom[addr]

// отрисовка на дисплей DMA

// вывод звука DMA

 

// эмуляция системы ввода

// считывание клавиш

[jcxz 184]

И не надо сравнивать какой-то допотопный КР580ВМ80 в связке с убогой графикой (Спектрум небось? )

В чём убогость-то? У Вас вроде 320*224? И во сколько раз это отличается от 256*256? А во сколько раз отличается частота вашего CPU от древнего i486?

И какие частоты у эмулируемых ваших CPU? Во сколько раз они отличаются от ВМ80?

Эмулируемые системы вполне сравнимы по скорости.

И это при том, что система команд у DSP гораздо более эффективна для обработки потоковых данных (конвертации экранной картинки).

И ресурсов (и по частоте CPU и по скорости работы системы памяти) у вас в разы больше чем было у меня на i486.

Да и тут уже несколько раз Вам показали с цифрами, что вывод картинки у Вас должен быть в разы быстрее.

 

Это типа троллинг? :santa2:

Нет. Просто кому-то для частотного управления двигателем достаточно слабого 8-битника, а кому-то гигагерцового ARM-а не хватает для мигания лампочками.... :laughing:

 

Полный перечень того что делается:

И что?

И сколько тактов тратится на "эмуляция памяти"? Или на "эмуляция ROM-set-а"?

В чём сложность-то? Самое тяжёлое там: эмуляция графики. Но, как уже заметил ув. _pv, даже с самыми тормозными характеристиками вашей шины достаточно 3мсек на вывод всей картинки. Остальное - вообще крохи.

 

// эмуляция звуковой системы (FM синтезатор + ADPCM + Wav sound*4 канала)

с этим в оригинале вроде как Z80 и справлялся.

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

Для DSP (тем более такого довольно высокого класса) это пара процентов загрузки CPU максимум.

Когда-то писал на TMS320VC5502 на 220МГц. И у меня ЧМ-модулятор генерил поток 96kS/s на внешний кодек, параллельно принимая с него-же поток сэмплов. При этом нагружая этот самый DSP всего на несколько единиц процентов.

 

PS: Сорри - нашёл и заглянул сейчас в тот свой код ЧМ-модулятора, пересчитал - он занимал процессорного времени менее 0.5%. И это ещё не самый быстрый алгоритм (считаю синус полиномом), можно гораздо быстрее.

Непонятно какие могут быть трудности с каким-то "FM-синтезатором" звуковой частоты

На CPU автора (даже если предположить, что он генерит 3 синусоидальных сигнала и смешивает их потом, а не тупо - 3 меандра ) даже в случае 3 синусоид и частоты квантования 48кГц, загрузка CPU этим синтезатором должна быть менее 1%.

[repstosw 18]

заглянул сейчас в тот свой код ЧМ-модулятора, пересчитал - он занимал процессорного времени менее 0.5%. И это ещё не самый быстрый алгоритм (считаю синус полиномом), можно гораздо быстрее. Непонятно какие могут быть трудности с каким-то "FM-синтезатором" звуковой частоты

 

На CPU автора (даже если предположить, что он генерит 3 синусоидальных сигнала и смешивает их потом, а не тупо - 3 меандра biggrin.gif ) даже в случае 3 синусоид и частоты квантования 48кГц, загрузка CPU этим синтезатором должна быть менее 1%.

 

Так и хочется натянуть свой опыт, да?

Не выйдёт.

Не мешайте говно с мёдом.......

 

Для начала советую поразмыслить над тем, как эмуляция вашего ЧМ-модулятора относится к:

 

1) Capcom System QSound

2) Yamaha YM2151

3) OKI6295

 

Вы хотя бы один из этих чипов эмулировали ?

 

Более на дебаты теоретиков не реагирую.

 

------------------

 

А теперь вопросы:

 

1) Насколько тормозной тип double для BlackFin ? Имеет ли смысл его заменить float ?

 

2) Каким образом можно изменить параметры растактовки шины EBIU для асинхронного банка, когда он был инициализирован ранее?

Тоесть переинициализировать. После того как EBIU запущен, изменить параметры перезаписью в региcтры: EBIU_AMBCTL0 EBIU_AMBCTL1 EBIU_AMGCTL не получается!

 

 

 

[jcxz 184]

Для начала советую поразмыслить над тем, как эмуляция вашего ЧМ-модулятора относится к:

Относится так, что любой источник звука - это генератор синусоиды (в самом тяжёлом случае) или их суммы. ЧМ-модулятор - тоже генерит синусоиду.

А более простые звуковые синтезаторы вообще меандры генерят. :laughing:

[repstosw 18]

Попробовал поставить частоту дискретизации 22050 Гц вместо 44100. Скорость всей эмуляции возросла до 75 FPS.

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

[jcxz 184]

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

Из чего можно сделать вывод что её тоже надо оптимизировать

PS: Насчёт "параметров растактовки шины EBIU" - это правильный ход мыслей, но тут я не советчик.

 

1) Насколько тормозной тип double для BlackFin ? Имеет ли смысл его заменить float ?

Если ваш Blackfin не имеет аппаратной поддержки double (смотреть надо мануал на ядро), то очень тормозной - на порядки медленнее аппаратного. И если можно заменить - следует менять.

А если он не имеет аппаратной поддержки и float тоже, то лучше стараться вообще не использовать плавучку. Тем более, что она редко когда реально нужна.

[_pv 52]

А теперь вопросы:

1) https://ez.analog.com/thread/43898

2) что-то не припомню никаких граблей при одновременном использовании на EBUI sdram и асинхронной шины.

 

Из чего можно сделать вывод что её тоже надо оптимизировать

так точно.

генераторы синуса и проигрование wavов, по нормальному реализованные, не могут занимать столько же времени как та же обработка палитры для всей картинки, объёмы данных не сравнимы.

[repstosw 18]

2) что-то не припомню никаких граблей при одновременном использовании на EBUI sdram и асинхронной шины.

Не про то вопрос был.

Когда я меняю параметры асинхронного банка (на котором висит дисплей) ПОВТОРНО - новые параметры не вступают в силу!

В мануале написано, что не следует менять параметры контроллера шины EBIU именно AMB во время его работы (тоесть когда уже проинициализирован) - мой случай.

Тогда как их менять, если по зарез надо?

При нажатии на reset ведь как-то работает. Может есть какой-нибудь способ перезагрузить параметры шины?

 

Если ваш Blackfin не имеет аппаратной поддержки double (смотреть надо мануал на ядро), то очень тормозной - на порядки медленнее аппаратного. И если можно заменить - следует менять.

А если он не имеет аппаратной поддержки и float тоже, то лучше стараться вообще не использовать плавучку. Тем более, что она редко когда реально нужна.

Это плохо!

Весь код звуковой системы на плавучке. Эмулятор был написан для x86 на языке Cи, при перекладке кода на Blackfin, будет эмуляция FPU.

[_pv 52]

Когда я меняю параметры асинхронного банка (на котором висит дисплей) ПОВТОРНО - новые параметры не вступают в силу!

В мануале написано, что не следует менять параметры контроллера шины EBIU именно AMB во время его работы (тоесть когда уже проинициализирован) - мой случай.

то есть в регистр EBIU_AMBCTL0 ничего не пишется??

а если сначала перед этим в EBIU_AMGCTL ноль записать, а потом поменять EBIU_AMBCTL0 и активировать банк обратно?

 

[repstosw 18]

1) https://ez.analog.com/thread/43898

Чуть-помогло (+5 FPS), сделал -fast-fp , бинарник чуть-вырос, что свидетельствует о замене либы, что радует.

 

то есть в регистр EBIU_AMBCTL0 ничего не пишется??

а если сначала перед этим в EBIU_AMGCTL ноль записать, а потом поменять EBIU_AMBCTL0 и активировать банк обратно?

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

Попытка укоротить setup, hold, write - приводит к плачевным результатам: кривая картинка на дисплее или её отсутствие.

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

 

Если дисплей привешать к PPI, то к нему можно будет обращаться как к массиву точек? Или PPI генерит свою развёртку ?

Дисплей PPT9999-A003-06-Q со встроенным контроллером S6E63D6.

 

Вот драйвер для него (тоже сам писал):

 

/*
Display PPT9999-A003-06-Q
S6E63D6 Display Controller Driver
*/

#define OLED_Command (*(volatile u16*) 0x20000000)
#define OLED_Data    (*(volatile u16*) 0x20010000)

const u8 Font8x8[2048]=
{
//тут моноширный шрифт 8x8 пикселей кодировка DOS :)
}

u16 OLED_Key;  //Цвет прозрачности
u16 OLED_Back; //Цвет фона

void OLED_Register(u8 c,u16 d)
{
OLED_Command=c;
OLED_Data=d;
}

void OLED_Prepare(void)
{
OLED_Command=0x23;          //Select 18-/16-bit Data Bus Interface
OLED_Register(0x03,0x0111); //16-bit Mode
OLED_Register(0x10,0x0000); //IC Standby Off
OLED_Register(0x05,0x0000); //Display Off
OLED_Register(0x18,0x003D); //Frame Rate > 80 Hz
OLED_Register(0xF8,0x000F); //VGH = +5V
OLED_Register(0xF9,0x000F); //VGL = -5V
OLED_Register(0x70,0x2B80); //Gamma Top/Bottom R
OLED_Register(0x71,0x3600); //Gamma Top/Bottom G
OLED_Register(0x72,0x3E00); //Gamma Top/Bottom B
OLED_Register(0x73,0x1F19); //Gamma Top Bottom R1,2
OLED_Register(0x74,0x2214); //Gamma Top Bottom R3,4
OLED_Register(0x75,0x221B); //Gamma Top Bottom G1,2
OLED_Register(0x76,0x1E16); //Gamma Top Bottom G3,4
OLED_Register(0x77,0x241E); //Gamma Top Bottom B1,2
OLED_Register(0x78,0x2617); //Gamma Top Bottom B3,4
SimpleDelay(1000000);
OLED_Register(0x05,0x0001); //Display On
}

void OLED_Rectangle(u16 xs,u8 ys,u16 xe,u8 ye)
{
OLED_Register(0x35,319-xe);
OLED_Register(0x36,319-xs);
OLED_Register(0x37,(ys<<8)|ye);
OLED_Register(0x20,ys);
OLED_Register(0x21,319-xs);
OLED_Command=0x22;
}

void OLED_Clear(u16 Color)
{
register u32 i;
OLED_Rectangle(0,0,319,239);
for(i=0;i<320*240;i++) OLED_Data=Color;
}

void OLED_OutChar(u16 x,u8 y,u8 c,u16 k)
{
register u32 i;
OLED_Rectangle(x<<3,y<<3,(x<<3)+7,(y<<3)+7);
for(i=0;i<64;i++)
{
  if(((Font8x8[(c<<3)+(i>>3)]>>(7-(i&7)))&1)) OLED_Data=k;
  else OLED_Data=OLED_Back;
}
}

void OLED_OutString(u16 x,u8 y,u8* s,u16 k)
{
register u32 i=0;
while(s[i])
{
  OLED_OutChar(x+i,y,s[i],k);
  i++;
}
}

void OLED_OutNumber(u16 x,u8 y,u16 n,u16 k)
{
OLED_OutChar(x  ,y,(n/100)%10+'0',k);
OLED_OutChar(x+1,y,(n/ 10)%10+'0',k);
OLED_OutChar(x+2,y, n     %10+'0',k);
}

void OLED_OutSprite(u16 x,u8 y,u16 w,u8 h,const u8* s)
{
register u32 i;
register u16 c;
register u16 *S=(u16*)s;
OLED_Rectangle(x,y,x+w-1,y+h-1);
for(i=0;i<(w*h);i++)
{
  if((c=S[i])!=OLED_Key) OLED_Data=c;
  else OLED_Data=OLED_Back;
}
}

[_pv 52]

Если дисплей привешать к PPI, то к нему можно будет обращаться как к массиву точек? Или PPI генерит свою развёртку ?

Дисплей PPT9999-A003-06-Q со встроенным контроллером S6E63D6.

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