75 replies to this topic

[dwane413]

I can't edit my last upload of the ASM and it has a mistake I just noticed. I changed byte $FE41 to $1E for testing and forgot to change it back to $00.

[dwane413]

As far as I can tell, I got all the colors converted. If you notice any I missed, let me know. The scanlines are not right. This is not a proper NTSC hack. It may not really be considered NTSC50 either, but I called it that because it isn't correct for NTSC.

This is the ASM and BIN with 291 scanlines line Zoo Fun. That's all I plan to do on it for tonight.

 Panda_NTSC50_hack.zip   15.76K   25 downloads

[dwane413]

Here is my latest ASM file. It doesn't change the binary any from what I posted before, but has more comments.

 Panda.zip   14.02K   31 downloads

[dwane413]

I've tried to convert Zoo Fun's colors to NTSC. This is like the Panda_NTSC50 file above, but I did this more hurriedly. Let me know if there are any problems.

This is the ASM and BIN with 291 scanlines.

 Zoo_Fun_NTSC50_hack.zip   15.46K   26 downloads

What I said above is also true for this:

dwane413, on Wed Jun 15, 2011 9:17 PM, said:

The scanlines are not right. This is not a proper NTSC hack. It may not really be considered NTSC50 either, but I called it that because it isn't correct for NTSC.

[thegoldenband]

Excellent, dwane413! I'm in the middle of a project right now but will check these out and report back (and this time will do so before 6+ months have passed!).

[Omegamatrix]

I worked more on the assembly. Many pointers are now labeled, and lots of things have been shuffled around. I used the colors Dwane posted, and converted them a bit more with guidance from a post by Michael (SeaGtGruff).

Current rom runs at 262 lines, but does move up and down still do to some re-positioning. I'm looking for a manual on what the object is. I still don't know! There seems to be pigs that fly, and if the Panda touches them he dies. Isn't a Panda tougher then a pig? They have claws, right? Then there is a dancing stick which seems to be what you want to get to, but you have to be careful when jumping up the ledges. Land on top and you are okay, land left or right and you'll drop.


The original game is full of glitches. I'm not sure what the purpose is of the game select, etc... A manual would be helpful!


 Panda Chase (NTSC).zip   19.39K   31 downloads

[thegoldenband]

Do Rom Hunter's posts in this thread help at all? It's not a manual, but he gives what would appear to be a workable synopsis of gameplay (in both games).

[dwane413]

Omegamatrix,
I've tried to combine my newest comments with your new ASM file. If I change anything you don't like, feel welcome to undo it. I'm new at this. I added three new variables Timer ($80), Lives ($A7) & CurrentScreen ($C4). I wasn't sure if I should delete the times used after them or not. I thought I probably should have, but left them in case.

 Panda Chase (NTSC) 2011y06m17d_16h29m.zip   14.83K   27 downloads

[dwane413]

LF4CD:
    ldy    #$00                  ; 2
    bne    LF4D3                 ; 3   never branch!  might be a bad bug...

I agree this is a bug. I'm replacing it with this:

LF4CD:
    ldy    #$00                  ; 2
    beq    LF4D3; was bne LF4D3  ; 3   always branch

The purpose of the code from $F4BF to $F4F8 is to put the right info in the RAM that points to the correct sprite according to which screen you are on. It looks this up from the table at $FC06 to $FC17. I think screens 1, 2 & 3 are supposed to each give Y a different value so each screen has a different set of sprites.

[dwane413]

In Panda Chase, I don't find anywhere that $CE & $CF are read. They are written to by the routine at $F4E3, which copies the pointers from $FC06,Y (every third byte starting at $FC08). I don't think the data that those pointer point to is ever used. Attached is an ASM where I've taken all that out and replaced it with either NOP or .byte $00. Could someone interested in this project check to see that I've done it right and haven't taken out anything useful. I've added *CHECK* in the comments where it needs checked. Thanks.

 Panda Chase (NTSC) 2011y06m17d_23h57m.zip   15.14K   24 downloads

Edited by dwane413, Fri Jun 17, 2011 11:04 PM.

[Thomas Jentzsch]

[quote name='dwane413' timestamp='1308357208' post='2305281']


I agree this is a bug. I'm replacing it with this:


Yes, that's definitely a bug. I suppose this is a left over from the debugging phase (testing the various screens), else the code could have jumped directly to LF4D3 instead of LF4CD.

[Thomas Jentzsch]

