The HMOVE artifacts

[Thomas Jentzsch]

I thought there once was some bit in [stella] about shifting the whole playfield or so, but I can't find it. Maybe something using RSYNC?

I can't remember something like that.

 

BTW: I have a Chinese PAL Jr., so I could check e.g. Gunfight. But this will have to wait a few days.

[cd-w]

Well, not the slightest clue about all the hardware rhabarber - but unless someone can prove that this trick doesn't work on his Jr. - it does work on all

And - even if it doesn't - it's their TIA that's broken, not the software.

 

The bBasic multisprite kernel uses this trick. I recently tested the binary that batari posted in this blog entry on my Chinese PAL Jr which is known to have problems and it worked fine. It seems that the problem only occurs for mid-scanline HMOVES. It would be good if the emulators could implement the Jr behaviour so that we could easily test for problems.

 

Chris

Edited April 11, 2006 by cd-w

[DEBRO]

The bBasic multisprite kernel uses this trick. I recently tested the binary that batari posted in this blog entry on my Chinese PAL Jr which is known to have problems and it worked fine. It seems that the problem only occurs for mid-scanline HMOVES

[supercat]

The bBasic multisprite kernel uses this trick. I recently tested the binary that batari posted in this blog entry on my Chinese PAL Jr which is known to have problems and it worked fine. It seems that the problem only occurs for mid-scanline HMOVES

 

Have both types of 'early' HMOVE been tested on 'weird' 2600jrs? I can imagine a situation where a cycle-74 HMOVE would work the same as another Atari but a cycle-73 HMOVE would behave differently (even though most Ataris consider cycle-73 and cycle-74 HMOVEs the same).

 

What I'd really like would be a way to trigger the 'HMOVE bar' (and corresponding 8-pixel push) without sending out any count pulses, without having to load movement registers with $80. That would save some cycles in the Ruby Runner kernel, if I could simply hit HMOVE at cycle 74 to push all the sprites 8 pixels left and do something magical to push all the sprites 8 pixels right. Unfortunately, on a normal Atari an HMOVE that occurs soon enough to trigger the 'HMOVE bar' will also be soon enough to kick out some count pulses (on a 'weird jr' I could probably make things work, but I want something that can be made to work on all Ataris).

[vdub_bobby]

Well, looking at the HMOVE chart, you can get *almost* there.

 

You can get 8 pixels left with an early HMOVE and 6 pixels right with a late (cycle 20) HMOVE, both with HMxx = $00.

[supercat]

Well, looking at the HMOVE chart, you can get *almost* there.

 

Well, maybe I can write a "horseshoes" or "hand grenade" game.

 

Although no emulators will support it yet, I think I have a solution for normal Ataris. With HMxx set to $80, do a very late HMOVE on the scan line I want to push right. Do another HMOVE a few cycles later, after the end of HBLANK. This should turn on the pulsers and leave them on. They won't have any effect, however, until the start of the next HBLANK. Wait for 16 pulses to be output, then hit another HMOVE to stop the pulsers. The sprites on this scan line will be pushed left 8 pixels.

 

Thus, three any-value stores for every two scan lines to shove all the sprites alternately left and right by 8 pixels. I doubt there's any cheaper way than that.

 

If it's necessary to have one of the sprites not move, that might still be possible, though I would expect four HMOVEs per scan line.

 

I would not expect these approaches to work at all usefully on the FB2, nor on the "funny" Juniors. On the funny Juniors, it should be possible to push sprites left 8 pixels in the usual manner (HMOVE at cycle 74 with an HMxx of 0). To push sprites right 8 pixels with an HMxx of 0, do a very late HMOVE with an HMxx of 0. To make a sprite not move, use an HMxx of $80.

[supercat]

I thought there once was some bit in [stella] about shifting the whole playfield or so, but I can't find it. Maybe something using RSYNC?

 

Looking over the TIA diagrams, it may be possible to smooth-scroll the playfield with RSYNC, but I don't think it would be very practical for most applications. RSYNC does reset the divide-by-four circuit, and does not appear to jinx the playfield shifter, so there might be some possibilities there. On the other hand, it would be necessary to bash RSYNC repeatedly to prevent the TIA from outputting a horizontal sync pulse (the last RSYNC should occur properly timed so that the horizontal sync pulse arrives when it should). All the RSYNC bashing might make it hard to do much else.

