Palettemate / enhanced video ULA with 4096 colours

[BBCB+64K]

This is very impressive!!! I wonder if BASIC V would allow the full access to the colour palette, since BASIC V's COLOUR accept 3(4?) comma seperated values. I have a 64MB ARM7TDMI Co-Pro that uses BASIC V.

Steve

[jgharston]

BASIC neither knows nor cares what the VDU driver is capable of, it merely sends a VDU 19,l,p,r,g,b sequence and the VDU driver does whatever it wishes with it.

[tricky]

What is fixed at 640 bits?

Yes - good point. With overscan, it's possible to have a display that's close to 800 pixels wide in mode 0.

And in mode 7, with "some nasty effects", or just palette swapping, I think that is 800 * 4 bits!
Did I mention that I think this is excellent

[PitfallJones]

Hi,

This topic is facinating - I've always considered the BBC's lack of palette a great shortcoming - even the Amstrad CPC with just 3 levels per channel had a great 27 colour palette.

I'd adjusted b-em awhile ago to run games with custom palettes (I hardwired it in the code for the emulator) - here's an example of it running mousetrap with a C64 palette - a little easier on the eyes!

I think if this board becomes reality it would be very easy to patch games to have a custom palette and of course the ability to have 16 unique colors at once would be a tremendous improvement - again look to Amstrad games to see what's possible!

- PJ

[jgharston]

I wrote most of a VDU extension to implement VDU 19,l,x,red,green,blue to program the palette. I'll probably find the code when looking for something else.

Had a bit of a rummage, and this it it, modifiled with a bit of code that I think sets colours with palettemate:

Code: Select all

   10 REM VDU19/src
   20 REM Extended VDU 19 driver
   30 :
   40 load%=&FFFF0A00:DIM mcode% &200
   50 wrchv=&20E:vduQ=&26A
   60 :
   70 FOR P=0 TO 1
   80   P%=load%:O%=mcode%
   90   [OPT P*3+4
  100   .go%
  110   LDA wrchv+0:STA oldwrch+1
  120   LDA wrchv+1:STA oldwrch+2
  130   LDA #newvdu AND 255:STA wrchv+0
  140   LDA #newvdu DIV 256:STA wrchv+1
  150   LDA #0:STA flag:RTS
  160   :
  170   .newvdu
  180   BIT vduQ:BMI check:STA flag
  190   .oldwrch
  200   JMP &FFFF
  210   .oldvdu
  220   PLA:JMP oldwrch
  230   .check
  240   PHA
  250   LDA vduQ:CMP #255:BNE oldvdu
  260   LDA flag:CMP #19:BNE oldvdu
  270   PLA:PHA:STA &323:\ last entry of VDU queue
  280   \ VDU queue
  300   \ &31F l
  310   \ &320 p
  320   \ &321 r
  330   \ &322 g
  340   \ &323 b
  350   LDA &31F:CMP #255:BEQ border1 :\ VDU 19,-1,p,r,g,b
  360   LDA &320:CMP #24:BEQ border2  :\ VDU 19,l,24,r,g,b
  370   JSR RGBtest:BEQ oldvdu        :\ VDU 19,l,p,0,0,0
  380   :
  390   \ VDU 19,l,ignored,red,green,blue
  400   \ VDUPlus
  410   LDA &321:LSR A:LSR A:LSR A:LSR A:STA &FE23 :\ red
  420   LDA &322:LSR A:LSR A:LSR A:LSR A:STA flag  :\ green
  430   LDA &323:AND #&F0:ORA flag:STA &FE23       :\ blue+green
  440   .done
  450   INC vduQ:PLA:RTS :\ Clear vduQ and return
  460   
  470   \ Chameleon
  480   LDA &321:LSR A:LSR A:LSR A:LSR A:STA &FE60 :\ red
  490   LDA &321:LSR A:LSR A:LSR A:LSR A:ORA #&40:STA &FE60 :\ green
  500   LDA &321:LSR A:LSR A:LSR A:LSR A:ORA #&80:STA &FE60 :\ blue
  510   
  520   :
  530   \ VDU 19,-1,p,red,green,blue
  540   .border1
  550   JSR RGBtest:BNE border2      :\ VDU 19,-1,ignored,red,green,blue
  560   LDA &320:AND #&0F:STA &FE22  :\ VDU 19,-1,physical,ign,ign,ign
  570   JMP done
  580   .border2
  590   JSR RGBtoP:STA &FE22:JMP done:\ VDU 19,ign,24,red,green,blue
  600   :
  610   .RGBtoP
  620   LDA &323:ASL A:LDA #0:ROL A:PHA
  630   LDA &322:ASL A:PLA:ROL A:PHA
  640   LDA &321:ASL A:PLA:ROL A:RTS
  650   .RGBtest
  660   LDA &321:ORA &322:ORA &323:RTS
  670   .flag:BRK
  680   ]NEXT
  690 IF P%>&B00:PRINT"WARN: Code overrun":END
  700 PRINT "*SAVE VDU19 ";~mcode%;" ";~O%;" ";~go%OR&FFFF0000;" ";~load%

