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?

"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

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)

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

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

22 pixels up: $9001 = 14

26 pixels down: $9001 = 38

Continued in next post...

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

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)

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 VICENTSC: total screen dimension of 200x233 + 234th rasterline in bordercolorBorder 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

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

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.

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:

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.

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:

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

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

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

Where do these values come from? I can trace them back to at least 2008 when they still were in vic.hFor PAL the value is 68 cycles (* 4 pixels) = 272 - this is 3 cycles short of the 71 PAL-cyclesFor 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:

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 248VIC_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?