Thinking more about this, reverting back to an IC that could be backwards compatible with the Beeb’s proper VidProc, working with the 6845, SAA5050 etc…
Let’s upgrade the shift register to 16 bits. For every 8 shifts, load the next byte from the frame buffer, as I think the proper VidProc does, but load it into the least significant 8 bits of the 16-bit shift register.
The 4-bit index into the palette register is formed either from the most significant 4 bits of the shift register, or bits 15, 13, 11 and 9, analogous to the original VidProc.
The benefit of this approach is that you can produce more interesting and useful effects from ‘partially programmed palettes’, especially if the index is formed from bits 15-12. You no longer lose information the more you shift the currently loaded byte, because you’re shifting the subsequent byte’s bits in, rather than constant zeroes, ones, or random noise. One high resolution pixel will always ‘know’ about its immediate neighbours on the right. Which means… hardware anti-aliasing, shading, more colours appearing when dithering etc.
The upper 8 bits of the shift register will need initialising some appropriate way, and it will probably have to handle right-hand border boundary conditions somehow, too. But if these challenges can be solved simply, then I reckon it’s possible to implement this improved VidProc maybe even as a CPLD drop-in replacement. And if on reset it defaults to the alternating bits method for forming palette indexes, then it should work straight away without any new or changed software at all.
Let’s upgrade the shift register to 16 bits. For every 8 shifts, load the next byte from the frame buffer, as I think the proper VidProc does, but load it into the least significant 8 bits of the 16-bit shift register.
The 4-bit index into the palette register is formed either from the most significant 4 bits of the shift register, or bits 15, 13, 11 and 9, analogous to the original VidProc.
The benefit of this approach is that you can produce more interesting and useful effects from ‘partially programmed palettes’, especially if the index is formed from bits 15-12. You no longer lose information the more you shift the currently loaded byte, because you’re shifting the subsequent byte’s bits in, rather than constant zeroes, ones, or random noise. One high resolution pixel will always ‘know’ about its immediate neighbours on the right. Which means… hardware anti-aliasing, shading, more colours appearing when dithering etc.
The upper 8 bits of the shift register will need initialising some appropriate way, and it will probably have to handle right-hand border boundary conditions somehow, too. But if these challenges can be solved simply, then I reckon it’s possible to implement this improved VidProc maybe even as a CPLD drop-in replacement. And if on reset it defaults to the alternating bits method for forming palette indexes, then it should work straight away without any new or changed software at all.
Statistics: Posted by Arx — Wed Jun 12, 2024 9:50 pm