QNICE-FPGA icon indicating copy to clipboard operation
QNICE-FPGA copied to clipboard

Discussion: Increase VGA resolution to 1280x1024 ?

Open MJoergen opened this issue 3 years ago • 4 comments

The recently added feature of fractional pixel scaling lead me to wish for a higher resolution VGA output.

My first thought was whether our VHDL implementation can support such a higher resolution, since it requires a pixel clock of 108 MHz (as opposed to the current 25,2 MHz), i.e. over 4 times faster?

So I did a quick test, where I connected the VGA module to the board system clock of 100 MHz (close enough for a quick feasibility study). I found that the VHDL implementation indeed can run at 100 MHz, provided some adjustments are made in the implementation, specifically by inserting some more flip-flops in the text mode and sprite pipelines. The architecture of the VGA module is much simpler than that of the (pipelined) CPU, so there should not be much work involved in these particular modifications.

But before I go any further, do we really want this feature? Because it will require changing the font (or will it?), and lots of other things (including documentation and emulator) that I can't quite predict right now. And what about WASM?

One thing I notice is that the increased resolution is precisely double the horizontal size and close to double the vertical size. So we could keep the rest of the design the same, and simply "double" the pixels both horizontally and vertically. Again, I'm not sure what the implications are, so therefore this call for discussion.

MJoergen avatar Nov 11 '20 08:11 MJoergen

Good question - I don't have any preferences here to be honest. What impact would this increase have on the memory requirements?

bernd-ulmann avatar Nov 11 '20 09:11 bernd-ulmann

Memory is a tough issue and a scarce resource. If we go for full bitmap graphics with 4 bits per pixel (16 colors), then that requires 1280x1024x4 / 16 = 328 k words. The current design has a corresponding memory requirement of 640x400x4 / 16 = 64 k words. So anything larger than the current design will require a lot more memory, and even addressing that memory will be problematic with only 16 address bits.

But we don't have to do that. We can keep the existing bitmap graphics (which BTW are not yet implemented) and scale up the each pixel by 2x2. So we would get 1280x800 screen pixels and some extra space at the top and bottom of the screen.

MJoergen avatar Nov 11 '20 09:11 MJoergen

While I find this a really cool idea - particularly also given our "competition" out there and the really good looking visual quality that a higher resolultion would bring, I am strongly opposing this for V1.7.

Here is why:

  • Font needs to be changed, otherwise it will look blurry.
  • Bitmap graphics: We want to have it and now this mode would eat a ton of memory
  • Emulator performance: We currently have some very unoptimzed situations in the emulator such as (issue #103) and others. Going to such a high resolution will amplify these kind of problems.
  • One challenge after the other without creating too many loose ends: We have not yet solved issue #156 which also needs some work in the Emulator. Given our limited resources, fixing #103 and #156 is more important.
  • WASM: Embedding on websites needs more screen space and therefore might need additional JavaScript or HTML mechanisms to cater for that (not speaking about performance)
  • Sprites: Right now, we are able to bundle together a few sprites to create for example a nice large space ship on the screen. If we increased the resolution, we need to bundle together much more sprites to get a nice large space ship on the screen and that eats up sprite memory and main memory
  • In general, a machine with such little RAM than ours is not poised to handle such large screens: Where would you store bitmap patterns of any background graphics you would like to show?
  • Plus: There are even more loose ends and TODOs that this would create: I want to remind you that these kind of fundamental changes always add a long-tail of tasks that only bubble to the top, as soon as we start with them.

I would say: I want this feature, but after V1.7 (which I renamed to V2.0 due to our email discussions we had).

sy2002 avatar Nov 11 '20 09:11 sy2002

@sy2002 I appreciate your input. This too is my gut feeling that the time is not right. I'll leave this issue as is, but keep it open as a placeholder in case circumstances change.

MJoergen avatar Nov 11 '20 10:11 MJoergen