dwane413, on Fri Jun 17, 2011 10:33 PM, said:

Could someone interested in this project check to see that I've done it right and haven't taken out anything useful. I've added *CHECK* in the comments where it needs checked. Thanks.

With the NOPs, you commented one INY which is definitely relevant for the 2nd iteration of the loop. Also the old initial values for Y (0,4,8) do not fit to the changes you did to the table.

I suggest not to change the code here.

Edited by Thomas Jentzsch, Sat Jun 18, 2011 1:06 AM.

[dwane413]

Thanks for looking at it Thomas.

Here are the same changes I made last night, but with a little more commenting.

I got rid of ram_CE:

ram_CB             ds 6  ; x9  ; Changed this from ds 3 to ds 6 because I removed CE *CHECK*
;ram_CE             ds 3  ; x1 Removed the only place I could find that accessed this *CHECK*

Thomas Jentzsch, on Sat Jun 18, 2011 1:04 AM, said:

Also the old initial values for Y (0,4,8) do not fit to the changes you did to the table.

Sorry I forgot to comment that I changed those values. 0,4,8 are the new values. They had been 0,6,C. I've added comments about it being changed. (By the way, last night before I discovered I needed to change them to 0,4,8, it did act weird.)

LF4BF:
    ldy    CurrentScreen         ; 3   Get CurrentScreen to determine the enemy & plant sprites
    beq    LF4F9                 ; 2³  Branch if Screeen 0       ; has none, so skip this part
    dey                          ; 2
    beq    LF4CD                 ; 2³  Branch if Screeen 1       ; Bamboo Sticks (FE21) & Animal A (FE42) sprites
    dey                          ; 2
    beq    LF4D1                 ; 2³  Branch if Screeen 2       ; Bamboo Sticks (FE21) & Animal B (FE59) sprites
    ldy    #$08                  ; 2   Was "ldy #$0C" - Changed after reducing number of pointers at LFC06,Y *CHECK*
    bne    LF4D3                 ; 3   always branch - Screeen 3 ; Animal C (FE6E) & Animal A (FE42) sprites

LF4CD:
    ldy    #$00                  ; 2   Was "ldy #$00" - Change not needed after reducing number of pointers at LFC06,Y *CHECK*
    beq    LF4D3; was bne LF4D3  ; 3   always branch
LF4D1:
    ldy    #$04                  ; 2   Was "ldy #$06" - Changed after reducing number of pointers at LFC06,Y *CHECK*
LF4D3:
    ldx    #$00                  ; 2
LF4D5:
    lda    ram_DC                ; 3   Check frame counter
    lsr                          ; 2
    lsr                          ; 2
    lsr                          ; 2
    lsr                          ; 2
    bcc    LF4F1                 ; 2³  If bit 3 is off branch to use the first frame of sprite
    iny                          ; 2   Skip first frame of sprite
    lda    LFC06,Y               ; 4   Load pointer to second frame of sprite
    sta    ram_A0,X              ; 4   Store in RAM

Thomas Jentzsch, on Sat Jun 18, 2011 1:04 AM, said:

With the NOPs, you commented one INY which is definitely relevant for the 2nd iteration of the loop.

Although I might be wrong, I did this intentionally. The relevant INY for the 2nd part of the loop is still there. It's just before "bne LF4D5". The one I commented is for the pointer that I removed.

LF4E3:
;    iny                          ; 2   Removed because pointer was removed - It prepared for loading pointer to unknown data *CHECK*
;    lda    LFC06,Y               ; 4   Removed because pointer was removed - Loads pointer to unknown data
;    sta    ram_CE,X              ; 4   Removed because I don't see where $CE & $CF are used
     NOP           ; Unused, moved from above *CHECK*
     NOP
     NOP
     NOP
     NOP
     NOP
    inx                          ; 2
    cpx    #$02                  ; 2   Have you loaded the pointer to sprite 2
    beq    LF4F9                 ; 2³  If yes, branch out of this
    iny                          ; 2   Prepare to load sprite 2
    bne    LF4D5                 ; 2³
LF4F1:
    lda    LFC06,Y               ; 4   Load pointer to first frame of sprite
    sta    ram_A0,X              ; 4   Store in RAM
    iny                          ; 2   Skip second frame of sprite
    bne    LF4E3                 ; 2³

Here is where I got rid of the pointers. This info is loaded, but I can't find when it is ever used. The commented INY above was for $FC08, $FC0B, $FC0E, $FC11, $FC14 & $FC17. Since I got rid of those pointers, it needs less "INY"s in the loop above.