After doing *VDU19 this gives you:
VDU 19,l,p,0,0,0 - set physical colour as per standard VDU driver (eg COLOUR l,p in supporting BASICs)
VDU 19,l,x,red,green,blue - set 24-bit colour (eg COLOUR l,red,green,blue)
VDU 19,-1,p,0,0,0 - set border to physical colour (eg COLOUR -1,p)
VDU 19,-1,x,red,green,blue - set border to 3-bit physical colour from b7 of rgb value (eg COLOUR -1,red,green,blue)
VDU 19,x,24,red,green,blue - set border to 3-bit physical colour from b7 of rgb value (eg COLOUR l,red,green,blue)
as per VDU 19 documentation.

[tricky]

Not sure about mousetrap, but having choice is definitely great. I would suspect that the way you have set it up, nearly every game would be compatible.
Roughly what do you think this will cost?

[RobC]

Not sure about mousetrap, but having choice is definitely great. I would suspect that the way you have set it up, nearly every game would be compatible.
Roughly what do you think this will cost?

Yes - the idea is that by modifying the physical colours, any original software isn't aware that this is going on. You just define the palette and away you go. I'll try to post some pictures of games using modified palettes over the weekend.

As for cost, I'm not sure yet. I've never looked at getting PCBs made but the component count is fairly low (as most of the work is done in the CPLD) so it should be a lot cheaper than building the Chameleon or getting hold of a suitable RAMDAC.

[RobC]

Had a bit of a rummage, and this it it, modifiled with a bit of code that I think sets colours with palettemate:

Code: Select all

snipped...

Many thanks - I'll have a play with this tomorrow.

The new oscillators have arrived so my next task is to fix mode 7. I'm also working through Mike Stirling's code as it's much better than mine!

[jgharston]

Had a bit of a rummage, and this it it, modifiled with a bit of code that I think sets colours with palettemate:

Code: Select all

snipped...

Many thanks - I'll have a play with this tomorrow.

I noticed I missed off the logical colour number. It probably should be:
390 \ VDU 19,l,ignored,red,green,blue
400 \ VDUPlus
405 LDA &320:ASL A:ASL A:ASL A:ASL A:\ logical colour
410 LDA &321:LSR A:LSR A:LSR A:LSR A:ORA flag:STA &FE23 :\ colour+red
420 LDA &322:LSR A:LSR A:LSR A:LSR A:STA flag :\ green
430 LDA &323:AND #&F0:ORA flag:STA &FE23 :\ blue+green
440 .done

Also, if you implement 12-bit border colour will it know the differce between selecting an 3-bit physical colour and the start of a 12-bit colour? Eg ?&FE22=%00000bgr for 3-bit colour, ?&FE22=%xxxxrrrr:?&FE22=%bbbbgggg for RGB colour with xxxx not zero.

And a thought occurs on how to ensure that the double writes to &FE22/23 don't get out of sequence and so when a program makes a first write the ula is expecting the first byte. My thought is that a writre to &FE20/1 (the normal ULA registers) should reset the state to 'expecting first of double write'

