| KEGS enhancements [message #421220] |
Fri, 15 December 2023 16:52 |
gids.rs
Messages: 1395
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
I am trying to drum up support to have a 640x400x256 color screen implemented into KEGS by Kent and would like other peoples thoughts on it.
There would be no need for scan lines, interrupts, racing the beam, or interlaced graphics and no slowing the video down to 1 Mhz. Just a pure hi-speed unhindered video display.
It would work like this:
Banks 2, 3, 4 and 5 would be used for the screen, since Bank 1 is already used for shadowing and shouldn't be interfered with plus it may be needed for programming.
A 640x400x256 screen would require 4 full banks.
Each pixel would be represented by a full byte requiring 640 ($280) bytes per line.
100 lines would require 640*100=64000 bytes in each bank
Scan lines would not be needed and the 256 color selection would be made up of whole bytes. 4 bytes required for each color description.
Each Color description requires whole bytes of Red, Green & Blue and one page for luminescence. In each bank of memory it would look like:
$FB00.FBFF - each byte being the red color for the color selected by the pixel
$FC00.FCFF - each byte being the green color for the color selected by the pixel
$FD00.FDFF - each byte being the blue color for the color seclected by the pixel
$FE00.FEFF - each byte being the luminescence of the color selected by the pixel
For example. if the pixel # is $22 then the color for that pixel is derived from
red - $FB00 + $22
green - $FC00 + $22
blue - $FD00 + $22
lum - $FE00 + $22 - luminescense gets added to each of the values in the Red/Green/Blue locations. In this case the value in FE22 gets added to each of the values in FB22, FC22 and FD22 to increment the color without increment the values in Red/Green/Blue locationi.
4 pages of color description = $400 (1024) bytes and gives us a choice of 256 colors out of 16,777,214 in each bank.
Each bank could have its own set of colors, so theoretically the screen can view up to 1024 colors at the same time. This would require that the palette be loaded from each bank before each bank of 100 lines is sent to the Mac or PC video memory.
A partial screen of graphics then would require a total of 65024 bytes needed for 100 lines of graphics and 512 bytes of free memory.
Then, for a 640x400 screen, 4 banks of contiguous RAM memory will be needed..
Each bank uses memory from $0000.$FAFF for the screen and $FB00.FEFF for the color palettes
And $FF00.FFFF - can be reserved for some other color scheme. Thoughts?
Each bank holds 100 lines of 640 pixels requiring 640 ($280) bytes per line in linear fashion
Linear meaning the first bank views the top 100 lines, 2nd bank second 100 lines, 3rd bank third set of 100 lines and 4th bank last set of 100 lines. No interlacing.
I hope this would be easy enough to implement.
I believe with this set-up that one can achieve far better results than I am getting from some of the graphics convertors for 256 color screens.
IamRob
|
|
|
|
Members
Search
Help
Register
Login
Home
