I just had another idea. If each 8x8 block can support 1 color, it is only necessary to build the color scanline once per 8 character scanlines.
The color cog has space to hold·a prebuilt color line. Each color scanline·could be prebuilt in cog·during the·previous character scanline. The the cog waits for the current scanline time and just copies the cog color buffer to hub, then proceeds to build the next color line in the cog.
BTW - I have not fully understood the color build process.
Does this make sense ??? or am I missing something ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Thanks for the nice table COG tricks. That was easy, and it makes a lot of sense.
I've attached the archive modified for single character color cells. First the bad news: At 96Mhz, it will only do 40 characters [noparse]:([/noparse]
There is some good news! The TV cog can do the waitvids at 80Mhz, so it's not the problem. It can do a full 640 pixels, 8 pixels a frame, 4 color mode. That is fetching a word for the pixels and a long for the colors. IMHO, that makes this possible. Cool.
I kind of hate to throw more cogs at text. IMHO, three should be enough, with the two cog, two color deal as a fall back. As this is written right now, 64 characters actually works in that mode.
-->Building colors only once every 8 scanlines is a great idea. Interestingly, the color cog is the slowest of the lot. I thought for sure it would be the quicker one, leaving room for a mouse pointer. I'm gonna set that aside for the moment and focus on getting the 80 characters at 96Mhz. That's the core spec everybody (including me) wants.
I'm thinking to buy time, the line ram is going to have to be double buffered so that almost the entire scan time can be used to build up the graphics.
The problem area is too many HUB fetches. Perhaps a different memory scheme would help. I'm gonna think on it as my coding time for the weekend is coming to an end! Promised my daughter Race for the Cure, so it's up at 6:00 AM... happy days!
Color generation works like this:
There is a palette in the COG. 16 values.
A color byte gets read. Each nibble is used as an index to the color table. The indexed values are combined into a long for use by the TV cog. The lower nibble is the background color, and it maps to the lsb of the color long in the color ram. The other nibble is the character pixel color, and I just filled the other three bytes with that value, figuring the mouse operation would change the color it needs when that happens down the line. I used a coupla bit masks for this. That's why the color table is longs with the same value in all four bytes.
The plan for that is for the color cog to refresh the COG palette every vblank from the HUB, allowing for color changes at run time. The other parameters would be treated the same way, meaning the whole works just runs in the COG's and is hands off for other applications. I don't think that has to change in concept.
One nice thing about this happens to be the value 0 actually being black, instead of sync. This is handy for all sorts of reasons.
Next move for me, barring some other idea, is to consider double buffering the scan line pixel and color buffers, freeing time. If that fails, then I'm going to reconsider memory mapping schemes in an attempt to cut down on HUB access.
Here's a 40 character single cell screenie!
Bit shuffling appears to be the most costly propeller operation I've encountered. The UNIX way might be the right way: Smart Data for simple code! Time trade-offs for optimal use of memory sometimes are very costly. That means maybe color words, for less manipulation just to get a palette. What do you all think of maybe a 5K run time foot print for this -vs- 4K?
Just to clarify... tx_22.spin is the problem. It cannot do 80 chars at 96MHz yet.
How much is it short by? Maybe the easier question (I could try and calculate it) is how much time is there between the start of each scanline in nS/uS ? (Thanks baggers 62.5uS for NTSC and 64uS for PAL)
Some more ideas...
The color cog is pretty much free most of the time now, so with a little bit of improvement here, maybe we can do part of the character scanline in this cog also, to relieve the tx cog of having to do the whole job. Not sure how space will go here.
Ok, thinking aloud (can you hear me???), maybe the color cog and the tx cog have to be almost identical. One renders the first half of each scanline and the other renders the second half. Then, also within each 8 scanlines, each cog does 1/2 of 1/8 of preparing the color for the next character line.
Think I need some hardware running !! Oh no... what about ZiCog/TriBlade :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Here is a modified tx_24 which should take 56*4 = 216·clocks to execute a 4 character render loop·which I think may just work for 80 characters at 80MHz. 80 / 4 * 216 * 12.5nS = 54uS.
There were a couple of mods I did previously to save other overheads outside the main char fetch loop which might also be required.
As before, nothing tested nor compiled. It is possible I have transposed the characters because of incorrect endian.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I think I can squeeze a run through later today. Nice idea! And yes, the primary problem is the text cog. I saw the other mods and needed to debug them. That can happen on this pass, so they are all added together. I took the table mod as I had time for one quick pass and wanted a gross speed check.
No ZiCog - Triblade? Nonsense! That's just a matter of some configuration to the init part of the thing. Coley had the cool autodetect, which works straight away on the three common boards. Some extra pindefs can be added for the usual "uncomment this for your particular board" deal. The frequency parameters can be computed in the SPIN program easily enough.
Hoping that is what you meant. CP/M on this thing was part of the goal. Figured a VGA line driver was either written that could be used, or one could be written.
The other goal was the nice DOS EDIT style editor we saw at the Parallax convention. 80 characters for that will be sweet!
I was meaning I am distracted from coding the TriBlade & ZiCog.
And yes, I thought it would be great for the CPM and Dos style software.
If tx_24 works would you like to add a few nops in the loop to find where it fails so I know how much oomph is left. Otherwise, comment out a few instructions in the loop to find out how short it is. Hopefully it will just work
If the REV instructions can be removed, then that will save 16 clocks per loop (4 per character).
BTW In the early days, only 96 characters were displayed ($20-$7F) with the 8th bit used as inverse. $00-$1F are control characters and so should not appear as valid characters.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Well, it's a bit too long to compile. Need to free up some longs. A bunch can come from the crude parameter loading loop. Gonna have to find a few more.
If needed, the font table can be reversed at run time. It could be located in the waitvid loop, but that will deffo cost enough to put 80 out of reach on an 80Mhz board. Given the size of things, That's a deffo plan. No REV anywhere. SPIN can just do it.
Teen Age Girls... I'm sitting here early in the morning, now waiting [noparse]:)[/noparse] So, I've got about half an hour while they do what it is they do [noparse]:)[/noparse]
So then the Atari font will work for a first pass. Easy fix is to double it, then invert it. (96 character deal)
Did a bit of tinkering. I'll most likely run the refactored text cog code this evening. I actually can't stand to wait!!
The way this thing is built right now, it is possible to just run each cog on it's own to see capability. If both the text cog and color cog are commented out, some simple test color bars are seen. Uncomment the color code, and the color cells can be seen. Uncomment the text cog and the characters can be seen. I was testing and ended up quite pleased at this behavior.
I like this and am going to do a bit of cleanup so that is always possible and easily understood going forward.
Two color text then would just be a two cog affair. Nice. Just don't run the color cog.
Once the core 80 column, single character 16 color palette color cell is done, other COG functions can then be written. That is where PAL, VGA (probably somebody besides me as I rarely can test VGA), mouse pointer will happen. An example of this would then be three cogs needed for 2 color text with a colored mouse pointer.
If my suggestions work for 80 characters at 80MHz, then it might be possible to use 1 cog for both text and color at 96MHz by performing 10 characters of color per linescan, building an alternate color table in advance. Cannot wait for the current results - hope there is a bit of time to spare
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Yeah, me too. Will let you know tonight. Looks good though.
IMHO, if that can be done, that can be a special plug-in kind of COG, where the higher clock is needed. I've a xtal or two and plan on running at 100Mhz on a Demo board at some point in the future. Final packaging will be the three cogs, then extra variants for this and that special case. A graphics COG would make sense under the same arrangement.
Thanks again for the mind share. [noparse]:)[/noparse]
A question... In the loop I modified, 4 character bytes are read, but there are 2 longs written, meaning 16 bits of line scan for each byte. Can you please explain why it is not 8 bits for the text? I am obviously missing something basic here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Yeah, the font is one bit per pixel(2 color), and the scan line driver wants to see two bits per pixel.(4 color) That's the one long -vs- two longs deal you are seeing.
A year or so ago, when I tried this, I was using one bit per pixel mode and was able to get high character densities in a single cog. Color cut down on that some, but still it performed very well. The problems were poor NTSC signal generation. Really, that was a game quality signal, not a text quality one. This put PAL conversion off the table, and limited the color character density to below 40 characters per line. AiGeneric came out of that and is a compromise all around, and is being used on a fair number of projects.
From that effort, I've seen the following needs:
1. Mouse pointer / Sprite capability.
2. Multi-color characters for games and more detailed GUI efforts.
3. Higher character densities. 80 columns is where a lot of people want to be.
4. Better color signal and control.
5. Frugal HUB run time memory foot print.
What I didn't know about the 80 was whether or not newer display devices were capable of rendering it with enough fidelity to be useful. Given what I've seen by examining some of my consumer electronics, I suspected a good quality, interlaced color signal would do the 80. If not, there is little doubt an S-video signal would. Either way, it kind of made sense to shoot for the 80 per line, using 64 characters as a nice fall back for those projects that don't need 80, but could benefit from higher character densities and lower complexity than seen in the TV_Text driver. (those fonts are very large, making smaller text sizes challenging on TV displays)
On this pass then, I decided to build up from a 4 color mode capable video signal. Eric had produced the nice templates that really made that part easy, so I jumped on those and started building up to the text and that's where things are right now.
IMHO, it's really close. I don't see it not happening, and above all I really want a nice, serious text / graphics display that will see some use. In the list above, it was rare that people were worried about COG's. If they are, the older single COG drivers I did will do 64 two color screens in a pinch. Heck, one of them runs completely in COG, containing enough of a font table to just require a screen buffer somewhere. That's about as tiny as it gets. Serial terminals are our friends from there.
There is one other element that contributes to this and that is color re-direction. The way propeller graphics work means encoding some of the sync signals into the color space. Sync is literally one of the available colors. This is kind of cool in that we get to build the signal, but is unforgiving where building displays is concerned. Propellers get us one bit per pixel, two bits per pixel, and 8 bits per pixel where not all 8 bits are used. 16 colors, as Baggars recently just did, is a very sweet spot given the memory size of the chip.
I've gotten into trouble many times because 0 is not black! The value 2 is black and that's an annoyance.
All of this combines to make life easy for this project color wise. Just use words for color memory, adding about 1K to the HUB run time foot print, and mask those into the color memory. No worries. That would be absolute propeller colors though, where 00 is not black. Adding a CLUT (color lookup table) gets both things done. Nibbles can very easily describe color with enough bits to be very useful, and 0 can be black. Also possible then is color cycling where changing a single value impacts all display pixels drawn according to that value.
Really then, I'm not so worried about the color COG. Easy solutions exist there. It's the text one that matters. If it can do it's thing to 80 characters at 80Mhz +, life is good, because the 8 bit, single color font is the worst case. It can already happen with a 16 bit 4 color font, at the cost of more run time HUB memory being required for the table of display characters.
I'm hoping it all shakes out such that the original memory plan would work.
Assuming that's the case, the various driver COG's will read their HUB parameters during the VBLANK, update their timing and tables, then display the next video frame with those in play, just like an old graphics chip would. From there, any other program running need only write a few values to update it's screen display, with no worries other than that.
2 bits per pixel puts all 5 of the items above on the table.
Thanks potatohead. That gives me a bit more background info. I haven't played with the TV & VGA display code - I have just used them as is. But the 80 character TV display is a requirement on a single prop + ram _microSD ZiCog/CPM SBC solution, hence the interest. We have both cogs and hub space, but a lack of pins is an issue. Hoping that 1 or 2 pin TV solution will work. I can get that and a Keyboard connected with less sram.
I am going to build the TV circuit on my TriBlade to test your code, hopefully today
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I will give it a try. Got my hw running so have looked at the output. My code must have a bug or else not enough time or something. Have to go out shortly so will look after that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The rev instructions won't be needed. Flip the $%(*#&$% pixel table and be done with that. Also don't need the "and charcolor_mask" instruction either. That was for making one character in a two character color cell a different color.
That's quite a few instructions gone!
'Block the following into 4 characters at a time (Cluso99)
'need to verify we have the correct endian (correct byte order within the long)???
'code is optimised (out of normal order) to ensure no wasted timeslots between hub accesses
:loop4 rdlong C4, _screen 'get 4 character from screen memory
rol C4, #8+3 'top byte first
mov C, C4 'get it (already shifted <<3 i.e multiply x8)
and C, x07F8 'remove other bits ($FF << 3)
add C, _fontsum 'add font tab + scanline offset
'next 2 instructions are free due to hub access
rol C4, #8 'next byte
mov C1, C4 'get it (already shifted <<3 i.e multiply x8)
rdbyte D, C 'get pixels from fonttab
movs [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]2a, D 'modify P2 (need at least 1 instr before P2)
add _screen, #4 'next block of 4 characters
:P2a mov E, pixel_table 'source self modify
'and E, charcolor_mask 'color definition for character 2
'process 2nd char
and C1, x07F8 'remove other bits
add C1, _fontsum 'add font tab + scanline offset
rdbyte D, C1 'get pixels from fonttab
movs [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]2b, D 'modify P2 (need at least 1 instr before P2)
'if the pixel_table has to be reversed, why isnt it reversed in the first place???
'REV E, #16 '\this can probably be improved to do once
'shl E, #16 '/ 'save font pixels for line ram
:P2b mov E2, pixel_table 'source self modify
'and E2, charcolor_mask 'color definition for character 2
'REV E2, #16 '\this can probably be improved to do once
or E, E2 '/ 'save font pixels for line ram
rol C4, #8 'next byte
mov C, C4 'get it (already shifted <<3 i.e multiply x8)
and C, x07F8 'remove other bits
wrlong E, _lnram 'put 2 sets font pixels into line ram
'process 3rd char
add C, _fontsum 'add font tab + scanline offset
rol C4, #8 'last byte (use in C4) (already shifted <<3 i.e multiply x8)
rdbyte D, C 'get pixels from fonttab
movs [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]2c, D 'modify P2 (need at least 1 instr before P2)
and C4, x07F8 'remove other bits
:P2c mov E, pixel_table 'source self modify
'and E, charcolor_mask 'color definition for character 2
'REV E, #16 '\this can probably be improved to do once
'process 4th char
add C4, _fontsum 'add font tab + scanline offset
rdbyte D, C4 'get pixels from fonttab
shl E, #16 '/ 'save font pixels for line ram
movs [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]2d, D 'modify P2 (need at least 1 instr before P2)
add _lnram, #2 'next lineram long
:P2d mov E2, pixel_table 'source self modify
'and E2, charcolor_mask 'color definition for character 2
'REV E2, #16 '\this can probably be improved to do once
or E, E2 '/ 'save font pixels for line ram
sub count, #4 wz
'there are 2 wasted instructions that could be done here in the hub window
wrlong E, _lnram 'put 2 sets font pixels into line ram
add _lnram, #4 'next lineram long
if_nz jmp #:loop4 'next group of 4 chars
'=============================================================
It's stamping two characters in some cells, and not others. Close! Very close!
Ok, here's the archive of the current code. I've folded the new loop into the last working text cog file. Pixel table has been reversed, and I commented out the instructions not necessary to handle pixels anymore. This should then just be fetch, rotate, mask, etc....
I modifed the color cog to just write the same colors to the line ram. The text cog works to 64 characters. Still needs debugged, but it's plenty fast enough.
Sweet!
Cluso99, good code help. I think this will be fast enough. More later when I get home.
Here is the code with bugs fixed but moved for speed yet. I will post that shortly. Thought you might like something.
What do I need to do to get 80 characters?
I tried just bumping to 80 and got no display (TV can't handle it???). 64 works but very jittery. Is there some timing I need to do?? The TV is Panasonic HD CRT about 8-9 years old.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Not much farther to go now! Got the bitmasks and such sorted out.
Here's a screen capture 80 characters @ 96Mhz. Back on track. It does 64 at 80Mhz, BTW. I've a little problem with the blank scan line routine that crept in there somehow. I'm working on that bugger right now. Once the frame is clean again, then it's time to sort out the characters.
Cluso99 -- That's a confusing loop! Guess I have to learn to think a bit differently for the best speed! At 96 Mhz, I can put at least 7 nops in the loop before things break down.
I've attached an 80 character capture. Specs are same as before 64 characters at 80Mhz, 80 characters at 96Mhz. You will note the blue strip at the top, and the extra dark section at top left. That's sync level video and most TV's isn't going to handle this well. Capture cards are good about this. That's some bug that crept in, and is the cause of display jitters at the higher counts. Gonna have to go back a few revisions and see where that could have entered the picture. With the text cog speed proven, this is priority one.
I'm compensating to see the display by changing the count in the blank scanline routine in the text cog. Normally the count here is just number of waitvids. Back it off to 60 or so, and most displays will display, despite the sync being present in the active area. [noparse]:([/noparse]
The attached archive is set for 80 @ 96Mhz. You can set the number of characters per line to a multiple of 16 characters on slower hardware. This archive has the fixed and fast character text loop. (nice!)
Also in this archive, the color cog is mostly dead, just writing the testcolors long to the line ram each scanline. Some variation of the faster loop will do the colors, I'm sure.
I'm very likely to fix this display bug, then clean up and make sure two color text works perfectly with a stable, in-spec display.
The blank scan line routine was changed to do one count per waitvid, meaning the pixel buffer was written into the color buffer. It's fixed for the moment by just enlarging the pixel buffer to 80 longs.
Archive attached set for 80 chars at 96Mhz. Should display just fine.
rr003 has everything in sequence but this loop will take 240 clocks whereas by reordering the same instruction and utilising the nops we get 192 clocks (equivalent to 60 instructions down to 48). Original code loop was 2 x 32 = 64 instructions = 256 clocks.
How this works is...
count each rd/wr byte/word/long as 2 instructions (8 clocks)
instructions between each rd/wr byte/word/long will be padded to 2 + multiple groups of 4 because of hub access
· which means it will be padded to 2/6/10/14/18... instructions, so you may as well use them to advantage
So re-ordering can save significant time (about 20%).
Postedit: Maybe you might like to leave the code before re-ordering in but commented out for others to read·to see how it is really working.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Yeah, that's really cool Cluso99. Your comments on the second mod helped a lot actually. I still think in a very linear fashion on these things. Need to break out of that habit, it seems [noparse]:)[/noparse] Thanks!
I've just folded them into the working code, if you don't mind. Was easier to limit changes. With these things you get either something you can look at, something you have to put a scope on, or a mess! The other small mods you have in there just need a debug. The vertical one didn't work quite right. Was also easier to just focus on the text loop. Now that a stable frame is here again, the others are easy pickings. I think they are all done anyway, but for the logic related ones.
So, there may well be time for color in this cog, but it's going to have to start to build during the vertical back porch. (top border) Some changes in the simple display logic are needed for this to happen.
IMHO, it's worth a shot to pack it into this COG, for a two cog, text only solution. I'm going to think on that for just a bit. Given 8 scans, there is very likely time. Might cost an additional color buffer foot print though.
So, here's are the color choice(s):
The original color scheme called for a color palette table in the HUB. 16 values. It gets copied to the cog doing color each VBLANK. Other programs can put values there and see changes the next frame. (smallest memory foot print, greatest instruction cost)
One color byte then has two color nibbles. Lower nibble = background color, upper nibble = character color. Take the nibble, index to the color table, then mask that color found in the table, into the color RAM area. That's really it for the color done that way.
The easier choice, if it all goes in one COG, is to just use a word for color. Each byte gets dropped into the color RAM long. LSB = background, MSB = foreground. (moderate memory foot print, still high instruction cost) The way things are right now, the other color values can be ignored. Nothing displays them.
The easiest choice is to just use longs for the color. They get copied into the line ram directly. (large foot print, very low instruction cost) Easy cheezy on this one.
Two color text will be an option anyway, for where color doesn't matter a whole lot.
Comments
I just had another idea. If each 8x8 block can support 1 color, it is only necessary to build the color scanline once per 8 character scanlines.
The color cog has space to hold·a prebuilt color line. Each color scanline·could be prebuilt in cog·during the·previous character scanline. The the cog waits for the current scanline time and just copies the cog color buffer to hub, then proceeds to build the next color line in the cog.
BTW - I have not fully understood the color build process.
Does this make sense ??? or am I missing something ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I've attached the archive modified for single character color cells. First the bad news: At 96Mhz, it will only do 40 characters [noparse]:([/noparse]
There is some good news! The TV cog can do the waitvids at 80Mhz, so it's not the problem. It can do a full 640 pixels, 8 pixels a frame, 4 color mode. That is fetching a word for the pixels and a long for the colors. IMHO, that makes this possible. Cool.
I kind of hate to throw more cogs at text. IMHO, three should be enough, with the two cog, two color deal as a fall back. As this is written right now, 64 characters actually works in that mode.
-->Building colors only once every 8 scanlines is a great idea. Interestingly, the color cog is the slowest of the lot. I thought for sure it would be the quicker one, leaving room for a mouse pointer. I'm gonna set that aside for the moment and focus on getting the 80 characters at 96Mhz. That's the core spec everybody (including me) wants.
I'm thinking to buy time, the line ram is going to have to be double buffered so that almost the entire scan time can be used to build up the graphics.
The problem area is too many HUB fetches. Perhaps a different memory scheme would help. I'm gonna think on it as my coding time for the weekend is coming to an end! Promised my daughter Race for the Cure, so it's up at 6:00 AM... happy days!
Color generation works like this:
There is a palette in the COG. 16 values.
A color byte gets read. Each nibble is used as an index to the color table. The indexed values are combined into a long for use by the TV cog. The lower nibble is the background color, and it maps to the lsb of the color long in the color ram. The other nibble is the character pixel color, and I just filled the other three bytes with that value, figuring the mouse operation would change the color it needs when that happens down the line. I used a coupla bit masks for this. That's why the color table is longs with the same value in all four bytes.
The plan for that is for the color cog to refresh the COG palette every vblank from the HUB, allowing for color changes at run time. The other parameters would be treated the same way, meaning the whole works just runs in the COG's and is hands off for other applications. I don't think that has to change in concept.
One nice thing about this happens to be the value 0 actually being black, instead of sync. This is handy for all sorts of reasons.
Next move for me, barring some other idea, is to consider double buffering the scan line pixel and color buffers, freeing time. If that fails, then I'm going to reconsider memory mapping schemes in an attempt to cut down on HUB access.
Here's a 40 character single cell screenie!
Bit shuffling appears to be the most costly propeller operation I've encountered. The UNIX way might be the right way: Smart Data for simple code! Time trade-offs for optimal use of memory sometimes are very costly. That means maybe color words, for less manipulation just to get a palette. What do you all think of maybe a 5K run time foot print for this -vs- 4K?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 12/13/2009 11:48:21 AM GMT
How much is it short by? Maybe the easier question (I could try and calculate it) is how much time is there between the start of each scanline in nS/uS ? (Thanks baggers 62.5uS for NTSC and 64uS for PAL)
Some more ideas...
The color cog is pretty much free most of the time now, so with a little bit of improvement here, maybe we can do part of the character scanline in this cog also, to relieve the tx cog of having to do the whole job. Not sure how space will go here.
Ok, thinking aloud (can you hear me???), maybe the color cog and the tx cog have to be almost identical. One renders the first half of each scanline and the other renders the second half. Then, also within each 8 scanlines, each cog does 1/2 of 1/8 of preparing the color for the next character line.
Think I need some hardware running !! Oh no... what about ZiCog/TriBlade :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 9/20/2009 8:05:29 AM GMT
Here is a modified tx_24 which should take 56*4 = 216·clocks to execute a 4 character render loop·which I think may just work for 80 characters at 80MHz. 80 / 4 * 216 * 12.5nS = 54uS.
There were a couple of mods I did previously to save other overheads outside the main char fetch loop which might also be required.
As before, nothing tested nor compiled. It is possible I have transposed the characters because of incorrect endian.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
No ZiCog - Triblade? Nonsense! That's just a matter of some configuration to the init part of the thing. Coley had the cool autodetect, which works straight away on the three common boards. Some extra pindefs can be added for the usual "uncomment this for your particular board" deal. The frequency parameters can be computed in the SPIN program easily enough.
Hoping that is what you meant. CP/M on this thing was part of the goal. Figured a VGA line driver was either written that could be used, or one could be written.
The other goal was the nice DOS EDIT style editor we saw at the Parallax convention. 80 characters for that will be sweet!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 9/20/2009 12:37:57 PM GMT
And yes, I thought it would be great for the CPM and Dos style software.
If tx_24 works would you like to add a few nops in the loop to find where it fails so I know how much oomph is left. Otherwise, comment out a few instructions in the loop to find out how short it is. Hopefully it will just work
If the REV instructions can be removed, then that will save 16 clocks per loop (4 per character).
BTW In the early days, only 96 characters were displayed ($20-$7F) with the 8th bit used as inverse. $00-$1F are control characters and so should not appear as valid characters.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
If needed, the font table can be reversed at run time. It could be located in the waitvid loop, but that will deffo cost enough to put 80 out of reach on an 80Mhz board. Given the size of things, That's a deffo plan. No REV anywhere. SPIN can just do it.
Teen Age Girls... I'm sitting here early in the morning, now waiting [noparse]:)[/noparse] So, I've got about half an hour while they do what it is they do [noparse]:)[/noparse]
So then the Atari font will work for a first pass. Easy fix is to double it, then invert it. (96 character deal)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 9/20/2009 1:26:06 PM GMT
"-lnram" s/be "_lnram"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
The way this thing is built right now, it is possible to just run each cog on it's own to see capability. If both the text cog and color cog are commented out, some simple test color bars are seen. Uncomment the color code, and the color cells can be seen. Uncomment the text cog and the characters can be seen. I was testing and ended up quite pleased at this behavior.
I like this and am going to do a bit of cleanup so that is always possible and easily understood going forward.
Two color text then would just be a two cog affair. Nice. Just don't run the color cog.
Once the core 80 column, single character 16 color palette color cell is done, other COG functions can then be written. That is where PAL, VGA (probably somebody besides me as I rarely can test VGA), mouse pointer will happen. An example of this would then be three cogs needed for 2 color text with a colored mouse pointer.
Off to work now...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
IMHO, if that can be done, that can be a special plug-in kind of COG, where the higher clock is needed. I've a xtal or two and plan on running at 100Mhz on a Demo board at some point in the future. Final packaging will be the three cogs, then extra variants for this and that special case. A graphics COG would make sense under the same arrangement.
Thanks again for the mind share. [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
A question... In the loop I modified, 4 character bytes are read, but there are 2 longs written, meaning 16 bits of line scan for each byte. Can you please explain why it is not 8 bits for the text? I am obviously missing something basic here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
A year or so ago, when I tried this, I was using one bit per pixel mode and was able to get high character densities in a single cog. Color cut down on that some, but still it performed very well. The problems were poor NTSC signal generation. Really, that was a game quality signal, not a text quality one. This put PAL conversion off the table, and limited the color character density to below 40 characters per line. AiGeneric came out of that and is a compromise all around, and is being used on a fair number of projects.
From that effort, I've seen the following needs:
1. Mouse pointer / Sprite capability.
2. Multi-color characters for games and more detailed GUI efforts.
3. Higher character densities. 80 columns is where a lot of people want to be.
4. Better color signal and control.
5. Frugal HUB run time memory foot print.
What I didn't know about the 80 was whether or not newer display devices were capable of rendering it with enough fidelity to be useful. Given what I've seen by examining some of my consumer electronics, I suspected a good quality, interlaced color signal would do the 80. If not, there is little doubt an S-video signal would. Either way, it kind of made sense to shoot for the 80 per line, using 64 characters as a nice fall back for those projects that don't need 80, but could benefit from higher character densities and lower complexity than seen in the TV_Text driver. (those fonts are very large, making smaller text sizes challenging on TV displays)
On this pass then, I decided to build up from a 4 color mode capable video signal. Eric had produced the nice templates that really made that part easy, so I jumped on those and started building up to the text and that's where things are right now.
IMHO, it's really close. I don't see it not happening, and above all I really want a nice, serious text / graphics display that will see some use. In the list above, it was rare that people were worried about COG's. If they are, the older single COG drivers I did will do 64 two color screens in a pinch. Heck, one of them runs completely in COG, containing enough of a font table to just require a screen buffer somewhere. That's about as tiny as it gets. Serial terminals are our friends from there.
There is one other element that contributes to this and that is color re-direction. The way propeller graphics work means encoding some of the sync signals into the color space. Sync is literally one of the available colors. This is kind of cool in that we get to build the signal, but is unforgiving where building displays is concerned. Propellers get us one bit per pixel, two bits per pixel, and 8 bits per pixel where not all 8 bits are used. 16 colors, as Baggars recently just did, is a very sweet spot given the memory size of the chip.
I've gotten into trouble many times because 0 is not black! The value 2 is black and that's an annoyance.
All of this combines to make life easy for this project color wise. Just use words for color memory, adding about 1K to the HUB run time foot print, and mask those into the color memory. No worries. That would be absolute propeller colors though, where 00 is not black. Adding a CLUT (color lookup table) gets both things done. Nibbles can very easily describe color with enough bits to be very useful, and 0 can be black. Also possible then is color cycling where changing a single value impacts all display pixels drawn according to that value.
Really then, I'm not so worried about the color COG. Easy solutions exist there. It's the text one that matters. If it can do it's thing to 80 characters at 80Mhz +, life is good, because the 8 bit, single color font is the worst case. It can already happen with a 16 bit 4 color font, at the cost of more run time HUB memory being required for the table of display characters.
I'm hoping it all shakes out such that the original memory plan would work.
Assuming that's the case, the various driver COG's will read their HUB parameters during the VBLANK, update their timing and tables, then display the next video frame with those in play, just like an old graphics chip would. From there, any other program running need only write a few values to update it's screen display, with no worries other than that.
2 bits per pixel puts all 5 of the items above on the table.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
I am going to build the TV circuit on my TriBlade to test your code, hopefully today
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Here's the screen capture from the first pass, after making sure all else was correct but the new loop.
Not bad!
Here's the code, tx24 + new loop, just for reference. I'm working through this loop now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 12/13/2009 11:49:03 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Any chance you could post a complete .zip for the last file?
Thanks
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
That's quite a few instructions gone!
'Block the following into 4 characters at a time (Cluso99) 'need to verify we have the correct endian (correct byte order within the long)??? 'code is optimised (out of normal order) to ensure no wasted timeslots between hub accesses :loop4 rdlong C4, _screen 'get 4 character from screen memory rol C4, #8+3 'top byte first mov C, C4 'get it (already shifted <<3 i.e multiply x8) and C, x07F8 'remove other bits ($FF << 3) add C, _fontsum 'add font tab + scanline offset 'next 2 instructions are free due to hub access rol C4, #8 'next byte mov C1, C4 'get it (already shifted <<3 i.e multiply x8) rdbyte D, C 'get pixels from fonttab movs [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]2a, D 'modify P2 (need at least 1 instr before P2) add _screen, #4 'next block of 4 characters :P2a mov E, pixel_table 'source self modify 'and E, charcolor_mask 'color definition for character 2 'process 2nd char and C1, x07F8 'remove other bits add C1, _fontsum 'add font tab + scanline offset rdbyte D, C1 'get pixels from fonttab movs [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]2b, D 'modify P2 (need at least 1 instr before P2) 'if the pixel_table has to be reversed, why isnt it reversed in the first place??? 'REV E, #16 '\this can probably be improved to do once 'shl E, #16 '/ 'save font pixels for line ram :P2b mov E2, pixel_table 'source self modify 'and E2, charcolor_mask 'color definition for character 2 'REV E2, #16 '\this can probably be improved to do once or E, E2 '/ 'save font pixels for line ram rol C4, #8 'next byte mov C, C4 'get it (already shifted <<3 i.e multiply x8) and C, x07F8 'remove other bits wrlong E, _lnram 'put 2 sets font pixels into line ram 'process 3rd char add C, _fontsum 'add font tab + scanline offset rol C4, #8 'last byte (use in C4) (already shifted <<3 i.e multiply x8) rdbyte D, C 'get pixels from fonttab movs [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]2c, D 'modify P2 (need at least 1 instr before P2) and C4, x07F8 'remove other bits :P2c mov E, pixel_table 'source self modify 'and E, charcolor_mask 'color definition for character 2 'REV E, #16 '\this can probably be improved to do once 'process 4th char add C4, _fontsum 'add font tab + scanline offset rdbyte D, C4 'get pixels from fonttab shl E, #16 '/ 'save font pixels for line ram movs [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]2d, D 'modify P2 (need at least 1 instr before P2) add _lnram, #2 'next lineram long :P2d mov E2, pixel_table 'source self modify 'and E2, charcolor_mask 'color definition for character 2 'REV E2, #16 '\this can probably be improved to do once or E, E2 '/ 'save font pixels for line ram sub count, #4 wz 'there are 2 wasted instructions that could be done here in the hub window wrlong E, _lnram 'put 2 sets font pixels into line ram add _lnram, #4 'next lineram long if_nz jmp #:loop4 'next group of 4 chars '=============================================================It's stamping two characters in some cells, and not others. Close! Very close!
Ok, here's the archive of the current code. I've folded the new loop into the last working text cog file. Pixel table has been reversed, and I commented out the instructions not necessary to handle pixels anymore. This should then just be fetch, rotate, mask, etc....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 12/13/2009 11:49:52 AM GMT
I modifed the color cog to just write the same colors to the line ram. The text cog works to 64 characters. Still needs debugged, but it's plenty fast enough.
Sweet!
Cluso99, good code help. I think this will be fast enough. More later when I get home.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Here is the code with bugs fixed but moved for speed yet. I will post that shortly. Thought you might like something.
What do I need to do to get 80 characters?
I tried just bumping to 80 and got no display (TV can't handle it???). 64 works but very jittery. Is there some timing I need to do?? The TV is Panasonic HD CRT about 8-9 years old.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 9/22/2009 4:59:49 AM GMT
The loop (should)·takes 48 instruction times = 192 clocks @ 12.5nS = 2.4uS for 4 chars
80 / 4 * 2.4uS = 48uS which should leave plenty for the overhead, or maybe doing the color as well ????
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Here's a screen capture 80 characters @ 96Mhz. Back on track. It does 64 at 80Mhz, BTW. I've a little problem with the blank scan line routine that crept in there somehow. I'm working on that bugger right now. Once the frame is clean again, then it's time to sort out the characters.
Cluso99 -- That's a confusing loop! Guess I have to learn to think a bit differently for the best speed! At 96 Mhz, I can put at least 7 nops in the loop before things break down.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Time to merge and see what's what.
There is a problem with the blank scan line loop. Change the count to 40, and then you should see a better display.
Back in a few.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
I've attached an 80 character capture. Specs are same as before 64 characters at 80Mhz, 80 characters at 96Mhz. You will note the blue strip at the top, and the extra dark section at top left. That's sync level video and most TV's isn't going to handle this well. Capture cards are good about this. That's some bug that crept in, and is the cause of display jitters at the higher counts. Gonna have to go back a few revisions and see where that could have entered the picture. With the text cog speed proven, this is priority one.
I'm compensating to see the display by changing the count in the blank scanline routine in the text cog. Normally the count here is just number of waitvids. Back it off to 60 or so, and most displays will display, despite the sync being present in the active area. [noparse]:([/noparse]
The attached archive is set for 80 @ 96Mhz. You can set the number of characters per line to a multiple of 16 characters on slower hardware. This archive has the fixed and fast character text loop. (nice!)
Also in this archive, the color cog is mostly dead, just writing the testcolors long to the line ram each scanline. Some variation of the faster loop will do the colors, I'm sure.
I'm very likely to fix this display bug, then clean up and make sure two color text works perfectly with a stable, in-spec display.
Then move to the color cog and other options.
UPDATE: I pulled this archive. Use the one below.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 9/22/2009 6:47:19 AM GMT
The blank scan line routine was changed to do one count per waitvid, meaning the pixel buffer was written into the color buffer. It's fixed for the moment by just enlarging the pixel buffer to 80 longs.
Archive attached set for 80 chars at 96Mhz. Should display just fine.
On to cleanup and color!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 10/11/2009 10:36:27 AM GMT
rr003 has everything in sequence but this loop will take 240 clocks whereas by reordering the same instruction and utilising the nops we get 192 clocks (equivalent to 60 instructions down to 48). Original code loop was 2 x 32 = 64 instructions = 256 clocks.
How this works is...
So re-ordering can save significant time (about 20%).
Postedit: Maybe you might like to leave the code before re-ordering in but commented out for others to read·to see how it is really working.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I've just folded them into the working code, if you don't mind. Was easier to limit changes. With these things you get either something you can look at, something you have to put a scope on, or a mess! The other small mods you have in there just need a debug. The vertical one didn't work quite right. Was also easier to just focus on the text loop. Now that a stable frame is here again, the others are easy pickings. I think they are all done anyway, but for the logic related ones.
So, there may well be time for color in this cog, but it's going to have to start to build during the vertical back porch. (top border) Some changes in the simple display logic are needed for this to happen.
IMHO, it's worth a shot to pack it into this COG, for a two cog, text only solution. I'm going to think on that for just a bit. Given 8 scans, there is very likely time. Might cost an additional color buffer foot print though.
So, here's are the color choice(s):
The original color scheme called for a color palette table in the HUB. 16 values. It gets copied to the cog doing color each VBLANK. Other programs can put values there and see changes the next frame. (smallest memory foot print, greatest instruction cost)
One color byte then has two color nibbles. Lower nibble = background color, upper nibble = character color. Take the nibble, index to the color table, then mask that color found in the table, into the color RAM area. That's really it for the color done that way.
The easier choice, if it all goes in one COG, is to just use a word for color. Each byte gets dropped into the color RAM long. LSB = background, MSB = foreground. (moderate memory foot print, still high instruction cost) The way things are right now, the other color values can be ignored. Nothing displays them.
The easiest choice is to just use longs for the color. They get copied into the line ram directly. (large foot print, very low instruction cost) Easy cheezy on this one.
Two color text will be an option anyway, for where color doesn't matter a whole lot.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Bed time here. Catch you tomorrow.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!