Плата центрального недопроцессора nedoCPU-32

[Shaos]

Подтянул из инета пиксельартовскую картинку и кусочек её затолкал в PIC32

[Shaos]

Интересно, что чёрно-белый вариант вышеприведённой картинки тоже далеко не бессмысленный

[JeNNeR]

http://www.giantbomb.com/space-quest-th ... 08/images/
http://www.welovedosgames.net/article/C ... 0graphics/

*sarcasm mode on*
Если цвета с этих Ч/Б картинок без переделки (т.е. "искаропки") совпадут с их цветными аналогами, тогда поздравляю, Вы изобрели заново способ кодирования цветных изображений
*sarcasm mode off*

З.Ы. Искренне завидую. И поздравляю с впечатляющим результатом.

[Shaos]

Ну заново-незаново, а на одном чипе дешевле $5

По первому линку - аппловские картинки - надо смотреть какая там палитра была у Возняка.

А по второму линку - картинки испорчены - их уже кто-то растянул (я на них натыкался уже).

P.S. А вообще как я уже писал AGI-движок можно портировать, тогда и Space Quest будет, и Police Quest и т.д.

[Shaos]

Посмотрел википедию - у Возняка цвета вроде похожи, но расположены в очень странном порядке:



P.S. Возможно он их младшими битами вперёд засовывал, а не старшими...

P.P.S. Хотя вроде тоже нет - на своих местах только чёрный, белый и оба серых, а всё остально - перепутано...

[Shaos]

Вот набросал номера аппловской палитры и всех моих четырёх палитр - больше всего совпадений у палитры 1, однако полного совпадения нет нигде и логики формирования цветов я не вижу, ну и кроме того пара цветов чуть другие (ярко красный вместо оранжевого и жёлто-зелёный вместо коричневого):

Code: Select all

Apple-II:        Pal0  Pal1  Pal2  Pal3
----------------------------------------
 0=BLACK   0000  0000< 0000< 0000< 0000<===
 1=RED     0001  0100  1000  0001< 0010
 2=D.BLUE  0010  0001  0010< 0100  1000
 3=PURPLE  0011  0010  0100  1000  0001
 4=D.GREEN 0100  1000  0001  0010  0100<
 5=GRAY1   0101  0101< 0101< 0101< 0101<===
 6=M.BLUE  0110  0011  0110< 1100  1001
 7=L.BLUE  0111  1011  0111< 1110  1101
 8=BROWN   1000  1100  1001  0011  0110 ?
 9=ORANGE  1001  0110  1100  1001< 0011 ?
10=GRAY2   1010  1010< 1010< 1010< 1010<===
11=PINK    1011  0111  1110  1101  1011<
12=L.GREEN 1100  1001  0011  0110  1100<
13=YELLOW  1101  1110  1101< 1011  0111
14=AQUA    1110  1011  0111  1110< 1101
15=WHITE   1111  1111< 1111< 1111< 1111<===
----------------------------------------
                     4     8     7     7

P.S. Посмотрел на те аппловские картинки внимательнее - они на самом деле чёрно-белые, т.к. в областях, которые должны быть покрашены одним цветом на самом деле разные паттерны пикселов присутствуют и не с шагом не кратным 4 - так что раскрашиваться они НЕ будут

[Shaos]

Видимо от режима 256x200 с почти что квадратными пикселами (и круглыми окружностями) придётся отказаться (ну не натягивается он на частоту 57.27272 МГц) - в результате остаются только ПЦ режимы - 320x200 да 640x200 с цветом и без...

С другой стороны 256x200 тоже можно оставить как вариант - ведь с ним всё быстрее и без кварца можно обойтись...

Поэкспериментировал - 256x200 без дополнительных проверок на режим работает ровно с такой же скоростью, что и 320x200, а вот если такую проверку поставить, то ВСЕ режимы начинают работать медленнее - т.е. вывод: отказываемся от 256x200 как бесполезного режима, в результате частоту проца без кварца уменьшаем с 64 до 60 и 320/640 начинают влезать более удобным образом...

P.S. Убрал режим с 256 пикселами в строке

[Stan]

Убрал режим с 256 пикселами в строке

А Вам не кажется, что этот режим был бы весьма удобен для отображения скриншотов ZX_Spectrum или даже для эмуляции последнего на платформе PIC32 ?

[Shaos]

Убрал режим с 256 пикселами в строке

А Вам не кажется, что этот режим был бы весьма удобен для отображения скриншотов ZX_Spectrum или даже для эмуляции последнего на платформе PIC32 ?

