Last visit was: Fri Sep 17, 2021 9:51 pm
It is currently Fri Sep 17, 2021 9:51 pm



 [ 138 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10  Next
 FISA64 - 
Author Message

Joined: Fri May 08, 2015 6:22 pm
Posts: 61
robfinch wrote:
Quote:
An interesting feature for a bitmap controller could be to have the ability of applying different scaling attributes to different rectangular sections of the screen. It would be nice for applications such as font and bitmap editing, retro system and arcade emulators, etc. It would both simplify the application code and provide more memory bandwidth when drawing low res areas or the screen. It would however complicate the linebuffer by needing to track if the scaling on a line has changed from the last.

One way to implement it would be to have multiple bitmap controllers, which store the bitmap in their own private block RAM. This would keep the buffering simple. Assuming secondary bitmaps are low res it might not take up that much block ram. 32X32 cell bitmap to edit a bitmap font for instance takes only 1024 words of block RAM. The control logic for a bitmap controller isn't that large so having several controllers probably isn't a problem.

I finally got the roto-zoom code completed for the bitmap controller. But it doesn't work that well (it's buggy yet). The first test, displaying the screen at a rotation of zero degrees, caused the screen display to drop about 50 scanlines downwards for some reason. An screen garbage was present along the left side of the screen. Rather than debug the code I'm going to leave the rorozoom code in as a `ifdef block and leave the debugging for another day.
I was thinking along the lines of a single bitmap controller with a limmited scaler (/2, /4, /8) where it re-uses the pixel data (for X) or section of the linebuffer (for Y) rather than fetching new data from ram. This is very similar to your original scaller, but with with midscanline modechange ability. I'll have a play with this idea once I get some ram up and running. I've connected 2MB of 10ns SRAM (CY7C1061AV33) to the FPGA though only tested reading at this point (displayed the non-initialized RAM pattern to screen). I'll have another play with rotozoom, though I suspect it will be easier on the SRAM. I guess the 'R' in RAM isn't as random as it once was ;)

Quote:
Quote:
What about sprites, scalable roto-sprites could be a very cool idea, saving lots of spritemap data (or lots of sprite rotation and scale code). I wonder how hard it would be to give sprites a forward, back, left, right motion control based on angle of rotation as opposed to the usual absolute possitioning.

It would probably be a lot of logic to have scalable roto-sprites implemented to work in real-time. All those multiplies and sin lookups would have to be done for each sprite. The spritecontroller as it is, allows for multiple images to be fed into the sprite's buffer. Which can then be accessed by updating an image pointer. The idea was to allow some simple animations to be performed simply by changing the image pointer. The multiple sprite images stored could be a single image which is precalculated to different rotations. As for the sprite positioning maybe a processor instruction that supports the movement along an angle could be used. Fed into the instruction would be distance and angle of motion and output would be dx, and dy. This is really almost a polar to Cartesian co-ordinate translation instruction.


I have a few ideas I'm going to toy with along the lines of sprites, half of which are likely a bit crazy and include adding a bit of intelligence to the sprite controller etc. I'll see how I go and post anything interesting that comes of it.


Sat May 16, 2015 4:36 am

Joined: Fri May 08, 2015 6:22 pm
Posts: 61
robfinch wrote:
Quote:
What's your plan for circles?

No plan. I was wondering about that and other shapes not supported by orgfx. It is possible to draw Bezier curves with orgfx. I think by combining two curves properly one could draw a circle. I'd also like to be able to draw arbitrary polygons, I have a piece of software code to draw filled polygons, and have been studying what it would take to do in hardware.
Circles can be calculated with a couple multipliers if you have some spare, and good old pythagoras theorem.
Pretty sure I can optimize this for RAM usage, currently though it tests every pixel in the plot range. At least it should be nice and linear for ram.

Example from the vid I posted earlier. The XOR's were just a quick hack for the quadrant detection, there are better ways :)
Code:
         -- Draw ring on native pixel plane
         pixelv := vcount - 000;
         pixelh := hcount - 000;
         IF pixelv >= 0 AND pixelv <= 511 AND pixelh >= 0 AND pixelh <= 511 THEN
            xytemp1 := NOT pixelh(7 DOWNTO 0) XOR pixelh(8)&pixelh(8)&pixelh(8)&pixelh(8)&pixelh(8)&pixelh(8)&pixelh(8)&pixelh(8);
            xytemp2 := NOT pixelv(7 DOWNTO 0) XOR pixelv(8)&pixelv(8)&pixelv(8)&pixelv(8)&pixelv(8)&pixelv(8)&pixelv(8)&pixelv(8);
            radius := (xytemp1 * xytemp1 / 256) + (xytemp2 * xytemp2 / 256);
            IF radius >= 52 AND radius <= 62 THEN
               Pixel_Colour <= "011111111101110000001111111111";
            END IF;
         END IF;

Quote:
With a development board with 12 bit RGB output is it possible to output more than 4096 colors ? I think that maybe the least significant bit of each color component could be pulse-width modulated at high frequency to generate an additional bit(s). PWM can't be applied to more significant bits as it would result in repeated bit values, but the LSB could be modulated.
The pixel clock in use is about 42 MHz. Using a 4x or more clock (168MHz) a pulse stream could be sent on the LSB for each desired color. '1111' would be full on, '0000' would be full off. But one could also send '1010' 1/2 power or '1000' 1/4 power or '1110' 3/4 power for the LSB. Using fractional amounts of power an additional bit could be generated.
The problem with this approach is relying on the DAC's R's and C's time constant to generate fractional signal levels. The time constant may make the required frequency too high to be practical. On the other hand the development board could be modified to support it.


This sounds a bit tricky but could work depending on the DAC. Is there a means of connecting a better DAC to the devboard.
At first glance I thought you were talking about sending tricky subpixel timing to the ADC in the display itself, I think Ed's post indicates he may have made the same interpretation.


Sat May 16, 2015 6:42 am

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1632
Oops, yes, I miscounted there. The DAC outputs are 4 bits per channel, and some LCDs at least have a 6 bit or even 8 bit ADC on the input. So with a suitable time constant it's possible that the monitor will sample the dithered output as intended.


Sat May 16, 2015 9:10 am

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1482
Location: Canada
To increase the number of bits per color something along the lines of the following which uses a 7x dot clock frequency for subpixel timing might work. The code is for one color component (red), all three components would be handled the same way.
Code:
module ColorCvt6to4(rst,clk7x,ri,ro);
input rst;
input clk7x;
input [5:0] ri;
output reg [3:0] ro;

reg [6:0] power17,power27,power37,power47,power57,power67;
always @(posedge clk7x)
if (rst) begin
   power17 <= 7'b0001000;
   power27 <= 7'b0100010;
   power37 <= 7'b1010100;
   power47 <= 7'b1010101;
   power57 <= 7'b1101011;
   power67 <= 7'b1110111;
end
else begin
   power17 <= {power17[5:0],power17[6]};
   power27 <= {power27[5:0],power27[6]};
   power37 <= {power37[5:0],power37[6]};
   power47 <= {power47[5:0],power47[6]};
   power57 <= {power57[5:0],power57[6]};
   power67 <= {power67[5:0],power67[6]};
end


always @(posedge clk7x)
   ro[3:1] <= ri[5:3];
always @(posedge clk7x)
case(ri[2:0])
3'b000:   ro[0] <= 1'b0;
3'b001: ro[0] <= power17[6];
3'b010: ro[0] <= power27[6];
3'b011:   ro[0] <= power37[6];
3'b100:   ro[0] <= power47[6];
3'b101:   ro[0] <= power57[6];
3'b110:   ro[0] <= power67[6];
3'b111:   ro[0] <= 1'b1;
endcase

endmodule


Two "extra" bits would be processed by this code.
The bandwidth of the DAC is pretty high as pixels are displayed nice and sharp at 85MHz. The DAC uses a 4k resistor for the LSB, so assuming 1pf of stray capacitance (a guess), the RC time constant works out to about 250MHz. Anyway the output may end up dithered. I was planning on about a 300MHz clock but I don't know if the logic would be fast enough.

_________________
Robert Finch http://www.finitron.ca


Sat May 16, 2015 2:01 pm WWW