Dos that make sense? I've only had one cup of tea today.

[RobC]

Also, if you implement 12-bit border colour will it know the differce between selecting an 3-bit physical colour and the start of a 12-bit colour? Eg ?&FE22=%00000bgr for 3-bit colour, ?&FE22=%xxxxrrrr:?&FE22=%bbbbgggg for RGB colour with xxxx not zero.

Yes - I can test for xxxx being non-zero and proceed accordingly.

And a thought occurs on how to ensure that the double writes to &FE22/23 don't get out of sequence and so when a program makes a first write the ula is expecting the first byte. My thought is that a writre to &FE20/1 (the normal ULA registers) should reset the state to 'expecting first of double write'

Dos that make sense? I've only had one cup of tea today.

Makes perfect sense. The CPLD has a simple state machine so that it knows which type of write is to be expected next. The state machine currently gets reset at power-up. Not sure about resetting on writes to FE20/1 as that could clash with the MOS flipping flashing colours etc.

Another option would be to use FE22 for the first write and FE23 for the second. The border could be set via colour 0 as I think that some monitors have issues if you redefine it to be anything other than true black.

[jgharston]

Make perfect sense. The CPLD has a simple state machine so that it knows which type of write is to be expected next. The state machine currently gets reset at power-up. Not sure about resetting on writes to FE20/1 as that could clash with the MOS flipping flashing colours etc.

That happens on interupts with a write to &FE20, so could just document that the program writer needs to do SEI/CLI around code that writes to FE22/23.

Another option would be to use FE22 for the first write and FE23 for the second. The border could be set via colour 0 as I think that some monitors have issues if you redefine it to be anything other than true black.

But then how do you tell the difference between setting the 12-bit palette for logical colour 0 and setting the 12-bit palette for the border by using logical colour 0 to select the border? I think FE22=border palette, FE23=pixel palette makes more sense.

[tricky]

And leaves you 15 other values for the top 4 bits of &FE22 (assuming 0000xxxx starts border colour setting) for things like horizontal scrolling

[RobC]

That happens on interupts with a write to &FE20, so could just document that the program writer needs to do SEI/CLI around code that writes to FE22/23.

Thinking about it, I'd like to be clearer about how the issue might occur before I think about modifying the existing behaviour. How do you think this problem might arise?

But then how do you tell the difference between setting the 12-bit palette for logical colour 0 and setting the 12-bit palette for the border by using logical colour 0 to select the border? I think FE22=border palette, FE23=pixel palette makes more sense.

The 12-bit palette is for physical colours rather than logical colours and I'm led to believe that changing physical colour 0 can cause problems on some monitors. So, by specifying that writing 0000xxxx modifies the border rather than physical colour 0, we could save a register address.

However, it was only a suggestion - I'm happy to stick with FE22=border palette, FE23=pixel palette.

[jgharston]

But then how do you tell the difference between setting the 12-bit palette for logical colour 0 and setting the 12-bit palette for the border by using logical colour 0 to select the border? I think FE22=border palette, FE23=pixel palette makes more sense.

The 12-bit palette is for physical colours rather than logical colours and I'm led to believe that changing physical colour 0 can cause problems on some monitors.

I've never had any problem on any monitor doing VDU 19,0,any_nonzero_value,0,0,0 to change the background colour to non-black. Tho' I think we've got crossed wires mixing up the terms "physical colour" and "logical colour".

Logical colours are what you select with COLOUR n and GCOL 0,n, and are the bitmap in memory, and the first parameter in the VDU 19 sequence. COLOUR 4 selects a certain bitmap to write into memory regardless of what that bitmap ends up being displayed as on the screen.

Physical colours are what are actually displayed on the screen by translating the logical colour via the palette to the physical colour to display on the screen. The normal BBC has 3-bit physical colours, 0-7, black, red..etc..cyan,white (ignore flash for the moment). The Archimedes, Chameleon, Prisma and Palettemate have 12-bit physical colours, &000 to &FFF.

