| |
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;) |
|
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Can confirm: https://csdb.dk/forums/?roomid=11&topicid=128036#139185
(But i still have only a 64-cycle NTSC machine.) |
| |
hedning
Registered: Mar 2009
Posts: 4595 |
WTF is wrong here.
 |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting 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;)
Quoting hedningWTF is wrong here.
(image left out) Oh, this looks odd indeed. Could you tell me what kind of setup you have that gives this result? Especially the missing numbers in the upper rows are not as it should be. Or is it "just" some $D8xx-colours accidentally set to dark blue (I refrained from initialising $d8xx)? Hope we can sort this out... |
| |
hedning
Registered: Mar 2009
Posts: 4595 |
Quote: Quoting 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;)
Quoting hedningWTF is wrong here.
(image left out) Oh, this looks odd indeed. Could you tell me what kind of setup you have that gives this result? Especially the missing numbers in the upper rows are not as it should be. Or is it "just" some $D8xx-colours accidentally set to dark blue (I refrained from initialising $d8xx)? Hope we can sort this out...
C64 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. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting CopyfaultOr is it "just" some $D8xx-colours accidentally set to dark blue (I refrained from initialising $d8xx)? With such an old machine, definitely quite likely. Older ROM revisions set char colours to background colour when clearing the screen. Can quickly be found out using a cartridge monitor, of course. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting CopyfaultSo 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;) Not the only error or outdated knowledge it has, but it actually only needs a new revision. =) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
don't forget to send patches/updates to https://sourceforge.net/p/vice-emu/code/HEAD/tree/techdocs/VICI.. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Groepazdon't forget to send patches/updates to https://sourceforge.net/p/vice-emu/code/HEAD/tree/techdocs/VICI.. Haven't considered this before, tbh. I think many parts need pretty thorough edits and more explanation, first and foremest to make it more accessible and lower the entry bar considerably. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
go ahead :) |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
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. |
... 10 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
