FPGA VGA Controller for 8-bit computer

[nockieboy]

...Shifting it to the left 1 pixel at a time will not make the right hand side vertically jump except all the way on the right hand side of the window.

Okay, well that's what I'm seeing then - way over at the right-hand side of the window, the image is re-appearing, but one line higher.

I'm curious, have you ever programmed direct HW registers for a video display on an Atari 800, or Amiga?  Did you not know this is how their internal video processors work the same way.  Or are you just used to library calls with do this control 'bit' manipulation under the hood?

I've never done anything like this in my life!  Closest I got to the hardware on the Amiga was with Blitz Basic 2 when I wrote a Scorched Earth clone and some other basic games instead of studying.  So, not even vaguely close.  I hadn't even really touched assembly on my Amstrad as a kid; I've learned the vast majority of what I know in the last two years working on my DIY computer.  It's been a learning curve! 

Nope, that's wrong.  Right now, every time the horizontal address needs to increase, every 8, 4, 2 ,or every pixel, it increments by 1 address.  Meaning, 1 byte at a time.  We need to double this addition once every 8, 4, 2, or every pixel.  This has nothing to do with the vertical increment as that setting specifies the number of horizontal bytes you source image is.  So, naturally you would just have the correct number set there by the Z80 defining the number of bytes per line in the source graphic.  This is not what I am asking.  When MAGGIE is drawing the image, as it requests every single pixel, when the 16bit setting is high, it needs to recognize that every pixel is 2 bytes (16 bit) wide, not 1 byte.  How will you adapt MAGGIE to handle this.

Ah okay, back to the drawing board. 

[BrianHG]

Now I want you to think out of the box here.  Having the ram read address increment 2 for every 1 pixel instead of 1 for every 1 pixel, yet not touch the sub-bitplane-pixel counter isn't hard with a little thought.

[nockieboy]

It's no good, I've gone code-blind staring at MAGGIE trying to work out exactly WHERE ram_read_pointer_x is incremented by one pixel.     

Should I be looking to make changes in the if (run_x) begin block?

Also notice inc_addr_x isn't used at all?  Is that for a later feature?

[BrianHG]

Yes, the ram read pointer is being incremented inside the if(run_x).
At line 174.

But if you think about it, you might run into trouble here as the sub-pixel X position is also buried into the X increment here.  You don't want to alter how the bit-plane sub pixel positioning is generated.

Try looking at line 98.  You might be able to come up with a few ideas there.

[nockieboy]

Yes, the ram read pointer is being incremented inside the if(run_x).
At line 174.

But if you think about it, you might run into trouble here as the sub-pixel X position is also buried into the X increment here.  You don't want to alter how the bit-plane sub pixel positioning is generated.

Try looking at line 98.  You might be able to come up with a few ideas there.

Okay, so here's what I'm thinking.  This is where the ram_read_pointer is incremented by a value relating to the mode (line 183 in my MAGGIE):

Code: [Select]

ram_read_pointer_x <= ram_read_pointer_x + 2**pixel_per_byte;
If MAGGIE is operating in 16-bit mode, this needs to add another 8 bits on this line?  So something like this?

Code: [Select]

ram_read_pointer_x <= ram_read_pointer_x + 2**pixel_per_byte + 8 * pixel_16_bit;

[BrianHG]

Yes, the ram read pointer is being incremented inside the if(run_x).
At line 174.

But if you think about it, you might run into trouble here as the sub-pixel X position is also buried into the X increment here.  You don't want to alter how the bit-plane sub pixel positioning is generated.

Try looking at line 98.  You might be able to come up with a few ideas there.

Okay, so here's what I'm thinking.  This is where the ram_read_pointer is incremented by a value relating to the mode (line 183 in my MAGGIE):

Code: [Select]

ram_read_pointer_x <= ram_read_pointer_x + 2**pixel_per_byte;
If MAGGIE is operating in 16-bit mode, this needs to add another 8 bits on this line?  So something like this?

Code: [Select]

ram_read_pointer_x <= ram_read_pointer_x + 2**pixel_per_byte + 8 * pixel_16_bit;

Still thinking inside the box... 

Unfortunately, with your code, when in 1 bitplane mode, 16 bit pixel, you will increment the X address every pixel, plus increment the X address twice every 8th pixel.  With a 16 bit data pixel, we would still want the X to increment twice every 8 pixels, but not during the middle of the 7 pixels of the bitmap.

