How can this be fixed in vic20 specific code when the viceo-viewport.c forcefully centers the picture to the border, when the VIC-20 itself does not do so?

that code is for centering the entire image within the viewport - ie the "borders" is the black area around the actual emulator picture when you eg go to fullscreen mode and dont have hardware scaling enabled. try switching to "full borders" in the c64 emulator - then the picture is not centered either..... but the vic20 code can not do that apparently.

the "debug" numbers are the actual limits (including overscan) - these are probably the only ones that are correct (because you can pretty much calculate them)the other numbers.... i dont know where they come from. some of them i have interpolated from the others when i added the different border modes....

if you really want to dig into this, look at what the C64 code does for "full border" and port that to the respective vic20 code

and no, there never was a specific maintainer for NTSC - TLR did most of the recent vic20 stuff for that matter.

Thanks for explaining! Hmm, with the recent VICE from pokefinder in NTSC-mode and Debug Borders I get "uneven" left and right borders right now in xvic as well. So the functionality must be there already. As the VIC can shift its borders by $9000 and $9001 this must be hidden deeper in the code. Still looking. It worked correctly in VICE 2.3 before so that's even more confusing.

I've also investigated the "debug"-borders for C64 and for PAL it seems to go for the full 63 cycles * 8 pixels = 504 pixels with 136 left sideborder and 48 right sideborder. Debug-border for PAL VIC20 are set to 272 in VICE right bow, but going by the C64-rule should be set to 284 (71 cycles * 4 pixels).

a lot has been changed/rewritten since 2.3, so thats not really a good reference...

when changing that value to 284 (or 260 for NTSC) you get black borders left and right, it seems the rendering code doesnt write to these pixels at all. yawn (i guess thats why the numbers are what they are, they hide the non working area)

groepaz wrote:when changing that value to 284 (or 260 for NTSC) you get black borders left and right, it seems the rendering code doesnt write to these pixels at all. yawn (i guess thats why the numbers are what they are, they hide the non working area)

Apart from vic-timing.h the values also need to be changed in victypes.h, then you have no black bars:

Interesting are the values 12 and 38 hiden in there in the middle. These are the ROM-start values for left border ($9000) and top-border ($9001) VIC-registers from PAL. The comment says they are handled dynamically, but at least changes in the first value have some effect. NTSC-values would be 5 and 25. I tried these, but they screw up the PAL-display then. The $9001-value really has no effect. I have no idea how this can work right now. Must be somewhere inside vic.c

Ok, I think I finally got it. In fact as suspected I needed to provide a different value in "raster_set_geometry" where it says "12 * 4 * VIC_PIXEL_WIDTH" right now. I now set this variably depending on machine-type and border-mode. This also allows a fix for

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.

tokra wrote: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.

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.