Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > Requests > Please run these Test-Programs....
2017-09-14 22:46
chatGPZ

Registered: Dec 2001
Posts: 11073
Please run these Test-Programs....

yay,

in order to get some definitive answers and to confirm VICE is working correctly (or not) it would be great if someone who has a video-capture card could run these test programs and provide screenshots from the real thing:

https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/VIC..

interesting are results from "new" and "old" VICII (they will produce slightly different result). this is very hard to spot on a CRT (we are talking about a one pixel difference) so if you have a way to capture the real thing please do it :)


another no less interesting case is this test program:

https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/VIC..

this one is kindof strange, since apparently it will produce different output depending on the temperature of the VICII. if you look at the two reference images... https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/VIC.. and https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/VIC.. eg notice the number of "1" in the fourth character row. this difference is apparently NOT there when the "new" VICII is "cold". it apparently appears on _some_ "new" VICII after a rather long warmup (an hour or more), and it apparently even then also randomly appears and disappears on power cycles. so for this one we need ppl with "new" C64s who can run the program, check the result, powercycle, repeat (a few times) - and do the same after a longer warmup period. the readme in that directory shows the interesting parts of the output.

thanks for your help!
2017-09-15 06:06
tlr

Registered: Sep 2003
Posts: 1698
I think you should do the modesplit one too if you do videomode-*.
Modesplit probably hasn't got all of the transitions of the videomode ones but the most important difference is that it repeats the splits for each D016 shift. Also each split is repeated for a char height making tiny changes way easier to spot.

I can add more transitions to it if you provide some suspect ones based on other findings.
2017-09-15 09:33
Oswald

Registered: Apr 2002
Posts: 5005
what is this modesplit, any interesting properties ? :) I thought it just changes mode in any cycle ?
2017-09-15 10:17
chatGPZ

Registered: Dec 2001
Posts: 11073
please, if you want to know what the testprograms do, just look at their sourcecode.
2017-09-15 10:21
Oswald

Registered: Apr 2002
Posts: 5005
I want to know what interesting properties modesplit has.
2017-09-16 15:31
tlr

Registered: Sep 2003
Posts: 1698
Quote: what is this modesplit, any interesting properties ? :) I thought it just changes mode in any cycle ?

The interesting properties are in the machine. The program just try to provoke it in a visible way. ;)

Seriously though, a lot of subtle differences got exposed through modesplit so I recommend it.
2017-09-17 18:50
chatGPZ

Registered: Dec 2001
Posts: 11073
i'd like to extend the above request....

1) please also capture https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/crt.. - that will help a lot with actually "reading" the supplied captures and compare them with emulator screenshots

2) as tlr already mentioned, please also capture https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/VIC..

thanks!

i'll be slowly work through provided results (there is no need to actually make screenshots btw... just capture a video of how you run all those tests after each other, i'll grab the screens myself) and try to create proper pixel perfect reference pictures for our testbench.
2017-09-17 22:07
Copyfault

Registered: Dec 2001
Posts: 466
Quoting Oswald
I want to know what interesting properties modesplit has.

Guess it's just what you think: triggering a change of the hires/multicol-mode within the display area. There seems to be a different behaviour between the VIC chip revisions, the chip conditions (and maybe more) so this is of particular interest.

@Groepaz: feel free to correct and/or add infos.
2017-09-18 14:20
chatGPZ

Registered: Dec 2001
Posts: 11073
yes, all those tests do is switching between various modes. the point is that the switches do NOT take effect on character boundaries, but are delayed by one or two (or three) pixels - depending on the VIC revision, and apparently also on temperature. the more you look at it, the less straightforward it gets.

thus: please provide some captures - its the only way to make this accruate.
2017-09-25 23:23
chatGPZ

Registered: Dec 2001
Posts: 11073
Anyone? Lemming? ZeroX? Xiny? please... :)
2017-09-26 09:21
Xiny6581

Registered: Feb 2004
Posts: 71
Okay I will give it a go now!
Let's hope my capture-card is with me.
:)
2017-09-30 09:07
MagerValp

Registered: Dec 2001
Posts: 1055
I don't have a video capture card, but maybe a 4k video of a studio monitor works?

http://termos.hg5.gu.se:8000/

This is my 8580 BN/E machine, has been powered on for about 10 minutes.
2017-09-30 10:30
chatGPZ

Registered: Dec 2001
Posts: 11073
will check... generally its a bit hard to overlay/compare screenshots with anything that doesnt come from a capture device though :)
2017-10-20 20:51
ChristopherJam

Registered: Aug 2004
Posts: 1356
Looking at this properly now my MMC64 is working again.

My only capture device is a 100MHz scope that sadly can only buffer a raster line or three, which just leaves me with photos of my monitor, unless the tests were rewritten to be a black screen aside from a line of interest so I can trigger off the first white pixel.

I assume the mode switching delays could also be measured using sprite collisions? Happy to put together a test along those lines if there's interest.
2017-10-21 03:27
willymanilly

Registered: Jan 2016
Posts: 27
I can confirm the output of my c64 emulator matches my real c64 to the pixel level when running all those videomode programs. I don't have a video-capture card to take nice screens shots but I spent quite a bit of time running all these programs side by side to match the real thing. My real c64 revision is 250466.