Take a long hard look at line 98 once again and ask yourself, this read address increases by 1 at the right time, in 16 bit mode, when it increases by 1, I want it to increase by 2 instead...

[nockieboy]

Unfortunately, with your code, when in 1 bitplane mode, 16 bit pixel, you will increment the X address every pixel, plus increment the X address twice every 8th pixel.  With a 16 bit data pixel, we would still want the X to increment twice every 8 pixels, but not during the middle of the 7 pixels of the bitmap.

Take a long hard look at line 98 once again and ask yourself, this read address increases by 1 at the right time, in 16 bit mode, when it increases by 1, I want it to increase by 2 instead...

Okay, so I tried this:

Code: [Select]

assign read_addr[19:0] = ram_read_pointer_x[22:3] + 8*pixel_16_bit;
Didn't work.

And I tried this in if (run_x) begin:

Code: [Select]

if (width == 0) begin

ram_read_pointer_x <= ram_read_pointer_x + 8*pixel_16_bit;

end

Didn't work.

The idea being with the above piece of code was to add 8 bits to the pixel address pointer at the end of the tile...    I think the problem is, I don't fully understand what the existing code is doing.  If I did, I'd see the bigger picture and probably find the solution, even if it's not the most efficient way to do what you're asking.  But as it is, I'm almost groping in the dark for the solution.

So, I want MAGGIE to read a pixel, which is represented in memory by 1, 2, 4 or 8 bits.  In 8-bit mode, the next pixel immediately follows on from the current one, so line 184 handles this increment to the next pixel, incrementing ram_read_pointer_x by 1, 2, 4 or 8 bits according to the mode.  However, in 16-bit mode, the pixel size remains the same (either 1, 2, 4 or 8 bits in size, specified by the 2 LSBs), but for each increment we need to skip a byte which contains palette or colour information??

This is my understanding of how MAGGIE is working, in a nutshell and to me the solution is to change line 184 to add 8 bits to ram_read_pointer_x every time it increments to skip the current pixel's associated palette/colour byte??  This means:

Code: [Select]

ram_read_pointer_x <= ram_read_pointer_x + 2**pixel_per_byte + 8*pixel_16_bit;
...but then I remember that for all the sub-pixels in the same tile, they share the same colour/palette byte, so incrementing by the extra 8 bits isn't necessary until the end of the tile.  But then I'm getting confused with tiles, sprites and variable widths, etc.  But where in the code does the 'end of tile' trigger occur?

 

I'm off to bed. Perhaps all this might make more sense tomorrow. 

[BrianHG]

Ok, I'll give you half of this one.  Line 98 should be:

assign read_addr[19:0]      = ram_read_pointer_x[22:3] << pixel_16_bit;

This multiplies the ram read pointer address by 2 when in 16 bit mode.
Now, you need to patch 4 other lines so that the read address is still correct during reset and image width setting.  See lines 137,138, & 146,147.

If you coded things correctly, when viewing my 256 color test image, enabling the 16 bit mode should horizontally shrink the image in half with a replica image to the right of it shifted up by 1 line.

If you got this working, we will tackle the getting rid of the old OSD text and wire in 2 MAGGIES in it's place to generate text, including color text.  Then, the palette mixer will need re-working to accept 5 inputs.

[nockieboy]

Ok, I'll give you half of this one.  Line 98 should be:

assign read_addr[19:0]      = ram_read_pointer_x[22:3] << pixel_16_bit;

This multiplies the ram read pointer address by 2 when in 16 bit mode.

  Now this is where bit operations start to look like a dark art to me.    ram_read_pointer_x is a 20-bit address, pointing to the current pixel.  Bit-shifting that value left 1 place if in 16-bit mode doubles the value, why would that doubled value point to the next byte?

If ram_read_pointer_x is, e.g., 0x40 - doubling that to 0x80 via a <<1 operation won't point to the next byte, it'll point to an arbitrary area of RAM, an increasing distance from the previous memory location as the address increases?  If ram_read_pointer_x is operating anywhere in the top half of memory, this operation will put the pointer out of bounds, surely?   

EDIT:  Ignore the above - boy did my thoughts go off on a tangent there!! 