Ну 256x192 замечательно влезает в 320x200

А вообще для показа ZX-экранов нужен цвет, который на PIC32 без дополнительной хардверной обвязки возможен пока только в режиме 160x200, куда ZX-экран очевидно не влезет...

[Shaos]

Вот так отработал пример config.c:

Code: Select all

/* config.c - A.A.Shabarshin (April 2015) */

#include "xorlib.h"

int main()
{
 unsigned long conf = xoconfig();

 xoprintf("XORLib v%i.%i configuration:\n",
   XORLIB_VERSION>>8, XORLIB_VERSION&0xFF);

 if(conf & (1<<XOMODE_320x200_MONO)) 
   xoprintf("XOMODE_320x200_MONO\n");
 if(conf & (1<<XOMODE_160x100_GRAY5))
   xoprintf("XOMODE_160x100_GRAY5\n");
 if(conf & (1<<XOMODE_640x200_MONO))
   xoprintf("XOMODE_640x200_MONO\n");
 if(conf & (1<<XOMODE_320x100_GRAY5))
   xoprintf("XOMODE_320x100_GRAY5\n");
 if(conf & (1<<XOMODE_160x200_COL15))
   xoprintf("XOMODE_160x200_COL15\n");
 if(conf & (1<<XOMODE_160x100_COL120))
   xoprintf("XOMODE_160x100_COL120\n");
 if(conf & (1<<XOMODE_320x200_COL4))
   xoprintf("XOMODE_320x200_COL4\n");
 if(conf & (1<<XOMODE_160x200_COL16))
   xoprintf("XOMODE_160x200_COL16\n");
 if(conf & (1<<XOMODE_320x200_COL16))
   xoprintf("XOMODE_320x200_COL16\n");
 if(conf & (1<<XOMODE_160x200_COL256))
   xoprintf("XOMODE_160x200_COL256\n");
 if(conf & (1<<XOMODE_640x200_COL16))
   xoprintf("XOMODE_640x200_COL16\n");
 if(conf & (1<<XOMODE_320x200_COL256))
   xoprintf("XOMODE_320x200_COL256\n");
 if(conf & (1<<XOMODE_640x350_COL16))
   xoprintf("XOMODE_640x350_COL16\n");
 if(conf & (1<<XOMODE_640x480_COL16))
   xoprintf("XOMODE_640x480_COL16\n");
 if(conf & (1<<XOMODE_800x600_COL16))
   xoprintf("XOMODE_800x600_COL16\n");
 if(conf & (1<<XOMODE_EXTENDED_VGA))
   xoprintf("XOMODE_EXTENDED_VGA\n");

 if(conf & XOCONFIG_BIGENDIAN)
   xoprintf("BIG ENDIAN\n");
 else
   xoprintf("LITTLE ENDIAN\n");
 if(conf & XOCONFIG_32BITINT)
   xoprintf("32-BIT INT\n");
 else
   xoprintf("16-BIT INT\n");
 if(conf & XOCONFIG_NTSCTV)
   xoprintf("NTSC TV\n");
 if(conf & XOCONFIG_PALTV)
   xoprintf("PAL TV\n");
 if(!(conf & XOCONFIG_NTSCTV)&&
    !(conf & XOCONFIG_PALTV))
   xoprintf("MONITOR\n");
 if(conf & XOCONFIG_NETWORK)
   xoprintf("NETWORK\n");
 if(conf & XOCONFIG_KEYBOARD)
   xoprintf("KEYBOARD\n");
 if(conf & XOCONFIG_MOUSE)
   xoprintf("MOUSE\n");
 if(conf & XOCONFIG_SDCARD)
   xoprintf("SD-CARD\n");
 if(conf & XOCONFIG_CDROM)
   xoprintf("CD-ROM\n");
 
 return 0;
}

P.S. Кстати оказалось, что PIC32 работает в режиме "little-endian", а я так надеялся, что он big (MIPS-ы вроде умеют и так, и эдак)...

[Shaos]

Попробую ка я программно генерить "NTSC color burst" - если у японца получилось, то и у меня получится

Ой, а этот японец нашёл меня в твиттере и добавил в избранное пару моих твитов про XORLib

P.S. А потом ещё и подписался

[Shaos]

Ещё одна демка - причём в HD качестве



http://youtu.be/8ZoB1-8BEgk

P.S. Исходник вот:
https://github.com/shaos/xorlib/blob/master/examples/coloroto.c

P.P.S. Тут использована палитра 1 (цвета композитного CGA) и формирование кадра 160x200 занимает примерно целый кадр (1/60 секунды) с опцией -O1...

