Cosmic Ark stars width

[thrust26]

The stars are all 1 pixel wide, while they are changing width between 0 (invisible), 1 and 2 pixel in the old core (and on real hardware too).

Also check the attached file which uses the same effect but with four objects. In the new core, all dots are 2 pixel wide (which looks very nice ;), while they alternate width (0..2 pixel) in the old one. StarsEffect.zip

Same in Stellarator.

[DirtyHairy]

It's good that you raise this --- I am aware of the issue, but I forgot to add it to the tracker. I know that there is an effective description of this effect in Stella, and, afaik, the exact pattern varies over different TIA generations. I suspect this is the result of some interplay between the phase of the extra clock pulses and the object enclockifier logic described in Andres Towers' notes.

Do you know whether someone ever fully understood this effect? Do player sprites exhibit the same effect?

[thrust26]

I don't know if anyone ever fully understood this, sorry.

Players behave the same, see the StarsEffect ROM.

[DirtyHairy]

Actually, the old core doesn't show wobbling for either players or ball (I would assume that at least the ball should behave the same way as the missiles)? How does real hardware behave here (I am still waiting for my harmony :stuck_out_tongue: )?

[thrust26]

For me it does

[DirtyHairy]

Hmmm, if I switch off everything but P1, I don't see any variation

[sa666666]

The old core will only show wobbling for missiles, since that's all that the core is coded to do. IOW, there's specific code for missiles that blank a pixel, spread it out over two pixels, or draw it as normal. There is no such code for any other graphical object. I refer you to the following code:

// TODO - 08-27-2009: Simulate the weird effects of Cosmic Ark and // Stay Frosty. The movement itself is well understood, but there // also seems to be some widening and blanking occurring as well. // This doesn't properly emulate the effect at a low level; it only // simulates the behaviour as visually seen in the aforementioned // ROMs. Other ROMs may break this simulation; more testing is // required to figure out what's really going on here. if(myHMM0mmr) { switch(myPOSM0 % 4) { case 3: // Stretch this missle so it's 2 pixels wide and shifted one // pixel to the left myM0Mask = &TIATables::MxMask[myNUSIZ0 & 0x07] [((myNUSIZ0 & 0x30) >> 4)|1][160 - ((myPOSM0-1) & 0xFF)]; break; case 2: // Missle is disabled on this line myM0Mask = &TIATables::DisabledMask[0]; break; default: myM0Mask = &TIATables::MxMask[myNUSIZ0 & 0x07] [(myNUSIZ0 & 0x30) >> 4][160 - (myPOSM0 & 0xFF)]; break; } } else myM0Mask = &TIATables::MxMask[myNUSIZ0 & 0x07] [(myNUSIZ0 & 0x30) >> 4][160 - (myPOSM0 & 0xFF)]; if(myHMM1mmr) { switch(myPOSM1 % 4) { case 3: // Stretch this missle so it's 2 pixels wide and shifted one // pixel to the left myM1Mask = &TIATables::MxMask[myNUSIZ1 & 0x07] [((myNUSIZ1 & 0x30) >> 4)|1][160 - ((myPOSM1-1) & 0xFF)]; break; case 2: // Missle is disabled on this line myM1Mask = &TIATables::DisabledMask[0]; break; default: myM1Mask = &TIATables::MxMask[myNUSIZ1 & 0x07] [(myNUSIZ1 & 0x30) >> 4][160 - (myPOSM1 & 0xFF)]; break; } } else myM1Mask = &TIATables::MxMask[myNUSIZ1 & 0x07] [(myNUSIZ1 & 0x30) >> 4][160 - (myPOSM1 & 0xFF)];

[thrust26]

I stand corrected, no wobbling for players in current Stella. But on real hardware, they all wobble.

[DirtyHairy]

Thanks alot. I will adapt the effective description for missiles and ball into the new core, and once I can start testing on real hardware, I'll try to find a matching description for the players. Could you give me the source for StarsEffect (so I could adapt it and selectively toggle sprites)?

[thrust26]

I wish I could. After creating the binary I played with it (long ago) and broke something. So it may take a while until I have reverted those changes.

BTW: It may be, that my demo only shows the stars effect for M0/1 on real hardware. Hard to tell from watching a moving image on a small CRT.

[sa666666]

Thomas, if you manage to re-create the ROM, can you create an NTSC version for me to test? Right now, due to not having a PAL TV or console, I can't tell what's happening on real hardware because of the vertical scrolling.

