There is a small bug at the Demo and IoHandler levels: the Open call is not passing up the results of the lower level call. This
means that the demo driver always sees the mode as zero. The fix is straighforward:
@ Graham, Joao : Thanks for the feedback and taking the time to investigate. Seems my regression testing failed me there. I'll correct the bugs and produce a new release.
Graham Stabler said...
It now thinks it is in Pal but it still shows B&W so perhaps not.
The bug only stopped the correct mode being reported back so it should have worked. PAL+LARGEFONT is showing colour okay for me.
My only thought is that your TV composite video could be expecting s-video and dropping the colour; mine does that if I have the wrong option selected.
The other thing I can suggest is trying a Demo object modified for PAL to see if that's also B&W or colour.
It is a rubbish screen so that may well be the problem, it does show colour but not all that well, I'll try again tommorow.
Basically I'm just in need of a bigger font than I get from tv_text while not taking as much memory as graphics.spin. My screen just does not display the text of tv_text well enough.
In the search for a reference beautiful 8x8 driver, there are certain tradeoffs and choices that need to be made:
Number of colors onscreen. We could have two colors, foreground and background, and this will take the smallest amount of memory.
Palette support. If we use a 16 color fixed palette, then we can use 4 bits to store that information, on a per character basis.
The ability to choose background colors. Do we want the ability to choose background colors on a per character basis? This would add 4 bits, totalling 8 bits of color data, turning this into 16 bits per character. At 40x25x16 bit, that's about 2K of screen buffer.
If we instead used the 4 bits for other things than background color, we could have things such as inverse video mode, flashing, and two other fancy text attributes.
Do we want to support more than 40x25 in the reference driver? i.e. support character mode 12.
A nice feature would be text window support. Separate buffers defined for different lines. This would allow us to have a status window, an output window, and an input window.
For my specific purposes, the Z-Machine, I would use the 40x25 reference driver with:
In two color mode, with a dark blue background, and light blue foreground.
With inverse video support.
With windowing support, so that there can be a status line in inverse video that shows the current room and the score.
But, the above features mentioned earlier, especially 16-bit color mode would be fantastic for things such as a roguelike. [noparse]:)[/noparse] Not only that, but a roguelike with a custom font set!
So, what is our goal with the reference driver? [noparse]:)[/noparse] Comments and feedback would be appreciated.
Graham Stabler said...
Basically I'm just in need of a bigger font than I get from tv_text
There could be some confusion here. My code uses TV_Text for the large font, the new 8x8 driver for the small font, so you'll get the same or worse I'm afraid.
Look at all of this. Can't wait 'till the weekend to run some of this stuff.
IMHO, things like text window support belong higher up, in TV_Text, or something. The font, color mapping, screen modes, etc... all should be in the lower level driver, exposing those things necessary for the higher level stuff to do it's thing.
The 3.x driver, I wrote before all the changes, has nice variable timing. IMHO, this is something to keep. In two color mode, it will do 64 chars, if wanted. In color per char mode, it will do up to 40. I think people using smaller display screens may want 32, 20, etc... That timing will port right over to the 2.x and likely the changed / new drivers. I'm sure the same can be done for PAL too.
Inverse video, comes for free on the 3.x two colors ones. There are two colors in the HUB, two in the COG. Set them opposite, and it's golden. There might be time to just have the high bit flip the colors, or choose another set. (need to find room for two instructions in that one)
The plan for "16 bit" color / character mode, was to have 4 color chars be an option. Have those be half the resolution of the two color chars. Hadn't thought about color mapping.
I really like the 16 color, fixed background variation from Hippy. Perhaps that's a far better way to go, and just make sure those are run time modifiable. Overall, I think that's the best use of HUB memory, colors on screen, etc...
@hippy: Perhaps a trade off with the background color would be the ability to specify the fixed color.
Or can this be done already and I didn't see it.
Wes Brown said...
So, what is our goal with the reference driver? [noparse]:)[/noparse]
Good question, but I don't think there's a simple answer. Some people will be after the most basic fixed foreground/background colour scheme with smallest footprint while others are just after a 'more rows' display without massive memory use but with good functionality. Ne'er shall the 'twain meet ( until we have #if ).
On the practical front, just how much processing time you have between waitvids to churn out characters determines what you can and cannot achieve and that may dictate if your screen array has to be word or long, which may in turn dictate the most appropriate way of doing things.
Myself, I wanted low memory footprint, more rows than TV_text gives, a choice of at least four foreground colours and at least two background colours although inverse vido might be acceptable.
Ideally I suppose the best reference design would be a driver which did all possibilities with it being easy for the end-user to cut out functionality they do not need. The biggest bugbear I find in hacking video drivers is adjusting the screen array between byte, word and long. Any code which could use any type of course needs the worse case amount of screen array allocating. One solution there may be to put the array at the top end of memory and dynamically determine its start address at run time.
Second best would be separate reference designs for each possibility from the most basic to those tailored for specific applications.
Added : Hadn't spotted the discussion had moved on to another page. Your above post sounds like a good reference to aim for.
Settable scanlines, to 160 or 320 to change horizontal resolution.
Probably should be: Vertical pixel height. Likely only need variable 1 or two scan lines, but doing these really means any arbitrary vertical height is possible.
I did this in the bitmap driver. No biggie.
That 3.x code does any number of chars from 10 (likely lower) to as high as 70, depending on the color logic. Having the parametric timing in there is pretty cool. The real bummer comes from it being spin constants. Really should get the assembly treatment so that it can be run-time stuff. (tough for me, at this stage)
Hippy is exactly right. With out #if, we are just gonna have to make easily modifiable code, and put out some driver variants, or compromise big time on overall capability. IMHO, this is not too big of a deal. Many projects will do their own thing and won't need to reference other code bodies. Hippy's project is a good example. I suspect Graham's will be too.
Essentially then, all the code posted on this thread is useful!
For those things that do tie together to form a greater whole, perhaps settling on a core feature set is a good idea. The greater utility of the larger project, makes dealing with less than peak possible performance totally reasonable.
hippy said...
Myself, I wanted low memory footprint, more rows than TV_text gives, a choice of at least four foreground colours and at least two background colours although inverse vido might be acceptable.
Hmm. Eight colors, three bits, with the fourth bit an inverse video toggle? With eight bits for the character, we'd have 12 bits per character for color data + character. There's a lot of possibilities with inverse video if it flips the background/foreground colors. With 12 bits, we might even have enough time to do 62 column mode in something other than two color mode.
potatohdead said...
Hippy is exactly right. With out #if, we are just gonna have to make easily modifiable code, and put out some driver variants, or compromise big time on overall capability. IMHO, this is not too big of a deal. Many projects will do their own thing and won't need to reference other code bodies. Hippy's project is a good example. I suspect Graham's will be too.
Anyone at Parallax listening? Compiler-time directives such as #if in the propeller tool, pretty please! [noparse]:)[/noparse]
On the matter of processing time, I had an idea today. If we grabbed data a word at a time, we get longer between waitvids to do stuff.
There is an assembly opcode to reverse the bits. Maybe there are some unexplored options there. Could pack screen memory PC style. Every even byte is a character pointer, every odd one, it's color definition.
potatohead said...
On the matter of processing time, I had an idea today. If we grabbed data a word at a time, we get longer between waitvids to do stuff.
There is an assembly opcode to reverse the bits. Maybe there are some unexplored options there. Could pack screen memory PC style. Every even byte is a character pointer, every odd one, it's color definition.
If each time we grab data, we have to wait for the hub, then it's likely going to be a lot better if we grab more chunks of data at a time. If we're grabbing a word at a time, then we might as well go with 16 bits for character + color.
I'm thinking:
character (8) + color (4) + inverse (1) + misc (3)
I'm not sure what else we could use the remaining misc bits for? Any ideas?
Although if we read it a byte at a time, we could use two separate byte-aligned buffers, one for character data and one for color and attribute data. This would allow us to much more easily support 2 color and 16 color mode in the same driver. The 2 color driver would just ignore the color table, and the user doesn't have to allocate the buffer for the color table.
-Wes
Post Edited (Wes Brown) : 10/26/2007 3:50:00 AM GMT
character (8) + color (4) + inverse (1) + misc (3)
I'm not sure what else we could use the remaining misc bits for? Any ideas?
-Wes
Underline, blink and cursor support:
bit 13 - underline mode (the bottom two rows of the character cell are completely filled with the foreground color)
bit 14 - inverse toggle mode, for blink and block cursor support (toggles inverse bit twice per second)
bit 15 - underline toggle mode, for underline cursor support (toggles underline bit twice per second)
Post Edited (Fabian Nunez) : 10/26/2007 5:08:25 AM GMT
Wes Brown said...
I'm not sure what else we could use the remaining misc bits for? Any ideas?
Flashing text ? It would save anyone who wanted that from having to run another cog to achieve the effect and putting flashing in 'user space' would probably require using another screen buffer to hold characters while they are temporarily replaced by spaces.
Width stretch ? Double up the pixels and use two waitvid, skip the next character to keep charPtr handling easy. Might not be easy to implement in the execution time available - or adjust VSCL
Variable timing support, using timing from 3.x drivers, allowing different resolutions such as 20, 40, 62 character modes.
Settable vertical pixel height.
8 color palette for foreground colors, palette is adjustable at runtime.
One background color, adjustable during runtime.
Multiple font support, font switching, font swapping by changing the pointer. (Some old school games used font swapping for animation.)
NTSC/PAL support. (I'm going to need help testing PAL, as I don't have anything that can emulate PAL.)
Relocatable 'origin' -- this would allow us to have a larger buffer than what is shown on the screen, and can be useful for scrolling.
Each cell is a word consisting of:
bits 0-7 - character data (8) 256 character set
bits 8-10 - color data (3) 8 colors
bit 11 - inverse mode (foreground and background colors are reversed)
bit 12 - underline mode (the bottom two rows of the character cell are completely filled with the foreground color)
bit 13 - inverse toggle mode, for blink and block cursor support (toggles inverse bit twice per second)
bit 14 - underline toggle mode, for underline cursor support (toggles underline bit twice per second)
bit 15 - flashing text mode (background color takes place of foreground color twice a second)
Thoughts? Do we really want 16 colors, or is 8 colors with lots of attribute support better?
-Wes
Considering that combinations of bits 13-15 (the timer related modes) are probably not going to be terribly useful, you could pack all 3 modes into 2 bits and still have 16 colors:
bits 0-7 - character data (8) 256 character set
bits 8-11 - color data (4) 16 colors
bit 12 - inverse mode (foreground and background colors are reversed)
bit 13 - underline mode (the bottom two rows of the character cell are completely filled with the foreground color)
bits 14-15 toggle attributes (2): 00 - no toggle attribute
01 - inverse toggle mode, for blink and block cursor support (toggles inverse bit twice per second)
10 - underline toggle mode, for underline cursor support (toggles underline bit twice per second)
11 - flashing text mode (background color takes place of foreground color twice a second)
Thinking about underline mode, I'm not sure if drawing the bottom two lines of the character cell in inverse mode would look better than just filling them with solid color. Some experimentation should tell which is better.
Post Edited (Fabian Nunez) : 10/26/2007 8:06:53 AM GMT
Got sidetracked by MacOS X 10.5 (Leopard) and installing it on my G5. Shiny. Pity that I can't run the Propeller tool on it.
Fabian Nunez's bit layout is what I'll be working with. I had been musing on this for the last couple days, and I think we can manage to have some driver settings be in 'real time' rather than hardcoded into the source. I wonder if the decision tree involved would increase the timing of the ops, though. By having this sort of flexibility, it increases the usability of the reference driver. Instead, these parameters could be used on initializiation? Hm.
I would use a 'configuration' bitmask, perhaps going something like this:
Comments
TV_MODE = io#TV_MODE_PAL + io#TV_MODE_LARGE_FONT
It still says
NTSC Only.....
And it's all in B&W so I think it probably still is in NTSC mode.
means that the demo driver always sees the mode as zero. The fix is straighforward:
diff AiChip_TvText_Demo_001/AiChip_IoHandler_001.spin /cygdrive/c/joao/Import/Parallax/Propeller/ObjectExchange/AiChip_TvText_Demo_001/AiChip_IoHandler_001.spin
70c70
< result := router.Open( setDeviceType, setBasePin, setMode )
---
> router.Open( setDeviceType, setBasePin, setMode )
72c72
< result := router.Close( setDeviceType )
---
> router.Close( setDeviceType )
diff AiChip_TvText_Demo_001/AiChip_TvText_Demo_001.spin /cygdrive/c/joao/Import/Parallax/Propeller/ObjectExchange/AiChip_TvText_Demo_001/AiChip_TvText_Demo_001.spin
223c213
< result := io.Open( setDeviceType, setBasePin, setMode )
---
> io.Open( setDeviceType, setBasePin, setMode )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
Jo
The bug only stopped the correct mode being reported back so it should have worked. PAL+LARGEFONT is showing colour okay for me.
My only thought is that your TV composite video could be expecting s-video and dropping the colour; mine does that if I have the wrong option selected.
The other thing I can suggest is trying a Demo object modified for PAL to see if that's also B&W or colour.
Basically I'm just in need of a bigger font than I get from tv_text while not taking as much memory as graphics.spin. My screen just does not display the text of tv_text well enough.
Graham
For my specific purposes, the Z-Machine, I would use the 40x25 reference driver with:
But, the above features mentioned earlier, especially 16-bit color mode would be fantastic for things such as a roguelike. [noparse]:)[/noparse] Not only that, but a roguelike with a custom font set!
So, what is our goal with the reference driver? [noparse]:)[/noparse] Comments and feedback would be appreciated.
-Wes
Look at all of this. Can't wait 'till the weekend to run some of this stuff.
IMHO, things like text window support belong higher up, in TV_Text, or something. The font, color mapping, screen modes, etc... all should be in the lower level driver, exposing those things necessary for the higher level stuff to do it's thing.
The 3.x driver, I wrote before all the changes, has nice variable timing. IMHO, this is something to keep. In two color mode, it will do 64 chars, if wanted. In color per char mode, it will do up to 40. I think people using smaller display screens may want 32, 20, etc... That timing will port right over to the 2.x and likely the changed / new drivers. I'm sure the same can be done for PAL too.
Inverse video, comes for free on the 3.x two colors ones. There are two colors in the HUB, two in the COG. Set them opposite, and it's golden. There might be time to just have the high bit flip the colors, or choose another set. (need to find room for two instructions in that one)
The plan for "16 bit" color / character mode, was to have 4 color chars be an option. Have those be half the resolution of the two color chars. Hadn't thought about color mapping.
I really like the 16 color, fixed background variation from Hippy. Perhaps that's a far better way to go, and just make sure those are run time modifiable. Overall, I think that's the best use of HUB memory, colors on screen, etc...
That's my .02
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
If so, it's not a big deal to double the scanlines in the 8x8, set it to 20 char mode, 15, or even 10! In that configuration, you would get 12 rows...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
A nice 8x8 would be sweet. Though with the nice and roomy HUB, likely a non-issue...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Or can this be done already and I didn't see it.
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
Think this is a good default feature set for the reference driver?
-Wes
On the practical front, just how much processing time you have between waitvids to churn out characters determines what you can and cannot achieve and that may dictate if your screen array has to be word or long, which may in turn dictate the most appropriate way of doing things.
Myself, I wanted low memory footprint, more rows than TV_text gives, a choice of at least four foreground colours and at least two background colours although inverse vido might be acceptable.
Ideally I suppose the best reference design would be a driver which did all possibilities with it being easy for the end-user to cut out functionality they do not need. The biggest bugbear I find in hacking video drivers is adjusting the screen array between byte, word and long. Any code which could use any type of course needs the worse case amount of screen array allocating. One solution there may be to put the array at the top end of memory and dynamically determine its start address at run time.
Second best would be separate reference designs for each possibility from the most basic to those tailored for specific applications.
Added : Hadn't spotted the discussion had moved on to another page. Your above post sounds like a good reference to aim for.
Probably should be: Vertical pixel height. Likely only need variable 1 or two scan lines, but doing these really means any arbitrary vertical height is possible.
I did this in the bitmap driver. No biggie.
That 3.x code does any number of chars from 10 (likely lower) to as high as 70, depending on the color logic. Having the parametric timing in there is pretty cool. The real bummer comes from it being spin constants. Really should get the assembly treatment so that it can be run-time stuff. (tough for me, at this stage)
Hippy is exactly right. With out #if, we are just gonna have to make easily modifiable code, and put out some driver variants, or compromise big time on overall capability. IMHO, this is not too big of a deal. Many projects will do their own thing and won't need to reference other code bodies. Hippy's project is a good example. I suspect Graham's will be too.
Essentially then, all the code posted on this thread is useful!
For those things that do tie together to form a greater whole, perhaps settling on a core feature set is a good idea. The greater utility of the larger project, makes dealing with less than peak possible performance totally reasonable.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Hmm. Eight colors, three bits, with the fourth bit an inverse video toggle? With eight bits for the character, we'd have 12 bits per character for color data + character. There's a lot of possibilities with inverse video if it flips the background/foreground colors. With 12 bits, we might even have enough time to do 62 column mode in something other than two color mode.
Anyone at Parallax listening? Compiler-time directives such as #if in the propeller tool, pretty please! [noparse]:)[/noparse]
-Wes
There is an assembly opcode to reverse the bits. Maybe there are some unexplored options there. Could pack screen memory PC style. Every even byte is a character pointer, every odd one, it's color definition.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
If each time we grab data, we have to wait for the hub, then it's likely going to be a lot better if we grab more chunks of data at a time. If we're grabbing a word at a time, then we might as well go with 16 bits for character + color.
I'm thinking:
I'm not sure what else we could use the remaining misc bits for? Any ideas?
Although if we read it a byte at a time, we could use two separate byte-aligned buffers, one for character data and one for color and attribute data. This would allow us to much more easily support 2 color and 16 color mode in the same driver. The 2 color driver would just ignore the color table, and the user doesn't have to allocate the buffer for the color table.
-Wes
Post Edited (Wes Brown) : 10/26/2007 3:50:00 AM GMT
Underline, blink and cursor support:
bit 13 - underline mode (the bottom two rows of the character cell are completely filled with the foreground color)
bit 14 - inverse toggle mode, for blink and block cursor support (toggles inverse bit twice per second)
bit 15 - underline toggle mode, for underline cursor support (toggles underline bit twice per second)
Post Edited (Fabian Nunez) : 10/26/2007 5:08:25 AM GMT
Width stretch ? Double up the pixels and use two waitvid, skip the next character to keep charPtr handling easy. Might not be easy to implement in the execution time available - or adjust VSCL
Features:
Variable timing support, using timing from 3.x drivers, allowing different resolutions such as 20, 40, 62 character modes. Settable vertical pixel height. 8 color palette for foreground colors, palette is adjustable at runtime. One background color, adjustable during runtime. Multiple font support, font switching, font swapping by changing the pointer. (Some old school games used font swapping for animation.) NTSC/PAL support. (I'm going to need help testing PAL, as I don't have anything that can emulate PAL.) Relocatable 'origin' -- this would allow us to have a larger buffer than what is shown on the screen, and can be useful for scrolling.
Each cell is a word consisting of:
bits 0-7 - character data (8) 256 character set bits 8-10 - color data (3) 8 colors bit 11 - inverse mode (foreground and background colors are reversed) bit 12 - underline mode (the bottom two rows of the character cell are completely filled with the foreground color) bit 13 - inverse toggle mode, for blink and block cursor support (toggles inverse bit twice per second) bit 14 - underline toggle mode, for underline cursor support (toggles underline bit twice per second) bit 15 - flashing text mode (background color takes place of foreground color twice a second)
Palette is 3 bits, defaults are:
0 - $06 - RGB_WHITE 1 - $1C - RGB_BLUE 2 - $5C - RGB_GREEN 3 - $3D - RGB_CYAN 4 - $BC - RGB_RED 5 - $FC - RGB_MAGENTA 6 - $8D - RGB_YELLOW 7 - $07 - RGB_BRIGHT_WHITE
Thoughts? Do we really want 16 colors, or is 8 colors with lots of attribute support better?
-Wes
Considering that combinations of bits 13-15 (the timer related modes) are probably not going to be terribly useful, you could pack all 3 modes into 2 bits and still have 16 colors:
bits 0-7 - character data (8) 256 character set bits 8-11 - color data (4) 16 colors bit 12 - inverse mode (foreground and background colors are reversed) bit 13 - underline mode (the bottom two rows of the character cell are completely filled with the foreground color) bits 14-15 toggle attributes (2): 00 - no toggle attribute 01 - inverse toggle mode, for blink and block cursor support (toggles inverse bit twice per second) 10 - underline toggle mode, for underline cursor support (toggles underline bit twice per second) 11 - flashing text mode (background color takes place of foreground color twice a second)Thinking about underline mode, I'm not sure if drawing the bottom two lines of the character cell in inverse mode would look better than just filling them with solid color. Some experimentation should tell which is better.
Post Edited (Fabian Nunez) : 10/26/2007 8:06:53 AM GMT
Fabian Nunez's bit layout is what I'll be working with. I had been musing on this for the last couple days, and I think we can manage to have some driver settings be in 'real time' rather than hardcoded into the source. I wonder if the decision tree involved would increase the timing of the ops, though. By having this sort of flexibility, it increases the usability of the reference driver. Instead, these parameters could be used on initializiation? Hm.
I would use a 'configuration' bitmask, perhaps going something like this:
bits 0-1: columns modes (2): 00 - 40 column mode 01 - 62 column mode 10 - 70 column mode 11 - 20 column mode bits 2: vertical pixel height (1): 0 - 0 vertical pixel 1 - 1 vertical pixel bits 3-4: toggle attribute (2): 00 - 2 color mode 01 - 16 color mode 10 - 8 bit color mode (unsupported yet, obviates character text modes) bits 5-7: undefined-Wes