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

[Mike]

... the saga continues.

Part 3 ended with a 160x240 graphics mode, which - even though it allowed other programs (BASIC, and ML) being run concurrently - chewed up nearly all processing power of the VIC. Now how did we get to display 208x208?

I could speed the process up a little today by starting to copy back while the 48 extra-lines are still being displayed -

This reminds me about the HCB mode in 'Edge of Disgrace'. There, the colour RAM at $D800 also is swapped on-the-fly, so that in a FLI-mode *all* attributes are of 4 pixels height. During display of the top half of the characters, the bottom half is written - and vice versa.

They even went as far, as they even don't copy the data from yet another RAM range, rather the new attributes are operand fields of LDA # instructions.

(This last sentence took a few seconds to sink in ... and then:)

Eh, you might be up to something ...

Instead of:

LDA $2xxx:STA in the lower 1K

LDA #xx:STA

Even though then there's no more a continuous bitmap, the provision of the image data then only takes 5/6, instead of 7/8 cycles.

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

No wonders.

In that case, the addresses are all distinct. Thus far I haven't seen a packer that smart to recognise an operand field is counted upwards.

As I wrote beforehand, a case for a code generator.

(One and a half hour later:)

P.S.: It just occured to me you could even go one better:

Put the bitmap, with char map, again complete into the upper 4K, so that you don't need to save the ZP.

Then, two routines, which write 48x20 bytes with LDA #$xx:STA $xxxx into the bitmap, doing the update always at that place where the raster beam is currently absent.

2 * 6 cycles/copy * 48 * 20 = 11520 cycles/frame.


lo and behold, VIC runs with nearly 50% of its original speed again.

Cheers,

Michael

[tokra]

P.S.: It just occured to me you could even go one better:

Put the bitmap, with char map, again complete into the upper 4K, so that you don't need to save the ZP.

Then, two routines, which write 48x20 bytes with LDA #$xx:STA $xxxx into the bitmap, doing the update always at that place where the raster beam is currently absent.

2 * 6 cycles/copy * 48 * 20 = 11520 cycles/frame.


lo and behold, VIC runs with nearly 50% of its original speed again.

Hehe, I had a similar thought after your first mail. You wouldn't need to limit yourself to 48 extra-lines then, though. My calculations for possible resolutions:

Code: Select all

 192*160
+192*80 = 1920 Byte = copy time at least 1920 * 2 * 6 = 23040 = too long

 192*160
+192*64 = 1536 Byte = copy time at least 1536 * 2 * 6 = 18432 = works
-------
192*224=43008 pixels


 208*144
+208*64 = 1664 Byte = copy time at least 1664 * 2 * 6 = 19968 = might just work (312 * 71 Zyklen = 22152 PAL-cycles)
---------
208*208=43264 pixels

By calculation the latter two should fit into the raster-time.

I'd like to "lock" the 160x240 version for now, having the continous address space is just to nice to be sacrificed This way existing BASIC-code can easily be extended to the new resolution.

I will work on 208x208 or 192x224 separately.

Greetings,
Torsten

[Mike]

Hehe, I had a similar thought after your first mail. You wouldn't need to limit yourself to 48 extra-lines then, though.

Indeed.

I also had considered a resolution of 184x240 pixels, but then the char map seemed to make a problem - I'd need to think that through more thoroughly. Time to go to bed.

(Aside: as I wrote this, it was half past one in the morning. )

I will work on 208x208 or 192x224 separately.

If you're going to publish the results, you should consider adding some design. For example, a slide-show of pictures.

[tokra]

I also had considered a resolution of 184x240 pixels, but then the char map seemed to make a problem - I'd need to think that through more thoroughly.

Hmm, I made some calculations:

Code: Select all

184*160
184*80 = 1840 Byte = copy time at least 1840 * 2 * 6 = 22080 - will probably be too tight (just 72 cycles left) 

This may work in theory, but the VIC would be tied up nearly completly. And if you accept THAT (just displaying the resolution) you can use the lower 1K as well. The maximum possible resolution this way probably is 208x240:

Code: Select all

208 * 144 = Top 4K
208 *  64 = Bottom 4K = 1664 Byte = copy time at least 1664 * 2 * 6 = 19968
208 *  32 = Bottom 1K

This just fits in the top 4K with Video- and Char-RAM:

Video-RAM 338 Byte: $1000-$1152
Char-RAM $1160-$1fff

49920 pixels - not bad for the little VIC

