Bricadeira bem básica e de quebra umas dicas de como usar os modos não-RGB do V9958 nos MSX2+ e MSX turbo R. Para começar, uma imagem de exemplo já previamente dimensionada em 512×424:

Claro que ela precisa ser convertida para algo que um MSX entenda, então basta dar uma passada no MSX Screen Conversor e pronto — aliás, excelente programa escrito pelo Rafael Jannone. Agora temos uma tela que pode ser carregada na SCREEN 12 (256×212 YJK com suas 19.268 cores) com BLOAD “COLORES.S12“,S:

Que tal agora converter a imagem para a SCREEN 10? De acordo com a documentação ela usa um tal de modo YUV que tem 12.499 cores. Mas apesar de menos cores ela permite usar junto as 16 cores em RGB (então seriam 12.515? Hehehe). Mas como faz?

Os dados que compõe a imagem nos dois modos de vídeo estão codificados de forma bem parecida, ambos usam conjuntos de 4 bytes para guardar as informações das cores.

Na SCREEN 12 cada bit está assim:

byte   n -> Y Y Y Y Y J J J
byte n+1 -> Y Y Y Y Y J J J
byte n+2 -> Y Y Y Y Y K K K
byte n+3 -> Y Y Y Y Y K K K

Cada um dos 4 bytes tem sua informação de intensidade luminosa (YYYYY, 5-bit) e as informações de cores (JJJJJJ e KKKKKK, 6-bit cada um) compartilhados entre este conjunto de vizinhos (sim, bem parecido com o que o JPEG funciona).

E na SCREEN 10 assim:

byte   n -> Y Y Y Y C J J J
byte n+1 -> Y Y Y Y C J J J
byte n+2 -> Y Y Y Y C K K K
byte n+3 -> Y Y Y Y C K K K

A única diferença é que o espaço para luminância diminui em 1 bit (o que reduz os tons de luminosidade de 32 para 16) e este bit, o bit-3 (ou 4º bit) ao qual chamei de C, passa a ser utilizado para indicar qual o tipo de codificação de cores utilizar.

Com C em 0 as coisas funcionam como no modo YJK mas com ele em 1 a informação de crominância é descartada e Y tratado como uma cor RGB de 0 a 16 (com a paleta de 512 padrão do MSX).

E é por este motivo que tentativa de carregar a tela na SCREEN 10 resulta nisto aqui:

Que porcaria, não? A solução é simples, basta apagar cada 4º bit para corrigir a codificação, certo? Justamente! A primeira coisa que vem pela cabeça é fazer algo assim:

FOR I=0 TO 54271:VPOKE I,VPEEK(I)AND&HF7:NEXT I

E esperar pela varredura completa da tela. Mas há um jeito mais fácil, muito mais rápido e quase indolor:

LINE (0,0)-STEP(255,211),&HF7,BF,AND

Desta forma o trabalho é realizado automaticamente pelo VDP através dos recursos de cópia lógia do Bit Blit que ele tem embutido.

Use AND 0xf0 para produzir uma imagem em tons de cinza na SCREEN 10 e 0xf8 na SCREEN 12. E nestas operações lógicas ainda é possível usar OR e XOR também.

Mas tem um detalhe, este comando resulta em um erro ao ser usado SCREEN 10!

E agora eu conto que a SCREEN 10 e a SCREEN 11 são o mesmo modo de vídeo no V9958, aquilo que as torna diferentes está apenas na cabeça do MSX-BASIC que não deixa os comandos COLOR, CIRCLE, DRAW, LINE, PAINT, PSET etc usarem cores acima de 15 na SCREEN 10, disseram a ele que aqui só há 16 cores e é tudo que ele precisa saber. Solução?

Mudar o “SCREEN 10” (ou SCREEN 8 ou SCREEN 12 que não tem esta limitação) para aplicar a conversão, salvar o arquivo e aí obter o COLORES.S10:

E só para ter certeza de que realmente as 16 cores do MSX podem ser usadas um programa de testes:

100 DEFINT A-Z:SCREEN 10
105 BLOAD "COLORES.S10",S
110 FOR I=0 TO 15:FOR C=0 TO 3:J=8*C
115 FOR Y=J TO J+7:FOR X=8*I TO 8*I+7
120 XX=X*2:YY=148+Y*2
121 ON C+1 GOSUB 135,140,145,150
125 NEXT X,Y,C,I
130 GOTO 130
135 PSET (XX+1,YY+1),I:RETURN
140 LINE (XX,YY)-STEP(1,1),I:RETURN
145 LINE (XX,YY)-STEP(1,0),I:LINE (XX,YY)-STEP(0,1),I:RETURN
150 LINE (XX,YY)-STEP(1,1),I,BF:RETURN

Não é código mais bonito do mundo mas gera isto daqui:

O reticulado é para provar de que não está havendo tipo algum de borramento. Mas rode o programa na SCREEN 11 ou SCREEN 12 e vejam um pesadelo colorido.

Em tempo…

Usando a mesma lógica, na SCREEN12, basta fazer:

LINE (0,0)-STEP(255,211),&HF8,BF,AND

Para obter uma versão somente com tons de cinza (luminância) da imagem: