Agreed. This would be good to change. Pixel output order is backward. And making low bit rate bitmaps in linear order is something people will do a lot of. It's just frugal use of RAM.
If you want more birds, you have to go widescreen
Here's WVGA (852x480):
(it shimmers a little tiny bit, probably due to the pixel clock not being even divisor of 50 MHz clock)
Rayman, change the XCONT that initiates the hsync pulse to XZERO. That will cause each line to be output with each pixel having a constant NCO value (i.e. pixel 100 will always have the same NCO value and, therefore, the same time offset on the scan line. That should take care of the shimmer.
So, for RDLONG lookup modes, 1/2/4-bpp, the byte order is correct, but the bit groups come out backwards? I agree that this should be straightened out. Did I characterize the problem properly?
So, for RDLONG lookup modes, 1/2/4-bpp, the byte order is correct, but the bit groups come out backwards? I agree that this should be straightened out. Did I characterize the problem properly?
Great. That'll be best for me, unless there's some reason not to change the bit/nibble order.
Be interesting to see if 2-bit color comes out right...
I guess this doesn't need immediate fixing, since it can be rectified with the added code for now...
Rayman, to get this resolved most efficiently, could you tell me what board you are using? I don't want to make files for every board until I know we've got it fixed. Thanks.
Rayman, change the XCONT that initiates the hsync pulse to XZERO. That will cause each line to be output with each pixel having a constant NCO value (i.e. pixel 100 will always have the same NCO value and, therefore, the same time offset on the scan line. That should take care of the shimmer.
You're right! That fixed it. WVGA mode (852x480) is rock solid now.
One thing that will be a little peculiar about this bit-order change: 'RFLONG LUT' data will be read from hub as if a stream of bytes, with 1/2/4-bit pixel groups read from the top down in each byte. On the other hand, when you do an 'immediate LUT', pixel groups will be read from the top down in the long.
Chip, I think that is right. Once the longs are end to end, shouldn't it be a linear stream?
This chip, being a 32-bit machine, should probably treat those 1/2/4/8-bit fields as being parts of a long, not bytes. That would match up with 'immediate LUT', too. It's a bit of a pain when you are outputting, say, 8-pixel 1bpp character slices, and you need to MSB-justify the data before sending it out. That seems wrong. If we maintain low-bits-first for LUT modes, you can do things like RDBYTE+XCONT more efficiently.
Does it have to be one way or the other? Can it be a setting?
I think it's pretty powerful to use 1-bit bitmaps as is, without reformatting. Lets you define a font as a bitmap image...
Yes, being able to easily handle standard image files nicely allows many things.
Not just fonts, but image backgrounds, 'skins' and even colour blends etc become simple to create & render.
Re 2bpp - can Photoshop create that ?
If other formats suggest an ordering, then that one should 'slot into'; the same thinking.
Does it have to be one way or the other? Can it be a setting?
I think it's pretty powerful to use 1-bit bitmaps as is, without reformatting. Lets you define a font as a bitmap image...
Do you mean we treat hub memory as a string of bytes for this purpose, and then read each bit (field) from top to bottom, in each byte? Or should it be top to bottom at the long level? Then there's the fact that sometimes you want to stream out from the bottom bits.
We could use the unused S/# operand to select bit orders for RFLUT modes. We need to determine what the needed options are.
Maybe I don't understand, but I think the byte order is fine w.r.t. Bmp format. It's the nibble order in 4 bit mode and bit order in 1 bit mode that are backwards.
Also, I think it should be the same with or without lut
We just need to fix the bit order for the 1/2/4-bpp RFLONG LUT modes. I got it. This can all be done when the RFLONG data is loaded into the transfer unit. The rest stays the same.
When doing the 1/2/4-bpp RFLONG LUT modes, try using #1 for S/# on the XINIT/XCONT/XZERO instructions. #1 will re-order the bitfields. #0 will keep them as they've been.
Comments
Little Endian's backwardness strikes yet again.
Rayman, change the XCONT that initiates the hsync pulse to XZERO. That will cause each line to be output with each pixel having a constant NCO value (i.e. pixel 100 will always have the same NCO value and, therefore, the same time offset on the scan line. That should take care of the shimmer.
It doesn't come out wrong because there are always several XCONTs that make a scanline.
If the fix is in, my 8x8 driver should deliver mirror image characters, and the font reverse routine at the beginning can be commented out.
Or Rayman's 2 color bitmap won't need whatever REV instruction it's got to sort the image out.
Super! I'll get this fixed.
Be interesting to see if 2-bit color comes out right...
I guess this doesn't need immediate fixing, since it can be rectified with the added code for now...
True, but the benefit of fixing it now, is it can be tested now, and anything it breaks can be found.
It does not sound like a complex fix.
Rayman, to get this resolved most efficiently, could you tell me what board you are using? I don't want to make files for every board until I know we've got it fixed. Thanks.
Potatohead, what board are you using? I recall a DE2-115.
You're right! That fixed it. WVGA mode (852x480) is rock solid now.
Guess I'll have to programmatically create a data file...
I suppose in this case it doesn't really matter which way the bits are shifted, since there's no target media anyway...
This chip, being a 32-bit machine, should probably treat those 1/2/4/8-bit fields as being parts of a long, not bytes. That would match up with 'immediate LUT', too. It's a bit of a pain when you are outputting, say, 8-pixel 1bpp character slices, and you need to MSB-justify the data before sending it out. That seems wrong. If we maintain low-bits-first for LUT modes, you can do things like RDBYTE+XCONT more efficiently.
What should we do?
I think it's pretty powerful to use 1-bit bitmaps as is, without reformatting. Lets you define a font as a bitmap image...
Not just fonts, but image backgrounds, 'skins' and even colour blends etc become simple to create & render.
Re 2bpp - can Photoshop create that ?
If other formats suggest an ordering, then that one should 'slot into'; the same thinking.
Do you mean we treat hub memory as a string of bytes for this purpose, and then read each bit (field) from top to bottom, in each byte? Or should it be top to bottom at the long level? Then there's the fact that sometimes you want to stream out from the bottom bits.
We could use the unused S/# operand to select bit orders for RFLUT modes. We need to determine what the needed options are.
1) byte-level endian swap on RFLONG input - this makes data byte-ordered
2) bitfield-level endian swap - this reorders the bitfields within the bytes
Thinking about it, I don't think anyone would want one without the other. Maybe these could be made together, as a single option?
Also, I think it should be the same with or without lut
Wait... Maybe I'm not sure about that last part
We just need to fix the bit order for the 1/2/4-bpp RFLONG LUT modes. I got it. This can all be done when the RFLONG data is loaded into the transfer unit. The rest stays the same.
Try this file on your -A7 board:
https://drive.google.com/file/d/0B9NbgkdrupkHemFrNlE5UWc0MkU/view?usp=sharing
When doing the 1/2/4-bpp RFLONG LUT modes, try using #1 for S/# on the XINIT/XCONT/XZERO instructions. #1 will re-order the bitfields. #0 will keep them as they've been.
Same for 1bpp mode. I don't have a quick way to test 2bpp mode...
Okay. So, it works as you'd like it to, but you haven't been able to test the 2bpp mode.
Here is a DE2-115 file that has the new bitfield reordering:
https://drive.google.com/file/d/0B9NbgkdrupkHZ240VVhEZ1ltRHM/view?usp=sharing
It's just two cogs.