FPGA VGA Controller for 8-bit computer

[BrianHG]

As I'm sure you know, this is important as it defines when you write or copy all these settings, right now, the lower memory address holds the MSB of a 16 bit or 32 bit number.  As you increase the memory address, you head toward the LSB.  So, I assume we are keeping this setup?

IE, you wont be using any compilers/interpreters which store 16bit ints backwards making this graphics card incompatible?

Hmm..    This could be a bit of an issue if the conversion for little-endian to big-endian is done by the Z80 - it'll add processing overhead to any interactions with the GPU.

EDIT: Of course my suggestion to convert in the z80_bridge wouldn't work, as only 1 byte is written at a time by the Z80 so it would be impossible to work out if a 16-bit word is being written and thus needed to be reversed...

It's just 1 more thing I need to also consider.  What we might do is make an Invert feature on the LSB bit of the HW_Regs address input and only worry about the 16 bit ints.  Only the base address setting in the address generator is 24 bit and we can do the same invert with the palette memory reads easily enough.  As for the 16bit color raster graphics, we can use a spare bit in the video mode setting to swap the byte_in and byte_in_h.  This would be near all control register software select able, however, any 8 bit control settings will be swapped with their adjacent control settings.

Note that all 16 bit data, whether big or little endian will need to be 16 bit word aligned, as it is currently setup.

[nockieboy]

This would be near all control register software select able, however, any 8 bit control settings will be swapped with their adjacent control settings.

So that would just require a little adjustment of the documentation - instead of video_mode being at HW_REGS[16 + 0], it would be at HW_REGS[16 + 1]?  Ditto for each pair of bytes in memory?

[BrianHG]

This would be near all control register software select able, however, any 8 bit control settings will be swapped with their adjacent control settings.

So that would just require a little adjustment of the documentation - instead of video_mode being at HW_REGS[16 + 0], it would be at HW_REGS[16 + 1]?  Ditto for each pair of bytes in memory?

Nope, if we are going to do it, it needs to be done right.  Otherwise, all your HW_Regs would begin on an odd address.  No future compatibility with a 16 bit processor as well.

[nockieboy]

Nope, if we are going to do it, it needs to be done right.  Otherwise, all your HW_Regs would begin on an odd address.  No future compatibility with a 16 bit processor as well.

Future compatibility is important too - no telling when I might get the urge to make a computer based on one of the 68010s I have in a box somewhere... 

Okay, so how hard is it going to be to do it right?  It affects any memory in the GPU (including the hardware registers) that the host system can access for a 16-bit value, but only when it accesses that memory using one of the (few) 16-bit opcodes - but they're useful for the kind of work I'd be doing here with graphics; lots of copying and moving data. 

[BrianHG]

Ok, the address generator's IOs.

Code: [Select]

1) inputs:
clk
pc_ena[]==0
all HW_regs
all HV_triggers
cmd_in[31:0]

2) outputs: (use all wires as we will embed the connected registers inside the module)
read_addr[19:0]
cmd_out[31:0]
bp_2_rast_cmd[23:0]

3) parameters:
HW_REG_BASE = #
H_RESET_TRIG = #
H_POS_TRIG    = #

