Is it possible to access the video memory directly from the c++ sketch?
It seems to me that using the VidorGraphics library is rather slow for the space invaders game I am trying to program. I understand that when I use VidorGraphics methods all commands are passed to the FPGA with the Mailbox and that in this way plotting a single pixel takes allmost the same time as filling a rectangle, and it is just to slow to make any smooth rendering of multiple objects.
I did try the GFX library in the thread Vidor GFX rasterizer but couldn't get it to work.
So...
Is it possible to access the video memory directly from the c++ sketch?
or is there another way to squeeze more operations to the Video output during af frame?
oldhandmixer:
I did try the GFX library in the thread Vidor GFX rasterizer but couldn't get it to work.
How exactly it didn't work?
For the lib basis I've used the library sources and examples provided with the VidorBitstream repository, and not the one available from arduino ide libraries. And I've just replaced VidorGraphics lib in arduino ide libraries path with the files resulting from building MKRVIDOR4000_graphics project.
As for the direct memory access - no, there's none.
Jtag mailbox is quite slow. If you want some really fast writes into sdram, you'd make a custom interface to FPGA, spending a lot more parallel lines between SAMD and FPGA, losing the board's pins, because they would be shared with lines you will use for fast bus to FPGA.
To make it all faster, ideally you'd want to perform only high level functions/commands on SAMD (like request to blit a preloaded sprite to the specified location), and move all your low level operations into the fpga. Means writing more code for embedded Nios cpu, and maybe building additional hw in verilog/vhdl, doing some more specific tasks. Writing to memory is extremely primitive operation, performed many times. The serial link between SAMD and FPGA becomes a bottleneck.
If you don't have any experience with HDL and FPGA, then yeah, there's not much options left.
Maybe you will tell what higher level tasks you would need from fpga to build a game? Think of FPGA as of some kind of GPU, and not as of video framebuffer.
Thanks for your reply.
I had hoped that the FPGA and the SAMD shared a chunk of memory, and yes that there would be some blit operations.
It seem that if I want to program a video game or a demo it has to be 100% FPGA to get smooth animations, double buffering and blitting. I guess I have some learning to do 8)
It doesn't have to be 100% FPGA 
The game's logic should stay on SAMD, and FPGA would serve as a GPU and "disk" controller with onboard flash chip.
But there's no shared memory, can't be.
It's two separate chips, linked with 27 (including clock and reset) lines, with 24 of them being exposed as board's pins, or used for on-board i2c bus.
By sacrificing the board's pins it's possible to build fast 16-bit bus, multiplexing the data/address.
Or having small address space (like 4-bit), only for GPU registers, and sending big data over wide 16-bit serial interface, but you'll need to learn first to design and implement it.