View unanswered posts | View active topics It is currently Fri Mar 29, 2024 9:42 am



Reply to topic  [ 74 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
 Sprite / Cursor Controllers 
Author Message

Joined: Fri May 08, 2015 6:22 pm
Posts: 61
I think I was looking at the wrong point in my code, so my post above is probably a red herring and can be deleted.

robfinch wrote:
I have it almost working after only a few hours of play. It displays characters on-screen but they are flipped horizontally.

I'm not sure if this is relevant to your design, but if your char generator is using the lowest 3 bits of the horizontal counter, you can XOR those bits with "111".

Excuse the VHDL notation.

You may have something like:
hcount(2 DOWNTO 0)

Flip things the right way around with:
hcount(2 DOWNTO 0) XOR "111"


Sun Nov 26, 2017 5:36 am
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Thanks, I got it to work. I eventually switched the code to a simple shift register.
Code (68k assembler) like the following now works to display a character on-screen:
Code:
;------------------------------------------------------------------------------
; Parameters:
;   d0.w      character to display
;   d1.w      x position
;   d2.w      y position
; Trashes:
;   a6
;------------------------------------------------------------------------------

DispCharAt:
      move.l   #VDGREG,a6
      swap   d0                  ; save off d0 low
.0001:                           ; wait for character que to empty
      move.w   0x42A(a6),d0         ; read character queue index into d0
      cmp.w   #28,d0               ; allow up 28 entries to be in progress
      bhs.s           .0001               ; branch if too many chars queued
      swap   d0                  ; get back d0 low
      move.w   d0,0x420(a6)         ; set char code
      move.w   fgcolor,0x422(a6)      ; set fg color
      move.w   bkcolor,0x424(a6)      ; set bk color
      move.w   d1,0x426(a6)         ; set x pos
      move.w   d2,0x428(a6)         ; set y pos
      move.w   #0,0x42E(a6)         ; pulse character queue write signal
      rts

It sure beats the number of cycles, code complexity, for copying a bitmap to the screen.

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


Sun Nov 26, 2017 4:24 pm
Profile WWW

Joined: Fri May 08, 2015 6:22 pm
Posts: 61
That's a nice simple interface for text blits, I recall the Amiga blitter being that complex to set up that small copies such as text chars were quicker to do with the CPU, particularly if the CPU had been upgraded.
String output could be accelerated a bit if the x and y position registers were able to auto update to the next char pos.


Sun Nov 26, 2017 6:25 pm
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Quote:
String output could be accelerated a bit if the x and y position registers were able to auto update to the next char pos.

Hey, I hadn't thought of that. It should be possible to do for the next set of changes. I made the font size programmable so it should just be a matter of adding the font size register to the current position.

I must have larger fonts ! The 8x8 font is barely readable on the display. I like to be able to see descenders in the font. The display controller was modified to handle more font sizes besides just 8x8. The width and height of the font is now programmable up to 16x16, but the display memory currently only support 10 bits. So the font width is limited to 10 bits. Font size can also be reduced if desired. Smaller fonts write the screen faster than larger ones. For an 8x8 char it takes about 224 clock cycles. (averages about 4 clock per pixel). It’s still significantly faster than software.
I’ve made several small modifications to the test system and now it doesn’t work :( Software wise the inline code which didn’t previously use any ram has been turned into subroutines. Hardware wise a scratchpad memory was added so that the dram doesn’t have to be used exclusively. Suspected are problems with the dram. Also added were a multi-stream prng and keyboard interface. The increased size of the system may have introduced timing bugs. Updates for the display and status leds aren't proper, but I can see the address bus incrementing so the cpu is running something.

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


Mon Nov 27, 2017 3:19 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
It’s just a few more states :) The character draw queue turned into a command queue this morning. The controller now offers pixel plot acceleration in addition to bitmap font acceleration and blit drawing. The fields required for pixel plot info were already present for char info (x,y coord and color), it was simply a matter of adding a command number register. I hope to add line draw acceleration next, it’s just a couple of more registers.
The font size for characters can be specified on a character by character basis which should allow for variable pitch fonts. The font still has to be stored in the controller’s memory as if it were fixed pitch.

I got hung up on the infamous ‘combination loop’ error. It took me a most of a day to find the error. I left out a ‘posedge’ specification at one point in clocked logic.
Back in business with the system now almost working :) It spits out a visible startup message again. This time using subroutine calls (ram memory).

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


Mon Nov 27, 2017 1:03 pm
Profile WWW

Joined: Fri May 08, 2015 6:22 pm
Posts: 61
robfinch wrote:
I hope to add line draw acceleration next, it’s just a couple of more registers.

Both the DDA and Bresenham's line drawing algorithms have related circle drawing algorithms.
Filled polygons also become easy once you have line drawing.


robfinch wrote:
The font size for characters can be specified on a character by character basis which should allow for variable pitch fonts. The font still has to be stored in the controller’s memory as if it were fixed pitch.

This gives you all you need for simple kerning.