Of course it won't double the number (at least not in the sense that it will exceed the top of memory) as it's capped at 20 bits.

Now, you need to patch 4 other lines so that the read address is still correct during reset and image width setting.  See lines 137,138, & 146,147.

Our line numbers are out of sync - 147 is an empty line, and the others don't make much sense.  Rather than try to guess which lines you're talking about (139,140 and 151, 152 presumably), here's the latest version of MAGGIE; if you use this one, the line numbers you're quoting will match up to what I'm seeing.

EDIT:  I'm off to go learn more about bit-shift operations (well, the concepts we're dealing with more than the operations themselves).   There's clearly a hole in my understanding here.  But bit-wise tantrum aside, here's what I've done with MAGGIE to get 16-bit mode working as you've specified:

Code: [Select]

Line 139: ram_read_pointer_y <= (reset_addr << (3 - pixel_16_bit)) + period_x_rst; // V_TRIG is high during the first active line of video, set the read pointer, both
Line 140: ram_read_pointer_x <= (reset_addr << (3 - pixel_16_bit)) + period_x_rst; // the backup and currrent display address to the exact reset base address + x_offset during this line

Line 151: ram_read_pointer_y <= ram_read_pointer_y + (inc_addr_y[15:0] << (3 - pixel_16_bit));  // vertical increment display position in backup buffer
Line 152: ram_read_pointer_x <= ram_read_pointer_y + (inc_addr_y[15:0] << (3 - pixel_16_bit));  // vertical increment display position in current display address

I've just countered the doubling of ram_read_pointer by only shifting it left twice instead of 3 times in 16-bit mode.  Seems to work - the image is doubled, as you stated. 

[nockieboy]

Just in case you want photographic evidence. 

8-bit mode:


16-bit mode:

[BrianHG]

Ok, you got that all correct.

Now, 1 last thing before making wiring the MAGGIE into text mode.  A font 'Y' coordinate counter.

This one is weird as it sort of sits in parallel with the 'Y' period counter, but, it needs to either be off, count between 0 and 7, or 0 and 15.  It needs to increment after every number of period sequence counts for the 'Y' scale, yet, it also needs to prevent the height, height_count and inc_addr_y[15:0] from taking place until it reaches it's end.

Lets add an assign:
assign font_y_size[3:0] = hw_regs[Y_SCALE][7:4];

font_y_size will define the height of the font.  With this, you should be able to define a font tile size of '0' being 1 line font, to 15, being a font 16 lines tall.

The second assign will be: (It is actually taking the place of the 'period_y_rst[3:0]')
assign font_y_rst[3:0] = hw_regs[Y_START_SUB][3:0];

This reset position will define the beginning first line to be shown of the font at the top left hand of the window.  It performs the equivalent function to the bitplane's period_x_rst.


Now, you will also need a reg:
font_y_pos[3:0]

This reg will reg will hold the counter of the current display's font's 'Y' coordinates.

Let's see how you weave the font Y position into the current 'Y' coordinate counting system.  Unfortunately, there is nothing for you to display and if you haven't set up a simulation, you will have to guess/assume your results as a vertical font size of '7' ie 8, should stretch your picture vertically 8 fold.

To properly test this, we would need to wire the 2xMAGGIEs in place of the current text generator, assign the font Y coordinates to the cmd_out, and make the font 'SLAVE' mode in the second MAGGIE receive the command in, process it's base address with the incoming memory character data and font Y coordinates buried in the cmd_in port, and generate a new output address to sen to the memory to read a second time to fetch the font image to send to the BART for display.

This is the last of the truly tricky stuff.  Once done, we will fix up the palette mixer to handle multiple inputs, combine the 2 palettes (4444 & 565) into 1 larger palette and touch up how the layers are blended.

[BrianHG]

Ok, I'll give you half of this one.  Line 98 should be:

assign read_addr[19:0]      = ram_read_pointer_x[22:3] << pixel_16_bit;

This multiplies the ram read pointer address by 2 when in 16 bit mode.

  Now this is where bit operations start to look like a dark art to me.    ram_read_pointer_x is a 20-bit address, pointing to the current pixel.  Bit-shifting that value left 1 place if in 16-bit mode doubles the value, why would that doubled value point to the next byte?

