Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: Increase VGA resolution to 1280x1024 ? #188

Open
MJoergen opened this issue Nov 11, 2020 · 4 comments
Open

Discussion: Increase VGA resolution to 1280x1024 ? #188

MJoergen opened this issue Nov 11, 2020 · 4 comments
Assignees
Labels

Comments

@MJoergen
Copy link
Collaborator

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.

@bernd-ulmann
Copy link
Collaborator

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

@MJoergen
Copy link
Collaborator Author

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.

@sy2002 sy2002 added the V2.0 label Nov 11, 2020
@sy2002
Copy link
Owner

sy2002 commented Nov 11, 2020

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 Emulator: Optimize vga_refresh_rendering() for VGA_FONT_DATA and VGA_PALETTE_DATA #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 VGA Emulator: Dynamic aspect ratio #156 which also needs some work in the Emulator. Given our limited resources, fixing Emulator: Optimize vga_refresh_rendering() for VGA_FONT_DATA and VGA_PALETTE_DATA #103 and VGA Emulator: Dynamic aspect ratio #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).

@MJoergen
Copy link
Collaborator Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants