BASIC support for odd screen sizes
Posted: Sat Apr 25, 2020 7:03 am
Hi all,
nothing like a global shutdown to bring some ideas to fruition. I've been tinkering with this over the last week or so, if something else that does this already exists, please feel free to stop me immediately!
I'm working on a wedge that will enable full 'native' support of different screen sizes. As you would know, the VIC-I is a very versatile chip, in that it allows the user to select any screen size they wish. This is an excellent feature, and pretty unique for machines of that time. Unfortunately, the Vic's firmware only supports a screen size of 22 columns by 23 lines.
On NTSC screens, I understand the borders are quite small, so it's not really possible to make the screen too much larger before the characters disappear out of sight (24 or 25 columns by 27 or 28 rows of 8-pixel characters). On PAL screens, the borders are much larger, and depending on the screen, it's normal to be able to fit 28 or 29 columns by 35 or 36 rows. I get 28 columns by 36 rows on my modern LED screen, and that is also what you will see on many emulators including VICE.
There are numerous 40 column software solutions (among others) and they work - but being 'bitmap' solutions they use a lot of memory and slow the processor down considerably, not to mention the colour map gets thrown out and sometimes the readability suffers as well.
Edit : The program now does the following:
- provides 'native' support for any screen size, up to 32 columns by 36 rows height (1024 bytes maximum)
- detects when the screen has been resized, and recalibrates the screen accordingly
- works for PAL and NTSC (at least from testing on VICE this works)
- fits into 3K memory expansion slot, works for any machine with memory expansion.
The idea came to me as I was looking at my 3K memory expander, wondering what I could possibly want to use this for.
As a further idea, I am also considering providing support for 'double height' characters, however this comes with further compromises. (Edit : I've decided against this for now..)
Updated Link:
https://drive.google.com/open?id=1eOrKi ... JYn_fmn501
nothing like a global shutdown to bring some ideas to fruition. I've been tinkering with this over the last week or so, if something else that does this already exists, please feel free to stop me immediately!
I'm working on a wedge that will enable full 'native' support of different screen sizes. As you would know, the VIC-I is a very versatile chip, in that it allows the user to select any screen size they wish. This is an excellent feature, and pretty unique for machines of that time. Unfortunately, the Vic's firmware only supports a screen size of 22 columns by 23 lines.
On NTSC screens, I understand the borders are quite small, so it's not really possible to make the screen too much larger before the characters disappear out of sight (24 or 25 columns by 27 or 28 rows of 8-pixel characters). On PAL screens, the borders are much larger, and depending on the screen, it's normal to be able to fit 28 or 29 columns by 35 or 36 rows. I get 28 columns by 36 rows on my modern LED screen, and that is also what you will see on many emulators including VICE.
There are numerous 40 column software solutions (among others) and they work - but being 'bitmap' solutions they use a lot of memory and slow the processor down considerably, not to mention the colour map gets thrown out and sometimes the readability suffers as well.
Edit : The program now does the following:
- provides 'native' support for any screen size, up to 32 columns by 36 rows height (1024 bytes maximum)
- detects when the screen has been resized, and recalibrates the screen accordingly
- works for PAL and NTSC (at least from testing on VICE this works)
- fits into 3K memory expansion slot, works for any machine with memory expansion.
The idea came to me as I was looking at my 3K memory expander, wondering what I could possibly want to use this for.
As a further idea, I am also considering providing support for 'double height' characters, however this comes with further compromises. (Edit : I've decided against this for now..)
Updated Link:
https://drive.google.com/open?id=1eOrKi ... JYn_fmn501