LFC06:
    .byte <LFE21         ; $FC06  Bamboo Sticks sprite 1
    .byte <LFE2C         ; $FC07  Bamboo Sticks sprite 2
;    .byte <LFE37         ; $FC08 Although this pointer is loaded into RAM, that info is never used *CHECK*
    .byte <LFE42         ; $FC09  Animal A sprite 1
    .byte <LFE4A         ; $FC0A  Animal A sprite 2
;    .byte <LFE51         ; $FC0B Although this pointer is loaded into RAM, that info is never used *CHECK*
    .byte <LFE21         ; $FC0C  Bamboo Sticks sprite 1
    .byte <LFE2C         ; $FC0D  Bamboo Sticks sprite 2
;    .byte <LFE37         ; $FC0E Although this pointer is loaded into RAM, that info is never used *CHECK*
    .byte <LFE59         ; $FC0F  Animal B (?Pig) sprite 1
    .byte <LFE60         ; $FC10  Animal B (?Pig) sprite 2
;    .byte <LFE67         ; $FC11 Although this pointer is loaded into RAM, that info is never used *CHECK*
    .byte <LFE6E         ; $FC12  Animal C (green animal) sprite 1
    .byte <LFE77         ; $FC13  Animal C (green animal) sprite 2
;    .byte <LFE7F         ; $FC14 Although this pointer is loaded into RAM, that info is never used *CHECK*
    .byte <LFE42         ; $FC15  Animal A sprite 1
    .byte <LFE4A         ; $FC16  Animal A sprite 2
;    .byte <LFE51         ; $FC17 Although this pointer is loaded into RAM, that info is never used *CHECK*

    .byte $00           ; Unused, moved from above *CHECK*
    .byte $00
    .byte $00
    .byte $00
    .byte $00
    .byte $00

This morning I added these comments to the part of the code where the data had been. What I posted last night just had the code in the new location with no explanation at the old spot.

;LFE37 to LFE41:      Unused data - removed from here and added blank space below *CHECK*
... [code skipped in this post] ...
;LFE51 to LFE58:      Unused data - removed from here and added blank space below *CHECK*
... [code skipped in this post] ...
;LFE67 to LFE6D:      Unused data - removed from here and added blank space below *CHECK*

Here I changed the data that had been after each animal/plant sprite into zeros. I moved all of this after byte $FE7E so they would be together (and so I could see if it caused any problems). What I posted last night had $FE7F to $FE87 (empty) at the bottom of this section, but I thought why move empty data below other empty data.

LFE7F:
    .byte $00 ; Unused data - changed to blank space *CHECK*
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
LFE37:
    .byte $00 ; Unused - changed to blank space & moved from above *CHECK*
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
LFE51:
    .byte $00 ; Unused - changed to blank space & moved from above *CHECK*
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
LFE67:
    .byte $00 ; Unused - changed to blank space & moved from above *CHECK*
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;
    .byte $00 ;

Thomas Jentzsch, on Sat Jun 18, 2011 1:04 AM, said:

I suggest not to change the code here.

If you still think so, I'll take your word on it. I feel privileged to have you looking at my work. Thanks.

EDIT: Added current test ASM with the updated comments mentioned above. Nothing is changed but comments.
 Panda Chase (NTSC) 2011y06m18d_08h03m.zip   15.45K   34 downloads

EDIT2: The reason I found this was because I had been trying to find out what that unknown data was used for. The only reason I brought this up was because I concluded that it was unused. If there's a chance that it might break something, then it is fine to leave it like it was.

Edited by dwane413, Sat Jun 18, 2011 7:36 AM.

[Lucky Man]

Omega, that works great! A few little problems, but definitely playable.

Thanks so much for all your help everyone!

[dwane413]

Lucky Man, on Sat Jun 18, 2011 12:18 PM, said:

Omega, that works great! A few little problems, but definitely playable.

I agree. I tried it on real hardware today and was impressed. It's the first version that would work on my tv without rolling.

Lucky Man, on Sat Jun 18, 2011 12:18 PM, said:

Thanks so much for all your help everyone!

Glad I could help out a little. Of course Omegamatrix did the hard part.

[Omegamatrix]

dwane413, on Fri Jun 17, 2011 3:41 PM, said:

