Jump to content
IGNORED

TV signal out of sync when switching menu pages


Al_Nafuur

Recommended Posts

 

I suspect that the TV signal is not synced properly when switching to or from the wait routine in RAM (rotating + sign) and the text kernel.

 

maybe @Thomas Jentzsch or @Andrew Davie can have a look at the code (maybe) here:

 

 

https://gitlab.com/firmaplus/atari-2600-pluscart/-/blob/master/source/Atari2600ROM/PlusCart.asm#L941

 

Link to comment
Share on other sites

  • 8 months later...

Apart from fixing the sync, I think the switching would look better and less noticeable if you mask the sides of the "wait" screen background with the playfield just like in the text kernel, so that they both have the same horizontal size.

  • Like 1
Link to comment
Share on other sites

I've had a quick look at this. It's been a while.

The "spinner" code that performs a wait loop while the address BUS is inactive (i.e., while the PlusCart is away in the cloud building up the next menu display frame) lives in Zero page. It is very tight; 119 of 121 available bytes are in use.  I suspect one of the issues is that the frame size (#scanlines) for this is hardwired, and probably not the same size as the menu frame. There may be other issues related to OS/VB timing; I only had a brief look.

The tight usage of ZP means that I can't index to have variable frame size as used for the menu frame, however the fact that it lives in zero page means that I can do some self-modifying trickery which might fix that particular issue.  I will try and put aside some time to looking into this soonish.

As to the masking of the spinner screen sides; a brief look at it makes the logo look odd because it now becomes (+1 pixel) left-edge aligned to a black edge.  It's only a single PF write (PF1) and there's not enough zeropage space to do two writes (PF1/PF2) in the kernel.  To create the mask would need SP0/SP1 or similar bands on the sides, in black. Can't use PF because it's coloured white and there's no time/room for colour changes. Starts to become a lot of fiddling for not a lot of functionality.

So, I think that's not gonna happen.

 

 

 

Edited by Andrew Davie
fixed left-aligned comment
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

 

29 minutes ago, Andrew Davie said:

As to the masking of the spinner screen sides; a brief look at it makes the logo look odd because it now becomes (+1 pixel) left-edge aligned to a black edge.  It's only a single PF write (PF1) and there's not enough zeropage space to do two writes (PF1/PF2) in the kernel.  To create the mask would need SP0/SP1 or similar bands on the sides, in black. Can't use PF because it's coloured white and there's no time/room for colour changes.

Thanks for the explanation. Maybe you could use a (quad size) sprite instead of PF1 for the spinning logo? That way you aren't tied to a specific horizontal position. The sprite  position, color, as well as PF0 color and data for masking the sides could be set before jumping to the zero page code.

 

But I totally agree that masking the sides is just a very minor cosmetic improvement and doesn't justifies extensive rewrite of the code.

Link to comment
Share on other sites

3 hours ago, alex_79 said:

 

Thanks for the explanation. Maybe you could use a (quad size) sprite instead of PF1 for the spinning logo? That way you aren't tied to a specific horizontal position. The sprite  position, color, as well as PF0 color and data for masking the sides could be set before jumping to the zero page code.

 

But I totally agree that masking the sides is just a very minor cosmetic improvement and doesn't justifies extensive rewrite of the code.

It is what it is because I didn't rewrite, but took the original code and made incremental changes and now it is what it is.  I agree that use of a sprite would be much better, and I'll look into it. As with these things, it's a hobby and doing stuff for other people sometimes seems like... work :)

 

  • Like 2
Link to comment
Share on other sites

Ah well, the spinner -> sprite, and margin stuff proved to be very straightforward, so that's working in the standalone testbed anyway. So now it's on to the frame timing/synch stuff.  The vid shows the margins as @alex_79 suggested, and the spinner as a sprite (roughly) centered in the screen. I did like it top-left, but now it can be anywhere. You can see how the transition (the same size margin) will look. Now uses mirrored PF and masking of pf2 (black) to get the borders the same. The changes were very simple.  

 

On to the synching issue...

 

 

 

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...