VICE palette files with colors as seen on real machines

You need an actual VIC.

Moderator: Moderators

groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: VICE palette files with colors as seen on real machines

Post by groepaz »

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.

there already exists a ticket for it too: https://sourceforge.net/p/vice-emu/bugs/689/
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Re: VICE palette files with colors as seen on real machines

Post by tokra »

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).
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: VICE palette files with colors as seen on real machines

Post by groepaz »

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)
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Re: VICE palette files with colors as seen on real machines

Post by tokra »

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:

Code: Select all

#define VIC_PAL_SCREEN_WIDTH            284
#define VIC_NTSC_SCREEN_WIDTH           260
However when I do so it f*cks up the left border position in NTSC-mode completely...
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: VICE palette files with colors as seen on real machines

Post by groepaz »

ew... what the hell :) getting closer anyway, all that is missing now is a way to offset the whole display window somehow.... *shrug* (and i really wonder why only NTSC is affected in such a weird way)
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Re: VICE palette files with colors as seen on real machines

Post by tokra »

It gets even weirder... vic.c calls

Code: Select all

    raster_set_geometry(&vic.raster,
                        width, height,
                        vic.screen_width * VIC_PIXEL_WIDTH,
                        vic.screen_height,
                        22 * 8 * VIC_PIXEL_WIDTH,
                        23 * 8,          /* handled dynamically  */
                        22, 23,          /* handled dynamically  */
                        /* handled dynamically  */
                        12 * 4 * VIC_PIXEL_WIDTH,
                        38 * 2 - vic.first_displayed_line,
                        1,
                        vic.first_displayed_line,
                        vic.last_displayed_line,
                        vic.screen_width + vic.max_text_cols * 8,
                        vic.screen_width + vic.max_text_cols * 8);
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
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: VICE palette files with colors as seen on real machines

Post by groepaz »

vic20.c:machine_change_timing() is where it all starts.... and then vic.c:vic_change_timing() and vic-timing.c:vic_timing_set() ....

can you fix the NTSC mode by changing those value in the first place?
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Re: VICE palette files with colors as seen on real machines

Post by tokra »

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

Code: Select all

/*
    FIXME: in NTSC the text window is (by default) not centered on the line,
           some way to do that is needed to make "no border" work correctly.
 */
in vic-timing.h and now makes "No Border"-mode in NTSC work correctly.

Only 4 files total in VICE's vic20-directory needed some minor changes. Please find attached submitted for your approval :)
Attachments
xvic-fix.7z
(839.9 KiB) Downloaded 85 times
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: VICE palette files with colors as seen on real machines

Post by groepaz »

excellent patch! slightly cleaned up and applied in r30456
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Re: VICE palette files with colors as seen on real machines

Post by 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:
Image

I tried on the original machine how far down I can push the picture. This is with POKE 36865,130 (= rasterline 260)
IMG_0671.JPG
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:
IMG_0672.JPG
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
IMG_0673.JPG
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
Attachments
xvic-ntsc-vertical-fix.7z
(836.78 KiB) Downloaded 85 times
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: VICE palette files with colors as seen on real machines

Post by groepaz »

again, added in r30482 ... keep it coming :)
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: VICE palette files with colors as seen on real machines

Post by Mike »

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:

Image

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
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: VICE palette files with colors as seen on real machines

Post by 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 :)
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Re: VICE palette files with colors as seen on real machines

Post by tokra »

Found some time to whip up a test program. Results show Mike was right... is he ever wrong? :D
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 83 times
PAL-screenshot:
IMG_0677.JPG
NTSC-screenshot:
IMG_0679.JPG
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: VICE palette files with colors as seen on real machines

Post by groepaz »

I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
Post Reply