| |
Parody
Registered: Jul 2013
Posts: 7 |
Leftmost sprite position and opening borders
I just noticed that x=0 for a sprite doesn't cover the "start" of the left side border, Is there any way to achieve this? |
|
| |
robo
Registered: Nov 2012
Posts: 9 |
I tried the same thing last week, you can use #$1f0 (= $f0 with xpos-hibit in $d010 set). |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
make it a 16 bit x variable, and switch d010 to make it fit |
| |
Parody
Registered: Jul 2013
Posts: 7 |
Thank you very much for the replies! :) |
| |
Firehawk
Registered: Aug 2011
Posts: 31 |
Do note that the $1f0 position is 8 pixels to the left of $000, not 16.
http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt
this page will help you with most of the quirks regarding the VIC-chip. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
how does this work internally ? seems like inner xcoo is not truly 9 bit, hence $1f0 is on the left side, how does that happen ? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
you could find out yourself easily: how did you expect it to work and why? |
| |
jailbird
Registered: Dec 2001
Posts: 1578 |
Glad to see that people are still trying to open the borders. I'm here to help on your quest with my favorite quote!
"The opened outline is able to capture something of our secret thoughts and its permutative behaviour. We can recognize an item here and there but the line always glides further with unlimited combination of associations. Curves of the consiousness, curves of the subconcious."
You're welcome. |
| |
Mixer
Registered: Apr 2008
Posts: 452 |
Chuck Norris was playing Exploding Fist, once his character kicked so hard that the borders opened and have been open for him ever since. |
| |
jailbird
Registered: Dec 2001
Posts: 1578 |
Hey Mixer, while you're here! Your sid from 3rd Stone from the Sun is one of the best C64 musics ever. Just so you know. |
| |
Cresh
Registered: Jan 2004
Posts: 354 |
Cannot agree more. But originally it is from Tour De Force |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
@Oswald: There are 63 cycles on a raster line, thus 63*8 = 504 pixels available, not 512. It's easy as that. Somewhere it has to wrap. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Never did anything with ntsc machines, but will there be a gap with these machines (since they have 65 cycles) where you can't put any sprites? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: @Oswald: There are 63 cycles on a raster line, thus 63*8 = 504 pixels available, not 512. It's easy as that. Somewhere it has to wrap.
thanks, that makes some sense.
tho the inner xcoo should still be 9 bits, right, there can not be a 8.95 bits counter so it wraps at 504 ? :)
or is it just the misalignment, that x =0 is not on the leftmost position...
not trying to be an ass here, just wondering :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:or is it just the misalignment, that x =0 is not on the leftmost position...
its an arbitrary position that was chosen so when sprite x position is 0, the sprite is hidden behind the left border.
and of course, the counter is 9 bits :) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
that makes sense again, tho it seems they forgot about x stretched sprites :) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quoting GroepazQuote:or is it just the misalignment, that x =0 is not on the leftmost position...
its an arbitrary position that was chosen so when sprite x position is 0, the sprite is hidden behind the left border.
and of course, the counter is 9 bits :)
It's not a counter, it's a compare register. If raster x>compare x then shift pixels from shift register. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
of course, raster X is the counter :) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: of course, raster X is the counter :)
That's right! ;) |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting WVLNever did anything with ntsc machines, but will there be a gap with these machines (since they have 65 cycles) where you can't put any sprites?
Hmm, did not do anything on an NTSC machines myself but I don't think that these extra cycles should be different compared to other '-'-cycles in the right sb. My guess is that sprites will show up at these positions.
It would be interesting to know wether the right NTSC-sb is 2 chars wider than the PAL-sb or if it also 'ends' after approx. 4 chars. If so, the 9-sprites-on-one-rasterline-routine would not be possbile on NTSC;)
Maybe some cracker/NTSC-fixer knows the answer. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting WVLNever did anything with ntsc machines, but will there be a gap with these machines (since they have 65 cycles) where you can't put any sprites? There must be a gap. However, it's quite likely in the horizontal blank area, such that the sprite is entirely inside the invisible part of the sideborders when it "jumps" over that gap.
According to http://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src.. , the visible part of the left border on 65-cycle NTSC is 56 pixels wide, and 44 pixels on the right border. This makes the visible area 56+320+44=420 pixels wide. Add 48 on the left side to scroll the sprite in, and you have 468 pixels. This is still less than 512.
According to http://unusedino.de/ec64/technical/misc/vic656x/pal-ntsc.html , the gap is at X=412=$19c. With above assumptions, the sprite is just outside the visible left border at coordinate $1b0 (=-$50), and just outside the visible right border at $184. $50+$184=$1d4=468.
As $184 < $19c < $1b0, the gap (which should be 8 pixels wide, less than the gap's distance to either side) should not be relevant, and you can scroll the sprite smoothly in and out the visible area. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
And now i just remembered that the -1 position (1 pixel between sprite and non-border area) is not represented as $1ff, but $1f7 or something. Should still be no problem. |
| |
null
Account closed
Registered: Jun 2006
Posts: 645 |
Quote: Glad to see that people are still trying to open the borders. I'm here to help on your quest with my favorite quote!
"The opened outline is able to capture something of our secret thoughts and its permutative behaviour. We can recognize an item here and there but the line always glides further with unlimited combination of associations. Curves of the consiousness, curves of the subconcious."
You're welcome.
I'm so happy this quote isn't dead yet. |
| |
GH
Registered: Sep 2014
Posts: 77 |
Oh it will live forever because we're just human ;) |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting KrillQuoting WVLNever did anything with ntsc machines, but will there be a gap with these machines (since they have 65 cycles) where you can't put any sprites? There must be a gap. However, it's quite likely in the horizontal blank area, such that the sprite is entirely inside the invisible part of the sideborders when it "jumps" over that gap.
...
Now I'm confused... What is actually meant by "gap"?
According to AAY64's timing schemes, the additiional cycles of NTSC machines are inserted at PAL-cycle #57. But this cycle lies within the (optionally) visible part of the right sb. So this should mean that sprites at these "additional" NTSC-cycles are visible if the right sb is opened.
The remaining question is wether the right sb ends @cyc#60 (NTSC) or @cyc#62. So "worst case" would be that the visible area in the right sb is just as wide as on a PAL system, no? |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
I think the "additional" gfx is under the right border/horizontal blank...
Otherwise we have a 8/16 pixels misaligment on sprites and screen coords in the left part of the screen...
But i can't see this difference between pal and ntsc. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting CopyfaultNow I'm confused... What is actually meant by "gap"? A gap in sprite positioning. 65 cycles equal 520 pixels, but there are only 9 bits to set the sprite X position. Thus, there are 8 positions you cannot put the sprite to. However, i'm pretty sure that you can "display" sprite pixels there, and span that gap, by setting its X position to just before that gap. The shift registers logics and all should work just fine. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Isn't possible that in ntsc a cycle equates to 7.7538... pixels, so we have always 504 screen dots, but with a little "fast sync", that isn't visible?
Just my thoughts... eh! |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: Isn't possible that in ntsc a cycle equates to 7.7538... pixels, so we have always 504 screen dots, but with a little "fast sync", that isn't visible?
Just my thoughts... eh!
No, nothing points to this being true. For instance new graphics data is fetched every cycle on the VIC-II, where would it be buffered? |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote: No, nothing points to this being true. For instance new graphics data is fetched every cycle on the VIC-II, where would it be buffered?
It should not be buffered.
The VIC would do the same tasks, but instead of finishing after eighth pixels, would end after "7.7538..." pixels.
After 65 cycles we "are" at pixel 504, as we use 8 pixels for 63 cycles...
A difference of a "0.25" pixel every 8, should not be noticeable "by eye" (and could absolutely not exist). |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: It should not be buffered.
The VIC would do the same tasks, but instead of finishing after eighth pixels, would end after "7.7538..." pixels.
After 65 cycles we "are" at pixel 504, as we use 8 pixels for 63 cycles...
A difference of a "0.25" pixel every 8, should not be noticeable "by eye" (and could absolutely not exist).
That doesn't make sense to me. There are 65 cycles on NTSC. A byte is fetched every cycle (=8 bits) So how could you display that as 7.75 pixels every cycle without having a FIFO buffer?
Sure you could stretch the first seven pixels to make the eigth pixel smaller, but it is still 8 pixels.
You should be reasoning like this: What is the easiest way to make the chip the most similar between PAL/NTSC/PAL-N? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
To see what happens check out the lightpen trigger/coordinate test here:
https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/VIC..
It triggers the lightpen cycle for cycle from just before the next frame start to a few rows after.
"analyse dumps/dump6567.prg" gives you that lightpen X $c2 (xpos $184) is doubled.
The viciisc implementation that matches this is controlled by the tables here:
https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/sr..
EDIT: It should be mentioned that the assumption is actually that $180-$187 is repeated twice, so it's more like $180 is doubled.
The reason for this assumption is that the exact offset of the lightpen trigger is 2 pixels less on the 8562.
To verify it completely, a more precise lightpen trigger has to be externally implemented. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Mumble mumble...
How this can be achieved by VIC-II:
{ Phi1(62), 0x184, None, SprDma1(1), BaSpr3(1, 2, 3), None },
{ Phi2(62), 0x184, None, SprDma2(1), BaSpr3(1, 2, 3), None },
{ Phi1(63), 0x184, None, SprPtr(2), BaSpr2(2, 3), None
...perhaps the processor can control the position of the raster beam,stopping it for 3 half-cycles?
Or, perhaps, suddenly the VIC-II accelerates? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: Mumble mumble...
How this can be achieved by VIC-II:
{ Phi1(62), 0x184, None, SprDma1(1), BaSpr3(1, 2, 3), None },
{ Phi2(62), 0x184, None, SprDma2(1), BaSpr3(1, 2, 3), None },
{ Phi1(63), 0x184, None, SprPtr(2), BaSpr2(2, 3), None
...perhaps the processor can control the position of the raster beam,stopping it for 3 half-cycles?
Or, perhaps, suddenly the VIC-II accelerates?
Xpos is a counter, not the actual beam position. There are 520 pixels clocked out during the line, although some aren't visible on the actual composite signal of course.
The sprite DMA cycles are probably another counter in the actual chip so they don't depend on the stopped xpos counter.
BTW: The mid 0x184 should probably be 0x180 in the table, but the lowest bits aren't used in practice so it doesn't matter. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
So the XPOS counter is only "lightpen-related" and not "pixel related"?
This means that to "keep it simple" in VIC There are 3 types of different coordinates: lightpen, DMA and pixels? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
The assumption is that xpos is used both for lightpen and sprite triggering. For coordinates not visible in the output signal it's hard to prove but so far it seems to fit.
There is no pixel counter. It's just the number of dotclocks that fit in 63/64/65 cycles depending on the machine.
For "DMA" and other types of triggering that seems to be handled by counting cycles during each row and triggering stuff at specific cycles (see the table), but it is probably split into several counters in the chip, e.g BA, sprite fetches, visible columns, ... |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
I did my homework, because these "double values" of XPOS do not convince me.
How many bits consists xpos?
I think is a matter of rounding.
Look at this:
473 60 14,5538461538316 372 11,4769230769116 458
474 60 14,5846153846008 373 11,5076923076808 459
475 60 14,6153846153700 374 11,5384615384500 460
476 60 14,6461538461392 375 11,5692307692192 461
477 60 14,6769230769084 376 11,5999999999884 462
478 60 14,7076923076776 377 11,6307692307576 463
479 60 14,7384615384468 378 11,6615384615268 464
480 60 14,7692307692160 379 11,6923076922960 465
481 61 14,7999999999852 380 11,7230769230652 466
482 61 14,8307692307544 381 11,7538461538344 467
483 61 14,8615384615237 382 11,7846153846036 468
484 61 14,8923076922929 383 11,8153846153728 469
485 61 14,9230769230621 384 11,8461538461420 470
486 61 14,9538461538313 385 11,8769230769112 471
487 61 14,9846153846005 386 11,9076923076804 472
488 61 15,0153846153697 387 11,9384615384496 473
489 62 15,0461538461389 388 11,9692307692188 474
490 62 15,0769230769081 388 11,9999999999880 475
491 62 15,1076923076773 388 12,0307692307572 476
492 62 15,1384615384465 388 12,0615384615264 477
493 62 15,1692307692157 388 12,0923076922956 478
494 62 15,1999999999849 388 12,1230769230648 479
495 62 15,2307692307541 388 12,1538461538340 480
496 62 15,2615384615233 388 12,1846153846032 481
497 63 15,2923076922925 388 12,2153846153724 482
498 63 15,3230769230617 389 12,2461538461416 483
499 63 15,3538461538309 390 12,2769230769108 484
500 63 15,3846153846001 391 12,3076923076800 485
501 63 15,4153846153693 392 12,3384615384492 486
502 63 15,4461538461385 393 12,3692307692184 487
503 63 15,4769230769077 394 12,3999999999876 488
504 63 15,5076923076769 395 12,4307692307568 488
505 64 15,5384615384461 396 12,4615384615260 489
506 64 15,5692307692153 397 12,4923076922952 490
507 64 15,5999999999845 398 12,5230769230644 491
508 64 15,6307692307537 399 12,5538461538336 492
509 64 15,6615384615229 400 12,5846153846028 493
510 64 15,6923076922921 401 12,6153846153720 494
511 64 15,7230769230613 402 12,6461538461412 495
512 64 15,7538461538305 403 12,6769230769104 496
513 65 15,7846153845997 404 12,7076923076796 497
514 65 15,8153846153689 405 12,7384615384488 498
515 65 15,8461538461381 406 12,7692307692180 499
516 65 15,8769230769073 407 12,7999999999872 500
517 65 15,9076923076765 408 12,8307692307564 501
518 65 15,9384615384457 409 12,8615384615256 502
519 65 15,9692307692149 410 12,8923076922948 503
520 65 15,9999999999841 411 12,9230769230640 504
First column are the "dotclocks" as they are emulated in NTSC;
second column are the cycles on the line;
third column are the incremental difference between a 520 dotclocks NTSC and an hypothetical 504 dotclock NTSC (504/65=7,75384615385 // 8-7,75384615385 = 0,246153846154/8 = 0,0307692307692 dot per cycle);
fourth column are XPOS values as reported in vice sources linked here;
fifth column are the incremental differences aligned with XPOS 0 at cycle 13 of the rasterline;
sixth column are the "dotclocks" -rounded- to be 504 in 65 cycles using the integer part of "fisrt column, minus, third colum".
Starting from the first cycle on the line, we have a "double value" (488) on cycle 63, quite exactly in the same place where XPOS is readed twice by testprogram.
Obviously, the values are not identical, but I've done the calculations using a spreadsheet, while the vic uses internal registers ...
And one last thing:
(quoted from Vic Article)
Quote:
It is important to note that the units for display and for the needed
memory accesses are separate from each other for the sprites as well as for
the graphics. There is a data buffer between the two units that holds the
read graphics data and buffers it for the display circuits. In the normal
operation of the VIC, the functions of the two units are so closely tied to
each other that they appear like a single function block. By appropriate
programming, however, you can decouple the circuits and e.g. display
graphics without previously having read data (in this case, the data which
are still in the buffer are displayed).
Could this be the "buffer" that compensates for the difference of "speed"?
I'm completely wrong? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Skepticism is good but I suggest you apply the principle of Occam's razor to this.
1. Note first that dotclock is physical input to the VIC-II. Its frequency is 8 times PHI1.
2. A fractional counter is going to be a larger piece of hardware than a regular counter with a simple wait at one cycle.
3. The original VIC-II (6567R56A, earlier?) has 64 cycles (=exactly 512). It was later adjusted to 65.
It was then made into the 6569 which has 63. The ordering of the 65 cycle chips (NTSC/PAL-N) and 63 cycle (PAL) may be disputed. Perhaps at the same time?
4. The design is limited by die space (=NMOS transistor count).
Now, we know that the 6569 has a gap just at the left border edge. Why would that be choosen if there was already a fractional implementation in the design? This gives that it is reasonable to expect that the 65 cycle version is also implemented as a gap.
Now, if we doubt this, we should try to prove or disprove our theory.
lightpen is one indication.
spritegap tests for gaps more directly by sweeping two sprites with differing xpos against each other checking for missing collisions.
e.g 01000000 00000000 00000000
against 10000000 00000000 00000000 spritescan is a framework for verifying sprite rendering anomalies. It currently doesn't check for gaps but a test can be easily added.
Spritescan uses the same principle principle as spritegap but patterns can be defined by tables to do more complex tests.
I challenge you to write a test to prove or disprove your theory. If it works on a real box but not in x64sc, please file a bug report here: https://sourceforge.net/p/vice-emu/bugs/ |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Ok, first of all... thanks for your replies, then i hope to be able to write some code regarding this...
Then... there is another "little strange thing" that goes around in my mind.
In the vic article, the "internal x coord register" was described as a 9 bits counter.
How can count more than 512 x positions with just 9 bits?
I'm thinking about also to sprite collision detection or lightpen matches in the "area" 513-520 "dots"...
How can vic know "where" is between this range? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
I suspect it's 9 bits, but uses an extra flip-flop to alternate between resetting to $180 or not when reaching $188. Just shooting from the hips though :) |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
This "flip-flop" seems to "freeze" the counter instead of resetting it... but looks like a strange and too complex solution to me... |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Which solution that is easier (and just needs a few gates) would you propose, then? And don't say anything about fractional counters :) |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
I don't have a solution... more simple o more complex, but if xpos is the same for sprites and lightpen, and we have the same value of xpos for 1 cycle = 8 pixels, how can vic detect a sprite collision correctly in this range of dots? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Collisions are not directly related to xpos. Collisions occur when data shifted out from the sprite shift registers fulfill a collision condition. Xpos is only used to trigger the sprite.
I don't believe the value of xpos stays the same. It seems like 0x180-0x187 repeats twice like I stated earlier. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
"Trigger" a sprite mean "set" where it appears?
If so, in NTSC, where would appear 2 sprites with coord $184 and $187?
{ Phi1(62), 0x184, None, SprDma1(1), BaSpr3(1, 2, 3), None },
{ Phi2(62), 0x184, None, SprDma2(1), BaSpr3(1, 2, 3), None },
{ Phi1(63), 0x184, None, SprPtr(2), BaSpr2(2, 3), None
...here we have 6 possible positions between 12 "dots"... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
LOL at those fractions |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
@flavioweb: it can be shown that a sprite can only trigger once per line so there will a gap instead of two triggers.
Perhaps if you are really sneaky you could change xpos on the fly so it gets set to $0180-$0187 exactly at the cycle where the repeat occurs? Then it should be triggered 8 pixels later which is way nerdy cool. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
i demand a test program :) |
