| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Comparing VIC-types: 65-cycle-NTSC vs. 63-cycle-PAL
While experimenting with NTSC-fixing a PAL-based routine for a gfx-mode, I stumbled across an oddity I cannot believe it's true.
Let's consider the following setup: raster IRQ on line $2f, all sprites active, timer configured s.t. it can be used for dejittering and that it gives a unique value for each cycle postion in every rasterline (this is usually the case when using a timer for dejittering).
According to the mighty VIC-article, a PAL-line is build up like this:
cycle# 00000000011111..............555556666
cycle# 12345678901234..............567890123
VIC-op [sprfetch]-XXX[free/badline]XXX[sprf]
The VIC-article also offers a cycle sheet for NTSC:
cycle# 00000000011111..............55555666666
cycle# 12345678901234..............56789012345
VIC-op [sprfetch]-XXX[free/badline]--XXX[sprf]
So the two additional cycles are placed right before the VIC-overtake-cycles for the sprite-fetches start.
Now with the timer we could step through all these cycle positions and check which timer value is read. For this purpose I wrote a little test program: Timercompare NTSC vs. PAL.
To my big surprise, I was not able to reach cycle-position 56 with the timer. Also, after a badline, I only get one value; delaying another cycle makes me read the timer value of cycle position 10 (which I always thought is blocked by a sprite fetch).
Could it be the VIC-article is wrong? Vice gave the same results as a real 65-cycle-NTSC-C64 (Thanks to Groepaz for testing!).
The values I get with my test prog suggest that on 65-cycle-NTSC-machines, the VIC-operations are distributed slightly different, i.e. like this:
cycle# 00000000011111..............55555666666
cycle# 12345678901234..............56789012345
VIC-op [spfetch]--XXX[free/badline]-XXX[sprft]
Maybe this is known already, but for me this was a big surprise so I post it here.
It would be really cool if some NTSC-users ran the test program linked above and share the values that are filled in $0d00..$0d7f.
Or I am completely missing a point and did something wrong in my test prog. But in this case I'd really like to be enlightened how the values can be explained;) |
|
... 10 posts hidden. Click here to view all posts....
|
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting CopyfaultQuoting KrillCan confirm: https://csdb.dk/forums/?roomid=11&topicid=128036#139185
(But i still have only a 64-cycle NTSC machine.) Thanks for the pointer! Was not aware that this thread also contains a discussion of how the VIC-cycles behave on NTSC machines.
So it seems that THE VIC-article is not correct. Still can't believe it, that article was the ultimate guide for anything about VIC for me... up to now, that is;)
From what I remember when we implemented x64sc the VIC-article wasn't very accurate regarding NTSC. I guess Christian mostly focused on PAL and didn't verify the NTSC findings as much. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting hedningC64 breadbin NTSC, 1983 ASSY 250407. Will test it on my C64C NTSC machine as well later on. will open that one and look what ASSY it is. Both passed C64 diagnostics without errors. Thanks for doing the test! The characters on the screenshot give the same result as I had with Vice, CCS64 and what Groepaz reported from his real NTSC-machine-test.
Motivated by he missing characters on your screen, I added a "colfix"-version of the test, hoping it does not need a separate entry here. Ofcourse I'll create a new one if csdb moderation wants it to be separated. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting Silver Dream !Quoting Copyfault
Could it be the VIC-article is wrong? Vice gave the same results
Let's quickly check it with a different method
https://dl.dropboxusercontent.com/s/hjjfdl15cu983dj/6567R8timin..
This is 6567R8 there. What exactly is going on here? The y-position of one sprite is switched, which in turn seems to affect colours in the right sideborder.
Have to admit I did not try *really* hard, but I was not able to interpret this test sufficiently to decide if it leads to the same result.
Could you share a few words on how the test actually is done and what can be seen in the video? |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Sure. When no sprites are on the line, then all cycles are available, which can be seen as the line changes colour every cycle. When I move the sprite (0 in this case) onto the line then you can see, which cycle it exactly affects - IOW where the two extra cycles are taken by sprite data fetch and VIC does not listen to us anymore. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
And - FWIW - it surely doesn't look like matching the diagram in The VIC-II article by (hats off) Christian Bauer. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting Silver Dream !Sure. When no sprites are on the line, then all cycles are available, which can be seen as the line changes colour every cycle. When I move the sprite (0 in this case) onto the line then you can see, which cycle it exactly affects - IOW where the two extra cycles are taken by sprite data fetch and VIC does not listen to us anymore. Ok, think I got it: you write a colour every cycle (by use of REU or whatnot?) and the write-accesses work for all "free" cycles in a line but also for the overtake-cycles before the sprite fetch happens. So the 3-char-wide-brown in the sb on the right visualizes the last overtake-cycle and the two sprite-fetch-cycles for spr0.
This indeed coincides with what my test prog says:) |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
I upscaled the output (and corrected the off-by-one :-) so here this should be better visible:
https://dl.dropboxusercontent.com/s/ybg231g8jxjadh6/6567R8timin..
The one "yellow" cycle #56 is taken to open the border. I could of course polish it to show everything but the point is already made anyway. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Quoting CopyfaultOk, think I got it: you write a colour every cycle (by use of REU or whatnot?)
Yup - the whatnot ;-) Namely I wrote a few lines in VBASIC. With hardware support of course. |
| |
hedning
Registered: Mar 2009
Posts: 4595 |
Quote: Quoting hedningC64 breadbin NTSC, 1983 ASSY 250407. Will test it on my C64C NTSC machine as well later on. will open that one and look what ASSY it is. Both passed C64 diagnostics without errors. Thanks for doing the test! The characters on the screenshot give the same result as I had with Vice, CCS64 and what Groepaz reported from his real NTSC-machine-test.
Motivated by he missing characters on your screen, I added a "colfix"-version of the test, hoping it does not need a separate entry here. Ofcourse I'll create a new one if csdb moderation wants it to be separated.
The fixed version works fine on the 1983 250407 now. :) Thanx. Will send reports (screenshots) to you now on e-mail. Also tested my second ntsc machine (250466 from 1987). |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Received the email with the tests. The results are on par with those of the other tests done by Groepaz and what I checked on the emulators: one additional cycle before the overtake cycles of the sprite-fetches and one additional cycle after sprite fetches are done (i.e. cycles#10 and #11 are free to use, even on a badline).
Think we can put the myth told by the VIC-article to rest now;) Thanks to everyone for the support and hints!!!
The VIC-addendum Groepaz pointed to should be updated accordingly... hmm, actually also THE VIC-article itself. |
| Previous - 1 | 2 - Next |