[DirtyHairy]

BTW: It may be, that my demo only shows the stars effect for M0/1 on real hardware. Hard to tell from watching a moving image on a small CRT.

If my hypothesis is correct, then I would assume that ball and missiles behave equally, and that players either show no effect at all or at least behave differently.

I wish I could. After creating the binary I played with it (long ago) and broke something. So it may take a while until I have reverted those changes.

No worries, if the original source is lost, I think I can pull off the effect for a single sprite myself (four is above me).

[thrust26]

Recreated the ROM by using DiStella. The attached version allows some control over horizontal movement with left and right difficulty switches.

BTW: The code doesn't use P0 but the ball instead. Now I remember that I needed the sprite for something else. :) StarEffects (NTSC).zip

[thrust26]

OK, I tested on real hardware (PAL Darth Vader):

With each horizontal pixel, the width for BL and Mx changes like this: 1, 2, 3, 2... The player is slightly different (it displays 2 pixel where the others show 1): 2, 2, 3, 2

Actually it's even a bit more complex, you better see yourself.

[DirtyHairy]

400b333 implements the effective description of the old core for both missiles and ball. What remains are the players. In addition, I'd like to doublecheck how real hardware behaves for sprites of size > 1 (or large players for that matter).

[thrust26]

I made some experiments:

1. missiles, balls and players seem to behave (more or less) the same
2. as soon as the objects are at least 4 pixel wide, they do not change size or move anymore
3. below that size they are (depending on iteration) displayed with relative widths -1, 0, +1, 0 (and then repeating)
4. a double sized player with single pixel displays relative width -1 as 0, (but a single sized player with two consecutive pixel displays -1 too)
5. within the width sequence the pixel once (when they are widest) move left (0, 0, -1, 0...)
6. for single sized players with multiple isolated pixel enabled (e.g. %1001) only the rightmost pixel seems to be affected by the size and position change (more investigation necessary)

[DirtyHairy]

Thanks alot, Thomas. I will adapt the implementation according to your findings. A quick question regarding the players: does "at least 4 pixels wide" refer to the player graphics bitmask in this case?

[thrust26]

Yes, 4 consecutive single width pixel. Or 2 double width consecutive pixel or 1 quad width pixel.

[thrust26]

Cosmic Ark works like the old core now.

All stars are currently only 1 or 2 pixel wide, while my StarsEffect demo displays 1, 2 or 3 pixel wide ones. I tried checking Cosmic Ark on real hardware to see if the stars are also 3 pixel wide. But it is hard to tell with all that flickering.

Anyway, my demo also misses the 3 pixel width in the new core, so that's something for a future update.

[sa666666]

On my console (light sixer), there is a different pattern in Cosmic Ark. I originally added emulation of that behaviour, but reverted it when it didn't agree with the majority of what users were seeing. This is documented in the following links:

http://atariage.com/forums/topic/191061-cosmic-ark-stars-different-on-different-consoles/ http://atariage.com/forums/topic/150402-stella-30-released/page-1

I suspect it's because of different TIA versions. For now, I think it's best to do what the old core does. In the future, perhaps this can be extended for more hardware TIA versions.

[thrust26]

Agreed with the different versions.

But I found that the new core is still not quite right. The pattern is correct, but not positioned correctly. On my PAL Darth Vader they display like in the old core, which is identical with what Darrell and Chris see on they (non-Jr.) consoles.

Old:

Pre2:

And definitely no 3 pixel stars on my console too. So there must be something else which is triggering the different behavior in my StarsEffect demo...

[DirtyHairy]

@thrust26 : to clarify what's currently in pre2: the current implementation does not reflect the latest state of our discussion, but implements more or less what the old core was doing. Depending on the phase relative to the last movement clock of the pixel where rendering starts, the code does either:

• Increase width to two if the sprite is set to one pixel of width (delta = 3)
• Display sprite one cycle too early (delta = 3);
• Hide sprite (delta = 2)
• Render as usual (delta = 1, 0)

I have yet to find time to update the algorithm with your findings, but that'll propably happen after fixing the remaining bugs and adding RSYNC.

@sa666666 I already stumbled over those posts when I was doing initial research on my TIA implementation. In face of the diferrences between various hardware, I decided to do just that: leave out these interference effects altogether first and add them later, together with an option to toggle hardware flavor :smirk:

