Next colours

Discuss game and other programming topics not specifically covered in another forum

Moderator: Programming Moderators

|48K|
Posts: 8
Joined: Mon Jul 20, 2020 9:33 am

Next colours

Postby |48K| » Fri Sep 25, 2020 2:45 pm

Hi everyone, I have a Next v2 on order, but hope to get a development environment up and running in advance.

After reading the manual about colours and palettes it struck me that a rather defining feature/look of the ZX spectrum was its limited palette of 15 colours. These colours were vibrant, had similar tone, and kept graphics decisions clean and coherent across a game. Access to an extended palette comes with some risks that the software loses this unique look. Has this been discussed before?

I am interested by some of the choices of the palettes/colours used in the Next:

1. 9-bits enable 512 unique colours, but require encoding in a 16-bit palette look-up table. Since a 16-bit look up table is being used, was there a reason not to implement 12-bit (4096) or even 15-bit (32,768) colour? Can this be added in a FPGA update?

2. Despite reading (and re-reading) the manual, it's not clear to me how the default 8-bit R3G3B2 system is implemented. My specific question is: how are the Blue bits interpreted in 9-bit space? Is it essentially like the 3-bit intensities 0,2,4 and 6? (Or is it like 1,3,5,7 - which would be odd...) Or is it 0,3,5,7? (Enabling both pure black and pure white.)

3. I perceive some benefits of having a limited colour space to play with. As such, I am considering using a limited 6-bit (64-colour) palette (effectively R2G2B2). But what I am wondering is what would be the suitable intensities to use for each colour. Would 0,3,5,7 make the most sense?

4. Is it known what the original Spectrum colours would be (for bright and non bright) when expressed in in 9-bit (and/or 8-bit) colour space? I am quite tempted to just use these in order to maintain a strong Spectrum feel to my projects (but with the benefit of no colour clash).

Thanks!

Ped7g
Posts: 256
Joined: Mon Jul 16, 2018 7:11 pm

Re: Next colours

Postby Ped7g » Fri Sep 25, 2020 6:41 pm

1) I think the video signal DAC is only 3bit, so even if you reserve more bits per channel, it will not produce more shades of channel, but I'm not sure if that's hard HW limit of board/FPGA, or it's just written like that in FPGA and can be modified. I think it's hard limit, but I know very little about it.

2) B values are interpreted as 0, 3, 5, 7 (the lowest bit is zero when "B2" is zero, and one when at least one of the two upper bits is one) That's actually written into the 9 bit table, so if you write into 8bit color register %101'010'01, then if you read full 9bit color back, it will be %101'010'011

3) 0,3,5,7 makes most sense as you can then use those 8bit set nextregs to get the same values for blue

4) the bright colors have particular channel as %111 (7 in decimal). The non-bright colors have channel as %101 (5 in decimal). The bright "magenta" is patched to slightly different (%111'001'11) to not clash with the default transparency 0xE3.

|48K|
Posts: 8
Joined: Mon Jul 20, 2020 9:33 am

Re: Next colours

Postby |48K| » Fri Sep 25, 2020 8:45 pm

Ped7g wrote:
Fri Sep 25, 2020 6:41 pm
1) I think the video signal DAC is only 3bit, so even if you reserve more bits per channel, it will not produce more shades of channel, but I'm not sure if that's hard HW limit of board/FPGA, or it's just written like that in FPGA and can be modified. I think it's hard limit, but I know very little about it.

2) B values are interpreted as 0, 3, 5, 7 (the lowest bit is zero when "B2" is zero, and one when at least one of the two upper bits is one) That's actually written into the 9 bit table, so if you write into 8bit color register %101'010'01, then if you read full 9bit color back, it will be %101'010'011

3) 0,3,5,7 makes most sense as you can then use those 8bit set nextregs to get the same values for blue

4) the bright colors have particular channel as %111 (7 in decimal). The non-bright colors have channel as %101 (5 in decimal). The bright "magenta" is patched to slightly different (%111'001'11) to not clash with the default transparency 0xE3.
Thanks Ped7g.

1) If it is the hardware DAC limit than I guess this explains it. I can't see any other benefit of an expanded (yet still limited) colour space.

2) Thanks! OK, I think that make sense to me now. So the smallest blue bit is actually held in the second byte of the palette? (And made 1 when the B2 bits are non zero. Makes sense. So the 256 palette basically misses out all the shades when Blue is 2, 4 and 6.

3) Thinking about this again, I may actually just make palettes in the 7 primary spectrum colours but in 7 shades/intensities (of Blue, Red, Green, Magenta, Cyan, Yellow, White) plus black (50 colours in total) rather than bother with all the in-between mixtures. I'm looking forward to experiment. The beauty of the Speccy was, in many ways, how constrained some aspects were. Forced you to be creative!

4) Thanks for this. So adding 3, will simply give a darker shade of them. Perhaps just 21 colours (plus black) is actually perfect...
So bright magenta has a bit of extra green in it?

Out of interest: where is all the information available? The manual is extensive...but from a ZX spectrum owner feels quite jumbled and lots of information I'd like to know either isn't in there, or seem hard to find.

Ped7g
Posts: 256
Joined: Mon Jul 16, 2018 7:11 pm

Re: Next colours

Postby Ped7g » Sat Sep 26, 2020 8:30 am

2) yes. The second color byte is 0/1 depending on the smallest blue bit. But in Layer2 palette it can also have extra 0x80 (top bit set) to signal the color "priority", which raises the Layer2 pixel above everything else. This can be used for example for platformer with grass/bushes drawn in Layer2 and player sprite being in front of the platform graphics, except some bushes/signs may be drawn with priority bit and cover the player sprite as if "being in front of player". Etc...

In future versions of core (3.1.8) there are now two top bits of second byte reserved+stored in the palette (you write two bytes, but the HW throws away the unused bits, not storing them, in core 3.1.5 only 9 bits of color + 1 bit of L2 priority is stored), for every type of palette, so there are now 11 bits per color stored in the FPGA, but they have no function yet (except that top bit for Layer2, which already is "priority" bit). The plan is to extend this priority feature to other layers, but it's not implemented yet, and not clear how it will work.

4) yeah, bright magenta has G=1 ... But you can reconfigure it any way you wish, if you feel like %111'000'111 is more "true" ZX bright magenta, then set the palette to it, and modify nextreg $14 (decimal 20, global transparency color) to something else, to not clash with your new magenta.

All the information is "out there"? I kept reading the base docs (nextreg.txt, ports.txt are now available publicly on gitlab with core sources, in the early times I kept asking core team for info so much, that they gave me usually extra copy sooner), and the initial articles about sprites/tilemodes/etc... and changelogs with new distro versions, and I kept also experimenting with emulators and asking questions when something was not clear, or when I though I have found something weird. Then I refreshed most of the https://wiki.specnext.dev/Board_feature_control stuff, which helped to further cement my understanding of nextreg.txt and how the machine works and the wiki should be fairly up-to-date with core 3.1.5 (that's the one in official zip, in gitlab there's already 3.1.8 available for early adopters, to experiment+test it). The "topic articles" on wiki were mostly just copy of articles posted at https://www.specnext.com/category/resou ... es_coding/ and not always updated to reflect all new features of recent cores (but they are often more up to date than the specnext.com articles, as any user can refresh them on the wiki).

|48K|
Posts: 8
Joined: Mon Jul 20, 2020 9:33 am

Re: Next colours

Postby |48K| » Tue Sep 29, 2020 10:39 pm

Thanks for the pointers. I'll keep reading and looking around. Currently I need to get an emulator up and running...


Who is online

Users browsing this forum: No registered users and 3 guests