If you want to use BASIC the best you can get is 208x208 I think.

If you're going to publish the results, you should consider adding some design. For example, a slide-show of pictures.

Well, I'm way too untalented to draw. A picture-converting-tool would be handy. There are some ready-made out there, aren't there? Adapting this to the crude VIC-resolutions and addressing-modes seems to be the biggest pain, I guess. Converting the Elite-pic off the C64 took me a some long hours as well...

[Mike]

I also had considered a resolution of 184x240 pixels, but then the char map seemed to make a problem - I'd need to think that through more thoroughly.

184*160
184*80 = 1840 Byte = copy time at least 1840 * 2 * 6 = 22080 - will probably be too tight (just 72 cycles left)

Yep, that's as far as I got. I then tried to shift 10 characters into the bottom area, so then 160 bytes less had to be copied. But then I realised, that the text map also needs more space, 345 instead of 230 bytes. They could possibly also be supplied on-the-fly, but then it's easier to go for the lower 1K.

Well, I'm way too untalented to draw. A picture-converting-tool would be handy. There are some ready-made out there, aren't there?

For MINIGRAFIK, yes, indeed.

https://dateipfa.de/.Public/denial/mini ... grafik.zip -> PGM IMPORT

Adapting this to the crude VIC-resolutions and addressing-modes seems to be the biggest pain, I guess.

I do this part on the PC, with IrfanView. This includes a correction for the non-square aspect ratio of the VIC pixels. For data transfer, I use the *.pgm format.

And MINIGRAFIK reliefs me of thinking about the address function of the bitmap as long as the client program is written in BASIC.

Converting the Elite-pic off the C64 took me a some long hours as well...

Oh dear! Well, doing that chore once - manually - should be enough.

If you commit yourself to a certain graphics mode, the address function then is fixed. In that case, I could provide you with a dedicated converter.

Greetings,

Michael

[tokra]

Ok, here we go:

Binary: http://www.tokra.de/vic/208208-24k.prg
Source: http://www.tokra.de/vic/208208-24k.asm

PUCRUNCH could pack a lot out of the fast copy-rotuine this time. However, in RAM this routine now uses 1664 *5 * 2 bytes = 16640 bytes, which is over 16K. This means that this now will only work with at least a 24K expansion.

Code: Select all

10 sys24835
20 sys24841
30 fori=0to1663:poke8193+5*i,rnd(1)*256:next
31 poke198,0:wait198,1
35 fori=0to2079:poke6112+i,rnd(1)*256:next
37 poke198,0:wait198,1
40 fori=0to1663:poke16513+5*i,rnd(1)*256:next
998 poke198,0:wait198,1
999 sys24838

The free raster area (tested by using inc $900f before and after the copy loop) is very small indeed. More resolution - just as I thought - is probably only possible by sacrificing the use of BASIC.

[Mike]

The free raster area (tested by using inc $900f before and after the copy loop) is very small indeed. More resolution - just as I thought - is probably only possible by sacrificing the use of BASIC.

From an own test I deducted 24 raster lines, of which only 8 remain when a key is pressed, due to the keyboard scan.

If you decide to keep this display program I could provide a pixel-set, and line-drawing routine. And a "specialist" version of MGBROWSE would even allow for 52x26 = 1352 characters ... nice! The extra routines could go at the end of BASIC RAM.

And we shouldn't forget about the slide show. To get a continuous range for the kernal load, and save routines, $A000 .. $BFFF in BLK5 could be a good choice:

Code: Select all

5408 bytes for bitmap
 169 bytes compressed colour RAM
   2 bytes for 36878, and 36879

I suppose I could finish some of these routines already in the evening of tomorrow.

[tokra]

If you decide to keep this display program

You could add an extra line just as with the 160x200 mode. One would have to save 26 bytes plus 4 bytes from 816 to 820. This will need another 8 rasterlines, that's why I think 208x208 is a great resolution for use with BASIC to stick with

Anything larger is assembler-only - in my opinion 208x240 is the maximum resolution then or do you have any idea how to do 208x256? A slide-show in assembler would need to query the joystick or keyboard directly and load the next picture then (like in the VIMM-demo).

I could provide a pixel-set, and line-drawing routine. And a "specialist" version of MGBROWSE would even allow for 52x26 = 1352 characters ... nice! The extra routines could go at the end of BASIC RAM.

The pixel-set and line-drawing-routine could be added to the source so then the BASIC-RAM wouldn't have to be cut in two places.

