dwane413

I would give the seller a reasonable time to reply and see if they are willing to make things right. On the other hand, if I was the seller, I wouldn't be very happy if someone posted my email address to a public forum where anyone could see it. Actually, I think that is a violation of eBay rules: Publishing contact information (quoting relevant parts only)

I wouldn't exactly call it a trick. That's just how it's supposed to work. From Keystone Kapers' manual:

I'm guessing that you might be able to dump it, but I don't know. The only way to know for sure it to try it or have someone try it for you. If you have a Harmony cartridge, here are instructions for using it to dump a cartridge: Harmony-based cart dumper

I tried a Google search for posts at this site with orange paint and found this: Atari 2600 Orange Paint Match It's about joysticks and may not be what you're thinking of.

A short cartridge might not work too well in this modded Flashback 2.

Did this CIB (Complete in Box) Atari (either the console or the box) originally come with only 1 joystick?

I was one of the viewers.

Your link is messed up. The correct URL is here.

I don't know of any clones currently on the market, but there have been in the past. See AtariAge's Atari 2600 Consoles and Clones page.

This may not answer your question, but I thought this thread might be of interest to you: What is the 'original' version of Pac Kong and do I go with NTSC or PAL? You might also want to look around at the different versions on Atarimania. I don't know who programmed it.

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. Glad I could help out a little. Of course Omegamatrix did the hard part.

Jahfish's pictures were hosted on his own server.... jahfish.de. Since I don't know the history of his webspace, I can't say that they were deleted. They could still be online at a different address or they might have stayed online until his website went down. Irregardless, Go Daddy shows that that address is gone: So them being missing now isn't because they were deleted. I don't know how AtariAge's albums work, be if you post a picture that is hosted by AtariAge in a message here, I expect it will be around for a long time. In case you don't know what Schizophretard is referring to, see this.

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* 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 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 ; 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 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.

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

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.

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

That's because this thread is 10 years old, but you could find one of the pictures if you had a time machine.

I found pics on Atarimania by searching for Space Robot.

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 What I said above is also true for this:

There is another problem that I've found. The stem for the orange is one row of pixels too high. This makes it sometimes visible at the bottom of the strawberry when the strawberry is going up or down. I don't know if you could move the whole orange sprite down one byte or if that would mess up the bottom of the orange.

I don't mean to hurt your feelings, but it doesn't look ready for the store to me. Here is one of the first things I notice when I start this ROM: I don't know what you had in mind, but to me this makes the game look cheap. You've erased the first three segments of the Atari copyright logo, but left the forth segment (part of "2 A", but looks like "2 f"). I can't tell what you've put in the last two segments unless it is initials.... After writing that, I looked back through the thread and see that it should say "© Jr. P". Now that I know, I can see that, but it still doesn't look good like it is. In case anyone is wondering what else has been changed in this, the background is black (Ms. Pacman Black) and sprites have been changed for the ghost, Ms. Pac-Man and the fruit. With a copyright logo like this it would be more impressive, although I didn't get it quite centered:

Pea pods sound better to me.

Hope you enjoy your vacation.

I like your corn sprite. I don't like the idea of poop in a game though.

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