So, with the 160x200 mode working I thought about expanding the idea of saving and restoring bytes during graphics display which led to:
Part 3: Taking it further: 160x240
I've tried something insane just now: Making the 160x240-mode useable to BASIC. The idea is the same as with the extra line, but a step tougher:
While in IRQ:
1. Save lower 1K to $2400 (effectively just 679 bytes)
2. Copy 1K from $2000 to $0000
3. Display the 48 extra-lines.
4. Restore saved are from $2400 to $000
I'll just say this: It's working, but the VIC is slowing down so much that VICE even in Warp Mode at 3500% is just about as fast as it would be at 100% otherwise. Also due to speed all copy-routines are completely unrolled (otherwise it probably won't fit into the raster-time), so that those alone eat up 13K of space. Using a 16K expansion this leaves a whopping 512 BASIC-Bytes free One should really create the graphics in BASIC while it's off and just turning the graphics on for display only.
Small advantage anyhow:
- Graphics address space is continues from $1100-$23bf (as is the color space)
I will provide a "pretty" version of this tomorrow and will probably squeeze a few more bytes out of it. Right now I don't have anything presentable.
** New Frontiers in VIC-Hires-Graphics, Part 3
Moderator: Moderators
** New Frontiers in VIC-Hires-Graphics, Part 3
Last edited by tokra on Fri May 21, 2010 1:03 pm, edited 1 time in total.
- Mike
- Herr VC
- Posts: 4816
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: ** New Frontiers in VIC-Hires-Graphics, Part 3
Glork!tokra wrote:I've tried something insane just now: Making the 160x240-mode useable to BASIC. The idea is the same as with the extra line, but a step tougher: [...]
That's quite a feat!
I just calculated over the head; as is, your copying routine needs 8 cycles per byte (4 LDA, 4 STA), with indexed-indirect 9 cycles/byte, i.e. ~19200 vs. 21600 cycles: a PAL frame has ~22000 cycles. That might fit, but just barely. In any case, the VIC then runs with only 2% of its normal speed remaining. If we had something like a Blitter ...Also due to speed all copy-routines are completely unrolled (otherwise it probably won't fit into the raster-time),
You could generate the fully unrolled loop by another routine, as your program is run?I will provide a "pretty" version of this tomorrow and will probably squeeze a few more bytes out of it. Right now I don't have anything presentable.
And, of course, it would be nice, if the demo could be started with RUN.
Greetings,
Michael
Re: ** New Frontiers in VIC-Hires-Graphics, Part 3
tokra wrote:Making the 160x240-mode useable to BASIC.
Thanks But this wasn't much harder than the 160x200 mode. Most of the effort was understanding the raster-rotuine and then the timing is just trial and error.That's quite a feat!
It isn't that bad - I only have to copy 679 bytes out of the lower 1K and back (the rest is tape buffer and other free bytes, that normally don't get overwritten). 250 bytes of the are located in the zeropage and as such need 1 cycle less for copying. The char-RAM located at $2000-$23bff is another 960 bytes. In total: 2 x 679 + 960 + displaying the video-RAM from 240-299. That works "as is" on the VIC. I could speed the process up a little today by starting to copy back while the 48 extra-lines are still being displayed - you just mustn't overwrite those bytes that the VIC-chip hasn't displayed yet. As soon as they have been displayed, one can start copying back. This way 252 byte are copied back before the test of the raster line and the CPU-cycles are not wasted by waiting for the raster beam to leave the special area.I just calculated over the head; as is, your copying routine needs 8 cycles per byte (4 LDA, 4 STA), with indexed-indirect 9 cycles/byte, i.e. ~19200 vs. 21600 cycles: a PAL frame has ~22000 cycles.
tokra wrote:I will provide a "pretty" version of this tomorrow
I have just used PUCrunch for that now. This produces a RUN-able BASIC-program (although it didn't crunch any bytes out of the unrolled loop).You could generate the fully unrolled loop by another routine, as your program is run?
And, of course, it would be nice, if the demo could be started with RUN.
I also provided some commands:
sys 9831: turn on graphics
sys 9834: turn off graphic
sys 9837: clear graphics
I recommend clearing the graphics first and THEN turning it on. Otherwise it takes longer...
Binary: http://www.tokra.de/vic/160240-16k.prg
Source: http://www.tokra.de/vic/160240-16k.asm
Obligatory demo:
Code: Select all
10sys9837
20sys9831
30fori=0to4799:poke4352+i,rnd(1)*256:next
40poke198,0:wait198,1
50sys9834
Binary: http://www.tokra.de/vic/160240-32k.prg
Source: http://www.tokra.de/vic/160240-32k.asm
I know this is off topic and I Hope I'm aloud to comment, but when I RUN that little snippet program you guys use as an example, I see little custom characters appear. The same way you look at clouds and see shapes in them. I saw little aliens standing there and a med evil shield with a cross in it, a rocket ship and so forth. Some not all the way formed but there none the less. Just thought I'd point that out. Very cool.
PS- this is really neat stuff You are working on.
Later,
PS- this is really neat stuff You are working on.
Later,
Rob
- Mike
- Herr VC
- Posts: 4816
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Must have been the little green Men from Mars.GreyGhost wrote:I saw little aliens standing there and a med evil shield with a cross in it, a rocket ship and so forth.
No joking. Camille Flammarion and Percival Lowell got fooled by similar structures on Mars. Even though most of them were rather random assemblies of rocks, they meant to see artificial Martian canals.
But it had been just wild pattern recognition within the brain at work.