Для этого сначала хорошо бы подтвердить тестом на реале.
Вид для печати
Процедура перевода цвета из отдельных значений red, green, blue в 16-битный цвет Союз-Неона:
Можно оптимизировать эту процедуру по скорости или по размеру, но так наглядней - понятен принцип кодирования цвета.Код:; input: R1 = pointer to red,green,blue bytes (0..63)
; output: R2 = 16-bit combined colour
ConvertColour:
PUSH R1
PUSH R3
PUSH R4
CLR R2 ; combined colour
CLR R3 ; index in the bits table
MOV #6,R4 ; process 6 bits
1: RORB (R1)+ ; get a red bit
BCC 2
BIS BitsRed(R3),R2
2: RORB (R1)+ ; get a green bit
BCC 3
BIS BitsGreen(R3),R2
3: RORB (R1) ; get a blue bit
BCC 4
BIS BitsBlue(R3),R2
4: SUB #2,R1 ; set pointer back to red
TST (R3)+ ; next bit in the table
SOB R4,1
POP R4
POP R3
POP R1
RET
; strange RGB bit mapping
BitsRed: .WORD 0, 10, 20, 2000, 4000, 10000
BitsGreen: .WORD 40,100,200,20000,40000,100000
BitsBlue: .WORD 0, 1, 2, 4, 400, 1000
Использование процедуры показано ниже. Допустим, у нас 256-цветный режим (1 байт на точку), в R0 лежит номер цвета в палитре. Тогда, получив с помощью процедуры ConvertColour закодированный цвет в R2, мы должны положить его старший байт в одно место в палитре, а младший байт - в другое, на 256 байт дальше. Такое неудобное (для программиста) устройство палитр в Союз-Неоне.
Код:MOV #RGB,R1 ; pointer to RGB values
CALL ConvertColour
MOVB R2,Palette+256.(R0) ; save low byte
SWAB R2
MOVB R2,Palette(R0) ; save high byte
RGB: .BYTE 37.,29.,11.
Можно предположить, что изначально палитра выбирались из 256 цветов, затем размер памяти в последний момент под неë удвоили. Возможно уже были тогда программы использующие палитру из 256 цветов, и чтобы не переделывать их в палитре 64к второй байт сделали уточняющим (если там мусор окажется или нули - ничего страшного не будет).
Ну и так проще плату разводить, т.к. в область память палитры не нужно протаскивать дополнительные сигналы с шины данных.
Для написания небольших программ под БК на линукс я пользуюсь macro11 в версии от Rhialto и скриптом на perl для линковки, который там же в директории obj2bin. Для линковки в БКшный *.bin есть тот же самый скрипт с моими правками.
Пример команды сборки licheng.asm в БКшный licheng.bin (bash):
n=licheng && macro11 -rt11 -o $n.obj -l $n.lst $n.asm && obj2bkb --binary --base=01000 --outfile=$n.bin $n.obj
PS: Это был ответ на сообщение troosh чем можно линковать obj файлы от macro11. Цитирование почему-то пропало по дороге. Вебфорумы - зло.
Кто-нибудь может скомпилировать SPEED.SAV под Союз-Неон? Хочется измерить его производительность.
На неоновских дисках исходников не видел. Но сам бинарник и видео его запуска под симулятором выложил здесь: https://github.com/troosh/pk11-16/tr...oft/Benchmark/
Пардон, я думал речь идёт про другой speed.sav
- - - Добавлено - - -
Прогнал SPEED на 11/53 и прогоняю на 11/83
Доверие результатам есть - на 11/83 для MOV R0,R0 показал чуть менее пяти. Но так же становится понятным, что тестовый блок небольшой и умещается в
кэш.
Из занимательного
Код:MOV R0,R0 0.20 mks, 4995.2 op/ms 1 mem, 0.20 mks/mem
MOVB R0,R0 0.20 mks, 4995.2 op/ms 1 mem, 0.20 mks/mem
DEC R0 0.20 mks, 4995.1 op/ms 1 mem, 0.20 mks/mem
ADD R0,R0 0.20 mks, 4995.2 op/ms 1 mem, 0.20 mks/mem
SUB R0,R0 0.20 mks, 4994.9 op/ms 1 mem, 0.20 mks/mem
CLR R0 0.20 mks, 4995.0 op/ms 1 mem, 0.20 mks/mem
TST R0 0.20 mks, 4995.2 op/ms 1 mem, 0.20 mks/mem
COM R0 0.20 mks, 4995.1 op/ms 1 mem, 0.20 mks/mem
NEG R0 0.20 mks, 4995.1 op/ms 1 mem, 0.20 mks/mem
BIS R0,R0 0.20 mks, 4995.1 op/ms 1 mem, 0.20 mks/mem
BIT R0,R0 0.20 mks, 4995.2 op/ms 1 mem, 0.20 mks/mem
XOR R0,R0 0.20 mks, 4995.1 op/ms 1 mem, 0.20 mks/mem
ROL R0 0.20 mks, 4995.1 op/ms 1 mem, 0.20 mks/mem
ROR R0 0.20 mks, 4995.1 op/ms 1 mem, 0.20 mks/mem
ASL R0 0.20 mks, 4995.1 op/ms 1 mem, 0.20 mks/mem
ASR R0 0.20 mks, 4994.9 op/ms 1 mem, 0.20 mks/mem