VICE palette files with colors as seen on real machines

You need an actual VIC.

Moderator: Moderators

User avatar
tokra
Vic 20 Nerd
Posts: 813
Joined: Tue Apr 27, 2010 5:32 pm
Location: Germany

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

Postby tokra » Thu Nov 19, 2015 11:31 am

Will check and compare with my NTSC-VIC and 1084.

One other question that always bugged me: VICE has an internal palette and an external palette. If I choose the external palette default.vpl it looks completely different from the internal one. This is true for xvic, x64, x128 at least. What is the difference between the internal and external default-palette?

groepaz
Vic 20 Nerd
Posts: 570
Joined: Wed Aug 25, 2010 5:30 pm

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

Postby groepaz » Thu Nov 19, 2015 11:50 am

"internal" is calculated on the fly using the (hopefully correct) color angles/hues as by peptos research. the various "external" palettes are the much older RGB palettes, which once created never got updated. or something :) (replacing the old default palette for c64 by a current "pepto palette" is indeed on my todo list for that matter). for the most part, the external RGB palettes should be treated as out of date legacy material that is only there for reference and those people who cant live without them, all development/fixing/updating goes into the internal color generator :)

User avatar
tokra
Vic 20 Nerd
Posts: 813
Joined: Tue Apr 27, 2010 5:32 pm
Location: Germany

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

Postby tokra » Thu Nov 19, 2015 3:39 pm

I see, thanks. Somehow in my head the name "default" gave the palette importancy. I would say the NTSC-colors of VICE look ok. My orange is a little less "orangey" on my NTSC-VIC on my 1084, but I've seen pictures from other people here who have a better orange than me. Other than visual comparions I cannot help much sadly.

However I took the opportunity to measure the display of the NTSC-VIC on my 1084. I've resized the monitor settings so that there are no borders anymore and I can see the full area that the VIC displays (squeezing both vertically and horizontally). When I did the same for my PAL-VIC on the same monitor I got exactly the 224x283 display that VICE shows in PAL for "Normal Borders" mode, including the 284th at the bottom line that will ALWAYS be the border color, no matter what.

Anyway, here goes for NTSC, pictures first:

Standard screen 22x23: $9000 = 5 $9001 = 25 ($19)
IMG_0529.JPG

One character (8 pixels) to the right: $9000 = 7
IMG_0530.JPG

Two characters (16 pixels) to the left: $9000 = 1
IMG_0531.JPG

22 pixels up: $9001 = 14
IMG_0532.JPG

26 pixels down: $9001 = 38
IMG_0533.JPG


Continued in next post...
Last edited by tokra on Thu Nov 19, 2015 5:28 pm, edited 3 times in total.

User avatar
tokra
Vic 20 Nerd
Posts: 813
Joined: Tue Apr 27, 2010 5:32 pm
Location: Germany

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

Postby tokra » Thu Nov 19, 2015 3:54 pm

Adding another character line at the bottom: $9003 = 48 (24 lines)
Only the top rasterline of the new characterline is visible. Border-colored single rasterline below that one
IMG_0534.JPG

Full visible screen: 25 columns (200 pixels), 29 character lines (232 rasterlines)
IMG_0527.JPG

Two rasterlines lower. My later experiments confirmed the last rasterline of the last characterline is not visible here and the 234th line will always be the border-color. So the total visible resolution is 200x233 pixels (and a 234th rasterline in border-color)
IMG_0528.JPG


It would be nice if VICE would reflect these screen dimensions for NTSC (VIC-Setting: normal borders)

Overview:

PAL: total screen dimension of 224x283 + 284th rasterline in bordercolor - already emulated by VICE
NTSC: total screen dimension of 200x233 + 234th rasterline in bordercolor
Border margins from standard screen (after powering the device) differ from original machine: Should be 8 pixels to the right, 16 pixels to the left, 22 pixels to the top, 26 pixels to the bottom

groepaz
Vic 20 Nerd
Posts: 570
Joined: Wed Aug 25, 2010 5:30 pm

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

Postby groepaz » Thu Nov 19, 2015 5:35 pm

cool, thanks for the pictures! i updated the vertical dimensions in r30200 - for the horizontal dimensions its not that easy (ie not prepared for in the code), i dont know how to change that right now - perhaps you can convince TLR to have a look at it :)

User avatar
tokra
Vic 20 Nerd
Posts: 813
Joined: Tue Apr 27, 2010 5:32 pm
Location: Germany

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

Postby tokra » Thu Nov 19, 2015 6:08 pm

Thanks, will drop him a line. While we are drifting off-topic anyway: Wondering if IO2/IO3 RAM- (and ROM)-expansion at $9800-$9bff and $9c00-$9fff could be implemented to VICE (Settings-VIC20 settings-Custom). There were very few tools released for that memory-area, but it is completely viable.

groepaz
Vic 20 Nerd
Posts: 570
Joined: Wed Aug 25, 2010 5:30 pm

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

Postby groepaz » Fri Nov 20, 2015 4:00 am

