Direct vMem manipulation?

If you have feature requests, this is the place to post them. Please note your idea may already be something we have already discussed and decided against, or something we are working on privately, and we cannot be held responsible for any similarities in such instance. Whilst we cannot respond to every suggestion, your idea will be read and responded to where possible. Thank you for your input!
SerErris
Posts: 172
Joined: Sat Aug 08, 2020 9:18 am

Direct vMem manipulation?

Post by SerErris »


The future will tell how much of a constrain is to have no direct access to the memory with the CPU one one hand and the demand to do everything with the CPU in VRAM on the other hand.  Copying larger areas of VRAM will be painful (anyhow as it is a CPU task) but esp. with the VERA implementation as only some structured copy will work efficient with the auto increment. If you need to copy blocks of memory in an X/Y fashion it will require frequent write to the VERA ADDR registers and that will slow down the process. So I assume TILE Mode is the mode to go for anything that needs frequent movement/copying as it can be done in a different way with very low amount of data movement from CPU to VRAM.

BruceMcF
Posts: 1336
Joined: Fri Jul 03, 2020 4:27 am

Direct vMem manipulation?

Post by BruceMcF »


Exactly, that is the design goal. They already had a perfectly capable stack machine co-processor in the Gameduino, and not having a coprocessor in the "Video Chip" seemed like part of the design criteria when the call went out for fresh designs on more recent, non-obsoleted FPGA's.

Ingenuity is the key. You can have a tile based starship command deck, with "display portals" that are animated bitmaps done by reserving a set of font bitmaps for the bitmap graphics. The layout on the screen does not determine how easy it is to update them with the auto-increment ... the layout of the chosen tiles in the font bitmap does.

Post Reply