If ram_read_pointer_x is, e.g., 0x40 - doubling that to 0x80 via a <<1 operation won't point to the next byte, it'll point to an arbitrary area of RAM, an increasing distance from the previous memory location as the address increases?  If ram_read_pointer_x is operating anywhere in the top half of memory, this operation will put the pointer out of bounds, surely?   

EDIT:  Ignore the above - boy did my thoughts go off on a tangent there!! 

Of course it won't double the number (at least not in the sense that it will exceed the top of memory) as it's capped at 20 bits.

Now, you need to patch 4 other lines so that the read address is still correct during reset and image width setting.  See lines 137,138, & 146,147.

Our line numbers are out of sync - 147 is an empty line, and the others don't make much sense.  Rather than try to guess which lines you're talking about (139,140 and 151, 152 presumably), here's the latest version of MAGGIE; if you use this one, the line numbers you're quoting will match up to what I'm seeing.

EDIT:  I'm off to go learn more about bit-shift operations (well, the concepts we're dealing with more than the operations themselves).   There's clearly a hole in my understanding here.  But bit-wise tantrum aside, here's what I've done with MAGGIE to get 16-bit mode working as you've specified:

Code: [Select]

Line 139: ram_read_pointer_y <= (reset_addr << (3 - pixel_16_bit)) + period_x_rst; // V_TRIG is high during the first active line of video, set the read pointer, both
Line 140: ram_read_pointer_x <= (reset_addr << (3 - pixel_16_bit)) + period_x_rst; // the backup and currrent display address to the exact reset base address + x_offset during this line

Line 151: ram_read_pointer_y <= ram_read_pointer_y + (inc_addr_y[15:0] << (3 - pixel_16_bit));  // vertical increment display position in backup buffer
Line 152: ram_read_pointer_x <= ram_read_pointer_y + (inc_addr_y[15:0] << (3 - pixel_16_bit));  // vertical increment display position in current display address

I've just countered the doubling of ram_read_pointer by only shifting it left twice instead of 3 times in 16-bit mode.  Seems to work - the image is doubled, as you stated. 

You are thinking of this the wrong way.  I'm multiplying the read address by 2.  So, if you start at read address 0, then increase to 1, then increase to 2, then 3, the output will be 0, 2, 4, 6.  IE, every increment of 1 jumps 2 instead.

Now, the initial starting address, and Y increment every line, those we are dividing by 2, so when beginning a line, they also begin the memory address at the right position.

However, you may notice that we have lost the first address bit, or, the possibility of addressing ODD pixels here.  This is fine.  We will not be starting a display's memory address at an ODD memory location when using 16bit wide pixels.  Sort of like when using a 68000 to copy & manipulate 16bit pointers.  It also wants even word aligned address pointers.

[nockieboy]

Now, 1 last thing before making wiring the MAGGIE into text mode.  A font 'Y' coordinate counter.

This one is weird as it sort of sits in parallel with the 'Y' period counter, but, it needs to either be off, count between 0 and 7, or 0 and 15.  It needs to increment after every number of period sequence counts for the 'Y' scale, yet, it also needs to prevent the height, height_count and inc_addr_y[15:0] from taking place until it reaches it's end.

Lets add an assign:
assign font_y_size[3:0] = hw_regs[Y_SCALE][7:4];

font_y_size will define the height of the font.  With this, you should be able to define a font tile size of '0' being 1 line font, to 15, being a font 16 lines tall.

The second assign will be: (It is actually taking the place of the 'period_y_rst[3:0]')
assign font_y_rst[3:0] = hw_regs[Y_START_SUB][3:0];

This reset position will define the beginning first line to be shown of the font at the top left hand of the window.  It performs the equivalent function to the bitplane's period_x_rst.


Now, you will also need a reg:
font_y_pos[3:0]

This reg will reg will hold the counter of the current display's font's 'Y' coordinates.

...it needs to either be off, count between 0 and 7, or 0 and 15.

How is this decided?  Which HW_regs value am I using (if any) to set this behaviour?  Is this based on the screen mode?

Right, time is short for me these next few days so I'm going to try to make small changes in the time I have and post them up here for checking.  I've added the wire and reg you've mentioned above, and also the counting system to increment font_y_pos.  That's all it does at the moment - no checks or actions - it just increments the counter (hopefully in the right positions!)

[BrianHG]

Ok, to begin, ok so far.  Yes, implementation is all messy.

