Jump to content
  • entries
    657
  • comments
    2,699
  • views
    899,800

About this blog

Atari projects, Mac mini DVR, and other things

Entries in this blog

PRGE build of Frantic

Here's the build of Frantic that was shown at PRGE.  Al needed the demo ROMs at the start of October so he'd have time to build all the carts.     frantic_20231002_PRGE.bin   Changes:   Fixed issue where room sometimes changed color during transition to next room. Revised robot death sequence - when hit the robot's shape is now briefly color cycled (like the humanoid's death sequence) before the explosion sequence starts. Revised Otto logic for Fren

SpiceWare

SpiceWare in Frantic

Some love for Frantic

Been about a month since the last update for Frantic so I thought I'd spend some time on it. Tryed out Maze Type as the default selected option. Not a fan, already changed back to Start for next build. Added Diagnostic support like in Draconian, no longer need to create special diagnostic builds. Noticed that the ARM routines were not using the audio interrupt routine (which will be needed when voice samples are added back in). It's been turned on - and I'm now seeing screen

SpiceWare

SpiceWare in Frantic

LumaBoost

LumaBoost in place, flickering objects will increase in brightness to compensate for the flicker Special Room Object appears in the same location for a give X-Y room so that it doesnt change location if the humanoid dies and room is reinitialized wall types (destructive vs reflective) surrounding Special Room Objects are now drawn based on the object. Priority increased for Hit Special Object sound effect halved the speed of Homing Missiles Forced X position of

SpiceWare

SpiceWare in Frantic

Special Room updates

Moved routines from Vertical Blank to Overscan to fix screen roll problem Special object animation in place Big Otto's face will update, launches extra Evil Ottos with very primitive movement logic Hit the Power Plant and robots can't move, but can still shoot Hit the Central Computer and robots can't shoot and will randomly move (even into walls) Factory doesn't do anything yet, but if you hit it the animation stops Big Otto   Power Plant

SpiceWare

SpiceWare in Frantic

Robot and Tank animation

Changes Robot and Tank animation sequences are in place Robot and Tank "cool down" logic implemented, should prevent "rapid fire" Controls RESET = start game SELECT = return to menu Left Difficulty, Frenzy Special Room Test1: B = Off, A = On Right Difficulty, Stress Test Mode2: B = Off, A = On 1Frenzy Special Room Test will always put a special object in the room. Currently only Big Otto does anything, and it's the same experimental code as befor

SpiceWare

SpiceWare in Frantic

Shot revisions

missile/wall logic now checks all corners of the missile when testing for brick removal, fixes issues with Tank's Homing Missiles missiles now reflect off flickering walls in Frenzy variation ROM frantic20140218.bin   Source Frantic20140218.zip

SpiceWare

SpiceWare in Frantic

Homing in on you

Tanks now launch Homing Missiles changeable wall color menu is back lots of ROM savings Menu's back in place. All options should be functional, so let me know if something doesn't work as expected.   A couple Tanks launched Homing Missiles. They're shaped differently than the normal shots. The menu option sets the number of redirects each Homing Missile can make. Values range from 0-3 (0=no redirect). The "remove brick" routine needs to be updated to cop

SpiceWare

SpiceWare in Frantic

Feature parity with the final build of the prior reboot

I'm now at the point where I've implemented everything that was in the final build of the prior reboot the RAM usage has been changed so there's space for the 2K speech buffer preliminary animation sprite clipping etc On top of that, the Stealth feature is in place, which wasn't last go around.   The new routines have saved almost 2K! Before there was 7372 bytes free (see the comments), now there's 9218 bytes free. Like before, the 9218 doesn't consider

SpiceWare

SpiceWare in Frantic

Playable

Animation routines aren't in place yet, but we now have a playable build.   I always liked the Stealth Mode, so I've added that back in. It's currently controlled by the Right Difficulty switch. When enabled, all robots will initially be visible for 1 second. After that any robot that shoots will be visible for 1/2 second. If a robot is destroyed, all remaining robots will be visible for 1/2 second.   In the Frenzy version you can shoot out the solid walls - this can be handy