Omegamatrix,
I've tried to combine my newest comments with your new ASM file. If I change anything you don't like, feel welcome to undo it. I'm new at this. I added three new variables Timer ($80), Lives ($A7) & CurrentScreen ($C4). I wasn't sure if I should delete the times used after them or not. I thought I probably should have, but left them in case.

That's great! I changed the names slightly because the naming convention I like use to begins my variables with lower case so "CurrentScreen" became "currentScreen". I'll use your latest assembly for any further changes. Not too much time to work on it over the next few days though... but there are still a lot of things to fix.

[Thomas Jentzsch]

I am playing with the code myself. There is an obvious bug at Lf4cd:

    ldy    #$00     
    bne    Lf4d3    

The BNE should be a BEQ.

EDIT: But I see you found that one already.

Edited by Thomas Jentzsch, Sun Jun 19, 2011 8:50 AM.

[Lucky Man]

So Thomas was kind enough to work up a more stable conversion for Ski Hunt and Ski Run.

Thanks again, Thomas! You're the best!

Attached Files

•  Ski Hunt (NTSC by Thomas Jentzsch).bin   4K   32 downloads
•  Ski Run (NTSC by Thomas Jentzsch) V0.05.bin   4K   27 downloads

[thegoldenband]

Wonderful! I look forward to checking these out. I'm honored that my thread revive seems to have helped spark all this.

At some point we should post a list of all the PAL-NTSC conversions with MD5 signatures, proper credit to the people responsible, and any other notes. One thing I don't know off the top of my head is which conversions made by Atariage members are superior (less screen rolling, better colors, etc.) to "official" NTSC releases, i.e. prototype, pirate cart and/or multicart versions.

[Rom Hunter]

thegoldenband, on Wed Jun 22, 2011 12:37 PM, said:

At some point we should post a list of all the PAL-NTSC conversions with MD5 signatures, proper credit to the people responsible, and any other notes.

Would be nice if that point comes as soon as possible.

[Omegamatrix]

Bumping an old thread... here is an update to General Retreat, and a I've now made a Westward Ho (NTSC).


The update to General Retreat has:

- fixed the color of the flashing background. I missed this the first time, and it flashed red-green instead of red-blue
- fixed the left side of the house so it was even with the rest of the house (bug from original game)
- fixed the ground on the right side of the house so that it was even (bug from original game)



 General Retreat (rev2) NTSC.bin   4K   14 downloads

Westward Ho is essentially Custer's Revenge. So I hacked Custer's Revenge with:

- disabled the checksum that prevents hacking in Custer's revenge
- changed the logo to the Playaround logo
- fixed a ground/mountain on the right hand side so that it was even
- added four more scanlines so that it was a even 262 (important for NTSC games)



 Westward Ho (AKA Custers Revenge) NTSC.bin   4K   12 downloads


Have fun!!!

[Kurt_Woloch]

So... could really every PAL game be converted to NTSC? Are there no PAL games that do game calculations between frames that are so intensive that they can't run on NTSC because there would be not enough time to do all calculations between two frames (NTSC having fewer scanlines)?

[Thomas Jentzsch]

Kurt_Woloch, on Wed Feb 8, 2012 2:43 PM, said:

So... could really every PAL game be converted to NTSC? Are there no PAL games that do game calculations between frames that are so intensive that they can't run on NTSC because there would be not enough time to do all calculations between two frames (NTSC having fewer scanlines)?

You are right, some games written for PAL only were not easy to convert to NTSC.

But why worry? You only want to convert NTSC games to PAL. And then it always fits.

[thegoldenband]

Just throwing a guess out there, but: I'd imagine that classic-era games usually weren't programmed with maximum efficiency, especially the "off-brand" games, so maybe there's more room for people like Thomas to work their magic. However, I know there are a couple homebrews that are PAL-only, and certainly there are demoscene demos that are exclusive to PAL. It wouldn't surprise me if the demos, especially, were essentially impossible to convert without massive rewriting.

[Lucky Man]

Mr. Jentzsch has come through once again with a completed conversion of Panda Chase!

Here are 2 versions: The first is a standard conversion that looks the same as the original PAL version. The second cleans up the animation of the panda a bit.

 Panda Chase (NTSC by Thomas Jentzsch) V0.90.bin   4K   7 downloads
 Panda Chase (NTSC by Thomas Jentzsch) V0.92.bin   4K   16 downloads

So I guess we're pretty much done with these unless someone can finish converting Words-Attack. Thanks again everyone for all of your help with these.