Another note is on my real c64, on the ECM line of the vici_timing test turns back to checkered pattern one cycle later than expected, based on the observations of the output I get from modesplit, to match the alignment of BMM above. https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/VIC..

All of the above is emulated on my emulator to match my real c64, including fetchsplit, if you want some references to what my real C64 displays. http://www.z64k.com/resources/Z64KNewUI.jar

I've temporarily uploaded screenshots of modesplit and vici_timing from my real c64. They were just taken with my phone so don't expect the best quality. I never took any good shots of the other modes so don't have any to provide you. http://www.z64k.com/resources/modesplit.jpg
http://www.z64k.com/resources/vicii_timing.jpg
2017-10-23 01:04
chatGPZ

Registered: Dec 2001
Posts: 11073
Quote:
I can confirm the output of my c64 emulator matches my real c64 to the pixel level when running all those videomode programs.

how exactly did you check this? i find it extremely hard to check just looking at the output side by side - a lot of subtle one pixel differences are impossible to see that way, IMHO

that said, it would help a great deal if some more ppl could provide captures....
2017-10-23 05:50
willymanilly

Registered: Jan 2016
Posts: 27
Quote: Quote:
I can confirm the output of my c64 emulator matches my real c64 to the pixel level when running all those videomode programs.

how exactly did you check this? i find it extremely hard to check just looking at the output side by side - a lot of subtle one pixel differences are impossible to see that way, IMHO

that said, it would help a great deal if some more ppl could provide captures....


Taking into account my limited access to dedicated video capture equipment, I agree it's not ideal to rely on visual comparison, but long story short I connected my c64 to a 4K monitor which gave me much larger pixels to look at. I also played around the XSCROLL with the abovementioned test programs in the videomode folder to see the behaviour of the pixels as XSCROLL increased. From those results I simplified the logic of my VICII pixel rendering model as much as I could but ensuring it still accounted for all the observed behaviour when switching video modes. I spent considerable time on this and while I still might not have the perfect model and I might have misread a pixel position, I have triple checked my emulator matches the output of my real C64 that I use for benchmarking. A Video capture card would be very handy and it's something I've considered getting. It would definitely be a great help if other people can provide captures! :)
2017-10-23 11:45
wacek

Registered: Nov 2007
Posts: 487
Groepaz, do you still need those captures? Or is this case solved?
I can do some in decent quality.
2017-10-23 12:13
chatGPZ

Registered: Dec 2001
Posts: 11073
yes, the more captures from different people/setups the better. this is not an exact science unfortunately, new unexpected things pop up left and right =P

in case it wasnt mentioned yet, please also do modesplit and fetchsplit ... and to make it easier to handle, put the VIC revision and board ASSY number into the filename(s) please
2017-10-23 18:52
wacek

Registered: Nov 2007
Posts: 487
Groepaz, check these and let me know if they are any good quality wise.
http://arise64.pl/misc/vicetests1.zip
2017-10-23 19:50
chatGPZ

Registered: Dec 2001
Posts: 11073
quality looks ok... whats the exact ASSY# and VIC? just new/old isnt enough (i wish it was that easy...)
2017-10-23 20:44
wacek

Registered: Nov 2007
Posts: 487
VIC 8565R2 3891 22
PCB ASSY 250469 / NO 252311 REV.B
2017-10-23 20:55
wacek

Registered: Nov 2007
Posts: 487
If quality is good then I can do some more sets like this on the weekend (or earlier if I manage). I have like 30+ different 64s, at least 2 of which are the old ones.
2017-10-23 21:57
chatGPZ

Registered: Dec 2001
Posts: 11073
mmh checked again... these captures seem to be scaled somehow, thats not good... horizontal distortion is expected (and probably cant be avoided) - however, vertically it should be one (or two, or whatever even factor) pixels per actual scanline - else its quite impossible to overlay the reference pictures in a useful way :(
2017-10-23 22:07
wacek

Registered: Nov 2007
Posts: 487
Hmm. Then I need to go a different hardware route, utilising firewire. That will get the pix per line that you need. Definitely on the weekend then ;)
2017-10-23 22:30
chatGPZ

Registered: Dec 2001
Posts: 11073
no hurry :) i can only work on it on weekends myself :)
2017-10-28 15:16
chatGPZ

Registered: Dec 2001
Posts: 11073
could a moderator please delete the unrelated bullshit from here? thanks
2017-10-28 15:42
hedning

Registered: Mar 2009
Posts: 4542
Quote: could a moderator please delete the unrelated bullshit from here? thanks

Done. People: Keep to the topic ffs!
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Mike
JackAsser/Booze Design
jmin
Airwolf/F4CG
Matt
csabanw
MAT64
DeMOSic/HF^MS^BCC^LSD
psych
Guests online: 175
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 No Bounds  (9.6)
6 Comaland 100%  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 No Sprites  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 Party Elk 2  (9.7)
2 Cubic Dream  (9.6)
3 Copper Booze  (9.5)
4 Rainbow Connection  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Onscreen 5k  (9.5)
7 Dawnfall V1.1  (9.5)
8 Quadrants  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Birth of a Flower  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Nostalgia  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Logo Graphicians
1 Sander  (10)
2 Facet  (9.6)
3 Mermaid  (9.4)
4 Shine  (9.3)
5 Pal  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.085 sec.