The 'font_y_pos' limit is set by the  font_y_size hw_reg.  Having a  font_y_size of 0 means every new line is a new vertical address increment, or just call that mode 'OFF'.  Setting the  font_y_size to 7 means the Y font_y_pos will count from 0, 1, 2,... 7 before a inc_addr_y.  This means you font has 8 vertical position, or a font of 8x8.  Also, don't forget with the period_y setting, each of those 8 positions may be repeated 1, 2,3,4,...16 times stretching out you text vertically.

[nockieboy]

Some changes made around lines 160-180 to reset font_y_pos at the right time.  I'm not convinced it's right, though, as I'm confused about what is required and how to implement it.

So font_y_pos should increment on each pc_ena[3:0]==0 clock, if run_y is true, and not allow increments to height_count unless font_y_size is zero or font_y_pos == font_y_size, in which case allow a vertical increment to occur..... hmm.  No, I'm confused about this bit.  The whole if (run_y) begin block needs a close look at - this is where I'm presuming all the font_y_pos tweakery goes on, but I'm unsure what I should be doing.  I'd need a whole day to filter out the conditions of what you're asking for, then to try to understand MAGGIE in more detail than I do currently to then make the modifications to get it all to work as you want.  I'm struggling with time at the moment. 

[BrianHG]

Since you arent simulating, you are going to have to wire everything in.
Remove the old OSD text and wire in 2 MAGGIEs on the first 2 read ports, assign H&V + normal HW regs for each, and on the second MAGGIE's ram output, wire that one's BART's output into the palette mixer's text layer input and begin to play, except, the current MAGGIE is missing the function to receive the last MAGGIE's memory character and point to a font memory address.

[nockieboy]

Remove the old OSD text and wire in 2 MAGGIEs on the first 2 read ports...

So when you say 'remove the old OSD text', are you just talking about disconnecting read_text_addr and read_font_addr from the gpu_RAM in the vid_osd_generator, or completely replacing the vid_osd_generator with a module that handles the two MAGGIEs?

...assign H&V + normal HW regs for each, and on the second MAGGIE's ram output...

That would be the data_out#x from the gpu_RAM to the BART, right?

...wire that one's BART's output into the palette mixer's text layer input and begin to play, except, the current MAGGIE is missing the function to receive the last MAGGIE's memory character and point to a font memory address.

  Will have a go this weekend...

[BrianHG]

https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg2826458/#msg2826458

Since your current palette mixer has only 2 inputs, you will have to use the second MAGGIE's/BART's read channel to feed the first input of the current 2 channel palette mixer.

[nockieboy]

https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg2826458/#msg2826458

Already using it. 

[BrianHG]

Since your current palette mixer has only 2 inputs, you will have to use the second MAGGIE's/BART's read channel to feed the first input of the current 2 channel palette mixer.

[nockieboy]

I just don't have the time to put into this at the moment.  I started trying to wire up the two MAGGIEs and their BARTs in the vid_osd_generator a few days back and have come back to it to work on it again for half an hour and spent that time trying to work out where I was with it all instead of progressing it further. 

Doesn't help that I feel what you've asked me to do should be easy, but I'm struggling with it and feel that I've used up my question quota and should understand it all by now. 

[BrianHG]

Merry Christmas,

I've done a huge deal of work for you, something like 2-3 months worth based the current trend.

Here is all the work I have done:

Increased ram to 28672 bytes + 1024 bytes for the palette filling out your current Cyckone IV.

The main GPU ram begins at address 0 and reads/writes up until byte 28671. (address $6FFF).

The palette is currently stored at $007C00 through $007FFF.  The first 512 bytes is the ARGB 4444 palette while the second 512 bytes is the RGB 565 palette.

HW_regs now begin at address $006F00 through $6FFF.

MAGGIE code has been patched and text_mode_master/slave have been implemented.

Added MAGGIEs 0 through 4, 5 graphics layers in total.

When presenting bitmap/tile windows, the top MAGGIE, lower MAGGIE # has higher priority / sits above the lower ones.

All of the MAGGIEs have their HV resets set to HV_Trigger 8 & 9.

MAGGIE H&V top left window position begin with MAGGIE 0 @ 10 & 11.  Increase each HV trigger pair for each sequential MAGGIE.