for that please open a ticket on sf (feature request) and provide as much info about it as you can ... it shouldnt be hard to add, i guess.

User avatar
beamrider
Vic 20 Nerd
Posts: 825
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

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

Postby beamrider » Fri Nov 20, 2015 8:47 am

Would also be nice to have a "reduced border" option, that gives perhaps a 1cm border?

groepaz
Vic 20 Nerd
Posts: 570
Joined: Wed Aug 25, 2010 5:30 pm

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

Postby groepaz » Fri Nov 20, 2015 11:53 am

uhm... we already have full/normal/debug/none .... is there really a need for yet another border option? IMHO especially for vic20 its a bit doubtful, since the size of the display window is not fixed

User avatar
beamrider
Vic 20 Nerd
Posts: 825
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

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

Postby beamrider » Fri Nov 20, 2015 12:28 pm

When I developed Popeye on my small laptop, I often removed the border (otherwise it was too small to see). However after doing this, you can't tell when the screen display is shifted by poking 36864/5 since it doesn't move up/down without a border. A minimal border would rectify this.

User avatar
tokra
Vic 20 Nerd
Posts: 813
Joined: Tue Apr 27, 2010 5:32 pm
Location: Germany

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

Postby tokra » Fri Nov 20, 2015 1:09 pm

I only use "normal" and "debug" border mode. Never understood the need for "full" or even "no border". Blowing up the 22x23 screen to fullscreen would not feel like the VIC-20 anymore for me. But I guess you could compile VICE yourself with those kind of changes.

I think VICE should be about emulating the hardware as good as possible first and foremost. Branches that offer different user-features are always possible.

Still missing from emulation for example is NTSC-interlace. I've wrote a small programm that can discern between an emulated NTSC-VIC-20 and an original one:
emutest.zip
(367 Bytes) Downloaded 19 times

This is done by checking for rasterline $83 (131) which is only shown on every second half-frame. It does not occur in non-interlaced display. If it does not trigger in interlace-mode as well you have an emulated VIC-20.

While rewriting the whole VIC-display might be too much too handle for anyone right now, maybe there is a workaround for this behavior so that in interlace-mode (bit 7 of $9000 set) there is an extra-rasterline for every second frame where $9004 gets increased to $83 (131).

Edit: Just found some old notes of mine regarding interlace-mode:
- normal picture has 261 full rasterlines of 65 cycles each for a total of 16965 cycles
- interlaced picture has 263 odd-field-lines and 262 even-field-lines for a total of 525 lines which means a complete interlaced picture has 65x525= 34125 cycles which are 3x65 more than two full non-interlaced pictures
- the odd-field-lines are displayed above the even-field-lines
Last edited by tokra on Fri Jan 22, 2016 8:50 am, edited 1 time in total.

User avatar
tokra
Vic 20 Nerd
Posts: 813
Joined: Tue Apr 27, 2010 5:32 pm
Location: Germany

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

Postby tokra » Fri Jan 22, 2016 8:42 am

groepaz wrote:cool, thanks for the pictures! i updated the vertical dimensions in r30200 - for the horizontal dimensions its not that easy (ie not prepared for in the code), i dont know how to change that right now - perhaps you can convince TLR to have a look at it :)

I noticed that in VICE 2.3 the horizontal alignment of the VIC-image in NTSC was still correct as shown here:

Image

Starting with VICE 2.4 it was (wrongfully) centered. I think I finally found the culprit in the VICE-source at:

http://sourceforge.net/p/vice-emu/code/ ... viewport.c

Code: Select all

    /* Horizontal alignment strategy (from small to big):
     * 1. cut off left border, cut as much as needed from the right side of gfx
     *    except for moving area chips, there cut of equally from left/right side
     * 2. gfx fits, try to make the border area symmetric
     * 3. reveal the asymmetric border part, without black bands
     * 4. the complete screen fits, try to do equal black banding for the remaining space */

    /* smallest of left/right border */
    small_x_border = (int)screen_size->width - (int)gfx_position->x - (int)gfx_size->width;
    if (small_x_border > (int)gfx_position->x) {
        small_x_border = (int)gfx_position->x;
    }
    /* Easy part, just put it in center with symmetric borders */
    if ((int)gfx_size->width + small_x_border * 2 > (int)width) {
        first_x = (int)gfx_position->x - ((int)width - (int)gfx_size->width) / 2;
    } else { /* With a lot of space it's possible reveal the extra non-symmetric border part */
        if ((int)gfx_position->x > small_x_border) { /* left border bigger */
            first_x = (int)screen_size->width - (int)width;
        } else { /* right border bigger */
            first_x = 0;
        }
    }
    x_offset = ((int)width - (int)screen_size->width) / 2;

    if (x_offset < 0) {
        x_offset = 0;
    }
    if (first_x < 0) {
        first_x = 0;
    }
    /* Stop at the border, unless gfx_area_moves, then cut off even more */
    if (!geometry->gfx_area_moves && first_x > (int)gfx_position->x) {
        first_x = (int)gfx_position->x;
    }
    viewport->first_x = first_x;
    viewport->x_offset = x_offset;