I wouldn't be surprised if I've commented my sample VDU19 extension code incorrectly, I spotted I'd not actually specified the logical colour when writing to &FE23.

Edit: and I kept refering to 24-bit colour when I should have written 12-bit colour.

[jgharston]

Updated commenting and code layout. In doing this I realised what I haven't worked out from your description is if the Palettemate has the same palette entry layout as the video ula, in that in a four-colour mode you have to program palette entry n, n+4, n+8 and n+12 for logical colour n, and in 2-colour modes n, n+2, n+4, n+6, n+8, n+10, n+12, n+14 to match all the memory bitmap representations for logical colour n. Or does the Palettemate deal with this itself. I'll have to go back and re-read the thread.

Code: Select all

   10 REM VDU19/src
   20 REM Extended VDU 19 driver
   30 :
   40 load%=&FFFF0A00:DIM mcode% &200
   50 wrchv=&20E:vduQ=&26A
   60 :
   70 FOR P=0 TO 1
   80   P%=load%:O%=mcode%
   90   [OPT P*3+4
  100   .go%
  110   LDA wrchv+0:STA oldwrch+1
  120   LDA wrchv+1:STA oldwrch+2
  130   LDA #newvdu AND 255:STA wrchv+0
  140   LDA #newvdu DIV 256:STA wrchv+1
  150   LDA #0:STA flag:RTS
  160   :
  170   .newvdu
  180   BIT vduQ:BMI check:STA flag
  190   .oldwrch
  200   JMP &FFFF
  210   .oldvdu
  220   PLA:JMP oldwrch
  230   .check
  240   PHA
  250   LDA vduQ:CMP #255:BNE oldvdu
  260   LDA flag:CMP #19:BNE oldvdu
  270   PLA:PHA:STA &323:\ last entry of VDU queue
  280   \ VDU queue
  290   \  &31F logical colour
  300   \  &320 physical 4-bit colour (extension options if >15)
  310   \  &321 red component of physical colour
  320   \  &322 green component of physical colour
  330   \  &323 blue component of physical colour
  340   LDA &31F:CMP #255:BEQ border   :\ VDU 19,-1,p,r,g,b
  350   LDA &320:CMP #24:BEQ borderRGB :\ VDU 19,l,24,r,g,b
  360   JSR RGBtest:BEQ oldvdu         :\ VDU 19,l,p,0,0,0
  370   :
  380   \ VDU 19,l,ignored,red,green,blue
  390   \ Select Palettemate 12-bit physical colour
  400   LDA &31F:ASL A:ASL A:ASL A:ASL A:STA flag :\ logical colour
  410   LDA &321:LSR A:LSR A:LSR A:LSR A          :\ physical colour red component
  420   ORA flag:STA &FE23                        :\ write %llllrrrr
  430   LDA &322:LSR A:LSR A:LSR A:LSR A:STA flag :\ physical colour green component
  440   LDA &323:AND #&F0                         :\ physical colour blue component
  450   ORA flag:STA &FE23                        :\ write %bbbbgggg
  460   .done
  470   INC vduQ:PLA:RTS               :\ Clear vduQ and return
  480   :
  490   \ Select Chameleon 12-bit physical colour
  500   \LDA &321:\LSR A:\LSR A:\LSR A:\LSR A:\STA &FE60           :\ red component
  510   \LDA &322:\LSR A:\LSR A:\LSR A:\LSR A:\ORA #&40:\STA &FE60 :\ green component
  520   \LDA &323:\LSR A:\LSR A:\LSR A:\LSR A:\ORA #&80:\STA &FE60 :\ blue component
  530   :
  540   \ VDU 19,-1,p,red,green,blue
  550   .border
  560   JSR RGBtest:BEQ border3bit     :\ VDU 19,-1,p,0,0,0
  570   :
  580   \ VDU 19,-1,ignored,red,green,blue
  590   \ VDU 19,ignored,24,red,green,blue
  600   .borderRGB
  610   LDA #&80:STA flag                         :\ top nybble<>0 to indicate 12-bit colour
  620   LDA &321:LSR A:LSR A:LSR A:LSR A          :\ physical colour red component
  630   ORA flag:STA &FE22                        :\ write %xxxxrrrr
  640   LDA &322:LSR A:LSR A:LSR A:LSR A:STA flag :\ physical colour green component
  650   LDA &323:AND #&F0                         :\ physical colour blue component
  660   ORA flag:STA &FE22                        :\ write %bbbbgggg
  670   JMP done
  680   :
  690   \ VDU 19,-1,physical,ignored,ignored,ignored
  700   .border3bit
  710   LDA &320:AND #&0F:STA &FE22    :\ write %0000xbgr, top nybble=0 to indicate 3-bit colour
  720   JMP done
  730   :
  740   .RGBtest
  750   LDA &321:ORA &322:ORA &323:RTS :\ EQ=all RGB values are zero
  760   .flag:BRK
  770   ]NEXT
  780 IF P%>&B00:PRINT"WARN: Code overrun":END
  790 PRINT "*SAVE VDU19 ";~mcode%;" ";~O%;" ";~go%OR&FFFF0000;" ";~load%