[thrust26]

OK, more or less it works like the old core. :)

And my findings have low priority for sure.

[DirtyHairy]

I have started to revisit this with the goal to match hardware at least for missiles and ball for the next release. I was under the assumption that the difference between the old and the new core is just a phase shift and started toying around with a simple testcase that displays a static starfield with missile 0 over a grid. To my utter surprise:

• The difference between Stella 4 and 5 is a phase shift and a horizontal shift
• My Jr. esentially matches Stella 5 with an adjusted phase (41e2f77 fixes most of the remaining difference).

@thrust26 , @sa666666 could you run the testcase ( starfield.zip) on your hardware and check the result against the following screenshots (I know that your TIA is different, Stephen, but I am still interested in the result)? I also plan on posting the same test on AA. Diffculty B switches between PAL and NTSC.

Here are the screenshots. My own Jr. matches phase 2 (with an additional stray pixel on the left edge, but I know where this comes from).

Phase 0:

Phase 1:

Phase 2:

Phase 3:

Stella 4:

[thrust26]

Phase 2 for me (PAL Darth Vader)

BTW: @DirtyHairy On my PAL TV, the dark grays are much darker than in Stella. So I can only see the PF when I make the TV quite bright. How about yours?

[sa666666]

As I've said before, the TIA in my system seems to be different from most other people. I can't really tell which one it's more similar with; none of them, really.

[thrust26]

Looks like Phase 2, but with an extra pixel after each double pixel star.

[sa666666]

I managed to get a Jr. hooked up. The RF image is horrible, but at least you can see that's it's different from my Light Sixer (w/ svideo mod). This one looks more like phase 2.

[sa666666]

After playing around with the Jr. a little, I found some ROMs on an SDHC card that were used to test timer functionality. Unfortunately, some of the testing revealed that the current timer code in Stella is still not complete :disappointed: I will open a bug on this.

[DirtyHairy]

Thanks! Seems I am on the right trail after all. Is there a version of Stella's Stocking up for download somewhere so I could check out the Stay Frosty startfield myself? If this matches both Stella 4 and Stella 5, then there's got to be some aspect of horizontal movement that the new core gets right and the old one doesn't --- most likely related to the hblank phase in which the starfield effect is triggered,

@thrust26 Crap, I thought I got the contrast right this time :smirk: It is fine on our TV, but that's a composite mod on a Samsung LCD and not a CRT, so this may be misleading. I think I'll build a toggle into the next test rom for choosing between two different grid colors. I guess I'd like to get myself a CRT when we move to a bigger place.

@sa666666 Yes, your funky TIA seem to be basically phase 2 with an extra pixel after the wide ones and no supression of the next regular pixel.

I'll build a more flexible testcase that can switch between missiles and balls of different widths these days and put it up on AA --- I am very curious what different types of TIAs are out there as far as this phenomenon is concerned. I'll save the players for later, but I think we can include an updated version of the starfield effect that matches what seems to be the "vanilla TIA" for missiles and ball in the next release.

[sa666666]

I wonder, when I did the svideo mod on my light sixer, is it possible that the mod (or I) broke something in the TIA? At some point I will try swapping out the chip and see if it makes a difference.

Anyway, I'm signing off for tonight.

[DirtyHairy]

I am not an electrical engineer, but I think that this is possible --- not so much that the mod damaged the chip, but that it adds a capacity or resistance somewhere that influences the shape and phase of the movement clock pulses. I strongly suspect that this width modulation effect is a subtle interplay between the movement clock and the "regular" sprite clock pulses that feed the width and scanning circuits and, as such, is sensitive to environmental factors and to the circuit it is connected to.

In facto, on the forums, there are also hints that the starfield changes on some chips once the machine heats up.

[SpiceWare]

Stay Frosty - http://spiceware.org/StayFrosty.bin

Stay Frosty 2 (for your DPC+ work on 6502.ts) - http://atariage.com/forums/topic/240438-season-4-the-new-hsc-week-26-stay-frosty-2

Another datapoint for starfield from my NTSC light sixer:

[DirtyHairy]

@SpiceWare: Thanks a lot! Your light sixer looks precisely like my Jr. and the current Stella implementation. I've checked out Stay Frosty; Stella 5 now matches Stella 4 there (I haven't checked on hardware yet).

I'll try to get back to this issue in the next week and write an extended testcase that includes ball and players.