Joined: Fri May 08, 2015 6:22 pm
Posts: 61
For some reason I made the assumption that you were dealing with a real digital DAC rather than a handfull of resistors, and then I checked the Nexys 4 DDR schematic ;)
Wouldn't it be much easier to just add three new resistors to the current resistor DAC? You don't actually need to modify the board.

You could use a male and female VGA connector soldered back to back, from this you can break out the three RGB lines and run them to a PMOD header via 8.2K resistors, PMOD pins becoming your new LSB. Add some 16Ks as well for 18bits.


Sat May 16, 2015 4:48 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1482
Location: Canada
Quote:
Wouldn't it be much easier to just add three new resistors to the current resistor DAC? You don't actually need to modify the board.

It's easier to understand, but not necessarily easier to do. Of course it might actually work better with real R's too. I had thought of doing something similar, and have added R's to an RDAC before. I would prefer to wire directly to the board, keeping the R's close to the connector and leads short. If I were to do both adding R's and adding logic perhaps 24 bit color could be achieved.
One thing to watch out for when adding R's is the resistor precision. Each added R needs to be at least twice as precise as the one after it or there's no point to adding the resistor. The resistors may need to be carefully hand-picked.

_________________
Robert Finch http://www.finitron.ca


Sun May 17, 2015 2:24 am WWW

Joined: Fri May 08, 2015 6:22 pm
Posts: 61
Both methods have a bunch of 'fun' variables to deal with, though maniplating the clock at the sub-pixel level while relying on the inherent RC characteristics of the board design for a charge level seems like it involes a little more, ummm, 'fun'.
What are the jitter characteristics like with the Artix-7, and is it likely to cause any trouble with this method?
It's interesting and I'm curious to see how well it works.

I have the opposite problem at the moment, 30bits of colour information, and, now that I have the SRAM online, only a 16bit datapath.

I took the design from the video I posted in an earlier post and ported it to RAM just as a quick test and it works okay, though converting down to 16bit colour for storage is not so pretty.
I'm still using basically the same code as in the vid so the plotting is still all math based, but draws to RAM rather than the screen, on the next cycle I output that same pixel from RAM to the screen.


Sun May 17, 2015 8:02 am

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1482
Location: Canada
Quote:
Both methods have a bunch of 'fun' variables to deal with, though maniplating the clock at the sub-pixel level

I got around to trying the code out and it seems to work. The code is using a 350MHz subpixel clock. There's just a faint hint of "stripe-ing" if one looks up close. I'm trying to get a demo working that displays gradieated color rectangles to make it easier to see the results of the code but the FPGA board isn't co-operating. The board hangs after blanking out the screen.
Quote:
What are the jitter characteristics like with the Artix-7, and is it likely to cause any trouble with this method?

I think the jitter is fairly low as a PLL is in use to generate the clock, and all the clocks in the system originate from the same 100MHz crystal osc. I don't think the jitter is noticeable in the output.
Quote:
I took the design from the video I posted in an earlier post and ported it to RAM just as a quick test and it works okay, though converting down to 16bit colour for storage is not so pretty.
I'm still using basically the same code as in the vid so the plotting is still all math based, but draws to RAM rather than the screen, on the next cycle I output that same pixel from RAM to the screen.

With 10ns SRAM it would be difficult to both store and retrieve the color information. What pixel clock rate is in use ? I had to switch mine to 50MHz due to other system constraints (too many different clocks). But my system uses internal block RAM for display now so I can get by with faster clocks.

_________________
Robert Finch http://www.finitron.ca


Sun May 17, 2015 4:36 pm WWW

Joined: Fri May 08, 2015 6:22 pm
Posts: 61
robfinch wrote:
Quote:
I took the design from the video I posted in an earlier post and ported it to RAM just as a quick test and it works okay, though converting down to 16bit colour for storage is not so pretty.
I'm still using basically the same code as in the vid so the plotting is still all math based, but draws to RAM rather than the screen, on the next cycle I output that same pixel from RAM to the screen.

With 10ns SRAM it would be difficult to both store and retrieve the color information. What pixel clock rate is in use ? I had to switch mine to 50MHz due to other system constraints (too many different clocks). But my system uses internal block RAM for display now so I can get by with faster clocks.