[Shaos]

P.S. Кстати оказалось, что PIC32 работает в режиме "little-endian", а я так надеялся, что он big (MIPS-ы вроде умеют и так, и эдак)...

Я понял в чём состоял конфуз - хоть слова и представляются в памяти PIC32 в little-endian, SPI модуль вышвыривает их в однобитный выход старшими битами вперёд - отсюда и ощущение big-endian, однако это противоречит CGA, куда я эту либу тоже хочу портировать, т.к. там старшими битами вперёд идут только отдельные байты, а байты внутри слова идут младшими байтами вперёд - получается такая переплетающаяся косичка...

[Shaos]

Начинаю осваивать программирование CGA, например вот эта программа для OpenWatcom-C переводит CGA в композитный режим и генерит цветовые полоски, аналогичные XORLib-овским (правда обращаться к памяти надо побайтно, т.к. в словах байты переставлены из-за little-endian):

Code: Select all

#include <stdio.h>
#include <conio.h>
#include <graph.h>

int main()
{
 register int i,y;
 register unsigned char* p;
 _setvideomode(6);
 outp(0x3D8,inp(0x3D8)&0xFB);

 for(y=0;y<200;y++)
 {
   if(y&1) p = ((unsigned char*)0xBA000) + (y-1)*40;
   else    p = ((unsigned char*)0xB8000) + y*40;
   if(y<2||y>=198)
   {   /* white frame */
       for(i=0;i<80;i++) p[i] = 0xFF;
       continue;
   }
   p[0] = 0xF0;
   for(i=1;i<5;i++) p[i] = 0x00;
   for(i=5;i<10;i++) p[i] = 0x11;
   for(i=10;i<15;i++) p[i] = 0x22;
   for(i=15;i<20;i++) p[i] = 0x33;
   for(i=20;i<25;i++) p[i] = 0x44;
   for(i=25;i<30;i++) p[i] = 0x55;
   for(i=30;i<35;i++) p[i] = 0x66;
   for(i=35;i<40;i++) p[i] = 0x77;
   for(i=40;i<45;i++) p[i] = 0x88;
   for(i=45;i<50;i++) p[i] = 0x99;
   for(i=50;i<55;i++) p[i] = 0xAA;
   for(i=55;i<60;i++) p[i] = 0xBB;
   for(i=60;i<65;i++) p[i] = 0xCC;
   for(i=65;i<70;i++) p[i] = 0xDD;
   for(i=70;i<75;i++) p[i] = 0xEE;
   for(i=75;i<80;i++) p[i] = 0xFF;
 }

 getch();
 _setvideomode(-1);
 return 0;
}

Скриншот из DOSBox-а:

[Shaos]

P.S. Кстати оказалось, что PIC32 работает в режиме "little-endian", а я так надеялся, что он big (MIPS-ы вроде умеют и так, и эдак)...

Я понял в чём состоял конфуз - хоть слова и представляются в памяти PIC32 в little-endian, SPI модуль вышвыривает их в однобитный выход старшими битами вперёд - отсюда и ощущение big-endian, однако это противоречит CGA, куда я эту либу тоже хочу портировать, т.к. там старшими битами вперёд идут только отдельные байты, а байты внутри слова идут младшими байтами вперёд - получается такая переплетающаяся косичка...

Чтобы сделать единообразным код приложений и для PIC32, и для CGA, мне пришлось перенастроить связку DMA-SPI, чтобы они работали не с 32-битными словами, а с 8-битными байтами - тогда байты будут в правильном порядке засовываться - попутно указатель на видеопамять стал unsigned char* вместо int* - в результате оно как-то даже ускорилось: рисование пикселов стало на 1% быстрее, а рисование символов аж на 43% (это из-за того, что теперь не надо в слове маскировать знакоместо). Правда в режиме 640 пикселов в строке DMA стал не успевать предоставить второй байт в каждой строке - фиг знает почему - в результате пришлось всё сдвинуть маленько, чтобы эта дырка была в невидимой области - как итог получилась новая версия либы XORLib v0.2, но я её пока не выкладываю, т.к. надо все примеры под новый способ работы с видеопамятью подправить. Также попутно поменял режим XOMODE_320x100_GRAY5 (когда один серый псевдопиксел представляется квадратом 2x2 чёрно-белых пиксела) на XOMODE_213x200_GRAY4 (когда один серый псевдопиксел представляется горизонтальной полоской из 3 чёрно-белых пикселов), т.к. он более логичен по соотношению сторон...