SpiceWare

SpiceWare in Frantic

Missile driver rewritten

The missile routines have been added back. I also changed Otto to be a 2X sprite for testing purposes. It'll be changed back to a 1X sprite for the next build, which should be playable   I removed the original flicker logic routine and renamed the new one DisplaySprites. It uses DataStream0 and DataStream1 to populate the graphic and color datastreams for player0 and player1. Since the datastream usage is the same, I was able to merge those two functions into DataStream. The new

SpiceWare

SpiceWare in Frantic

Sprite driver rewritten

Sprite driver has been rewritten to work with the new kernel. I've also written an alternative sprite driver that improves performance, though there is a minor tradeoff when using it. I've set OPTIMIZE to 1, which causes some extra 6507 code to come into play. The extra code extends the display by 10 scanlines in order to show what's left in TIM64T for Vertical Blank and Over Scan. Some TVs may not like displaying a 272 scanline image, so it's possible this ROM will roll for some people. My C=10

SpiceWare

SpiceWare in Frantic

Optimized P0 routines

Optimized the player 0 reposition routines for 200+ byte savings. The room generation is back in place to make it easier to test the timing of playfield updates - when the room shifts left/right any playfield timing issues become readily apparent. To aid in reviewing it, the playfield has been given priority over the players:   The X position display was changed to show which of the reposition routines are in use - there are 22 of them, 11 for each player. The routine used will b

SpiceWare

SpiceWare in Frantic

Test of new reposition routines

For comparison, the top two robots are positioned using the standard reposition routine. The next two robots are positioned to the same X values using the new routines. The rest of the robots are repositioned to preset X locations using the new routines.   Move the joystick left/right to adjust the X position of player 0 and up/down for player 1. Hold fire to move slower.     Next up will be to do some ROM usage optimizations to the P0EarlyHMxx routines.  

SpiceWare

SpiceWare in Frantic

Reposition Player 0 routines done

The revised Reposition Player 0 routines take 4 scanlines. The routines in the prior version took 6 (5 to reposition, plus 1 to get back into sync with the main kernel loop).   This screenshot shows reposition routines P0EarlyHM25, P0EarlyHM30, P0EarlyHM35, ..., P0EarlyHM70 being triggered (the red robots). They also show NUSIZ0 being updated (the red missile).   Unlike player 1, the player 0 routines do not have any late updates. There's also quite a bit of SLEEP going

SpiceWare

SpiceWare in Frantic

Reposition Player 1 routines done

The revised Reposition Player 1 routines take 4 scanlines. The routines in the prior version took 5 (4 to reposition, plus 1 to get back into sync with the main kernel loop).   This screenshot shows reposition routines P1EarlyHM25, P1EarlyHM30, P1EarlyHM35, ..., P1EarlyHM70 being triggered (the green robots). They also show NUSIZ1 being updated (the green & white missile).   I do have a single late update - ENAM0 is updated at cycle 25 in P1EarlyHM22. That won't be

SpiceWare

SpiceWare in Frantic

New Kernel tested

Output from the new Kernel looks OK to me:   Due to the shift in timing, the new KernelEvent is more efficient than before. Before it looked like this: KernelEvent: ; 3 27 ; have to update PF2 before figuring out which Kernel Event, otherwise ; PF2 is updated to late in the Reposition Player 1 routines ldx DS_PF2L ; 4 31 stx PF2 ; 3 34 - PF2L, before 38 sty PF0 ; 3 37 - PF0R, 2

SpiceWare

SpiceWare in Frantic

Take 3