I'm being extremely rude with the SRAM, it's just a quick hack to see if I could read and write, without much thought put into a controller at all. For some reason the SRAM is playing along.
The ram is running at 100MHz in continuous back to back RW cycles. Pixel clock is 50 MHz.

I'll need to work on a proper controller, but even as is, it allows me to play with various (more standard) graphics algorythms that require RAM.

I implemented a switch that turns off the writes, a good way to make sure that what I'm seeing onscreen is actually from the RAM.
The image is shifted a couple pixels to the right, but is otherwise intact and of course becomes static (non animated) as the RAM is no longer being updated. Here is what I see.
http://i.imgur.com/E6EMj2Z.jpg


Mon May 18, 2015 5:42 am

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1482
Location: Canada
Quote:
I got around to trying the code out and it seems to work.

I got around to displaying a color bar test and.... what seemed to work doesn't work. :oops: For some reason I don't understand yet the number of colors available is actually reduced. It's almost as if the LSB's are stuck at a one or zero. But I can't see anything wrong with the code. The simpler idea of just using more R's in the RDAC is probably a better solution.

_________________
Robert Finch http://www.finitron.ca


Mon May 18, 2015 1:14 pm WWW

Joined: Fri May 08, 2015 6:22 pm
Posts: 61
robfinch wrote:
Quote:
I got around to trying the code out and it seems to work.

I got around to displaying a color bar test and.... what seemed to work doesn't work. :oops: For some reason I don't understand yet the number of colors available is actually reduced. It's almost as if the LSB's are stuck at a one or zero. But I can't see anything wrong with the code. The simpler idea of just using more R's in the RDAC is probably a better solution.


Just thinking, won't the charge level of your pattern vary depending on the last pattern.
A 1010 pattern directly after a 1111 pattern will have a different level to a 1010 pattern after a 0000 pattern.
I think you're being clobbered by the DC offset of the previous pattern.
Rather than patterns, think of it as a serial stream on the LSB at quad pixel rate.

I found some interesting videos along the lines of what you're working on. No real info but ΔΣ is key.
https://www.youtube.com/user/e8root/videos

Some simple ΔΣ code can be found at fpga4fun.com
http://www.fpga4fun.com/PWM_DAC.html


Another option might be temporal dithering similar to what's used in some cheaper LCDs.
This is just a case of alternating between colourvalue and colourvalue-1on alternating frames. There will be a flicker at half the refresh rate but in higher refresh modes shouldn't be perceivable.


Mon May 18, 2015 4:07 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1482
Location: Canada
Quote:
Another option might be temporal dithering similar to what's used in some cheaper LCDs.

I may try dithering the output instead. I half expected the circuit to produce a dithered output given the high bandwidth DAC.

I started working on a Bit-Blitter component. It copies a rectangular region from a source bitmap to a destination bitmap excluding pixels that match the transparent color.
It works a pixel at a time. The blitter currently handles up to 64 region copies from up to 16 source bitmaps to a single target bitmap. I've been trying to find information on blitter components on the web in particular capabilities and registers sets. There are a zillion sites that have non-specific information.

_________________
Robert Finch http://www.finitron.ca


Wed May 20, 2015 11:53 am WWW

Joined: Fri May 08, 2015 6:22 pm
Posts: 61
robfinch wrote:
Quote:
Another option might be temporal dithering similar to what's used in some cheaper LCDs.

I may try dithering the output instead. I half expected the circuit to produce a dithered output given the high bandwidth DAC.

I started working on a Bit-Blitter component. It copies a rectangular region from a source bitmap to a destination bitmap excluding pixels that match the transparent color.
It works a pixel at a time. The blitter currently handles up to 64 region copies from up to 16 source bitmaps to a single target bitmap. I've been trying to find information on blitter components on the web in particular capabilities and registers sets. There are a zillion sites that have non-specific information.


The Amiga had a nice full featured Blitter and is the only one I personally played with, lots of info in the Amiga Hardware Reference Manual.
Blitter information starts at scanned page 163 (pdf page 171).
http://ada.evergreen.edu/~tc_nik/files/ ... Manual.pdf