Mon Nov 27, 2017 2:27 pm
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Added a simple hardware cursor to the core after looking at doing it with software and yikes! The hardware cursor is a 16x16 bitmap of a single color (or inverted screen color). It can flash at one of three different rates, or not flash at all. Since I’ve now effectively added one old style sprite, additional old style sprite support may be added.

Designing the controller is tricky. It can’t work efficiently switching DMA access on a cycle-by-cycle basis because the block ram in the FPGA needs to be pipelined for best performance. This is unlike the DMA occurring on a cycle-by-cycle basis in the Amiga. I started working on this project after some frustration trying to get minimig to work on the FPGA board.

Some of the Amiga style blitter functionality was added to the core. The core now supports four DMA channels like the Amiga (three read, one write). In order to make the best use of the block ram access is pipelined to hide a two cycle read latency. So 16 pixels are fetched for each active channel before any updates to the ram are started, which also occur in bursts of 16 pixels. It takes an estimated 80 clock cycles to process 16 pixels (with four active channels). The controller goes back and checks for other operations while it’s performing a blit.

I’m not sure how useful the copper code is for the Amiga, but I’ve been thinking of trying to add a similar feature to this core. One problem is the display memory is only 10 bit wide. A solution is to provide a dedicated copper memory. It could be made as wide as the copper instruction set (about 42 bits) to improve performance. I’m left wondering how big copper programs are. I can’t imagine them being significant in size since they are driven on video display positions. So a few kbytes of dedicated memory might work.

The system is able to run a small monitor program now. Software was copied from a previous 68000 based system.

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


Tue Nov 28, 2017 3:18 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Added line drawing to the controller. It drew the test lines so fast I didn’t get a chance to see them drawing. The delay in the monitor’s display masked the drawing operation. By the time the monitor adjusted to the video format (800x600) the display was already drawn. So I changed the program to draw many more lines. The controller draws lines at a rate of 20 million pixels per second. Using Bresenham’s algorithm. It pauses the line drawing periodically (every 16 pixels) in order to allow the cpu to access memory, so that the cpu doesn’t become stalled waiting for a line draw to finish. Line draw commands go into a command queue.

I haven’t tested blitter operation yet. I just wrote the first test program to copy part of the screen to another area on the screen. The blitter supports separate image widths for both the source and destination. This allows a rectangular region to be copied to a linear region or the other way around. All the blitter cares about is having the same number of pixels to copy.

I write while waiting for system builds.

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


Wed Nov 29, 2017 2:58 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Late night, but I think blitting may be working. It’s possible to use the blitter to draw lines and fill areas of memory using the destination channel D by itself. I also got it to copy a portion of the screen over to another part of the screen using a source channel A and D. The pipeline depth was made a controllable option in case blitting of pixels next to each other is taking place. It can be set to zero for no-pipelining, in which case performance will be adversely affected.

Added a copper processor to the controller. It works much the same way as the copper in the Amiga with a few exceptions. There are four instructions WAIT, MOVE, SKIP, and JUMP. The copper reads more instructions bits than the Amiga as it supports higher resolution comparisons to the video counters. It also supports extended compare to a frame counter so operations may take place across multiple video frames. Rather than perform jumps by writing an address register and a jump register as I the Amiga, the copper directly supports a JUMP instruction. It can also jump to subroutines and return using a linkage register.
Rather than share the bus using alternating cycles, the copper grabs the bus for about 10 clock cycles straight so that pipelined ram accesses can occur. The copper returns to the idle state after every instruction so the cpu gets a chance to use the bus. I haven’t written any copper programs yet.

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


Wed Nov 29, 2017 7:37 pm
Profile WWW

Joined: Fri May 08, 2015 6:22 pm
Posts: 61
I had an interesting idea as an extension to line drawing. Something that could be called a Liitter "Line Image Transfer", or a Blitter for lines.
A line of source data in memory, in any orientation and of any length, could be mapped (length)/ copied to a destination line in memory (display ram, or offscreen) of differing orientation and length.

Sequential line copies would give you a Blitter made of Liitters, slower than the normal Blitter, but able to do a few new tricks.


Thu Nov 30, 2017 11:03 am
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Added audio capabilities to the display controller, so I guess now it’s an audio/video controller. I should really come up with a name for the circuit. There are four channels of audio supported, but the FPGA board only supports two. The software interface to the board’s audio controller isn’t finished yet, so no sound out yet. The ADAU1761 chip seems like a powerful device.

Changes to the blitter now allow it to support tiling. The source data can be smaller than the destination in which case the source will be tiled onto the destination. Added lowres 320x256 mode to the controller so I can read the text from several feet away.

Access to the block ram was modified, allowing many wait states to be removed from the controller’s memory access states which should speed up the system considerably. The block ram is now clocked at 200MHz while the state machine in the display controller is only 40MHz. Previously the block ram was clocked at the same rate as the state machine. The change gives up to five clock cycles for the block ram to respond, so it should always have data available for the next cycle of the state machine. Even if there are some timing problems and the access is delayed a cycle or two it should still work.

