| | 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? |
|
... 37 posts hidden. Click here to view all posts....
|
| | 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/ |
| Previous - 1 | 2 | 3 | 4 | 5 - Next | |
