This is a more lengthy post, sorry.
GreyGhost wrote:I just don't think I would get the same enjoyment from programming something that I couldn't use on the real thing.
Okay, that's something I can follow through. Sorry for that.
I'd just like to point out, that MAXIGRAFIK had been developed mainly within VICE, and I also have yet to see it running on my own VIC-20 (tokra already confirmed me it works) - I just didn't have the time to setup my VIC in the last months. But that didn't hold me from doing this here.
orion70 wrote:What really puzzles me, is how could you reach such a resolution.
As established earlier, the VIC chip can only access internal memory. Besides the character ROM, this means the bottom 1K RAM between addresses 0..1023 and the top 4K RAM between addresses 4096..8191. If we exclude the bottom 1K and do not use the CPU to assist the VIC chip in any other way than setting up the address generator in the "text" screen, and programming the VIC registers, the largest possible end result is 160x192 pixels - the resolution provided by MINIGRAFIK.
If the screen area of
freely definable pixels is to be enlarged, two options are possible, both of which are used by MAXIGRAFIK: 1st, use the bottom 1K as well and 2nd, dynamically update parts of the RAM the VIC chip can access, as the raster beam scans the whole screen. The trick here is to use the address generating "text" screen to point to the same bitmap area, but at different places on screen. And update the doubly used area, while the VIC chip doesn't access it. The following example omits many details, such as the relative speed of VIC access vs. CPU access, and the "free" CPU time in the border, but should make clear how MAXIGRAFIK works:
This arrangement might be in use:
Code: Select all
VIC displays: CPU updates:
+-------------------+ +-------------------+
| | | |
| Zone A | | Zone B1 |
| | | |
+-------------------+ +-------------------+
| | | |
| Zone B1 | | idle |
| | | |
+-------------------+ +-------------------+
| | | |
| Zone C | | Zone B2 |
| | | |
+-------------------+ +-------------------+
| | | |
| Zone B2 | | idle |
| | | |
+-------------------+ +-------------------+
Zones A, B1, and C span the whole RAM accessible to the VIC chip. But the characters in Zone B2 point to the
same part of the hires bitmap than those in Zone B1. Without further intervention by the CPU, Zone B1 and B2 would display the same content.
Now comes the trick: CPU and VIC are synchronised, so that while VIC is displaying Zone A, the CPU puts the intended data of Zone B1 into place. The CPU then idles as B1 is displayed. The VIC displays Zone C - and again the CPU puts fresh data of Zone B2 there. The result: even though B1 and B2 point to the same memory, we can display different content! In fact, we have increased the visible area by 33%.
That is really the main idea behind the increased resolution. MAXIGRAFIK takes this idea to the extreme in that the copying process is made as fast as possible, and the "idle" phases of the CPU have been minimized - which increases the display area by over 70% compared to MINIGRAFIK.
I can see it leaves little RAM free though - I should think about a 'light' implementation of this fantastic extension.
If there is RAM in BLK5, MAXIGRAFIK allows you to put the BASIC program there, i.e. 8191 BYTES FREE. This can be configured with MAXICONFIG. If your intended application needs more memory, that can be discussed here.
MAXICONFIG also allows to try out different memory configurations. But if a certain configuration is settled upon, it is possible to devise a boot-loader, which loads the display routine, the correct main program, and then autostarts the user program, as I've done with many programs that use MINIGRAFIK. Should program development of a client program advance to this stage, again, we can gladly discuss it here, too.
Greetings,
Michael
Edit: Slightly refined the example
.
.
.
.