Once again, Frantic is being rebooted   While working on Stay Frosty 2, Thomas Jentzsch suggested redoing the kernel to use VDELBL. It puts the ball on vertical delay with updates synced to GRP1. It's a clever idea - but due to how SF2 is designed that would have required me to draw the snowman using player(sprite) 1 instead of player 0, which would cause problems in the horizon due to object priorities:   I thought it could be useful for Frantic and Timmy, as their spr

SpiceWare

SpiceWare in Frantic

Speech prep finished

I've freed up enough RAM so I'll be able to add back in the speech routines. Part of it was freed up by changing the sprite variables from INT (4 bytes) to UNSIGNED CHAR (1 byte). The routines can handle 24 sprites, and there are 9 different values stored for each sprite (such as X, Y, Image ID, Animation Frame, etc), so the original RAM usage was 864 bytes. After the change that only took 216 bytes. The rest was freed up by moving variables from the Display Data area into the Frequency table ar

SpiceWare

SpiceWare in Frantic

Big Otto

New look for diagonal shots. Robot explosions back in place, utilizing the new 2x sprite feature. Doors are back in place. Special room objects for Frenzy (Left Difficulty = A) in place. Only Big Otto does anything at the moment. Evil Otto can be killed in Frenzy variation. Still some work to be done on this feature. Sleeping until something happens   Happy the humanoid was neutralized   mad that little otto was destroyed, so launc

SpiceWare

SpiceWare in Frantic

Playable

While there's still a lot to be added back, such as animations, Otto, and explosions, Frantic is once again playable.   ROM frantic20120318.bin   Source Frantic20120318.zip

SpiceWare

SpiceWare in Frantic

Shot driver rewritten

The shot driver has been rewritten to take advantage of the new kernel. It supports up to 6 shots by using 30 Hz flicker.   Vertical shots are now 5 pixels tall instead of 8. One of the things I discovered before the reboot was that you could shoot a robot on the other side of a horizontal wall because the shot was too tall (horizontal walls are 5 scanlines tall).   Shots are drawn round-robin so each shot will be drawn using the ball, missile 0 and missile 1 over subse

SpiceWare

SpiceWare in Frantic

Sprite driver rewritten

The sprite driver has been rewritten to work with the new kernel.   Left Difficulty A = Frenzy layout Left Difficulty B = Berzerk Layout   Right Difficulty A = all possible robots Right Difficulty B = normal randomized robot count       The display at the bottom is XXYYFF where X and Y is the room location and F is the flicker factor. 0 = no flicker 1 = 30 hz 2 = 20 hz 3 = 15 hz   ROM frantic_2012031

SpiceWare

SpiceWare in Frantic

Room generation back in place

The wall generation routines are back in place, as are the room shift routines. This is so the Playfield updates could be checked (it's really obvious when the room shifts left/right if one of the PFx updates is occuring at the wrong time).   Use the Left Difficulty switch to select Berzerk or Frenzy layout.   Use right joystick to change rooms.   Use left joystick to position robots.   To check the PFx updates for all 22 reposition kernels I tested with X

SpiceWare

SpiceWare in Frantic

Test of new reposition routines

Added some code to test the new reposition routines. Move the joystick left/right to adjust the X position of player 0 and up/down for player 1. Hold fire to move slower.   The topmost copy of each player is positioned using the standard reposition routines so that I could confirm the results were correct. The 2nd copy of each player is repositioned using the new routines. The remaining copies are hard coded and won't move.   I've also added the Score/Lives/Bonus kernel and a

SpiceWare

SpiceWare in Frantic

Reposition Player 0 routines done

The Reposition Player 0 routines have been rewritten. It now takes 5 scanlines to reposition player 0, plus an additional scan line to get back into sync with the main kernel loop. The player 0 graphics can start on the additional scan line, but a reposition of player 1 cannot be triggered on it as the BMI KernelEvent is what was dropped to get back in sync.   I was surprised that the reposition player 0 routines now take longer than player 1 (it used to take 2 and 3 scanlines respecti

SpiceWare

SpiceWare in Frantic

×
×
  • Create New...