This routine centers the image within the VICE-window unless there is enough space to "reveal the extra non-symmetric border part" as mentioned in the code. You can force this for example by chosing full-border-mode or debug-border-mode in VICE (Settings-VIC settings).

Essentially for correct emulation of VIC20-NTSC-behaviour, it should take the else-branch in the code above at

Code: Select all

    } else { /* With a lot of space it's possible reveal the extra non-symmetric border part */

even if the image is not centered within the VICE-window.

Don't really know how to make this change myself, will PM this to groepaz as well.

groepaz
Vic 20 Nerd
Posts: 570
Joined: Wed Aug 25, 2010 5:30 pm

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

Postby groepaz » Fri Jan 22, 2016 9:51 am

unfortunately this isnt the right place to fix it - it must be fixed in vic20 specific code

User avatar
tokra
Vic 20 Nerd
Posts: 813
Joined: Tue Apr 27, 2010 5:32 pm
Location: Germany

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

Postby tokra » Fri Jan 22, 2016 10:04 am

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?

* 2. gfx fits, try to make the border area symmetric

Will open a bug on VICE to further explain this.

User avatar
tokra
Vic 20 Nerd
Posts: 813
Joined: Tue Apr 27, 2010 5:32 pm
Location: Germany

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

Postby tokra » Fri Jan 22, 2016 1:47 pm

Hmm, researched this some more in the VICE-sourcecode. In victypes.h it says:

Code: Select all

#define VIC_PAL_SCREEN_WIDTH            272
#define VIC_NTSC_SCREEN_WIDTH           208

Where do these values come from? I can trace them back to at least 2008 when they still were in vic.h
For PAL the value is 68 cycles (* 4 pixels) = 272 - this is 3 cycles short of the 71 PAL-cycles
For NTSC the value does not really make sense and would just be 52 out of 65 cycles.
If I apply the rule of deducting 3 cycles like for PAL I would end up with 62 cycles * 4 pixels = 248

Then in vic-timing.h there are the various border-mode-settings for VICE:

Code: Select all

/* PAL: total screen dimension of 224x283 + 284th rasterline in bordercolor */
#define VIC_PAL_NORMAL_FIRST_DISPLAYED_LINE         28
#define VIC_PAL_NORMAL_LAST_DISPLAYED_LINE          311
#define VIC_PAL_NORMAL_DISPLAY_WIDTH                224

#define VIC_PAL_FULL_FIRST_DISPLAYED_LINE           18
#define VIC_PAL_FULL_LAST_DISPLAYED_LINE            311
#define VIC_PAL_FULL_DISPLAY_WIDTH                  248

#define VIC_PAL_DEBUG_FIRST_DISPLAYED_LINE          0
#define VIC_PAL_DEBUG_LAST_DISPLAYED_LINE           311
#define VIC_PAL_DEBUG_DISPLAY_WIDTH                 272

#define VIC_PAL_NO_BORDER_FIRST_DISPLAYED_LINE      76
#define VIC_PAL_NO_BORDER_LAST_DISPLAYED_LINE       259
#define VIC_PAL_NO_BORDER_DISPLAY_WIDTH             176

/*
    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.
 */

/* NTSC: total screen dimension of 200x233 + 234th rasterline in bordercolor */
#define VIC_NTSC_NORMAL_FIRST_DISPLAYED_LINE        27
#define VIC_NTSC_NORMAL_LAST_DISPLAYED_LINE         260
#define VIC_NTSC_NORMAL_DISPLAY_WIDTH               200

#define VIC_NTSC_FULL_FIRST_DISPLAYED_LINE          4
#define VIC_NTSC_FULL_LAST_DISPLAYED_LINE           260
#define VIC_NTSC_FULL_DISPLAY_WIDTH                 204

#define VIC_NTSC_DEBUG_FIRST_DISPLAYED_LINE         0
#define VIC_NTSC_DEBUG_LAST_DISPLAYED_LINE          260
#define VIC_NTSC_DEBUG_DISPLAY_WIDTH                208

#define VIC_NTSC_NO_BORDER_FIRST_DISPLAYED_LINE     50
#define VIC_NTSC_NO_BORDER_LAST_DISPLAYED_LINE      233
#define VIC_NTSC_NO_BORDER_DISPLAY_WIDTH            (176 + 8) /* FIXME */

The 272 for PAL can be found again in the VIC_PAL_DEBUG_DISPLAY_WIDTH. The 248 for VIC_PAL_FULL_DISPLAY_WIDTH lie in the middle between the 224 visible with normal borders and the 272 for debug borders.

Applying the same logic to NTSC the values should be:

VIC_NTSC_DEBUG_DISPLAY_WIDTH 248
VIC_NTSC_FULL_DISPLAY_WIDTH 224

It would be interesting to know WHY exactly the values were chosen in VICE as above. From what I heard there never was a real NTSC-VIC20-maintainer, so maybe it was just set to something that works?


Return to “Emulation and Cross Development”

Who is online

Users browsing this forum: No registered users and 1 guest