This can be optimised a lot. There is also an issue in this code in if you have the output stream redirected with *FX3 or *SPOOL then the last byte of the VDU 19 sequence doesn't get sent to the other streams.

[jgharston]

If the PaletteMate does need multiple palette entries programming in screen modes with fewer than 16 logical colours, the VDU 19 extender code should be as follows, also with interupts disabled while writing to the palette as the MOS does:

Code: Select all

  380   \ VDU 19,l,ignored,red,green,blue
  390   \ Select Palettemate 12-bit physical colour
  392   PHP:SEI                        :\ Disable IRQs
  395   .palette
  400   LDA &31F:ASL A:ASL A:ASL A:ASL A:STA flag :\ logical colour
  410   LDA &321:LSR A:LSR A:LSR A:LSR A          :\ physical colour red component
  420   ORA flag:STA &FE23                        :\ write %llllrrrr
  430   LDA &322:LSR A:LSR A:LSR A:LSR A:STA flag :\ physical colour green component
  440   LDA &323:AND #&F0                         :\ physical colour blue component
  450   ORA flag:STA &FE23                        :\ write %bbbbgggg
  452   LDA &31F:SEC:ADC &360:STA &31F :\ Add number of colours to step to next palette index
  454   CMP #16:BCC palette            :\ Loop to do all
  456   PLP                            :\ Restore IRQs
  460   .done
  470   INC vduQ:PLA:RTS               :\ Clear vduQ and return

Another point, replacing the 4-bit FBGR colour (ie b3=flash) with 4-bit IBGR (ie b3=intense) you should use 0-7=half bright colours and 8-15=full bright colours, to match all other implementations, see Wiki.

[1024MAK]

@ Rob, I like the idea of upgrading the Beeb's video circuitry to improve the colour selection. But all the colour palette talk is a bit confusing at a quick glance. I will have to re-read this thread when my brain is a bit less tired...

So keep working at it. Something that hopefully can be made available to *. members in due course. Then we will let Tricky, Rich and the other games programmers* loose on it, hopefully with very colourful results

Mark

* please don't be put out if I did not include your name, I can remember pins on chips and their functions, but peoples names, not so much

[trixster]

Amazing work and what a brilliant idea. Id definitely like to get one if they become available.

[RobC]

@ Rob, I like the idea of upgrading the Beeb's video circuitry to improve the colour selection. But all the colour palette talk is a bit confusing at a quick glance. I will have to re-read this thread when my brain is a bit less tired...

So keep working at it. Something that hopefully can be made available to *. members in due course. Then we will let Tricky, Rich and the other games programmers* loose on it, hopefully with very colourful results

Amazing work and what a brilliant idea. Id definitely like to get one if they become available.

Thanks for the encouragement and I wouldn't worry about all the details yet. I'm still evolving the VHDL code and so things are still likely to change!

