Jump to content
IGNORED

FailSafe (7800) - WIP


PacManPlus

Recommended Posts

Here is RC4, I did two things:

 

- Made it so when a power up scrolled off the screen, another one can still come up

- Made it so another power up is possible while a power up is still in effect.

 

 

Oh, and BTW, thanks Moycon and everyone else who showed interest. I'm trying to find a good 'classic' picture to use for the label... I don't want to repeat the 'Countermeasure' picture, but am looking for a very similar pic.

 

After that, I will start the preorders.

 

Thanks,

Bob

FAILSAFE.zip

Link to comment
Share on other sites

BTW, anyone in PAL land try the PAL version? Does it look ok?

Just testing the PAL game.

 

With only the tank on the screen its all stable. As soon as the playing area gets to the the first turret there is an intermittent line at the top (after rhe status bar) and bottom of the scrolling screen. The last line of the status bar background colour seems to be the first background line of the trees.

 

I think you might need another STA WSYNC before you change colours after the playfield is drawn. The last pixel in the trees is drawn in yellow.

 

The black shots are very hard to see on the very dark green grass. Can you tell me the addresses of the colours and I'll see if I can come up with a good PAL palette.

Link to comment
Share on other sites

LOL!!!

 

Not a bad idea, Allan...

 

Thanks!

 

I do want it to be in the same style as the last few games I released (Jr. Pac-Man, Super Pac-Man, Space Invaders, etc.) with the old style heading over the picture (which takes up the entire label).

 

Albert, how do I set that up? I've never done a contest before...

I guess a free cart and a mention in the manual (which I still need to do). Hopefully that is enough. :(

 

I'm already puting Jeff in the manual for the editor which sped up the completion of this game.

(BTW, you can post that whenever you are ready!)

 

Thanks,

Bob

Link to comment
Share on other sites

Albert, how do I set that up? I've never done a contest before...

I guess a free cart and a mention in the manual (which I still need to do). Hopefully that is enough. :(

I usually give people some store credit in the AtariAge Store as well as a free copy of the game. I can setup a label contest, although I was supposed to do one for the updated AtariVox/VecVox. We can discuss this privately. :)

 

..Al

  • Like 1
Link to comment
Share on other sites

I'm already puting Jeff in the manual for the editor which sped up the completion of this game.

(BTW, you can post that whenever you are ready!)

Thanks Bob! I am just fixing up some bugs you never encountered and cleaning things up. I also want to make sure it works with the *final* binary :)

 

-Jeff

Link to comment
Share on other sites

Hi!

 

I have added some more 'Powerups' (although these are VERY rare):

P - Bonus Tank (Player)

L - Shows you a random letter in the code (like the Depot does)

E - Energy; Restores your tank fuel

T - Time; adds 5 minutes to the total Launch time

 

I have also fixed where the enemies get placed; sometimes they were getting put inside a wall where you couldn't shoot them.

 

Finally, I have changed some locations of the Cruize Missile; it's damn near impossible to kill them while the tank is in the tight spaces I originally had them come out at.

 

Once I get the corrected PAL colors, I will post a bin.

 

Thanks,

Bob

Link to comment
Share on other sites

Hello

 

RC6 here. All of the changes mentioned in the above post. The game is getting easier. I can almost finish it on the 'Intermediate' level (I was never that good at Countermeasure, so this is a good sign).

 

One thing though - there is a single flickering scan line between the score section and the playfield that I don't know how to get rid of. It only happens on the real thing. It doesn't take anything away from the game, and quite frankly I've gotten so used to it I don't even see it any more.

 

It has something to do (I think) with switching modes (from 320 to 160). The score is 320 mode and the playfield is 160.

 

Let me know if you guys find anything else, and if I should make any more changes to the PAL colors - many thanks to *GroovyBee* for giving me the PAL colors to change to.

 

Thanks,

Bob

FAILSAFE.zip

Link to comment
Share on other sites

One thing though - there is a single flickering scan line between the score section and the playfield that I don't know how to get rid of. It only happens on the real thing. It doesn't take anything away from the game, and quite frankly I've gotten so used to it I don't even see it any more.

 

It has something to do (I think) with switching modes (from 320 to 160). The score is 320 mode and the playfield is 160.

 

I've been looking at the BeefDrop source code (vbi.asm) which also does a similar resolution change. The execution path to placing a new value in the CTRL register takes 53/54 Sally clock cycles upon entry to the DLI handler (depends if its changing to 160 or 320 mode). Maybe Kenfused can shed some light on why this is so?

  • Like 1
Link to comment
Share on other sites

Just to check to make sure I'm on the same page, does your code essentially have a DLI, and then once the DLI is executed, does it call an interrupt function that changes CTRL, and then RTI's back?

 

