** New Frontiers in VIC-Hires-Graphics, Part 1

Basic and Machine Language

Moderator: Moderators

User avatar
Mike
Herr VC
Posts: 3110
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

** New Frontiers in VIC-Hires-Graphics, Part 1

Postby Mike » Wed May 19, 2010 3:24 pm

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.
Last edited by Mike on Wed May 19, 2010 4:03 pm, edited 2 times in total.

User avatar
Mike
Herr VC
Posts: 3110
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Postby Mike » Wed May 19, 2010 3:41 pm

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. :lol:

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

User avatar
tokra
Vic 20 Nerd
Posts: 841
Joined: Tue Apr 27, 2010 5:32 pm
Location: Germany

Postby tokra » Wed May 19, 2010 4:07 pm

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:


Same time ago I pondered similar thoughts about using the lower 1K for high-res graphics, but I didn't consider *that* layout. :lol:

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.

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.

Taking the small current number of those in the forum who actively use MINIGRAFIK, this won't get you much more. :(

Maybe people just don't have any ideas what's possible and what not. [...]

Greeting from the far north
Torsten

User avatar
KingTrode
Vic 20 Hobbyist
Posts: 133
Joined: Tue Apr 13, 2010 2:32 am

Postby KingTrode » Thu May 20, 2010 3:49 am

Really looking forward to reading about both your ideas and seeing the end results :D

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 :D

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 :wink:

Here's hoping that somewhere down the line something similar on the sound/music standardisation front might appear. :idea:

Regards


Richard

User avatar
orion70
Meteo VIC
Posts: 3361
Joined: Thu Feb 02, 2006 4:45 am
Location: Piacenza, Italy
Occupation: Biologist

Re: ** New Frontiers in VIC-Hires-Graphics, Part 1

Postby orion70 » Thu May 20, 2010 5:50 am

Boys, THIS is interesting! I'm curious about the next messages, too.

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.

Does this mean that you have to mod the VIC's chipset to achieve higher resolutions? :?:

User avatar
Mike
Herr VC
Posts: 3110
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Postby Mike » Thu May 20, 2010 6:32 am

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. :?

The key about this is "exchanging" the roles of text screen, and character definitions.

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

orion70 wrote:Does this mean that you have to mod the VIC's chipset to achieve higher resolutions?

... we remain at software-only solutions. :)

User avatar
tokra
Vic 20 Nerd
Posts: 841
Joined: Tue Apr 27, 2010 5:32 pm
Location: Germany

Postby tokra » Thu May 20, 2010 2:29 pm

orion70 wrote:Does this mean that you have to mod the VIC's chipset to achieve higher resolutions?

... we remain at software-only solutions. :)


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.

The solutions we came up with all work with unmodded VICs however they come at a price, but more on that later ;-)

User avatar
ravenxau
Vic 20 Devotee
Posts: 295
Joined: Fri May 28, 2004 10:03 pm

Postby ravenxau » Thu May 20, 2010 5:50 pm

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?



As far as a port of elite goes, mabey someone with some ZX Spectrum experience can unravel and make use of this.

http://reptonix.awardspace.co.uk/sinclair/oneliners/strader.htm
Android Tablet running Frodo 64 emulator running VIC 20 emulator....

User avatar
KingTrode
Vic 20 Hobbyist
Posts: 133
Joined: Tue Apr 13, 2010 2:32 am

Postby KingTrode » Fri May 21, 2010 1:32 am

Thanks for the info in your earlier post Mike.

I have set myself a task of recreating the 160x192 Hires screen and displaying something on it - nice learning / understanding exercise for me :)

I'll post a screen shot of the results here.

User avatar
KingTrode
Vic 20 Hobbyist
Posts: 133
Joined: Tue Apr 13, 2010 2:32 am

Postby KingTrode » Sat May 22, 2010 4:42 am

Screen shot of WIP:

Image

User avatar
Mike
Herr VC
Posts: 3110
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Postby Mike » Sun May 23, 2010 2:31 pm

Hi, Richard!

KingTrode wrote:I created this character set using my CharEdit Application [...]

It bears a certain resemblance to this one: ;)

Image

It also needs optimisation for speed as this full screen of TEXT takes around 3 seconds to draw - [...]

Are you copying the characters from your character set definition pixel-wise, or what? :shock:

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.

User avatar
KingTrode
Vic 20 Hobbyist
Posts: 133
Joined: Tue Apr 13, 2010 2:32 am

Postby KingTrode » Sun May 23, 2010 3:48 pm

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

User avatar
Mike
Herr VC
Posts: 3110
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Postby Mike » Sun May 23, 2010 4:22 pm

KingTrode wrote: - could'nt remember who's though - now I know (Hope you don't mind) :)

The charset definition is included in the source I released together with MG Browse, so that could have saved you some work. ;)

The characters are drawn on a nibble basis, masking them into the bitmap.

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. :shock:

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

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.

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.

User avatar
KingTrode
Vic 20 Hobbyist
Posts: 133
Joined: Tue Apr 13, 2010 2:32 am

Postby KingTrode » Sun May 23, 2010 5:05 pm

Mike wrote:The charset definition is included in the source I released together with MGBROWSE, so that could have saved you some work. ;)


Aye, wish I had known that :(

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. :shock:


Never thought of doing that, I shall look into implementing this.

Here's the inner loop of the text draw routine in MGBROWSE:

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


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.


This one had crossed my mind, though not until yesterday - again I shall get this implemented soon.

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.


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.

As always - many many thanks for your input/help Mike - always most welcome :D


Richard

User avatar
RobertBe
Vic 20 Guru
Posts: 1867
Joined: Sat Jul 14, 2007 2:48 pm

Re: New Frontiers in VIC-Hires-Graphics Series

Postby RobertBe » Tue Nov 19, 2013 10:20 pm

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.

Thanks! Now I can go over all the articles in an organized manner.

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


Return to “Programming”

Who is online

Users browsing this forum: No registered users and 2 guests