localparam
V_RESET_TRIG = H_RESET_TRIG + 1
V_POS_TRIG    = H_POS_TRIG + 1
BP2RAST_cmd = HW_REG_BASE + 0   // transfers the video mode setting to the new bitplane_2_raster module
BP2RAST_bgc  = HW_REG_BASE + 1  // transfers the bg_color setting to the new bitplane_2_raster module
BP2RAST_fgc   = HW_REG_BASE + 2  // transfers the fg_color setting to the new bitplane_2_raster module
RST_ADDR_H  = HW_REG_BASE +      // MSB bits of 24 bit base read address
RST_ADDR_M  = HW_REG_BASE +      // MID bits of 24 bit base read address
RST_ADDR_L  = HW_REG_BASE +       // LSB bits of 24 bit base read address
YINC_ADDR_H = HW_REG_BASE +      // MSB bits of 16 bit Y-Line increment for read address
YINC_ADDR_L = HW_REG_BASE +      // LSB bits of 16 bit Y-Line increment for read address
X_SIZE_H = HW_REG_BASE +      // MSB bits of 16 bit display width screen pixels
X_SIZE_L = HW_REG_BASE +      // LSB bits of 16 bit display width screen pixels
Y_SIZE_H = HW_REG_BASE +      // MSB bits of 16 bit display height screen y lines
Y_SIZE_L = HW_REG_BASE +      // LSB bits of 16 bit display height screen y lines
X_SCALE  = HW_REG_BASE +      // Compound of two 4 bit words.  upper 4 bits controls the X increment every period, lower 4 bits is a pixel period counter to define the number of pixels until the upper 4 bits are added to the address-pointer.
Y_SCALE  = HW_REG_BASE +      // Compound of two 4 bit words.  upper 4 bits reserved for text tile mode Y size while the lower lower 4 bits is a line period counter to define the number of lines until YINC_ADDR is added to the address-pointer
X_START_SUB  = HW_REG_BASE +      //  An 8 bit word which defines an odd pixel start position within the period counter and X position within a bitplane's X coordinate position
Y_START_SUB  = HW_REG_BASE +      // An 8 bit word which defines and odd line start within within the period counter and Y coordinates inside a font.

Damn, we are at 20 control bytes per window, not 16...
This means 15 windows = 300 register control bytes.
We will stick with this for now as we only have 5 windows to worry about.

You will also need to take into account we are using other HV_Triggers, so assign you byte offseta around everything else.

Also, copy the current 'bitplane_to_raster' into a 'bitplane_to_raster_v2' as we will change the IO and depricate the old one soon.  In the new 'bitplane_to_raster_v2':

change '   .ram_byte_in' into 16 bit and get rid of '   .ram_byte_in_h'.

get rid of :

   .bg_colour( GPU_HW_Control_regs[10] ),
   .x_in( dly6_disp_x ),
   .colour_mode_in( GPU_HW_Control_regs[12][2:0] ),
   .two_byte_mode( GPU_HW_Control_regs[11][0] ),

and make a inputs:
       .bp_2_rast_cmd[23:0]
       .cmd_in[31:0]

assignments:
assign colour_mode_in[7:0] = bp_2_rast_cmd[7:0]
assign bg_colour[7:0] =  bp_2_rast_cmd[15:8]
assign fg_colour[7:0] =  bp_2_rast_cmd[23:16]
assign window_enable = cmd_in[7]                      // used to be "pixel_in_ena"
assign x_in[4:0]         = cmd_in[4:0]
assign two_byte_mode = colour_mode_in[6]


More to come (window counter and scale in address generator)....

[BrianHG]

Nope, if we are going to do it, it needs to be done right.  Otherwise, all your HW_Regs would begin on an odd address.  No future compatibility with a 16 bit processor as well.

Future compatibility is important too - no telling when I might get the urge to make a computer based on one of the 68010s I have in a box somewhere... 

Okay, so how hard is it going to be to do it right?  It affects any memory in the GPU (including the hardware registers) that the host system can access for a 16-bit value, but only when it accesses that memory using one of the (few) 16-bit opcodes - but they're useful for the kind of work I'd be doing here with graphics; lots of copying and moving data. 

Don't worry, it will be a parameter thing, also with the Lattice part, you may embed a full 125MHz 68020 + FPU & add external DDR ram for main system memory.

[nockieboy]

Ok, the address generator's IOs.
...
Damn, we are at 20 control bytes per window, not 16...
This means 15 windows = 300 register control bytes.
We will stick with this for now as we only have 5 windows to worry about.

Going to need a bigger FPGA!  The Lattice one is really looking like the best option - shame there's not a cheap(ish) dev board for it.

You will also need to take into account we are using other HV_Triggers, so assign you byte offseta around everything else.

Question regarding this line:  Do you mean that because there's more than one MAGGIE, their offsets will need to take every other MAGGIE's HV_Triggers into account so they don't end up using the same ones?  I feel I'm getting confused between HV_triggers and HW_regs.  (It is late here though).

Also, copy the current 'bitplane_to_raster' into a 'bitplane_to_raster_v2' as we will change the IO and depricate the old one soon.  In the new 'bitplane_to_raster_v2':

change '   .ram_byte_in' into 16 bit and get rid of '   .ram_byte_in_h'.

