VICE palette files with colors as seen on real machines

[tokra]

Thanks My investgations continue. I noticed that even with the latest VICE the NTSC-vertical position was still off by 1 rasterline. POKE 36865,14 (= rasterline 28) should put the picture at the top with no visble border-colored line above (just like in PAL) as can be seen here:


I tried on the original machine how far down I can push the picture. This is with POKE 36865,130 (= rasterline 260)

As NTSC on VIC20 has a total of 261 (non-interlaced) rasterlines this is the final line that can be displayed (lines 0...260 = 261 rasterlines).
But there is still a visible rasterline in border-color below that last displayed line! It may be difficult to see, but it is there - how can that be? It cannot be a 262nd rasterline as NTSC only has 261. I suspected it might be rasterline 0 instead, so I tried: POKE 36865,0 and got this:

There it is, rasterline 0 displayed at the very bottom of the picture, without any line below it. This is the line that is displayed in border-color on all other values for 36865 ($9001).
Just out of interest I tried the same on my PAL-VIC20. POKE 36865,0

The same line shows at the very bottom of the screen. The line itself seems to show garbage. I find it interesting that rasterline 0 is actually at the bottom of the picture, not at the top.

Anyway, I amended VICE a little (again) to include the correct vertical position so that POKE 36865,14 puts the picture at the top without a border-colored line above it.. I even managed to emulate the rasterline 0-effect for NTSC (a little). The line shows at the correct place but does not display garbage as on the real machine.

Attached again the changed source-files and a pre-compiled .exe

[groepaz]

again, added in r30482 ... keep it coming

[Mike]

The same line shows at the very bottom of the screen. The line itself seems to show garbage. I find it interesting that rasterline 0 is actually at the bottom of the picture, not at the top.

Take a look at this (simulated) screenshot of my TI$ border clock:



Now, the first pixel line of the extended text screen looks suspiciously similar to the 'garbage' in the most bottom line of your PAL screenshot. NTSC was tested with RAM expansion?

My take is, the VIC chip doesn't reset the text screen address pointer in the border area below the regular text screen, it then displays the first pixel line of the next text line, as if the border area actually hadn't been there. Only during vertical retrace the text screen address pointer then is resetted.

You can test with POKEs to addresses 8186..8191 with an unexpanded VIC-20 - the first 6 chars in that most bottom line should change accordingly. With that memory configuration, the VIC chip wraps over to the character ROM for the remaining 16 bytes of the lines, and that is what's shown as garbage in my screenshot.

[groepaz]

would be great if you guys could provide some simple deterministic (ie not displaying random junk that happens to be in memory) test programs for this stuff so it can be added to the test repo

[tokra]

Found some time to whip up a test program. Results show Mike was right... is he ever wrong?
Test-program attached. Works on NTSC and PAL with or without expansion. Shifts screen memory to $1c00 and poke reverse space, space and "dithered" reverse space into the invisible 24th line. Press Space to cycle through the 3 values. You will see the line changing at the bottom.

Code: Select all

10 poke56,28:clr:poke648,28:sys58648:rem screen ram @ $1c00
20 poke36865,0:rem vertical pos=0
30 a=160:gosub998
40 a=32:gosub998
50 a=102:gosub998
60 poke36865,peek(60901)
70 end
998 fori=0to22:poke7168+506+i,a:poke37888+506+i,0:next:rem poke extra line
999 poke198,0:wait198,1:return

vert0test.zip

(366 Bytes) Downloaded 238 times

PAL-screenshot:

NTSC-screenshot:

[groepaz]

thanks, added here: https://sourceforge.net/p/vice-emu/code ... vic_vert0/

[tokra]

I have investigated the rasterline 0 anomaly a little further to see what happened if I expanded the screen by $9003 (36867). I noticed that if I expand the screen just to far enough rasterline 0 contents will in fact be a copy of the first rasterline in that final char-line. I let the pictures speak:
PAL:

NTSC:

You can notice that in PAL there actually is a border-colored line above rasterline 0, while in NTSC there is not!

Continued in next post...

[tokra]

I've amended my vert0test.prg to display those oddities as well, see at the bottom

Results of the new test for PAL:

and NTSC:

New vert0test:

[groepaz]

thanks, added to the repo!

[Aturnwald]

Sorry for interrupt, but may be I can explain that 1 raster line at the top in PAL mode, but I'm not for sure, so correct me, if I'm wrong.

it has all to do with the sub-sequences that would be send by PAL, for e.g. you know, on old VCR's when look a movie you at the top of your screen, sometimes a black scrambled line ( it happens when the VCR's head isn't installed correctly ), on this line there would be send some informations about the screen, and the picture and movie-data ect. Also a lot of years ago in German, it was during the 80s a TV-station ( WDR ) sent over this line some files for the C64, ATARI, PC, AMIGA it was called "Public Domain" and with a special hardware you can get all these files, and every 24 h it changed and new files comes up. So, I used my VIC20 to send on this line files over the TV-Network in our home to another VC-20 ( it worked also on the C64, too ). I had a special electric module on the USER-PORT, with a small software and that's all. Also the guy, how installed this at my home, told me, that exactly this line would to all the stuff.

So, I think maybe that is, what you find out, but I'm not for sure, it's just a explain, also forgive me please for the interrupting.

cheers Toni