I remember some weird hardware color artifact happening in my Frogger Demo from 2003, where I ran into something similar. I set the background color to blue (for water) in the main routine, and then DMA would start. Halfway through the DLL, I set a DLI to call a function that changed the background color to black, followed by an RTI.

 

It was interesting-- The blue line always showed up somewhere in the middle of the screen (and if I remember right, it moved left/right a little bit, depending on timing).

 

If this is what you're doing, maybe you can have a single-line DLL entry with the DLI (for CTRL update), essentially shifting the screen down one, and then remove a DLL line from one of your offscreen values at the bottom? Of course, this may not be feasible, or even what you're doing, but hey-- worth the question. :)

 

-John

  • Like 1
Link to comment
Share on other sites

Just to check to make sure I'm on the same page, does your code essentially have a DLI, and then once the DLI is executed, does it call an interrupt function that changes CTRL, and then RTI's back?

 

I remember some weird hardware color artifact happening in my Frogger Demo from 2003, where I ran into something similar. I set the background color to blue (for water) in the main routine, and then DMA would start. Halfway through the DLL, I set a DLI to call a function that changed the background color to black, followed by an RTI.

 

It was interesting-- The blue line always showed up somewhere in the middle of the screen (and if I remember right, it moved left/right a little bit, depending on timing).

 

If this is what you're doing, maybe you can have a single-line DLL entry with the DLI (for CTRL update), essentially shifting the screen down one, and then remove a DLL line from one of your offscreen values at the bottom? Of course, this may not be feasible, or even what you're doing, but hey-- worth the question. :)

 

-John

 

Hey John: You are correct in your assumption. For you and GroovyBee, this is my DLI Kernel:

 

 

;  KERNAL - MAINTAIN THE ON-SCREEN DISPLAY
DLI       
         PHA                            ;STACK REGISTERS
         TXA
         PHA
         TYA
         PHA

         CLD
         LDA     KNLTEMP                ;SEE WHAT DLI HANDLER TO GO TO
         BMI     TOPDLI
         BEQ     MIDDLI
         BNE     BOTDLI                 ;IF ZONES FINISHED, DO BOTTOM TEXT

;  THIS TAKES CARE OF DLIS ON THE TOP OF THE SCREEN
TOPDLI
         LDA     #GRAPHON3              ;TURN ON 320 MODE, FOR SCORE & INFO LINE
         STA     CTRL
         LDA     #$00
         STA     WSYNC
         LDA     SCCOLOR
         STA     BACKGRND               ;SET BACKGROUND COLOR
         INC     KNLTEMP                ;SET UP FOR NORMAL DLIS
         JMP     DLIOUT

;  THIS TAKES CARE OF THE DLI FOR THE MAIN BODY OF THE SCREEN
MIDDLI
         LDA     #GRAPHON               ;PUT BACK 160 MODE
         STA     CTRL
         LDA     #$00
         STA     WSYNC
         ;STA     WSYNC
         ;STA     WSYNC
         LDA     PFCOLOR
         STA     BACKGRND               ;SET BACKGROUND COLOR
         INC     KNLTEMP
         JMP     DLIOUT

;  THIS ROUTINE TAKES CARE OF THE LAST DLI ON THE SCREEN, THE 'VERTICAL BLANK
;  ROUTINE'.
BOTDLI
         LDA     #GRAPHON3              ;TURN ON 320 MODE, FOR 2ND INFORMATION LINE
         STA     CTRL
         LDA     #$00
         STA     WSYNC
         STA     WSYNC
         ;STA     WSYNC
         LDA     #BLACK
         STA     BACKGRND               ;SET BACKGROUND COLOR
         INC     RTLOCAL+1              ;INCREMENT CLOCK
         BNE     DLITUNE
         INC     RTLOCAL
DLITUNE   
         ;;JSR     TUNER                  ;DO TUNES
         JSR     LOADER                 ;LOAD UP NEXT FRAME
         JSR     SCROLLSCRN             ;SCROLL SCREEN IF NECESSARY
DLLWAIT
         BIT     MSTAT                  ;WAIT FOR VBLANK
         BPL     DLLWAIT
DLLOTHER
         JSR     TUNER                  ;DO TUNES
         JSR     RAND                   ;UPDATE RANDOM NUMBER
         ;JSR     TUNER                  ;DO TUNES
         LDA     #$FF
         STA     KNLTEMP                ;SET TOP DLI TO HAPPEN NEXT
DLIOUT
         PLA                            ;UNSTACK AND LEAVE
         TAY
         PLA                            ;THIS IS WHERE MOST DLI'S LEAVE
         TAX
         PLA