get rid of :

   .bg_colour( GPU_HW_Control_regs[10] ),
   .x_in( dly6_disp_x ),
   .colour_mode_in( GPU_HW_Control_regs[12][2:0] ),
   .two_byte_mode( GPU_HW_Control_regs[11][0] ),

and make a inputs:
       .bp_2_rast_cmd[23:0]
       .cmd_in[31:0]

assignments:
assign colour_mode_in[7:0] = bp_2_rast_cmd[7:0]
assign bg_colour[7:0] =  bp_2_rast_cmd[15:8]
assign fg_colour[7:0] =  bp_2_rast_cmd[23:16]
assign window_enable = cmd_in[7]                      // used to be "pixel_in_ena"
assign x_in[4:0]         = cmd_in[4:0]
assign two_byte_mode = colour_mode_in[6]


More to come (window counter and scale in address generator)....

Apart from making the new inputs and assigns, most of those changes I'd already made, so that's good.  What's going to replace x_in, though?  I should also get rid of pixel_in_ena and pixel_out_ena as well?

[nockieboy]

Future compatibility is important too - no telling when I might get the urge to make a computer based on one of the 68010s I have in a box somewhere... 

Okay, so how hard is it going to be to do it right?  It affects any memory in the GPU (including the hardware registers) that the host system can access for a 16-bit value, but only when it accesses that memory using one of the (few) 16-bit opcodes - but they're useful for the kind of work I'd be doing here with graphics; lots of copying and moving data. 

Don't worry, it will be a parameter thing, also with the Lattice part, you may embed a full 125MHz 68020 + FPU & add external DDR ram for main system memory.

Yeah, I could have done that with the Z80 as well - could have fit everything onto an FPGA, but that would have sidestepped the reason I started the project in the first place; to learn about electronics and how to build a computer 'the old fashioned way', soldering and designing PCBs etc.  Plus I didn't really know anything about FPGAs until about 2 months ago.  I must admit, it's really tempting to stick a whole load of stuff onto the FPGA, not just the GPU... I'm certainly keen to get a programmable sound generator on it, and it would be remiss of me not to include a PS/2 port for a keyboard and maybe even an SD card interface as well... 

[BrianHG]

Now, more on the address generator.

Code: [Select]

Make the following regs

ram_read_pointer_y[19:0]
ram_read_pointer_x[23:0]
run_x
run_y
period_x[4:0]
period_y[4:0]