And we shouldn't forget about the slide show. To get a continuous range for the kernal load, and save routines, $A000 .. $BFFF in BLK5 could be a good choice:

Code: Select all

5408 bytes for bitmap
 169 bytes compressed colour RAM
   2 bytes for 36878, and 36879

I suppose I could finish some of these routines already in the evening of tomorrow.

Sounds good

Later that day, I thought about NTSC:

I've just made the calculations for an NTSC-VIC. The visible screen area is smaller and there is less raster-time as well. The maximum resolution with use of BASIC would probably be 192x208. Maximum viewable resolution would be 192x240 - this may be possible by using the lower 1K.

The 160x240 mode would work with an NTSC-machine as well - but only with the 6 cycles-addressing-mode.

I can't get very enthusiastic about NTSC though.

[Mike]

[...] - in my opinion 208x240 is the maximum resolution then or do you have any idea how to do 208x256?

In a thread here on Denial, long ago, carlsson and I toyed the idea of "executing" the frame buffer with the CPU. The VIC was intended to fetch its data from unconnected space, in theory it should read the data the CPU left on the data bus in the preceding half-cycle.

A continuous flow of LDA # instructions would supply $A9 as character byte (without any significance), and the operand field would supply the bitmap data.

Turned out we couldn't get it to work on carlsson's VIC-20, and so we abandoned the idea.

I could provide a pixel-set, and line-drawing routine.

Here we go: [...]

The archive contains 'plot.prg', 'line.prg', and sources. Just drop the two '*.prg' files into the same directory, where '208208-24k.prg' resides, drop the latter into VICE (incidently mounting the surrounding directory), and then, for example LOAD"LINE.PRG",8 and RUN.

I lifted the line-routine from MINIGRAFIK. Only minimal changes were necessary.

Feel free to include the routines into your display program.

Greetings,

Michael

[tokra]

Great! And the line-drawing-routine is pretty fast in spite of the slow display. I will probably expand this to sys 24845,a,x,y - calls, this would make for shorter BASIC-programs or I'll use tokens just like MINIGRAFIK.

[Wilson]

I love you guys

[Mike]

Great! And the line-drawing-routine is pretty fast in spite of the slow display.

ATM the routines are still missing for load, and save. I might write an address generator similar to this one, so there's no extra memory necessary. That generator also could "drive" the screen clear routine.

I will probably expand this to sys 24845,a,x,y - calls, this would make for shorter BASIC-programs or I'll use tokens just like MINIGRAFIK.

IMO a sensible thing to do. It did the parameter passing over registers, and ZP values just for a quick prototype.

Greetings,

Michael

[AmiDog]

1664 Byte = copy time at least 1664 * 2 * 6 = 19968

Well, if the memory layout isn't important, you could always move the STA's around and only have each possible LDA#$ once, thus using (worst case) (256 * 2 + 1664 * 4) * 2 = 14336 cycles. There is after all no need to spend time setting the accumulator to a specific value more than once.

[Mike]

Well, if the memory layout isn't important, you could [...] have each possible LDA#$ once, thus [...]

This method isn't applicable here, as the immediate fields of the LDA instructions are intended to form a kind of "distributed" bitmap. Precalculating the display program would only allow for a static display.

It might come useful for a static 208x256 display, though.

That however would require to "compile" the bitmap into a display program, and checking that all STAs happen to put their values into the RAM accessible by VIC before the raster beam arrives to fetch the data.

[tokra]

Well, if the memory layout isn't important, you could [...] have each possible LDA#$ once, thus [...]

It might come useful for a static 208x256 display, though.

That however would require to "compile" the bitmap into a display program, and checking that all STAs happen to put their values into the RAM accessible by VIC before the raster beam arrives to fetch the data.

Very interesting idea. I was hoping something like that would come out of our little "series".

I'm thinking a display consisting of 208x80+208x96+208x80 = 208x256 where there two 208x80 areas are switched on and off on need. This would calculate to a switch area of 2080 bytes, so a raster time of (2 * 256 + 2080 * 4) * 2 = 17664 cycles - very reasonable. Memory usage would be (257+ 6240) * 2 = 12994 bytes - also reasonable (if you use ldx #$00 and inx instead of loading the accumulator you save 255 bytes, that's where the 257 come from)

The biggest difficulty indeed would be to have the viewer-compilation-routine place the raster-switches at just the right places - this needs to be cycle-exact. But still quite doable I think.

Torsten