Author Topic: FPGA VGA Controller for 8-bit computer  (Read 510769 times)

0 Members and 44 Guests are viewing this topic.

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #700 on: December 12, 2019, 11:09:16 pm »
A tad confused by the code you've posted...  Specifically blocks 2 and 3???

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

Is it me, or do they have exactly the same first line?  (The select case - both are 3'b101 with the same comment??)

I've put the third block of code (or the second one above) in as 3'b110 and kept the comment name for it - 16-bit 4-bit colour pixel - 4 bits per pixel.

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.

I've changed x_in[3] to [2] on line 212 (see the attached updated BART module below) and swapped the ram_byte_in order in the if...else - hopefully that's right now?
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #701 on: December 12, 2019, 11:42:37 pm »

Is it me, or do they have exactly the same first line?  (The select case - both are 3'b101 with the same comment??)
Sorry, copy and paste error...
Only 1 mistake, again my error.  Line 160 should read this:

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

Everything else looks good.

Wire the current MAGGIE and BART into memory channel 3, as per diagram, and wire the bottom 8 bits of the 16 bit BART output into 'pixel_out_top_h' which you should rename to 'gfx_pixel[7:0] for now and feed it into the palette gfx_pixel input.  On the current OSD text generator, don't for get to erase the current 'pixel_out_top_h'.

This should be enough to develop the MAGGIE code.

(This is a lot of work, isn't it?)
« Last Edit: December 12, 2019, 11:47:40 pm by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #702 on: December 13, 2019, 08:52:22 am »
Wire the current MAGGIE and BART into memory channel 3, as per diagram, and wire the bottom 8 bits of the 16 bit BART output into 'pixel_out_top_h' which you should rename to 'gfx_pixel[7:0] for now and feed it into the palette gfx_pixel input.  On the current OSD text generator, don't for get to erase the current 'pixel_out_top_h'.

Stupid question time:  where/how am I instantiating MAGGIE?  I'm guessing this will be done in the existing video_osd_generator module and connected up to port 3 of the multiport_gpu_ram instance via wires?  What happens to the old outputs from the video_osd_generator?  Seems I've got some gutting to do with the video_osd_generator's internals?
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #703 on: December 13, 2019, 09:19:54 am »
Wire the current MAGGIE and BART into memory channel 3, as per diagram, and wire the bottom 8 bits of the 16 bit BART output into 'pixel_out_top_h' which you should rename to 'gfx_pixel[7:0] for now and feed it into the palette gfx_pixel input.  On the current OSD text generator, don't for get to erase the current 'pixel_out_top_h'.

Stupid question time:  where/how am I instantiating MAGGIE?  I'm guessing this will be done in the existing video_osd_generator module and connected up to port 3 of the multiport_gpu_ram instance via wires?  What happens to the old outputs from the video_osd_generator?  Seems I've got some gutting to do with the video_osd_generator's internals?
Not yet.  Read the text.  The BART output feeds the GFX input in the palette mixer module.  Look at the top hierarchy of your project.  You made a mistake.  You were feeding the GFX input of the palette mixer the OSD text 'pixel_out_top_h'.  That supposed to be the output of the new BART's 'pixel_out' bottom 8 bits.

The gutting will only take place once the MAGGIE can produce ASCII text.  We got a way to go.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #704 on: December 13, 2019, 09:53:09 am »
I've tried to update the symbol file for the vid_osd_generator due to the IO port name change etc suggested above, but am getting this error:

Error (10703): SystemVerilog error at vid_osd_generator.v(133): can't resolve aggregate expression in connection to port 8 on instance "b2r_1" because the instance has no module binding


It relates to this line in vid_ost_generator.v:
Code: [Select]
.GPU_HW_Control_regs(GPU_HW_Control_regs[0:(2**HW_REGS_SIZE-1)]),

I can't seem to find the issue - bitplane_to_raster.v is present in the project.  :-//

I've resolved quite a few variable-name errors in MAGGIE too, but as I can't get vid_osd_generator to build at the moment, I'm relatively stuck in trying to make the wiring changes.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #705 on: December 13, 2019, 10:03:01 am »
That isn't the error I'm getting:

888972-0

Choose now, American, or European English...

There is a lot more of 1 or the other out there, you might have to go through all the modules.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #706 on: December 13, 2019, 10:16:32 am »
After changing the 'color' issue, it compiles fine.  Yet, you haven't inserted the new MAGGIE & BART yet.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #707 on: December 13, 2019, 10:18:21 am »
That isn't the error I'm getting:

(Attachment Link)

Choose now, American, or European English...

There is a lot more of 1 or the other out there, you might have to go through all the modules.

That's odd - I'm not getting any of those errors (I'm compiling in Quartus Prime).  I 'translate' your code into UK English as I enter it, so there shouldn't be any 'color' spellings in the code?

One change I had made was to rename bitplane_to_raster_v2.v to bart.v.  I've removed the old bitplane_to_raster_v2.v file from the project.  Neither maggie.v or bart.v are referenced in the project code yet, so they're just 'sitting' there in the file list in the project but are still getting compiled, of course.



Above error relates to this line of code in maggie.v:

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

EDIT: Changed it to this:

Code: [Select]
h_trig_delay[7:1] <= h_trig_delay[6:0];
h_trig_delay[0] <= h_trig;

... and then got the 'color' errors in bart...  :palm:  Compiles now.  :phew:
« Last Edit: December 13, 2019, 10:27:26 am by nockieboy »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #708 on: December 13, 2019, 10:31:00 am »
So, where are we at?
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #709 on: December 13, 2019, 10:35:02 am »
So, where are we at?



Back to here again.  I'm ignoring this error for now as I presume we're removing the old bitplane_to_raster module and replacing it with bart.  Just working on those changes at the moment.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #710 on: December 13, 2019, 10:40:38 am »
Give me you project .zip, because mine compiles.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #711 on: December 13, 2019, 10:57:00 am »
Give me you project .zip, because mine compiles.

It compiles now for me too - but only once I removed the instantiation of the old bitplane_to_raster.  I've removed it from the project files now and all compiles well.  I'm just in the process of finishing up the bart connections and instantiating maggie.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #712 on: December 13, 2019, 11:08:20 am »
Give me you project .zip, because mine compiles.

It compiles now for me too - but only once I removed the instantiation of the old bitplane_to_raster.  I've removed it from the project files now and all compiles well.  I'm just in the process of finishing up the bart connections and instantiating maggie.
What did you do?
You need both barts, the old for the existing text and the new for the graphics layer with maggie.
The new bart isn't compatible with the old text generator.  Or at least, I never thought about doing that.

« Last Edit: December 13, 2019, 11:12:20 am by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #713 on: December 13, 2019, 11:15:16 am »


Still getting this error now I've added the HW_regs inputs - it's not happy with this line in the instantiation of bart OR maggie:

Code: [Select]
.GPU_HW_Control_regs(GPU_HW_Control_regs[0:(2**HW_REGS_SIZE-1)]),

 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #714 on: December 13, 2019, 12:02:58 pm »
How do you keep on making multiple changes to multiple working modules at multiple times?

Here is the functional original 'bitplane_to_raster.v'
Code: [Select]
module bitplane_to_raster (

// inputs
input wire clk,
input wire pixel_in_ena,
input wire [3:0] pc_ena,
input wire [15:0] ram_byte_in, // ****** changed to 16 bit width
input wire [7:0] ram_byte_h,
input wire [7:0] bg_colour,
input wire [9:0] x_in,
input wire [2:0] colour_mode_in,
input wire two_byte_mode,

// outputs
output reg pixel_out_ena,
output reg mode_16bit, // high when in 16-bit mode
output reg [7:0] pixel_out,
output reg [7:0] pixel_out_h,
output reg [9:0] x_out,
output reg [2:0] colour_mode_out

);

// internal registers
//reg [7:0] colour_data;

// *****************************************************************************
// *                                                                           *
// *  PASS-THRUS                                                               *
// *                                                                           *
// *****************************************************************************

always @ ( posedge clk ) begin

if (pc_ena[3:0] == 0) begin

x_out <= x_in;
//colour_data <= ram_byte_in; // in two-byte mode, colour_data should follow the ram_data byte
colour_mode_out <= colour_mode_in;

end // pc_ena

end // always@clk
// *****************************************************************************


// *****************************************************************************
// *                                                                           *
// *  RASTER GENERATION                                                        *
// *                                                                           *
// *****************************************************************************

// color_mode_in determines the operating mode for the bitplane_to_raster module
// it is a 3-bit signal, providing 4 modes of operation to this module e.g.:
//
// 000 =   2 colour mode - 8 pixels per byte in GPU RAM
// 001 =   4 colour mode - 4 pixels -----"------"------
// 010 =  16 colour mode - 2 pixels -----"------"------
// 011 = 256 colour mode - 1 pixels -----"------"------
// 1xx = OFF

always @ (posedge clk) begin

if (pc_ena[3:0] == 0) begin

pixel_out_ena <= pixel_in_ena; // pass pixel_ena through to the output

if (~pixel_in_ena || colour_mode_in[2]) begin

// nothing to see here (disabled)
pixel_out <= 8'b00000000;
pixel_out_h <= 8'b00000000;

end
else if (~two_byte_mode) begin // 8-bit mode

case (colour_mode_in)

2'h0 : begin // 1-bit (2 colour) - 8 pixels per byte
// set the output pixel color to the first 4 bits of the background color
// when the bit on the picture bitplane byte is 0 and use the upper 4 bits
// when the bit on the bit-plane byte is high

mode_16bit <= 1'b0; // update mode_16bit output to 8-bit mode

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

pixel_out[7:4] <= 4'b0000; // was: pixel_out[7:5] <= 3'b000;
//pixel_out[4] <= 1'b1; // changed for new palette_mixer module
pixel_out[3:0] <= bg_colour[7:4];

end
else begin

pixel_out[7:4] <= 4'b0000;
//pixel_out[4] <= 1'b0;
pixel_out[3:0] <= bg_colour[3:0];

end

end

2'h1 : begin // 2-bit (4 colour) - 4 pixels per byte
// output will be 2 bits stacked, 2 copies every second X pixel, you will
// output a 2 bit color. EG pixel 0&1 output bitplane[7:6],  pixel 2&3
// output bitplane[5:4], pixel 4&5 output bitplane[3:2]

mode_16bit <= 1'b0; // update mode_16bit output to 8-bit mode

pixel_out[7:2] <= 6'b000000;

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

end

2'h2 : begin // 4-bit (16 colour) - 2 pixels per byte
// output will be 4 bits stacked, 4 copies every four X pixel, you will
// output a 4 bit color.  EG pixel 0,1,2,3 output bitplane[7:4], EG pixel
// 4,5,6,7 output bitplane[3:0]

mode_16bit <= 1'b0; // update mode_16bit output to 8-bit mode

pixel_out[7:4] <= 4'b0000;

if (x_in[3])
pixel_out[3:0] <= ram_byte_in[3:0];
else
pixel_out[3:0] <= ram_byte_in[7:4];

end

2'h3 : begin // 8-bit (256 colour) - 1 pixel per byte
// output will be 8 bits stacked, 8 copies every eight X pixel, you will
// output a 4 bit color.  EG pixel 0,1,2,3,4,5,6,7 output bitplane[7:0],
// yes that same 1 value will repeat 8 times is the source X counter
// counts through those numbers sequentially

mode_16bit <= 1'b0; // update the mode output to show whether it's 8 or 16-bit mode

pixel_out <= ram_byte_in[7:0];

end

endcase

end // 8-bit mode
else begin // 16-bit mode

case (colour_mode_in)

2'h0 : begin // special colour text mode
// 2-bit colour 2-byte mode
// latch ram_byte as the bit plane graphic and colour_data
// as a replacement for the background default color. The
// rest should follow #1.

mode_16bit <= 1'b0; // update mode_16bit output to 8-bit mode

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

pixel_out[7:5] <= 3'b000;
pixel_out[4] <= 1'b1;
pixel_out[3:0] <= ram_byte_h[7:4];

end
else begin

pixel_out[7:5] <= 3'b000;
pixel_out[4] <= 1'b0;
pixel_out[3:0] <= ram_byte_h[3:0];

end

end
2'h3 : begin // 16-bit (true colour)
// taking 2 sequential bytes, like the color text mode, and outputting
// a full 16 bits parallel on the output

mode_16bit <= 1'b1; // update mode_16bit output to 16-bit mode

pixel_out <= ram_byte_in[7:0];
pixel_out_h <= ram_byte_h;

end

endcase

end // 16-bit mode

end // if (pc_ena[3:0] == 0)

end // always@clk

endmodule


Here is the original working initiation of that module:

Code: [Select]
bitplane_to_raster b2r_1(

.clk(clk),
.pc_ena(pc_ena[3:0]),

// inputs
.pixel_in_ena(pixel_ena),
.ram_byte_in(char_line),
.ram_byte_h(8'b00000000),
.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] ),

// outputs
.pixel_out_ena( pixel_out_ena ),
.mode_16bit( pixel_out_top_16bit ),
.pixel_out( pixel_out_top ),
.pixel_out_h( pixel_out_top_h ),
.x_out(), // disconnected for moment
.colour_mode_out() // disconnected for moment

);


Now, we are left with you error on MAGGIE when " Creating Symbol Files For Current File " :
It's a Quartus bug, or we just don't have the ' Perfect Syntax '  Quartus is expecting.

Temporarily change the line to:
Code: [Select]
.hw_regs( GPU_HW_Control_regs[2**HW_REGS_SIZE] ),
Then 'Creating Symbol Files For Current File'.
Then change the line back to:
Code: [Select]
.hw_regs( GPU_HW_Control_regs[0:(2**HW_REGS_SIZE-1)] ),
Then compile the project.

In maggie, all these are wrong:

// registers
reg ram_read_pointer_y[19:0];
reg ram_read_pointer_x[23:0];
reg period_x[4:0];
reg period_y[4:0];
reg h_trig_delay[7:0];

The [#:#] belongs on the left side when defining a reg.  The right side is to define an array size.

I'm going to check what's up with Quartus not liking the 'regs[0:(2**HW_REGS_SIZE-1)] ' inside a function, but my trick listed above for now will work.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #715 on: December 13, 2019, 12:34:15 pm »
Found the Quartus bug,

Rename the MAGGIE.v to MAGGIE.sv
Rename the vid_osd_generator.v to vid_osd_generator.sv

Then everything works including create symbols.

« Last Edit: December 13, 2019, 12:46:44 pm by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #716 on: December 13, 2019, 12:47:45 pm »
Found the Quartus bug,

Rename the MAGGIE.v to MAGGIE.sv
Rename the vid_osd_generator.v to vid_osd_generator.sv

Then everything works including create symbols.

Well done.  It compiles!  ;D
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #717 on: December 13, 2019, 12:51:22 pm »
Do we need to make some changes to the palette_mixer now?  Your diagram shows:
  • window_ena_out
  • mode_16_bit
  • mode_565
  • pixel_out
as outputs from BART to the Palette_Mixer, but the existing palette_mixer module has no matching inputs.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #718 on: December 13, 2019, 01:03:07 pm »
Do we need to make some changes to the palette_mixer now?  Your diagram shows:
  • window_ena_out
  • mode_16_bit
  • mode_565
  • pixel_out
as outputs from BART to the Palette_Mixer, but the existing palette_mixer module has no matching inputs.
Next week, for now, just feed 8 bits of the current pixel out.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #719 on: December 13, 2019, 01:08:10 pm »
Found the Quartus bug,

Rename the MAGGIE.v to MAGGIE.sv
Rename the vid_osd_generator.v to vid_osd_generator.sv

Then everything works including create symbols.

Well done.  It compiles!  ;D
Did you check for a picture?
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #720 on: December 13, 2019, 01:12:58 pm »
Okie dokie, well that seems to be working okay.  Has gone back to the old way of setting colours via HW_REGS[10].
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #721 on: December 13, 2019, 01:19:30 pm »
Arrrg, again, why?

Line 225 in vid_osd_generator:

      gfx_pixel <= pixel_out[7:0];

Erase that line!!!

Line 190:
   .pixel_out( pixel_out ),

Change that to :
.pixel_out( gfx_pixel ),


Lines 18 through 22:
   output reg osd_ena_out,
   output reg window_ena_out,
   output reg pixel_out_top_16bit,
   output reg [7:0] pixel_out_top,
   output reg [7:0] gfx_pixel,

Are all supposed to be 'WIRE', though except for the gfx_pixel fiasco, quartus automatically converted them to wires when compiling.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #722 on: December 13, 2019, 01:35:01 pm »
All sorted, image is good.  :-+
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 8143
  • Country: ca
    • LinkedIn
Re: FPGA VGA Controller for 8-bit computer
« Reply #723 on: December 13, 2019, 03:58:16 pm »
Here we go.

In that attached files, you have:
GPU_256char_font_MAGGIE_beta.zip    -> With a rudimentary MAGGIE address generator & other bug patches.
RS232_Debugger_Quick_file_MAGGIE_test.zip -> Quick load binary files which setup & turn on the new MAGGIE.

Changes I made to 'GPU_256char_font'.

1. Fixed a bug in the palette_mixer module.
    I for some reason had to assign the wire 'alpha_blend' to an 'integer' which I called blend.  This was connected with the '* (15-alpha_blend[3:0])' bug from a few days ago.  The multiply function seems to want an 'integer' in the math, otherwise it returns a '0' which made the second line on the mixer which didn't have the '15-' return a black image.

2.  Changed the 4444 text layer palette's .mif so that color 1, blue, is now semi translucent to the graphics layer below.  Color 0, black, is fully transparent.

3.  Changed the 565 palette's .mif so that color 255 is now white instead of black.

4.  Removed all the yellow H&V_Trigger cursors except for the first 4 of them.

5.  Added a code making rudimentary MAGGIE address generator:
    a) Moved the H&V resets to HV_trigger to 8, address 0x3F10, 0x3F12.             (do not touch)
    b) Moved the H&V window starting HV_trigger to 10, address 0x3F14, 0x3F16 (you can play with these)
    c) Base address 0x3F60 begins the MAGGIE controls.
        keep the BP2RAST setting the same
        play with RST_ADDR, YINC_ADDR, X_SIZE, Y_SIZE.  These are the only variables which function.

For now, use 8 bit color setting.

HV_trigger 10/11 tells MAGGIE where to position the top left coordinates of the window.

X_SIZE & Y_SIZE tells MAGGIE how many pixels wide and tall it's open window will be on the screen.

RST_ADDR tells MAGGIE the beginning byte position of the source bitmap graphics data.  You can write to this setting to also scroll horizontally and vertically the shown bitmap graphic inside the open window.

YINC_ADDR tells MAGGIE the width of the source bitmap graphics data in bytes.

Give me a report.


« Last Edit: December 13, 2019, 05:10:44 pm by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #724 on: December 13, 2019, 08:22:37 pm »
Hmm.. okay, so I've downloaded the project, compiled and flashed it to the FPGA and downloaded and loaded the binaries into RS232_debugger.  This is what I'm getting:

889170-0

I'm able to move it around, resize the overlay window etc. but I can't get a sensible image out of the overlay.  I haven't changed anything, I've just copied the project into a new folder and compiled it in Quantus Prime.  :-//  Also, it seems both quick binaries for the RS232_debugger are identical?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf