TS Forum

Great job. But I noticed that pallete is somewhat weird. What formula do you use?

Yes, maybe the palette is not the same. I use the following :

z80_byte tsconf_5_to_8[32];

for (i=0;i<32;i++) {
tsconf_5_to_8[i]=i*8;
}


//Colores tsconf
for (i=0;i<32768;i++) {

b= i & 0x1F;
g=(i >> 5 ) & 0x1F;
r=(i >> 10 ) & 0x1F;


r=tsconf_5_to_8[r];
g=tsconf_5_to_8[g];
b=tsconf_5_to_8[b];


color32=(r<<16)|(g<<8)|b;



screen_set_colour_normal(TSCONF_INDEX_FIRST_COLOR+i, color32);

}

What means... I scale a 5 bit colour value to a 8 bit (my final palete is RGB24)

Pallette is a bit tricky.

Code: Select all

u8 r, g, b;
u16 pal;
If (pal & (1 << 15))
{
r = ((pal >> 10) & 5) << 3;
g = ((pal >> 5) & 5) << 3;
b = (pal & 5) << 3;
}
else
...


Code: Select all

  always_comb
    case (pal)  // this is for each r,g,b - bits 14..10, 9..5, 4..0
      5'd0:    lut = 8'd0;
      5'd1:    lut = 8'd10;
      5'd2:    lut = 8'd21;
      5'd3:    lut = 8'd31;
      5'd4:    lut = 8'd42;
      5'd5:    lut = 8'd53;
      5'd6:    lut = 8'd63;
      5'd7:    lut = 8'd74;
      5'd8:    lut = 8'd85;
      5'd9:    lut = 8'd95;
      5'd10:   lut = 8'd106;
      5'd11:   lut = 8'd117;
      5'd12:   lut = 8'd127;
      5'd13:   lut = 8'd138;
      5'd14:   lut = 8'd149;
      5'd15:   lut = 8'd159;
      5'd16:   lut = 8'd170;
      5'd17:   lut = 8'd181;
      5'd18:   lut = 8'd191;
      5'd19:   lut = 8'd202;
      5'd20:   lut = 8'd213;
      5'd21:   lut = 8'd223;
      5'd22:   lut = 8'd234;
      5'd23:   lut = 8'd245;
      5'd24:   lut = 8'd255;
      default: lut = 8'd255;
    endcase


chernandezba,
Eres de Espana? Si es asi, de cual ciudad? Voy a viajar en Espana proxima semana =)

Thanks for the palette, I will change it (when I understand it )

Yes, I'm from Spain, Madrid / Si, vivo en España, Madrid

About palette, I don't understand the first part (u8 r, g, b;
u16 pal;....
)

About the second, does it mean that 5 bit values from 24 to 31 are all these translated to 255? Does it mean that all these colours will be the same?

chernandezba wrote:the first part (u8 r, g, b;
u16 pal

r, g, b meant to be output 8-bit values,
pal is value from CRAM.

chernandezba wrote:does it mean that 5 bit values from 24 to 31 are all these translated to 255

yep

chernandezba wrote:Si, vivo en España, Madrid

Voy a Barcelona, bastante lejos desde Madrid =(

Hi

But why having these 5 bit values (24 to 31) all the same to 255? You "lose" a lot of colours doing this

Yes, Madrid is a bit far from Barcelona (600 kms)

Before normal 5bit video DAC there was a PWM mode. So it's maintained for compatibility.

I see... so I understand no one is using these values from 24 to 31 to get different colors? Should I change my palette to match the real tsconf?

Thanks

Real tsconf supports both modes:
0 - 0..24, and 25..31 are the same as 24,
1 - 0..31 - regular DAC.
Some people have no VDAC yet.
What about software, well, some just use mode 1 and don't bother with PWM, some do.
I suggest supporting both modes.

I see. So I will be supporting the two palettes :

1) "without VDAC", 0..24, and 25..31 are the same as 24. So I will use the conversion table you shown before: 0->0, 1->10, 2->21, .... , 23->245 , 24->255, 26,27,28,29,30,31->255
2) "with VDAC", extending from 0..31. Do you have these conversion values? Or should I use my palette?

Thanks!

By the way, I suppose "vdver" bits from register 00AFH returns the type of vdac, but I see there:

000 2-bit VDAC + PWM levels 0-24
001 3-bit VDAC
010 4-bit VDAC
011 5-bit VDAC
100-110 reserved
111 VDAC2 (FT812)

Which of these combinations match my options "with vdac" and "without vdac"?

Ok... I read the tsconf.xls file, tab "cram" and I saw the bit 15 (C Video output control). And I don't understand how is this bit used. I mean... my palette has 32768 elements (15 bits)... but this will add another bit, so 65536 elements, but I don't see exactly the sense of it. I see it's related with having vdac or not, but I suppose this bit is a kind of control bit and not part of the palette? how?

chernandezba wrote:2) "with VDAC", extending from 0..31. Do you have these conversion values?

Code: Select all

r = ((pal >> 10) & 5) << 3;
g = ((pal >> 5) & 5) << 3;
b = (pal & 5) << 3;