MAGGIE 0 control HW_regs + 128 bytes, for 16 bytes.  Increase 16 bytes for each sequential MAGGIE.

When using text/font/tile mode, 2 adjacent MAGGIES must be used.  The first one must have the 'text_mode_master' bit set in the 'BP2RAST_cmd' while the second MAGGIE must have the 'text_mode_slave' bit set in the 'BP2RAST_cmd'.  The 'BP2RAST_cmd' video mode in both must match except in the master where the BP2RAST_cmd video enable [4] must be disabled, otherwise you will get junk on the screen.

The 16 control bytes for the 'text_mode_master' MAGGIE points to the text/tile IDs.  All other controls are identical as when using it as a bitmap graphics window.  The 'font_y_size', combined upper bits of '{hw_regs[Y_START_SUB][7:6],hw_regs[Y_SCALE][7:4]}' in the text_mode_master which must also be set to the font/tile height -1. EG: 0=1 line, 7=8lines, 15=16lines, 31=32lines when in text/font/tile master mode...

For the 'text_mode_slave' MAGGIE, the only functioning 4 controls are the 'reset_addr' which now points to the base memory address of the font/tiles graphics data, period_x[4] which defines a font being 16 pixels wide when set, or, 8 pixels when low, period_x[3:0] which mask out the upper bits for fonts/tile addressing for 256, 512, 1024, 2048, 4096 characters (used in 16 bit addressing mode, otherwise set these bits to 0), period_y[1:0] which defines the font height, 0=8, 1=16, 2=32, 3=64 lines tall, and 'BP2RAST_cmd' which should match the text_mode_master MAGGIE settings except for the master and slave bit.

All base memory address settings should be on an even byte when using 16 bit mode.  Fonts/tile graphics data should always begin on an even byte address.

BART has been patched to embed the .window_ena_out,.mode_16bit,.mode_565 into it's .pixel_out bus.

Palette_mixer has been updated to receive the new BART's .pixel_out bus with the embeded .window_ena_out,.mode_16bit,.mode_565.
The palette is now 512 entries wide, with the 4444 color palette occupying the first 256x16 entries while the 565 palette occupies the second 256x16 entries.
It also now has 5 inputs which get mixed together to form 1 output.

This means without text, you can mix 5 on-screen sprites, or, 1 text layer and 4 sprites.
Other than a ram limitation, there are no other output limitations.  Any mode ant any res with any palette may be all mixed simultaneously onscreen.

Right now, I disables the linear translucent alpha blending for a basic transparent of opaque pixel on each sprite layer until I figure out a good way to accomplish this across multiple layers without filling up your tiny FPGA.  Maybe we can reserve the alpha blend technique for 2 sets of different paired layers while going back to basic stencil layering between all the remaining layers.

I'm having trouble with clock domain crossing in trying to get the 2x core GPU ram working which will give you all 15 graphic layers.  Running everything at 2x clock would be simple, but I don't have the time to optimize your code to make this cyclone run at 250MHz.

Let's see if I can find the bug over the next day or 2.

Everything else is ready for you to get you Z80 running.

See the attached files and check the RS232_debugger quick load files which have a 16bit color text demo with 3 additional scaled sprites onscreen.  Photograph to make sure that everything works.  If you want nicer graphics, you will have to start generating you own files...

[BrianHG]

There has been so many changes, you will need to throw out your old project folder.

[nockieboy]

Wow - thank you so much!!   

Okay, so I've got some documentation to do and some work on the Z80 interface (the mux with the RS232_debugger interface is nowhere near done yet) and it's done. 

Merry Christmas to you too!! (and anyone else reading this!)





In the image above, the white fade-out on the right-side of the Z80 image isn't a photographic artefact - could that be caused by capacitance in the output wires?

[BrianHG]

In the image above, the white fade-out on the right-side of the Z80 image isn't a photographic artefact - could that be caused by capacitance in the output wires?

Strange.  Since I'm using a real DAC, I see nothing but a perfect image on my end.  Maybe something happened with the IO current strength settings, or, too much on screen for the the method of the analog dac.

When you have time, see if you can get a scope shot.

BTW, I now have all 15 layers working now on my side, but, your Cyclone IV is too small.  Maybe I will come up with an idea.  1 Cyclone larger and 15 would be no problem on your side too as you are ran out of logic cells and ram needs to shrink to fit the design as well.