NULLRTI
         RTI

 

Obviously the TOPDLI gets executed before the score lines, and the MIDDLI between the score lines and the playfield, and the BOTDLI between the playfield and the info line.

 

I've playes with different 'STA WSYNC's (as you can tell by the comments). But that just shifts where the flickering line is.

 

Bob

  • Like 1
Link to comment
Share on other sites

Thanks for sharing!

 

So, here's some thoughts/questions:

 

1) For your DLI, after the first PHA, what would happen if you just set CTRL to a dummy mode where VBLANK is off before executing the rest of the code? That would essentially stop DMA from doing anything it thought it should, so that it could finish processing the DLI). I'm not sure if that's the case of what's happening, but I'm thinking "hey, it might be worth a shot".

 

2) Here's another thing to play around with:

The Top and Middle DLI processing code does a lot of "extra handling" that it really doesn't need to. From some experiments I tried awhile back, I remembered that my DLI code was best to be as short as possible whenever executed during graphics-drawing DLL's. And, there are ways to do this in your code. :)

 

What I'm thinking is:

 

a) Move this code:

         TXA
         PHA
         TYA
         PHA
         CLD

to the BOTDLI section (since there are no JSR's or ADC/SBC statements in the code for the top and mid DLI's that can corrupt X/Y or be impacted by the decimal flag (I believe INC is not impacted by CLD)).

 

b) Then, instead of:

         JMP     DLIOUT

 

for the top and mid DLI code segments, you can just do:

         PLA ; restore accumulator
         RTI

 

Calculations-wise, these optimizations save a LOT of time. Essentially, you'll remove:

2 PHA's = 3*2 cycles

2 PLA's = 4*2 cycles

4 X/Y transfer statements = 2*4 cycles

1 CLD = 2 cycles

1 JMP = 3 cycles

 

Total: 27 cycles saved.

If that's enough, you don't even need the WSYNCs, and the DLI processing may be short enough for the top/mid kernels that everything will work out. If not, it may just be a good exercise to see what's "different" on-screen after trying this out.

 

That's my thoughts for now!

-John

 

P.S. I think the KNLTEMP mechanism is a cool idea. :)

  • Like 1
Link to comment
Share on other sites

I've been looking at the BeefDrop source code (vbi.asm) which also does a similar resolution change. The execution path to placing a new value in the CTRL register takes 53/54 Sally clock cycles upon entry to the DLI handler (depends if its changing to 160 or 320 mode). Maybe Kenfused can shed some light on why this is so?

I don't remember doing anything special although it sometime took some trial and error to get things working exactly right sometimes.

 

--Ken

  • Like 1
Link to comment
Share on other sites

Hi Guys:

 

Unfortunately, neither idea worked, but with a little more playing around with the WSYNCs and adding a 2 line NULL DLI that changed the screen resolution, I got rid of the flickering. I'll post a BIN later on when I get back.

 

Bob

 

Wonderful! I'm really glad to hear you found a way to solve it.

Link to comment
Share on other sites

Thanks!

 

Ok here is RC7!

 

- The flickering line has been eliminated!

- The two garbage scanlines between the bottom of the playfield and the top of the lower status line have been eliminated!

- HSC SUPPORT!

 

Note, in order for the HSC to return properly, we need to turn off DMA momentarily. As a result of this the intro music kind of gets interrupted when switching from the title screen to the high score screen and back. Nothing I can do about that. :(

 

Thanks guys!

 

New CCII entry:

7800: FailSafe	FAILSAFE	HSC_48K	HSC

FAILSAFE.zip

Link to comment
Share on other sites

Thanks!

 

Ok here is RC7!

 

- The flickering line has been eliminated!

- The two garbage scanlines between the bottom of the playfield and the top of the lower status line have been eliminated!

- HSC SUPPORT!

 

Note, in order for the HSC to return properly, we need to turn off DMA momentarily. As a result of this the intro music kind of gets interrupted when switching from the title screen to the high score screen and back. Nothing I can do about that. :(

 

Thanks guys!

 

New CCII entry:

7800: FailSafe	FAILSAFE	HSC_48K	HSC

Very nice,

 

I noticed when you get to the high-score screen in 'attract mode' it stays at the high-score screen and the screen flashes (goes blank fery quickly) and the returns to the high-score screen.

 

This is with the real hardware with the CC2.

 

Allan

Link to comment
Share on other sites

Hi Allan:

 

hmm... I had this at the beginning but I thought I resolved it (I was also testing this on real hardware) - did you just let it sit or did you play a game first or...

 

Is it easily repeatable?

 

thanks,

Bob

I played a game first. I only played one game so I don't know if it's repeatable.

 

Allan

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

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