Asterix converted to run on NTSC

A place where you can keep others updated about your NES-related projects through screenshots, videos or information in general.

Moderator: Moderators

Post Reply
NewRisingSun
Posts: 1029
Joined: Thu May 19, 2005 11:30 am

Asterix converted to run on NTSC

Post by NewRisingSun » Sun Jan 27, 2019 11:09 am

My first attempt at converting Asterix to run on NTSC (and Dendy) consoles.

The game updates at least fourteen tiles in every vertical blanking period, requiring copying 224 bytes from ROM to CHR-RAM, which is too much for the short vertical blanking duration on NTSC consoles when doing it like the game does, with indirect reads. The ideal solution would be to do it like Battletoads: prepare the CPU $01xx area during the frame, then an unrolled loop of 224 PLA/STA $2007 during vertical blanking. This is not directly possible here, as the game heavily uses the $01xx area for other things; changing this would require a major relocation of a great number of variables, and may not be possible at all without additional WRAM. I instead modified the game to only update one fourth of all the tiles during each vertical blanking period. This causes a slight lag in the main character's animation, that I find quite tolerable, but that I would expect others to find inacceptable.

The archive includes one patch that keeps the music speed as it is, for Dendy consoles or for people who like fast music, and another one that adjusts the music speed. The adjustment method may be a bit too crude for this arpeggio-heavy music. But the sound driver's internal tempo seems to be track-specific, and my attempts to change each track's tempo resulted in the tracks going out of sync after a while, similar to what has been observed in the PAL version of Over Horizon, so I eschewed that approach.

I played the music-adjusted version for a while on my Sharp Twin Famicom AN-505BK with an Everdrive N8 and did not notice any other glitches.
Attachments
AsterixNTSC.7z
(521 Bytes) Downloaded 226 times
Last edited by NewRisingSun on Sun Jan 27, 2019 2:37 pm, edited 2 times in total.

User avatar
rainwarrior
Posts: 7642
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Asterix converted to run on NTSC

Post by rainwarrior » Sun Jan 27, 2019 11:13 am

Cool!

tepples
Posts: 21720
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Asterix converted to run on NTSC

Post by tepples » Sun Jan 27, 2019 1:34 pm

I don't know anything about the architecture of Asterix. But does it have enough room in CHR RAM to double buffer the affected character's animations? And is the next cel predictable based on the current cel, such as in a run cycle? If so, you could try what Haunted: Halloween '85 does: preload the most likely next cel, and lag only on misprediction.

User avatar
tokumaru
Posts: 11443
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Asterix converted to run on NTSC

Post by tokumaru » Sun Jan 27, 2019 3:45 pm

Even if you can't use the unrolled PLA+STA method, you can still achieve comparable speeds with indexed addressing. Several years ago I posted about a generic solution for transferring data to VRAM at 8 cycles per byte, but since this is just for tiles you can probably use something more specialized.

If you do have the 224 bytes necessary to buffer the tiles available anywhere in RAM, you could consider storing the tiles in interleaved form (i.e. structure of arrays, rather than array of structures), and indexing them by tile rather than by byte. Something like this:

Code: Select all

TileByte0 = $0500 ;buffer starts at $0500
TileByte1 = TileByte0+14
TileByte2 = TileByte1+14
;(...)
TileByte14 = TileByte13+14
TileByte15 = TileByte14+14
With the buffer arranged this way, you can now blast tiles to VRAM like this, with very little overhead:

Code: Select all

  ldx TileIndex
CopyTile:
  lda TileByte0, x
  sta $2007
  lda TileByte1, x
  sta $2007
  lda TileByte2, x
  sta $2007
  ;(...)
  lda TileByte14, x
  sta $2007
  lda TileByte15, x
  sta $2007
  dex
  bpl CopyTile
Since this is copying the tiles backwards, you'd have to buffer the tiles in that order too, but that's easy if you know how many tiles you need to copy.

Even if you don't have the RAM to spare, it's still possible to interleave the tiles in ROM and use the same technique.

NewRisingSun
Posts: 1029
Joined: Thu May 19, 2005 11:30 am

Re: Asterix converted to run on NTSC

Post by NewRisingSun » Mon Jan 28, 2019 11:29 am

Thanks, guys --- I appreciate the suggestions. Looking at the memory log after playing through all levels, once, I can find $C3 bytes outside the $140-$1FF region that I could use to relocate the variables from there, which might keep the PLA option on the table after all. Otherwise, I will consider the suggestions offered here.

There seem to be 20 CHR-RAM sprite tiles unused at any time; the character animation takes 12 tiles, of which I can update at least three in any given frame, so there is space for two different "predicted" frames, which I would assume would make the algorithm quite complicated though.

Is there a possibility of creating a good 50 Hz timer on an NTSC system using the DPCM interrupt? If so, that might provide a better means of adjusting the music speed than my current "skip every 6th call" to the music routine, which makes the arpeggios rather uneven.

tepples
Posts: 21720
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Asterix converted to run on NTSC

Post by tepples » Mon Jan 28, 2019 11:38 am

Is it possible to make frames when only the instruments (including arpeggios) are updated and nothing else?

lidnariq
Posts: 8704
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Asterix converted to run on NTSC

Post by lidnariq » Mon Jan 28, 2019 11:45 am

NewRisingSun wrote:Is there a possibility of creating a good 50 Hz timer on an NTSC system using the DPCM interrupt?
Not exactly, but the closest three are
Block length 1(17 bytes), rate $5 = 51.8Hz
Block length 5(81 bytes), rate $F = 51.1Hz
Block length 4(65 bytes), rate $E = 47.8Hz

NewRisingSun
Posts: 1029
Joined: Thu May 19, 2005 11:30 am

Re: Asterix converted to run on NTSC

Post by NewRisingSun » Mon Jan 28, 2019 11:49 am

lidnariq wrote:Block length 1(17 bytes), rate $5 = 51.8Hz
Close enough. I suppose I can relocate what's in the $C000-C011 area to a few unused bytes at the end of the fixed back to make room for 17 bytes of silent samples.
lidnariq wrote:Is it possible to make frames when only the instruments (including arpeggios) are updated and nothing else?
What do you mean, "make frames"?

User avatar
rainwarrior
Posts: 7642
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Asterix converted to run on NTSC

Post by rainwarrior » Mon Jan 28, 2019 12:04 pm

He means that the note events are separate from updating of arpeggios, so if you can find the separation you can tick the note events twice on every fifth frame, but don't double the arpeggio tick.

Post Reply