[supercat]

Although no emulators will support it yet, I think I have a solution for normal Ataris.

 

It's possible to use repeated HMOVEs to generate motion clocks for a sprite whose HMxx is $80. Such a sprite does not get stuck in the confused state, however, but instead outputs a finite number of pulses less than 15.

 

The best application of this I think is to do a double HMOVE with the first move starting on cycle 60 (regarding an HMOVE immediately following a WSYNC as starting on cycle zero). The second HMOVE may occur any time before about cycle 72. This results in the following motions for the given values of HMxx.

 

$00-$70 -- Normal

$80 -- Left 8

$90 -- Confused

$A0-$F0 -- No motion(*)

 

Note that even though $00-$70 behave normally, there is no "HMOVE bar" at the start of the next scan line. Note also that if the second HMOVE immediately follows the first, only $90 will get confused; if it occurs later, other values may get confused as well.

[Cybergoth]

I thought there once was some bit in [stella] about shifting the whole playfield or so, but I can't find it. Maybe something using RSYNC?

 

Looking over the TIA diagrams, it may be possible to smooth-scroll the playfield with RSYNC, but I don't think it would be very practical for most applications. RSYNC does reset the divide-by-four circuit, and does not appear to jinx the playfield shifter, so there might be some possibilities there. On the other hand, it would be necessary to bash RSYNC repeatedly to prevent the TIA from outputting a horizontal sync pulse (the last RSYNC should occur properly timed so that the horizontal sync pulse arrives when it should). All the RSYNC bashing might make it hard to do much else.

 

Still can't find that part of the [stella] discussion. The info must be hidden somehwhere near them interlace experiments (~2003-2004) IIRC. I think the problem was that you couldn't use it for real PF softscroll, as with CPU cycles you can only trigger it in 3 pixel steps. So best effect you could generate probably was some screen shaking death sequence.

[+batari]

I thought there once was some bit in [stella] about shifting the whole playfield or so, but I can't find it. Maybe something using RSYNC?

 

Looking over the TIA diagrams, it may be possible to smooth-scroll the playfield with RSYNC, but I don't think it would be very practical for most applications. RSYNC does reset the divide-by-four circuit, and does not appear to jinx the playfield shifter, so there might be some possibilities there. On the other hand, it would be necessary to bash RSYNC repeatedly to prevent the TIA from outputting a horizontal sync pulse (the last RSYNC should occur properly timed so that the horizontal sync pulse arrives when it should). All the RSYNC bashing might make it hard to do much else.

 

Still can't find that part of the [stella] discussion. The info must be hidden somehwhere near them interlace experiments (~2003-2004) IIRC. I think the problem was that you couldn't use it for real PF softscroll, as with CPU cycles you can only trigger it in 3 pixel steps. So best effect you could generate probably was some screen shaking death sequence.

I looked too and couldn't find it. But 3 pixel steps doesn't mean a smooth scroll isn't possible. If the RSYNC thing does indeed work in the manner described above, I suppose you could do 3, 6, and 9 pixels, and shift the playfield itself accordingly to get single-pixel movement.

 

That said, the above also confused my notion of RSYNC. I was under the impression that it just restarted the sync counter.

 

[speculation]

So my impression is that, e.g., a RSYNC with the store occuring at cycle 1 would produce a single horizontal sync pulse one cycle late (i.e. at 77 cycles), but subsequent scanlines would all be 76. So the single RSYNC wouldn't do anything useful unless you hit RSYNC at cycle 1 during every scanline. But then you'd be producing sync pulses at 77 cycles, which wouldn't shift the playfield at all, but most likely widen the entire raster. And going too far out of spec may cause the TV to lose sync altogether.

[/speculation]

[Dionoid]

Hi, I know this is an old thread, but like to know if cycle 73/74 HMOVE's are considered safe for all Atari models.

I have successfully tested cycle 73 HMOVE's on several machines, including a PAL 2600 Jr made in China (this model is mentioned in this thread as being a machine that doesn't like late cycle HMOVE's).

Edited June 9, 2018 by Dionoid

[Thomas Jentzsch]

I think this is due to this discussion. I consider them incompatible and don't care.