132 replies to this topic

[moycon]

If this game is released on cart, add me to the list of pre-orders!!!

[PacManPlus]

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

Attached Files

•  FAILSAFE.zip   74.2K   95 downloads

[PacManPlus]

ACK!

Found a bug with the last change introduced. It completely ignored the number of enemies on the screen at once, and always did the max.

Fixed here, in RC5
Sorry!

Attached Files

•  FAILSAFE.zip   74.23K   123 downloads

[TrekMD]

Great news, Bob. Thanks!

[PacManPlus]

Thanks

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

Thanks,
Bob


EDIT - Also, having a REALLY tough time finding a good picture (that hasn't already been used) for the label / box.
I think this might be my first 7800 text label game!

[GroovyBee]

PacManPlus, on Sun Dec 13, 2009 1:32 PM, said:

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.

[mimo]

arrgh lost the text files for my CC2 menu so updating is going to be a pig, really want to try this and arkanoid out:roll:

[Allan]

PacManPlus, on Sun Dec 13, 2009 1:32 PM, said:

Thanks

EDIT - Also, having a REALLY tough time finding a good picture (that hasn't already been used) for the label / box.
I think this might be my first 7800 text label game!

Ah...Ah...Ah....contest.....choooooooooooooooooo!!!!!

Allan

[PacManPlus]

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

[Albert]

PacManPlus, on Mon Dec 14, 2009 10:12 AM, said:

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

[jwierer]

PacManPlus, on Mon Dec 14, 2009 10:12 AM, said:

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

[PacManPlus]

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

[PacManPlus]

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

Attached Files

•  FAILSAFE.zip   74.57K   114 downloads

[GroovyBee]

PacManPlus, on Mon Dec 21, 2009 5:54 AM, said:

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?

[Propane13]

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

[HatNJ]

moycon, on Thu Dec 10, 2009 3:34 PM, said:

If this game is released on cart, add me to the list of pre-orders!!!

Same here Love Bob's game relases I doubt Ive bought all of them might have missed one or 2 but definitely want this!!!

[PacManPlus]

Propane13, on Wed Dec 23, 2009 1:30 PM, said:

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

[Propane13]

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.

[kenfused]

GroovyBee, on Mon Dec 21, 2009 7:24 AM, said:

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

[PacManPlus]

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

[Ransom]

PacManPlus, on Fri Dec 25, 2009 8:19 PM, said:

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.

[PacManPlus]

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

Attached Files

•  FAILSAFE.zip   75.06K   109 downloads

[Allan]

PacManPlus, on Sat Dec 26, 2009 11:56 AM, said:

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

[PacManPlus]

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

[Allan]

PacManPlus, on Sat Dec 26, 2009 1:58 PM, said:

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