It looks the like the DDR ram is working. Several system constants like the screen color or size for instance, are being stored there.

Added a real-time clock interface to the system. The real-time clock is an I2C device. The system uses the I2C master controller available at opencore.org. The audio chip also needs an I2C controller.

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


Sat Dec 02, 2017 3:08 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Added a nicer hardware interface to the blitter for drawing filled or tiled rectangles. The AV Controller can now calculate the blitter parameters based on a pair of x, y co-ordinates rather than having to set the address and width.

A small texture descriptor memory (512 entries) was added to the core. Tiling rectangles uses a handle to the texture descriptor to determine what texture to use to fill the rectangle with. This saves having to specify all the texture parameters in the tile rect operation.

The entire system is sitting at < 19,000 LUTs.

Added double-buffering to the audio DMA to get rid of jitter that occurs due to delayed DMA cycles. Unlike the Amiga, exactly when the audio DMA will occur isn’t predictable. The longest running op of the AV controller is text blitting, which could take up to 640 cycles. So it could be several hundred cycles before the audio DMA occurs. Running @40MHz and 640 max cycle delay gives a period of 40M6/640 = 62,500 Hz. This is probably okay since the audio is now double-buffered.

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


Sat Dec 02, 2017 10:56 pm
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Changed text blitting to get information from a font table rather than needing to supply font size with blit command. It’s a little more work in the software to setup a font table(s), but not too bad. Fonts up to 32 x 32 pixels are now supported. Variable pitch fonts are also supported via a glyph lookup table. The hardware reads the font table to determine where the character bitmaps are located and how big the characters are. I tried to find information on font table hardware on the web without much success. I was hoping there might be a simple standard to follow. Instead I just rolled my own.

Text output is now about 3x faster. I found a way to compress the 3 cycles per pixel down to 1 cycle per pixel output. There’s still a little bit of overhead when the scan line of the bitmap changes. I also altered the state machine to go back to the idle state after every scanline rather than just at the end of the character blit. This means character blitting no longer holds up access for 600 clock cycles. It’s more like 11 to 35 clocks now depending on the character width. I’m trying to keep the number of clock cycles of delay down to 80 or less so that interrupt latency isn’t too horrible. IIRC some of the 68k’s instructions take this long to execute.

Got some audio output. A 600 Hz tone test signal for about 1s. This is the first audio output I managed to get out of the board so I’m relieved to find out it works. It worked without going through a software setup. It’s just a matter of a couple of shift registers loaded with audio data. The default config of the chip must be okay.

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


Sun Dec 03, 2017 5:15 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Added audio input to the core. If things go well a special audio plot mode should work. And… audio input seems to be working. Well okay, there were one or two fixes first. Pixels are displayed across the screen according to the microphone input level which looks a bit like a scope display. I’m not sure that the bits aren’t coming through a little scrambled. It looks like two’s complement numbers.

One limitation of the blitter is that it only works with full color pixels. It can’t handle two color bitmaps that use just a single bit to determine color. I’ve spent some time thinking about this and it maybe better to add a special DMA channel just for handling two-color bitmaps rather than try and incorporate the logic with the regular blitter channels. Amiga blitter processed in terms of bit-planes and therefore handled multiple two-color bitmap pixels at the same time. That makes it up to 16 times faster in that case. That means the Amiga blitter had to process multiple bit-planes though to get multi-colored graphics.

Added an alpha-blending operation to the blitter. Channel A is used as the alpha channel, Channel B is the color to blend towards, and channel C is the target color.
Anyways now that much of it is working I’m thinking of modifying the whole core to work with a 32 or 64 bit processor. Currently it’s designed around the 68k and it’s 16 bit databus.

A plan is to incorporate the orgfx core into the AV controller.

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


Mon Dec 04, 2017 6:11 am
Profile WWW

Joined: Fri May 08, 2015 6:22 pm
Posts: 61
robfinch wrote:
Added audio capabilities to the display controller, so I guess now it’s an audio/video controller. I should really come up with a name for the circuit. There are four channels of audio supported, but the FPGA board only supports two. The software interface to the board’s audio controller isn’t finished yet, so no sound out yet. The ADAU1761 chip seems like a powerful device.
.
.
The audio chip also needs an I2C controller.
It should be possible to mix pairs of channels and send the result to the two channels of the FPGA board. The Amiga was four channels, though the output was just stereo.

robfinch wrote:
Added audio input to the core. If things go well a special audio plot mode should work. And… audio input seems to be working. Well okay, there were one or two fixes first. Pixels are displayed across the screen according to the microphone input level which looks a bit like a scope display. I’m not sure that the bits aren’t coming through a little scrambled. It looks like two’s complement numbers.

Page 42 of the ADAU1761 datasheet has the following to say about twos complement:
Quote:
Data is processed in twos complement, MSB
first format. The left channel data field always precedes the right
channel data field in 2-channel streams.

http://www.analog.com/media/en/technica ... AU1761.pdf


Mon Dec 04, 2017 7:16 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 74 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

Who is online

Users browsing this forum: No registered users and 1 guest


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

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