Wishbone Monitor Controller Accelerator

Description

Accelerator functions

Many 8-bit systems has very limited address space. It's common that they can't access more than 64k of memory but often the available address spaces for video buffer is even much smaller. There are two ways to overcome this:

• Paging
• Indirect addressing

The important thing is that while paging provides two type of information in one cycle (what and where) indirect addressing provides only one.

Many algorithms uses relative addressing which is quite time-consuming to implement in SW. they would say things like, write to the pixel to the left, or up; Go two rows down, etc. The accelerator part of the design will do such post-modification of the cursor automatically by HW. It will have a set of modify registers (a small bunch of RAM). It will also has a separate address space of (lets say) 256 locations, used for indirect frame-buffer access. A write operation on this address space will identify a post-modify register and provide the information to be written to the frame-buffer. After the write completes, the cursor location will be incremented/decremented by the value in the addressed post-modify register. Read operation can work the very same way only returning data instead of writing it to the frame-buffer.

Let's have an example! Let's say we would like to implement an algorithm of scrolling the screen up by one line. With direct access the code for that would be something like this:

   mov  R1, frame_buffer_addr
   mov  R2, frame_buffer_addr+xres/8
   mov  R3, frame_buffer_size-xres/8
loop:
   mov  R4,[R2]
   mov  [R1],R4
   inc  R1
   inc  R2
   dec  R3
   jnz  loop

The same thing with indirect addressing:

   mov  R1, 0
   mov  R2, xres/8
   mov  R3, frame_buffer_size-xres/8
loop:
   mov  [cursor_reg],R2
   mov  R4,[pixel_reg]
   mov  [cursor_reg],R3
   mov  [pixel_reg],R4
   inc  R1
   inc  R2
   dec  R3
   jnz  loop

And finally the same thing with the accelerator functions:

   mov  R1, -xres/8
   mov  [cursor_post_inc_reg1],R1
   mov  R1, 1+xres/8
   mov  [cursor_post_inc_reg2],R1
   mov  R1, frame_buffer_addr
   mov  [cursor_reg],R1
   mov  R2, frame_buffer_size-xres/8
loop:
   mov  R1,[cursor_post_inc_reg1] ; will modify cursor position to the upper byte
   mov  [cursor_post_inc_reg2],R2 ; will modify cursor position to the lower-right pixel
   dec  R2
   jnz  loop

As you can see for this particular algorithm this approach is faster than even the direct access method to the frame-buffer. Hence the pompous word, accelerator.

If you think about the most common functions you will find that this approach fastens at least the following operations

• copy one part of the screen to another location, especially
• scroll
• mouse cursor
• character rendering
• Copy from local memory to frame buffer or back
• Line-drawing. Both vertical, horizontal, and Brezenhelm algorithms can benefit from it
• Drawing continuos curves of nearly any kind

• It takes time to set-up the engine and to program the various post-increment values
• Generaly, when arbitrary pixels are needed to be accessed it's not any faster than indirect addressing
• Required address range comparable to paged access

Programming information

As discussed above the accelerator maintains and updates a cursor register. That register is large enough to address all possible locations in the pixel memory, that is it has video_addr_width number of bits. This register can be read or written by asserting the cur_stb_i pin in a valid Wishbone cycle.

Each location in the accelerator memory functions as an increment value to the cursor. Thus each location has the same size as the cursor register itself. If data_width is less than video_addr_width such a location cannot be updated in one access. In that case the lower data_width bits of the location written or read directly form the data bus of the master Wishbone bus when the ACC_STB_I signal is asserted. The upper part of the location is written to/from the extension register. That register can be accessed by asserting the EXT_STB_I signal. Pixel memory accesses are performed upon the assertion of the MEM_STB_I signal. The accelerator location is selected by the address bits, the pixel memory location will be the current value of the cursor register, and the cursor register is updated with the value read from the accelerator location.

The accelerator has 2**accel_size locations.

Wishbone datasheet

Parameter description

Signal description

Author & Maintainer

Andras Tantos