chernandezba wrote:Which of these combinations match my options "with vdac" and "without vdac"?

"without vdac" - 0 (000)
"with vdac" - 3 (011) or 7 (111)

chernandezba wrote:the bit 15 (C Video output control). And I don't understand how is this bit used

Selects one of two above conversion tables (0 - no VDAC, 1 - with VDAC)

TS-Labs wrote:

Code: Select all

r = ((pal >> 10) & 5) << 3;
g = ((pal >> 5) & 5) << 3;
b = (pal & 5) << 3;

So same conversion as mine (I was multiplying by 8, and you are rotating left 3 times, which is the same )

chernandezba wrote:Which of these combinations match my options "with vdac" and "without vdac"?

"without vdac" - 0 (000)
"with vdac" - 3 (011) or 7 (111)

Ok

chernandezba wrote:the bit 15 (C Video output control). And I don't understand how is this bit used

Selects one of two above conversion tables (0 - no VDAC, 1 - with VDAC)

So... Every colour on the palette can decide if using vdac or not?
If someone sets, for example, palette index 3 to value 1 11111 11111 11111 will be using vdac, and if setting to 0 11111 11111 11111 it won't use vdac?

I don't know if I can fully emulate that way... I will need two palette entries of 32768 values, instead of one... one with conversion from full 5-8 bit colour component, and the other with 5-8 conversion (having 24...31 to 255). The problem is my indexes to the full palette of the emulator is a 16 bit value, so I'm limited to 65536 colours. Keep in mind I'm emulating 16 colours for speccy, 27 for cpc, 256 for ulaplus, 32768 for tsconf, etc. So I can't have two palettes for tsconf, this will need more than 65536 colours ...
I'm now emulating vdac/not vdac with a setting on the menu, so you can switch from one to the other. Every time you switch it, the full 32768 colour palette is recalculated

chernandezba wrote:So same conversion as mine

yep =)

chernandezba wrote:So... Every colour on the palette can decide if using vdac or not?

SUDDENLY - yes. Never thought about it in this way =)

chernandezba wrote:The problem is my indexes to the full palette of the emulator is a 16 bit value

I only use 8 bit index (256 cells) each of 32 bit.

Code: Select all

u32 pal[256];

Resulting the value for the frame video buffer (32 bit AGRB bitmap actually) is taken directly from the array of palette which is emulating CRAM.
You can use the same array to emulate any model of ZX, just overload palette array once you switch a model, like I do in Unreal Speccy. For 4-bit modes (ZX and others) use only 16 cells from palette.

My palette handling is different. I have a display buffer of 16-bit indexed colours. And these 16-bit values point to a rgb24 colour table (where all the colours used in the emulator are stored), which is the one that uses the video driver.
My 16-bit display buffer is used in a lot of places, I should change it (changing to a 32-bit display buffer for example) everywhere and having the risk of missing other "secondary" effects that I can't think now - in the past, I got often "segmentation fault" when some pointer gets lost in this buffer...
So anyway, I can do it, but it's a bit difficult. Maybe in next versions of the emulator (I'm planning to publish a stable version soon). And if someone uses that setting bit to do nice effects on demos (as you said: "Never thought about it in this way"), maybe I will emulate it soon

By the way, is there any other website, apart from http://prods.tslabs.info/, to get tsconf software to test my emulator?

Thanks

chernandezba wrote:I have a display buffer of 16-bit indexed colours.

I really see no reason for this.

chernandezba wrote:is there any other website, apart from http://prods.tslabs.info/

Nope. I tried to collect all available software there.

TS-Labs wrote:

chernandezba wrote:I have a display buffer of 16-bit indexed colours.

I really see no reason for this.
.

It's a bit hard to explain and I don't want to bother you with boring details. At a glance: it's a framebuffer of 720x576 of 16-bit values. These 16-bit values point to my rgb24 table. Changing it to, for example a 32 bit table, it's a long task

But why do you need a palette of 65536 entries? None of systems known to me use this many. Most use 256 entries, NDS (AFAIK) uses 1024.

Just seeing the TSConf palette, it’s a 15 bit palette so it has 32768 entries
Tbblue for example has a 9 bit palette so it has 512 entries

chernandezba, sorry, but - 256 colors * 15 bit = 512 bytes...
and again - sorry, but very strange decigion with "entries" for any known colors in system.

VBI wrote:chernandezba, sorry, but - 256 colors * 15 bit = 512 bytes...
and again - sorry, but very strange decigion with "entries" for any known colors in system.

Strange? Why? I need to have a full palette loaded in the emulator in order to draw it faster. Keep in mind I have different video drivers and they need an index to a full 24 bit colour table in order to draw the screen fast
Anyway, we are missing the point. We are not discussing how I’m programming my emulator. I was only asking how the 16th bit of every palette entry was used, and seems it’s is not used by anyone. So my implementation (having a configurable switch to enable vdac or not) it’s completely right , now
Cheers

ok, thanks!
as i know, in standart config we use only high 2 bits of color, anв low 3 as hardware color modulation
in system with vdac we use all 5 bit for color in "ts color space"