I've fitted a new oscillator to the development board and am correctly generating the 16MHz and 12MHz clocks so I can hopefully sort out mode 7 soon. If and when I get the bugs ironed out, I can start to think about putting this on a PCB.

[Rich Talbot-Watkins]

Amazing stuff Rob! 16 proper colours in Mode 2 was always the biggest thing on my wishlist!

Personally I think even 4096 colours is overkill though, given the crummy resolution you get to display them on. I'd be happy even with a 64 colour palette, that's more than enough to make some colourful screens (might also make the hardware simpler; two writes to change the palette - one to set the palette index, another to set the colour).

[simonm]

Amazing stuff Rob! 16 proper colours in Mode 2 was always the biggest thing on my wishlist!

YES! Even 8 half brite RGB levels would have been all kinds of awesome!

[RobC]

Amazing stuff Rob! 16 proper colours in Mode 2 was always the biggest thing on my wishlist!

Mine too.

Personally I think even 4096 colours is overkill though, given the crummy resolution you get to display them on. I'd be happy even with a 64 colour palette, that's more than enough to make some colourful screens (might also make the hardware simpler; two writes to change the palette - one to set the palette index, another to set the colour).

I tend to agree with 4096 colours being overkill but, given that the larger palette fits in the CPLD, it doesn't really make the hardware much more complicated (4-bit DACs vs 2-bit DACs). Plus, it's still only 2 writes to set a colour - anything larger would need an extra write so I ruled that out.

[tricky]

What would the chance of multiple palettes be?
For things like the enhanced mode 1 pictures, one of the limiting factors on the beeb is the time it takes to change palette entries. There is only time to change 2 colours during the off screen period. With yours you could change all four colours, but if you could swap palette with one write, then you could change palette mid line and be updating another palette ready to swap again.

[Rich Talbot-Watkins]

Just to go off on a tangent for a moment, I was interested to see how the 27 colour palette works on the Amstrad CPC. It's basically a hack on top of the 8 colour RGB, where the RGB outputs are actually tristate. Internally there are actually 32 colour numbers, which are converted to 27 unique outputs via this bit of twisted logic in the Gate Array:



These pairs of outputs then each go to a tristate buffer, such that if the _OEn output is high, the result is a 50% output; otherwise it's 0%/100% depending on the other output.