make the following assignments (don't forget to declare wires for new next names)

assign bp_2_rast_cmd[23:0] = { hw_regs[BP2RAST_fgc] , hw_regs[BP2RAST_bgc] , hw_regs[BP2RAST_cmd] }


assign x_rst         = HV_trig[H_RESET_TRIG]
assign xy_rst        = HV_trig[V_RESET_TRIG] && x_rst

assign v_trig        = HV_trig[V_POS_TRIG]
assign h_trig        = HV_trig[H_POS_TRIG]
assign window_enable = (HV_trig[H_POS_TRIG] || run_x) && run_y
assign cmd_out[7]    = window_enable  // commands the pixel/by/pixel window enable for the bitplane_2_raster module
assign cmd_out[6]    = 1'b0        // for now, disables the 2 byte color mode.

assign reset_addr[23:0]  = { hw_regs[RST_ADDR_H] , hw_regs[RST_ADDR_M] , hw_regs[RST_ADDR_L]  }
assign inc_addr_y[15:0]  = { hw_regs[YINC_ADDR_H] , hw_regs[YINC_ADDR_L] }
assign inc_addr_x[3:0]   =   hw_regs[X_SCALE][7:4]

assign read_addr[19:0]   = ram_read_pointer_x[22:3]
assign cmd_out[2:0]      = ram_read_pointer_x[2:0]   // commands the sub pixel X position for the bitplane_2_raster module

assign period_x[3:0]     = hw_regs[X_SCALE][3:0]
assign period_y[3:0]     = hw_regs[Y_SCALE][3:0]

assign period_x_rst[3:0] = hw_regs[X_START_SUB][3:0]
assign period_y_rst[3:0] = hw_regs[Y_START_SUB][3:0]

assign x_size[11:0]      = { hw_regs[X_SIZE_H][3:0], hw_regs[X_SIZE_L][7:0] }
assign y_size[11:0]      = { hw_regs[Y_SIZE_H][3:0], hw_regs[Y_SIZE_L][7:0] }


You got a killer, though a feature or 2 not yet implemented, starting here...

[BrianHG]

You will also need to take into account we are using other HV_Triggers, so assign you byte offseta around everything else.

Question regarding this line:  Do you mean that because there's more than one MAGGIE, their offsets will need to take every other MAGGIE's HV_Triggers into account so they don't end up using the same ones?  I feel I'm getting confused between HV_triggers and HW_regs.  (It is late here though).

The raster HV_triggers are a set 48 of X&Y coordinates, 24 horizontal, 24 vertical, which pulse the 'HV_trigger' output wires when that pixel coordinate or line number has been reached on the screen.

Those 48 raster HV_trigger screen coordinate positions are stored in the bulk first 96 bytes of the GPU_HW_REGS.  This doesn't mean wan cannot use each reg for more than 1 thing, just that if it shares a HV_Trigger setting, writing 1 number there would alter one of the raster triggers as well as whatever else you are controlling.

[BrianHG]

Also, copy the current 'bitplane_to_raster' into a 'bitplane_to_raster_v2' as we will change the IO and depricate the old one soon.  In the new 'bitplane_to_raster_v2':

change '   .ram_byte_in' into 16 bit and get rid of '   .ram_byte_in_h'.

get rid of :

   .bg_colour( GPU_HW_Control_regs[10] ),
   .x_in( dly6_disp_x ),
   .colour_mode_in( GPU_HW_Control_regs[12][2:0] ),
   .two_byte_mode( GPU_HW_Control_regs[11][0] ),

and make a inputs:
       .bp_2_rast_cmd[23:0]
       .cmd_in[31:0]

assignments:
assign colour_mode_in[7:0] = bp_2_rast_cmd[7:0]
assign bg_colour[7:0] =  bp_2_rast_cmd[15:8]
assign fg_colour[7:0] =  bp_2_rast_cmd[23:16]
assign window_enable = cmd_in[7]                      // used to be "pixel_in_ena"
assign x_in[4:0]         = cmd_in[4:0]
assign two_byte_mode = colour_mode_in[6]


More to come (window counter and scale in address generator)....

Apart from making the new inputs and assigns, most of those changes I'd already made, so that's good.  What's going to replace x_in, though?  I should also get rid of pixel_in_ena and pixel_out_ena as well?

x_in is now an internal wire and it has been assigned to a set of bits on the new cmd_in input port:
'assign x_in[4:0]         = cmd_in[4:0]', read code.

pixel_in_ena has been renamed to window_enable and is has been assigned to a cmd_in bit.  Read code.

pixel_ena_out, the one change I would make is rename it to 'window_ena_out' and keep it's same function.

[BrianHG]

How the address generator is wired and works:

The address generator takes a clk, pc_ena, HW_Regs & HV_Trigger inputs, plus a spare 32 bit cmd_in which will be used later.

It outputs a 24 bit control 'bp_2_rast_cmd[23:0]'  for it's mated 'bitplane_2_raster' module.

It also outputs a 20 address to go to it's mated read GPU memory address read port _#.

It also outputs a 32 bit cmd_out port which feeds the matching GPU multiport memory cmd_in_# port.

The new 'bitplane_2_raster' command module's new cmd_in port receives the cmd_out_# from the GPU multiport ram module which contains real-time pixel drawing instructions, like sub-x coordinates and window enable/disable functions.  In the next iteration, this output will also feed the next address generator's cmd_in & ram read address allowing font/tile graphics memory pointers.

[nockieboy]

Latest versions of the two new modules attached. 

[BrianHG]

#2, bitplane_to_raster_v2.v :

   input wire enable_in,   *** no longer in use.

   input wire [7:0]  GPU_HW_Control_regs[0:(2**HW_REGS_SIZE-1)],   *** no longer in use

   output reg enable_out,  *** no longer in use, replaced by window_ena_out,

   output reg [7:0] pixel_out,
   output reg [7:0] pixel_out_h,      **** merge these 2 into 1 single pixel_out[15:0]
                                                        **** correct all the appropriate code below.

   output reg [9:0] x_out     **** not used

parameter CTRL_BYTE_BASE = 16;    **** no longer used
parameter HW_REGS_SIZE   = 8;     **** no longer used

wire [7:0] bg_colour = GPU_HW_Control_regs[CTRL_BYTE_BASE + 1];
wire [7:0] fg_colour = GPU_HW_Control_regs[CTRL_BYTE_BASE + 2];
***** get rid of the "  = GPU_HW_Control_regs[CTRL_BYTE_BASE + #]; " in both cases

assign two_byte_mode         = cmd_in[6];  **** obsolete, get rid

      window_ena_out   <= window_enable;   // pass pixel_ena through to the output
              **** this output is also dependent if the video mode is on or off

      enable_out       <= enable_in;    **** no longer used

***** fix...
         case (GPU_HW_Control_regs[CTRL_BYTE_BASE + 0]) // select case based on video_mode HW_reg

----------------------
Next, the maggie.v...

[BrianHG]

next: maggie.v.

parameter H_RESET_TRIG   = 4;
parameter H_POS_TRIG   = 6;

add a parameter:
RAM_READ_CYCLES = 3;

add a reg:
h_trig_delay[7:0]

add an assign under bp_2_rast...:
assign text_mode_master = hw_regs[BP2RAST_cmd][7]

change :
assign window_enable         = run_x && run_y;

add just above
h_rst                =    text_mode_master ? h_trig_delay[0] : h_trig_delay[RAM_READ_CYCLES];  // When in text mode, push the window left by 'RAM_READ_CYCLES' as it takes a second memory read to get the font image

------
And all the way at the bottom:
------

always @(posedge clk) begin
   if (pc_ena_in[3:0] == 0) begin

      h_trig_delay[7:0] <= { h_trig_delay[6:0] ,  h_trig };

         if ( xy_rst ) begin // equivalent to a vertical sync/reset

         end else if (x_rst) begin   // equivalent to a horizontal sync/increment

         end else begin
            -------------------------------
            snap to it....
            -------------------------------
         end // ~x_rst

   end // if (pc_ena_in[3:0] == 0)
end //@(posedge clk)
endmodule

[nockieboy]

      window_ena_out   <= window_enable;   // pass pixel_ena through to the output
              **** this output is also dependent if the video mode is on or off

***** fix...
         case (GPU_HW_Control_regs[CTRL_BYTE_BASE + 0]) // select case based on video_mode HW_reg

Both of the above changes require an input that specifies the video mode.  This was specified in the HW_REGS, but we're not using those now - so what do I use in their place?

[nockieboy]

Latest updates to bart and maggie.

[BrianHG]

      window_ena_out   <= window_enable;   // pass pixel_ena through to the output
              **** this output is also dependent if the video mode is on or off

***** fix...
         case (GPU_HW_Control_regs[CTRL_BYTE_BASE + 0]) // select case based on video_mode HW_reg

Both of the above changes require an input that specifies the video mode.  This was specified in the HW_REGS, but we're not using those now - so what do I use in their place?

Tadaaaaaa:
-----------------------------------------------------------------------
assign colour_mode_in[7:0]   = bp_2_rast_cmd[7:0];
------------------------------------------------------------------------

Line #63 > NO
window_ena_out   <= window_enable && (##);   // pass pixel_ena through to the output

Line #67 > Put this:
window_ena_out   <= 1'b0 ;

Line #78 > What?  Its window_ena_out.
enable_out    <= 1'b0;            // set enable_out LOW
Make it:
window_ena_out    <= 1'b0;            // set enable_out LOW

Line #84, 102, 134, 148, 157, 166> What?  Its window_ena_out.
enable_out <= 1'b1;   // set enable_out HIGH

Change these lines:

Code: [Select]

if (ram_byte_in[(~x_in[2:0])] == 1'b1) begin
pixel_out[7:4] <= fg_colour[7:4];
pixel_out[3:0] <= font_color[7:4];

end
else begin

pixel_out[7:4] <= bg_colour[7:4];
pixel_out[3:0] <= font_color[3:0];

Add an assign and wire at the top of the code:
assign  font_color[7:0] = cmd_in[15:8]

************* ALSO,
What's with all the case 2'h# ?  2 bits?  When you are going up to over 5 or more cases?

Also, try to keep the pixels per byte in the mode numbers constant for the least significant bits.
IE:
00 = 8 pixels per byte
01 = 4 pixels per byte
10 = 2 pixels per byte
11 = 1 pixel per byte.

Use the next bit to the left for 16 bit modes on and off, also adhering to the first 2 bits pixels per byte.

Use the next bit over for video window mode ON/OFF.

We need the first 2 bottom bits to always reflect the 8pixels, 4pixels, 2 pixels, 1 pixels as 'MAGGIE' also uses these same 2 bits to know how fast to increment the memory read address.  IE, 1 inc per pixel, 1 inc every 2 pixels, 1 inc every 4 pixels, 1 inc every 8 pixels.  If you break this rule in the bitplane_2_raster module settings, the 2 modules will never sync pixel with memory.

[nockieboy]

Tadaaaaaa:
-----------------------------------------------------------------------
assign colour_mode_in[7:0]   = bp_2_rast_cmd[7:0];
------------------------------------------------------------------------

Line #63 > NO
window_ena_out   <= window_enable && (##);   // pass pixel_ena through to the output

Okay, the ## was there because I didn't know what signal to use.  Now I know it's colour_mode_in, would this work?

Code: [Select]

window_ena_out <= window_enable && colour_mode_in; // pass pixel_ena through to the output[/quote]

The idea being that if colour_mode_in is anything other than zero (off), and window_enable is high, then window_ena_out should be high?

************* ALSO,
What's with all the case 2'h# ?  2 bits?  When you are going up to over 5 or more cases?

Well spotted. 

[BrianHG]

Tadaaaaaa:
-----------------------------------------------------------------------
assign colour_mode_in[7:0]   = bp_2_rast_cmd[7:0];
------------------------------------------------------------------------

Line #63 > NO
window_ena_out   <= window_enable && (##);   // pass pixel_ena through to the output

Okay, the ## was there because I didn't know what signal to use.  Now I know it's colour_mode_in, would this work?

Code: [Select]

window_ena_out <= window_enable && colour_mode_in; // pass pixel_ena through to the output[/quote]

The idea being that if colour_mode_in is anything other than zero (off), and window_enable is high, then window_ena_out should be high?

Well spotted. 

Nope, do it as I said.

     The colour_mode_in is an 8 bit number, and if you read my text further, I want the bottom 2 bits of that variable to reflect specifically the number of pixels per byte.  This means having a color mode 0 = 1 byte to 8 pixels, usually text mode.

     The next bit#3 is the count of bytes per pixel, IE 16 bit color modes.  BUT YOU must keep the pattern of the 4 possible "pixels per byte".  The bit #4 will enable/disable the window completely.  We need a 'HARD' window disable setting since the layer may be active for font/tile mode, but the data coming through is the font's address data, not to be display.  That return data goes to the next line generator ad fed through to memory a second time then to that bitplane_2_raster module where that one will be enabled to generate an image.

[BrianHG]

This should help.  it is the internal full GPU MAGGIE wiring layout:



Once the MAGGIE is complete and pair's with the previous MAGGIE for tile text support, there will be no other code inside the vid_osd_generator other than wires between the first 4 modules in the image.  All that obsolete code with delays and reg delays making the current ascii text function will be erased and forgotten.

The only 1 remaining delay code will be the HS,VS,HDE, & VDE which need compensation for the number of pixel cycles the pipe you see above takes to generate the first pixel.

[nockieboy]

Tadaaaaaa:
-----------------------------------------------------------------------
assign colour_mode_in[7:0]   = bp_2_rast_cmd[7:0];
------------------------------------------------------------------------

Line #63 > NO
window_ena_out   <= window_enable && (##);   // pass pixel_ena through to the output

Okay, the ## was there because I didn't know what signal to use.  Now I know it's colour_mode_in, would this work?

Code: [Select]

window_ena_out <= window_enable && colour_mode_in; // pass pixel_ena through to the output[/quote]

The idea being that if colour_mode_in is anything other than zero (off), and window_enable is high, then window_ena_out should be high?

Well spotted. 

Nope, do it as I said.

     The colour_mode_in is an 8 bit number, and if you read my text further, I want the bottom 2 bits of that variable to reflect specifically the number of pixels per byte.  This means having a color mode 0 = 1 byte to 8 pixels, usually text mode.

I thought I was going mad, then I went back to look at your previous post and you'd edited in the extra information below!

Also, try to keep the pixels per byte in the mode numbers constant for the least significant bits.
IE:
00 = 8 pixels per byte
01 = 4 pixels per byte
10 = 2 pixels per byte
11 = 1 pixel per byte.

Use the next bit to the left for 16 bit modes on and off, also adhering to the first 2 bits pixels per byte.

Use the next bit over for video window mode ON/OFF.

We need the first 2 bottom bits to always reflect the 8pixels, 4pixels, 2 pixels, 1 pixels as 'MAGGIE' also uses these same 2 bits to know how fast to increment the memory read address.  IE, 1 inc per pixel, 1 inc every 2 pixels, 1 inc every 4 pixels, 1 inc every 8 pixels.  If you break this rule in the bitplane_2_raster module settings, the 2 modules will never sync pixel with memory.

And there I was thinking I was going mad as I was unaware of this info when I wrote my reply..   

I'm a tad confused though - if bit 2 determines 16-bit mode, what value of colour_mode_in equates to the special colour text mode?  It's marked as an 8-bit mode in the comments, but there aren't enough bits unless I move everything left one bit and use bit 3 to increase the number of modes to 8?

Currently I've got:

000 - 1-bit mode
001 - 2-bit mode
010 - 4-bit mode
011 - 8-bit mode
111 - 16-bit mode

I'm using bit 4 for on/off:

Code: [Select]

if (~window_enable | ~colour_mode_in[4]) begin
// disable output as turned off
pixel_out <= 16'b0000000000000000;
// disable output as not in display area
window_ena_out <= 1'b0;
end

So bit 3 is free, but you state that's for bytes per pixel?

[BrianHG]

Currently I've got:

000 - 1-bit mode
001 - 2-bit mode
010 - 4-bit mode
011 - 8-bit mode
111 - 16-bit mode

I'm using bit 4 for on/off:

Code: [Select]

if (~window_enable | ~colour_mode_in[4]) begin
// disable output as turned off
pixel_out <= 16'b0000000000000000;
// disable output as not in display area
window_ena_out <= 1'b0;
end

So bit 3 is free, but you state that's for bytes per pixel?

bit 3 is 16 bits per pixel, ie 111

Mode
111 - 16-bit mode

but you are missing
100 - 16 bit text mode, ie 1 byte = 8 pixels.  This one uses the upper part of the byte, [15:12] for the bottom bits of the foreground color and [11:8] for the background color while the upper 4 bit palette bits still use the fg_colour and bg_colour.

101 - 16 bit mode with a 2 bit color pixel, ie 2 bits per pixel, and the upper color bits come from the upper ram byte[15:10], IE used in fonts with 4 colors per pixel.  (heheheh - the byte[9:8] allow addressing a 1024 character font, 8x8 pixel or 1024 tiles)

110 - 16 bit mode with a 4 bit color pixel, ie 4 bits per pixel, and the upper color bits come from the upper ram byte[15:12], IE used in fonts with 16 colors per pixel. (heheheh - the byte[11:8] allow addressing a 4096 character font, 4x8 pixel or 4096 tiles for display with 16 color pixels spread across 16 positions in a 16 color palette.  Imagine what you can do with that.)

bits 0,1 are the bitplane depth, bit 2 is the 16bit wide source data, bit 3 is enable/disable, bits 4 are for the new output mode_565.

Also add an output wire to the bitplane_2_raster:
mode_565
and assign it
assign  mode_565 = colour_mode_in[4];

---------------------------------------------------
Also, take a look at the upper image again, I just forgot to add a feedback green signal for the MAGGA when in tile/font mode.

Add an input wire to the MAGGIE:
ram_din[15:0]

[nockieboy]

bit 3 is 16 bits per pixel, ie 111

Mode
111 - 16-bit mode

but you are missing
100 - 16 bit text mode, ie 1 byte = 8 pixels.  This one uses the upper part of the byte, [15:12] for the bottom bits of the foreground color and [11:8] for the background color while the upper 4 bit palette bits still use the fg_colour and bg_colour.

101 - 16 bit mode with a 2 bit color pixel, ie 2 bits per pixel, and the upper color bits come from the upper ram byte[15:10], IE used in fonts with 4 colors per pixel.  (heheheh - the byte[9:8] allow addressing a 1024 character font, 8x8 pixel or 1024 tiles)

110 - 16 bit mode with a 4 bit color pixel, ie 4 bits per pixel, and the upper color bits come from the upper ram byte[15:12], IE used in fonts with 16 colors per pixel. (heheheh - the byte[11:8] allow addressing a 4096 character font, 4x8 pixel or 4096 tiles for display with 16 color pixels spread across 16 positions in a 16 color palette.  Imagine what you can do with that.)

I'm having a complete brain fart setting these modes up.  I've read and re-read what you've written, but I'm still not 100% certain on what to do.     I've done what I can to the best of my understanding, but 110 (16-bit, 4 bits per pixel) is incomplete and I've probably messed-up on the other 16-bit modes as well.  Take a look at the attached files - they have all the changes you've mentioned so far, but these 16-bit modes are testing my focus tonight. 

bits 0,1 are the bitplane depth, bit 2 is the 16bit wide source data, bit 3 is enable/disable, bits 4 are for the new output mode_565.

Yep, understand that now.  Have corrected line 69 in the BitplAne_to_RasTer module to use bit 3 instead of 4.

Code: [Select]

if (~window_enable | ~colour_mode_in[3]) begin

// disable output as turned off
pixel_out <= 16'b0000000000000000;
// disable output as not in display area
window_ena_out <= 1'b0;

end


Also add an output wire to the bitplane_2_raster:
mode_565
and assign it
assign  mode_565 = colour_mode_in[4];

Done. 

Also, take a look at the upper image again, I just forgot to add a feedback green signal for the MAGGA when in tile/font mode.

Add an input wire to the MAGGIE:
ram_din[15:0]

That image makes it all much easier for me to visualise - thanks for that. 

[BrianHG]

Ooyoyoy...
ok, 1:

Code: [Select]

3'b100 : begin // 16-bit text mode - 8 pixels per word

mode_16bit <= 1'b0; // I know this is weird, the 16 bit mode is reserved for turning off the palette and passing 16 bits straight to the DAC
window_ena_out <= 1'b1; // set enable_out HIGH


if (ram_byte_in[(~x_in[2:0])] == 1'b1) begin

pixel_out[3:0] <= font_color[7:0];
pixel_out[7:4] <= fg_color[7:4];

end
else begin

pixel_out[3:0] <= font_color[3:0];
pixel_out[7:4] <= bg_color[7:4];

end

next:

Code: [Select]

3'b101 : begin // 16-bit text mode - 4 pixels per word

mode_16bit <= 1'b0; // I know this is weird, the 16 bit mode is reserved for turning off the palette and passing 16 bits straight to the DAC
window_ena_out <= 1'b1; // set enable_out HIGH

pixel_out[7:2] <= font_color[7:2];

case (x_in[2:1])
2'h0 : begin

pixel_out[1:0] <= ram_byte_in[7:6];

end
2'h1 : begin

pixel_out[1:0] <= ram_byte_in[5:4];

end
2'h2 : begin

pixel_out[1:0] <= ram_byte_in[3:2];

end
2'h3 : begin

pixel_out[1:0] <= ram_byte_in[1:0];

end
endcase
and:

Code: [Select]

3'b101 : begin // 16-bit text mode - 4 pixels per word

mode_16bit <= 1'b0; // I know this is weird, the 16 bit mode is reserved for turning off the palette and passing 16 bits straight to the DAC
window_ena_out <= 1'b1; // set enable_out HIGH

pixel_out[7:4] <= font_color[7:4];

if (x_in[3]) *********************** 3, again????? it should be 2!!! ALSO ~x_in[2] or swap the ram_byte_in to look like the above code.
pixel_out[3:0] <= ram_byte_in[3:0];
else
pixel_out[3:0] <= ram_byte_in[7:4];

end

And also line 138:
               if (x_in[3]) *********************** 3, again?? it should be 2!!! ALSO ~x_in[2] or swap the ram_byte_in to look like the above code.


get rid of lines 230-246.