** New Frontiers in VIC-Hires-Graphics, Part 1
Moderator: Moderators
- Mike
- Herr VC
- Posts: 4841
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
** New Frontiers in VIC-Hires-Graphics, Part 1
In the last two weeks, tokra, and I had quite a intense discussion about the limits of the VIC chip regarding high resolution graphics.
As a result, we pushed the achievable resolution for a full display bitmap (i.e. *all* pixels freely definable) much further than both of us originally imagined.
We will present this achievement in five separate threads, featuring a translation of the PM's to English. Just to prepare you about the results, here are the proposed names:
Part 1: Introduction, Overview
Part 2: Adding an extra line: 160x200
Part 3: Taking it further: 160x240
Part 4: Faster routine, better resolution: 208x208
Part 5: The Final Frontier? 208x240
Comments, and an open discussion are welcome, and we'll do our best to incorporate these as the story unfolds. It's just in that case we want to share how these new graphics modes came into existence, and not keep it a secret.
The routines involved are tuned to PAL VICs, but the principles behind them translate well to NTSC, at slightly less resolution.
...
One last thing beforehand: the 160x192 resolution, like used by MINIGRAFIK, is given as start point. It is the biggest resolution, that can be displayed on an unmodded VIC-20 without using the lower 1K RAM, or raster interrupts.
The first PM I wrote to tokra will follow shortly.
As a result, we pushed the achievable resolution for a full display bitmap (i.e. *all* pixels freely definable) much further than both of us originally imagined.
We will present this achievement in five separate threads, featuring a translation of the PM's to English. Just to prepare you about the results, here are the proposed names:
Part 1: Introduction, Overview
Part 2: Adding an extra line: 160x200
Part 3: Taking it further: 160x240
Part 4: Faster routine, better resolution: 208x208
Part 5: The Final Frontier? 208x240
Comments, and an open discussion are welcome, and we'll do our best to incorporate these as the story unfolds. It's just in that case we want to share how these new graphics modes came into existence, and not keep it a secret.
The routines involved are tuned to PAL VICs, but the principles behind them translate well to NTSC, at slightly less resolution.
...
One last thing beforehand: the 160x192 resolution, like used by MINIGRAFIK, is given as start point. It is the biggest resolution, that can be displayed on an unmodded VIC-20 without using the lower 1K RAM, or raster interrupts.
The first PM I wrote to tokra will follow shortly.
Last edited by Mike on Wed May 19, 2010 4:03 pm, edited 2 times in total.
- Mike
- Herr VC
- Posts: 4841
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
http://www.sleepingelephant.com/ipw-web ... php?t=4487
Hi, Torsten!
Same time ago I pondered similar thoughts about using the lower 1K for high-res graphics, but I didn't consider *that* layout.
Well, my posting in the OT before was mainly a result of earlier experience ... a graphics mode, which only supports itself will get less use than one which works better together with the rest of the system. Taking the small current number of those in the forum who actively use MINIGRAFIK, this won't get you much more.
And this despite I wrote the BASIC extension, so those concerned need not necessarily resort to machine language to display high resolution graphics on the VIC. Maybe it's just the sheer number of degrees of freedom, so one now needs to think more about design rather than just writing some pieces of code on squared paper ...
Anyway. It would be quite nice to make a new game with vector graphics on the VIC. It need not be a port of Elite. What do you think?
Greetings from Bavaria,
Michael
Hi, Torsten!
Same time ago I pondered similar thoughts about using the lower 1K for high-res graphics, but I didn't consider *that* layout.
Well, my posting in the OT before was mainly a result of earlier experience ... a graphics mode, which only supports itself will get less use than one which works better together with the rest of the system. Taking the small current number of those in the forum who actively use MINIGRAFIK, this won't get you much more.
And this despite I wrote the BASIC extension, so those concerned need not necessarily resort to machine language to display high resolution graphics on the VIC. Maybe it's just the sheer number of degrees of freedom, so one now needs to think more about design rather than just writing some pieces of code on squared paper ...
Anyway. It would be quite nice to make a new game with vector graphics on the VIC. It need not be a port of Elite. What do you think?
Greetings from Bavaria,
Michael
Here's a translation of my original reply. However I cut the "fat" out of it that doesn't apply to the graphic mode discussion. Here goes:
The 160x 240 mode may in the end just be for a demo. [...] After browsing through this forum, I'm noticing that the demo scene is not really active here. I'm wondering why, especially since a new VIC-20 demo was recently shown at the Breakpoint party. [...] At least there are source-codes of the demos around to learn from.
Greeting from the far north
Torsten
Yes, I thought of that layout late at night. All the other ideas I had wouldn't fit in memory or because of the resolution. The number of lines has to be dividable by 16 because of the double-height-chars. Maybe the lower 1K can be utilized in a sensible way by just using 679-767 and the tape buffer. This would however just provide another 8 lines - 160x200 would be a nice mode for the VIC though, since a "real" 40-char mode using 4x8 chars and 25 lines would be possible. All the other 40-char-modes either just use 24 lines or 4x7 chars.Same time ago I pondered similar thoughts about using the lower 1K for high-res graphics, but I didn't consider *that* layout.
The 160x 240 mode may in the end just be for a demo. [...] After browsing through this forum, I'm noticing that the demo scene is not really active here. I'm wondering why, especially since a new VIC-20 demo was recently shown at the Breakpoint party. [...] At least there are source-codes of the demos around to learn from.
Maybe people just don't have any ideas what's possible and what not. [...]Taking the small current number of those in the forum who actively use MINIGRAFIK, this won't get you much more.
Greeting from the far north
Torsten
Really looking forward to reading about both your ideas and seeing the end results
All of the code I have written has been based around the bog standard text screen and it's limitations.
I have always known that I could achieve much more and a better end result if I was using a Hi-Res display, but my lack of knowledge in that area has held me back.
Just the thought of all that extra screen real estate is mouth watering, let alone all the extra flexibility
I'm always looking to improve my knowledge/understanding of the VIC, and I see this as an excellent opportunity to reap the benefits of others much greater knowledge
Here's hoping that somewhere down the line something similar on the sound/music standardisation front might appear.
Regards
Richard
All of the code I have written has been based around the bog standard text screen and it's limitations.
I have always known that I could achieve much more and a better end result if I was using a Hi-Res display, but my lack of knowledge in that area has held me back.
Just the thought of all that extra screen real estate is mouth watering, let alone all the extra flexibility
I'm always looking to improve my knowledge/understanding of the VIC, and I see this as an excellent opportunity to reap the benefits of others much greater knowledge
Here's hoping that somewhere down the line something similar on the sound/music standardisation front might appear.
Regards
Richard
- orion70
- VICtalian
- Posts: 4341
- Joined: Thu Feb 02, 2006 4:45 am
- Location: Piacenza, Italy
- Occupation: Biologist
Re: ** New Frontiers in VIC-Hires-Graphics, Part 1
Boys, THIS is interesting! I'm curious about the next messages, too.
Does this mean that you have to mod the VIC's chipset to achieve higher resolutions?Mike wrote:One last thing beforehand: the 160x192 resolution, like used by MINIGRAFIK, is given as start point. It is the biggest resolution, that can be displayed on an unmodded VIC-20 without using the lower 1K RAM, or raster interrupts.
- Mike
- Herr VC
- Posts: 4841
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
The key about this is "exchanging" the roles of text screen, and character definitions.KingTrode wrote:I have always known that I could achieve much more and a better end result if I was using a Hi-Res display, but my lack of knowledge in that area has held me back.
Rather than using the standard character sets, or providing an own set of static user defined characters, and using a dynamic text screen to get a dynamic display as result, you:
- set up a static text screen, with each character used only once,
- with each character pointing to a 16 byte area within the character set definition by using double-height chars (enabled with a VIC register bit), and
- dynamically alter the character set definition to set, or clear single pixels.
There are still some degrees of freedom how to arrange characters in the text screen as address generator, you can put them row-wise (similar to C64), or column-wise (used in MINIGRAFIK, and ideally suited to the (),Y addressing mode). And opt for different numbers of columns, and rows - within certain limits.
You need 1 text screen byte to address the bitmap for every 16 bitmap bytes, i.e. 17 bytes total for a 8x16 pixel area. If only the upper 4K are used this leads to:
4096/17 ~= 240.9
Of course we can't use partial characters, but 240 characters can neatly be arranged in a 20x12 matrix, giving 160x192 pixels, i.e. the resolution provided by MINIGRAFIK.
Once the VIC registers are programmed, and the text map put in place, you can pretty much forget about them both, and just manipulate the bits in the bitmap to alter the display.
For higher resolutions, and if we want the VIC-20 still to do other things than just displaying the picture (i.e. run our own program!), the 6502 needs to assist the VIC chip during display, so a certain amount of cycles is lost. But ...
... we remain at software-only solutions.orion70 wrote:Does this mean that you have to mod the VIC's chipset to achieve higher resolutions?
orion70 wrote:Does this mean that you have to mod the VIC's chipset to achieve higher resolutions?
What Mike meant by "unmodded" VIC probably is that some people have added a 3K expansion to their VIC by piggybacking it on the existing RAM in the machine. Only this way the extra 3K are accessible by the VIC-chip and thus could be used to achieve higher graphics resolutions easily. The standard 3K-RAM expansion (or any RAM expansion for that matter) cannot be seen by the VIC-chip but just the CPU.... we remain at software-only solutions.
The solutions we came up with all work with unmodded VICs however they come at a price, but more on that later
As far as a port of elite goes, mabey someone with some ZX Spectrum experience can unravel and make use of this.Mike wrote:
Anyway. It would be quite nice to make a new game with vector graphics on the VIC. It need not be a port of Elite. What do you think?
http://reptonix.awardspace.co.uk/sincla ... trader.htm
Android Tablet running Frodo 64 emulator running VIC 20 emulator....
- Mike
- Herr VC
- Posts: 4841
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Hi, Richard!
Building the initial full view within MGBROWSE needs less than one second, even though BASIC is involved.
It bears a certain resemblance to this one:KingTrode wrote:I created this character set using my CharEdit Application [...]
Are you copying the characters from your character set definition pixel-wise, or what?It also needs optimisation for speed as this full screen of TEXT takes around 3 seconds to draw - [...]
Building the initial full view within MGBROWSE needs less than one second, even though BASIC is involved.
Last edited by Mike on Tue Dec 04, 2012 12:47 pm, edited 1 time in total.
Yes the char set is very similar, just the odd change here and there that I made as I was firing it into CharEdit.
I had that Image kicking about so I used it as a reference, I knew I had slurped it off someone that posts here's D/L Area - could'nt remember who's though - now I know (Hope you don't mind)
The way I went about things was as follows:-
The screen address is calculated from the current X/Y of the cursor, along with a flag to indicate which nibble is the target.
I have a lookup table with entries that point to the start address of each of the 20 columns (X), then the Y offset is added to that.
The characters are drawn on a nibble basis, masking them into the bitmap.
I have improved the speed somewhat to about 1 second for the above full screen, this time is just a visual guesstimate.
I'm quite pleased with it for a first attempt, as it has also enlightened me somewhat in the Hi-Res arena.
Richard
I had that Image kicking about so I used it as a reference, I knew I had slurped it off someone that posts here's D/L Area - could'nt remember who's though - now I know (Hope you don't mind)
The way I went about things was as follows:-
The screen address is calculated from the current X/Y of the cursor, along with a flag to indicate which nibble is the target.
I have a lookup table with entries that point to the start address of each of the 20 columns (X), then the Y offset is added to that.
The characters are drawn on a nibble basis, masking them into the bitmap.
I have improved the speed somewhat to about 1 second for the above full screen, this time is just a visual guesstimate.
I'm quite pleased with it for a first attempt, as it has also enlightened me somewhat in the Hi-Res arena.
Richard
- Mike
- Herr VC
- Posts: 4841
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
The charset definition is included in the source I released together with MG Browse, so that could have saved you some work.KingTrode wrote: - could'nt remember who's though - now I know (Hope you don't mind)
My routine always draws two characters at a time. This was inspired by the following observation: it is just wasted time toThe characters are drawn on a nibble basis, masking them into the bitmap.
- draw the single character in the left nibble, carefully retaining the data of the right nibble, and then
- even though then overwriting the right nibble, possibly even again retaining the data of the left nibble.
Here's the inner loop of the text draw routine in MG Browse:
Code: Select all
LDY #0
.TDraw_01
LDA (text_left),Y :AND #&F0:STA text_byte
LDA (text_right),Y:AND #&0F:ORA text_byte
STA (text_dst),Y
INY:CPY #8:BNE TDraw_01
Furthermore, for this text-dominated application, I always draw whole lines. This simplifies addressing somewhat, for the low-byte of the starting address I multiply the text line number with 8, always have $11 as high-byte, and just add 192 as I advance to the next character (pair) column.
Last edited by Mike on Tue Dec 04, 2012 3:08 pm, edited 1 time in total.
Aye, wish I had known thatMike wrote: The charset definition is included in the source I released together with MGBROWSE, so that could have saved you some work.
Never thought of doing that, I shall look into implementing this.My routine always draws two characters at a time. This was inspired by the following observation: it is just wasted time to
- draw the single character in the left nibble, carefully retaining the data of the right nibble, and then
- even though then overwriting the right nibble, possibly even again retaining the data of the left nibble.
This one had crossed my mind, though not until yesterday - again I shall get this implemented soon.Here's the inner loop of the text draw routine in MGBROWSE:
The charset data is duplicated in the right, and left nibble to avoid shifting them into position as they're masked out, and combined into one byte.Code: Select all
LDY #0 .TDraw_01 LDA (text_left),Y :AND #&F0:STA text_byte LDA (text_right),Y:AND #&0F:ORA text_byte STA (text_dst),Y INY:CPY #8:BNE TDraw_01
I can see how that would be so much quicker, though the plans I have for mine ATM will more snippets of text here and there - but this may come into play somewhere down the line.Furthermore, for this text-dominated application, I always draw whole lines. This simplifies addressing somewhat, for the low-byte of the starting address I multiply the text line number with 8, always have $11 as high-byte, and just add 192 as I advance to the next character (pair) column.
As always - many many thanks for your input/help Mike - always most welcome
Richard
Re: New Frontiers in VIC-Hires-Graphics Series
Thanks! Now I can go over all the articles in an organized manner.Mike wrote:Over the time, the threads about 'New Frontiers in VIC-Hires-Graphics' became scattered around in the Programming section.
I gathered all links to these here in this post, to make it easier to follow the whole development over the last three years.
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org