This is a lovely little hack which could have easily been done on the Beeb at very little extra cost (although it would've needed 5 bits for the 'physical' colour). Or, as Simon says, just a "half bright" bit which represents 50% output to all RGB, giving 15 colours.

The CPC palette was unique, and really rich and versatile.

[1024MAK]

What would the chance of multiple palettes be?

If there are enough resources, more than one palette plus an extra control register (and maybe a counter, depending on how much "memory" is available for palettes) could mean one palette per line up to the total number of palettes...

So if there are say four available palettes, the programmer could program (in the new register) which palette is wanted before each line starts to be generated.

Further, if a counter was included (and I don't know how useful this would be), it could automatically count through the available palettes at intervals defined by the new register, so every line, every second line, every 4th, 8th line etc...

Anyway, how practical this is, I'm not sure, but it's an idea to think about. As it would make multicoloured displays using more of the available 4096 colours easier to generate

Mark

[jgharston]

&FE22 selects the border colour, with the high nybble=%0000 selecting a 3-bit physical colour and the high nybble non-zero selecting a 12-bit physical colour, there's room there to specify a total of 16 things via that address. Eg
%0000xbgr - 3-bit border colour
%0001rrrr - first write of 12-bit border colour
%0010nnnn - select a palatte
etc

Thinking a bit more, it might make the internals of the palettemate simpler if the top nybble was arranged so a bit indicated that it was the first write of a two-byte write, which would also leave functional room for future expansion. Eg, something like:
%0xxxxxxx - write of a one-byte sequence, eg %0000xbgr border colour, %0100nnnn pallete number
%1xxxxxxx - first byte of a two byte sequence, eg %1000rrrr first byte of 12-bit border colour

Even if multiple palettes aren't implemented, I think it's useful enough to make bit 7 of &FE22 specify 3-bit border colour vs start of 12-bit border colour. It follows a useful principle of pushing the action specifier as far away as possible from the action data to leave space between the two so each has space to expand.

[RobC]

What would the chance of multiple palettes be?
For things like the enhanced mode 1 pictures, one of the limiting factors on the beeb is the time it takes to change palette entries. There is only time to change 2 colours during the off screen period. With yours you could change all four colours, but if you could swap palette with one write, then you could change palette mid line and be updating another palette ready to swap again.

Mike Cook's Chamelon had two palettes each holding eight 12-bit colours (so only 8 colours + flashing on screen in mode 2). I once used this to display many colours (can't quite remember exactly how many) on screen using an interrupt routine to modify the alternate palettes over several scan lines.

Unfortunately, there's not enough room to hold another 16 x 12-bit palette in the EPM570 but the larger devices in the series could do it. There would obviously be space to have multiple smaller (i.e. < 12-bit) palettes. One option might be 8 x 512 colour palettes but I haven't thought about how this would be controlled.

Also, if we're only talking about 4 (or even 2) colour screen modes, it might be possible to have a mode where a single write defines the physical colour at FE21 (rather than 4 or 8 writes as with the standard ULA) and then have that colour put through the extended 12-bit palette. (I still haven't checked the behaviour under "nasty effects"/Phoenix but I'd like to keep things as compatible as possible by default.)

If there are enough resources, more than one palette plus an extra control register (and maybe a counter, depending on how much "memory" is available for palettes) could mean one palette per line up to the total number of palettes...

So if there are say four available palettes, the programmer could program (in the new register) which palette is wanted before each line starts to be generated.

Further, if a counter was included (and I don't know how useful this would be), it could automatically count through the available palettes at intervals defined by the new register, so every line, every second line, every 4th, 8th line etc...

Anyway, how practical this is, I'm not sure, but it's an idea to think about. As it would make multicoloured displays using more of the available 4096 colours easier to generate

From memory, I think each scanline takes 64uS which is 128 cycles. With two loads and stores, I think it currently takes a minimum of 12 cycles to set a colour. So, it's not possible to modify more than 10 colours per scanline as things stand. Please do correct me if I've got this wrong as I've not tried it and am a bit hazy on the details.

If I stick with the EPM570, there's obviously a compromise between palette size/colour depth and the number of palettes.

To me, a single 12-bit palette seems "cleaner" as it's what the Arc does and more in keeping with Acorn's philosophy (if that doesn't sound too grand) but I am happy to consider alternatives. Apart from altering the number of DACs, it's not much of a change as the extended palette is the easy part of the VHDL.

[RobC]

&FE22 selects the border colour, with the high nybble=%0000 selecting a 3-bit physical colour and the high nybble non-zero selecting a 12-bit physical colour

I haven't implemented any border control features yet so it's slightly misleading to say that this is what it does

If I continue to use the EPM570 (which is preferable to me as that's what's on my development board), I may have to trade-off various features that have been mentioned: palette size, border control, horizontal scrolling and multiple palettes.

[jgharston]

I think keeping to a single 12-bit pallete would be the best option. With only two write needed to change a palette entry that's fast enough to simulate multiple palettes by changing the palette entries, especially with the required values to write precalculated.

For instance, flashing colours can easily be done by writing the pallete on every x VSync events. Somewhere I've got code that does this to allow non-completementary flashing on the Beeb (eg Red/Blue, Red/White, Black/Yellow) instead of the built-in complementary flashing (eg Red/Cyan, Black/White, Blue/Yellow).

You've not implemented it yet, but I think writing to &FE22 with %0xxxxxxx for one-byte border write and %1xxxxxxx for first byte of 2-byte border write makes programming and hardware sense.

[RobC]

Just had a bit of a play mainly to test out the "nasty effects" thing.

It handles the incomplete/inconsistent palette programming exactly as the VIDPROC in my other M128 does - Phoenix displays the multi-coloured stars and there's no shimmering (unlike some Beebs).

Here are some (not very good) photos of games with modified palettes:

Commando

Firetrack

Stryker's Run