Atari came along with a Blitter for the later ST models. There is a manual here (second link is text version, easier on the eyes).
http://dev-docs.atariforge.org/files/BL ... 7-1987.pdf
http://mikro.naprvyraz.sk/docs/ST_E/BLITTER.TXT

A bit more on the Atari Blitter.
http://paradox.atari.org/files/BLIT_FAQ.TXT

Something a bit more modern - Intel HD Graphics - Blitter Engine
http://www.x.org/docs/intel/HD/IHD_OS_V ... t5_BJS.pdf


Wed May 20, 2015 1:56 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1482
Location: Canada
So okay, I got a start on a blitter component after reading a little bit about Amiga, Atari and Intel blitters.
I plan to support a multiply raster operation to allow brightening or darkening an area. I haven't figured out yet exactly how it will work.
To get the blitter to work, a number of registers will need to be setup, then commands issued to a command port.
The following outlines how the blitter is working:

Code:
// General:
// The blitter image and bitmap registers must be setup, then the blitter
// will accept commands to be performed between images. The status register
// must be polled to determine when the blitter is finished an operation.
//
// The blitter command format is:
// | opcode2 | opcode1 | target,source1,source2 |
// |    6    |    6    |   6       6       6    |
//
// opcode 1 is applied between target and source1
// opcode 2 is applied to the result of opcode 1 and source 2
//
// opcode
// abrrrr
// ||++++ = raster operation
// |+---- = 1 = invert b operand
// +----- = 1 = invert a operand
//
// Raster operations
//
// rrrr
// 0000 all zereo's
// 0001 A
// 0010 B
// 0011 A AND B
// 0100 A OR B
// 0101 A XOR B
// 0110 A ADD B
// 0111 A SUB B
// 1000 A MUL B
// 1111 all ones
//
// Image Descriptors
// - Normally there are numerous images associated with an application.
// - The blitter allows for 64 image descriptors to be registered at once.
// - The most time critical images may be resident others will have to be
//   swapped with memory.
//
// Regno
// 0x000   [12: 0] image x position within bitmap
//         [28:16] image y position within bitmap
// 0x004   [12: 0] image width in pixels
//         [28:16] image height in pixels
// 0x008   [31: 0] reserved
// 0x00C   [ 3: 0] image bitmap descriptor index
//         [ 9: 8] image corner
//         [16:16] pattern indicator
//
// 0x010 to 0x3FC   repeat of 0x000 to 0x00C for 63 more images
//
// Bitmap Desciptors
// - Bitmap descriptors describe the size and location of the bitmap in memory
// - Usually multiple images are stored in a bitmap and there may be multiple
//   bitmaps associated with an application.
// - The blitter stores descriptor information for up to 16 bitmaps.
// - There is usually a single target bitmap from which the display is rendered.
//
// Regno
// 0x800   [12: 0] bitmap width
//         [28:16] bitmap height
// 0x804   [31: 0] bitmap base address
// 0x808   [ 3: 0] bitmap color depth
//
// 0x810 to 0x8FC
//         Same as 0x800-0x80C but for 15 more bitmap descriptors
//
// GLobal Registers
// 0xF00   [31: 0] command reg
// 0xF10   [31: 0] status reg
//
// Image Corner:
// - Determines which corner of the image to begin the transfer at. Useful when
//   source and destination images overlap.
//
// Pattern Indicator:
// - Indicates that the image is a pattern to be used to fill an area. In the
//   case of a pattern the pattern size may be smaller than the target fill
//   area. Indexes into the pattern will wrap around so that the pattern repeats
//   in the target fill area.
//
// 3200 LUTs (5120 LC's)
//


Current source code can be found at: http://github.com/robfinch/Cores/blob/master/video/trunk/rtl/verilog/rtfBlitter.v

_________________
Robert Finch http://www.finitron.ca


Thu May 21, 2015 1:57 pm WWW

Joined: Tue Dec 11, 2012 8:03 am
Posts: 285
Location: California
Make sure you take a look at Samuel Falvo's (kc5tja on 6502.org) article on blitter theory at http://6502org.wikidot.com/blitter-theory-part-1 .

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Thu May 21, 2015 6:12 pm WWW
 [ 138 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10  Next

Who is online

Users browsing this forum: AhrefsBot, CCBot and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software