DEFENDER III - Atari Flashback Portable

[Mr SQL]

DEFENDER III

 

Edit: 8/17/23 Added support for Defender III to the Commodore 64 Atari 2600 Emulator, see this post for details.

Commodore 64 prgs: defenderiii.prg   defender3trainer.prg  

 

Basic Gameplay:

 

Protect Martian Cities from fallling Meteors by blasting them out of the sky!

 

Meteor impact slowly destroys the cities of Mars - your ship is equipped with audial Radar which allows you to hear off screen meteor impacts; reach them fast enough and you can stop the meteors in mid-destruction!

 

Restore health to damaged Cities by catching falling score power-ups.

 

To complete the wave and defend a new City, you must destroy at least 10 meteors before either your Ship or the City are destroyed.

 

Shields:

 

The impact from any of the baddies will damage your Ion shields to varying degrees with spectacular plasma color effects (not in the Beta yet) - take on too much damage and your shields are eventually destroyed completely; sustain a hit without sheilds and the game is over. When you save a City, your Ion shields are fully recharged.

Defender III Weapons:

 

All Defender games have different weapons - in Defender you had a colorful laser burst while Defender II sported more precise particle beam weapons. In Defender III, you've got an unlimited supply of remote control Drones, which control a bit differently than laser bursts or particle beams:

 

Until a Drone goes offscreen and out of range you'll have full control over it - you can even make the Drones do loop-de-loops and figure eights which comes in handy for clipping the high speed meteors. It can take awhile to get used to not being able to fire another shot after you miss a target because your Drone is still airborne - this Defender plays different

 

Game Characters:

 

Meteors
Enemy landers

heat seeking pods
Surface to air missiles

Buildings

Score power-ups

Defender Ship

Remote control Drones

 

Console compatibility:

 

Beta 5 currently plays on all Atari consoles including the Flashback Portable though the pre-production version is as of yet untested (someone please test on a pre-production unit!)

 

Defender III does not work in Stella yet, at least not in my version - a scrolling mosaic appears at the start instead of the ship being in outer space, and the mosaic permeates the cityscape once the game starts making it unplayable. I will find a workaround for this as development continues; Defender III was programmmed in Flashback BASIC which is also in Beta.

 

I'll post new versions of the game as development progresses, hope everyone enjoys!

 

DefenderIII_Beta5.bin

 

Edit: 3/2017: Defender III and Defender III Trainer ROM's below!

 

Changes:

 

Harder to clear a level, you must destroy 15 meteors!

Unique bonus round challenge levels - a playable title screen level and a playable game over level showing waves completed.

 

You'll need a light touch to play these levels without starting a new game.

 

Defender_III_Trainer_v1.binDefender_III_v1.bin

 

Edited August 17, 2023 by Mr SQL
Emulator tuning

[Keatah]

You should let the stella team know. They're redoing the core for the tia. And if it work on real hardware, but not in emulation, they want to know about it! http://atariage.com/forums/topic/259633-testing-the-new-stella-tia-core/

[fiddlepaddle]

I like it...nice and fast (tested via FBP) Be nice to see score and/or number of meteors remaining...

[iesposta]

Hint:

 

To play in Stella, start the game.

Hit the tilde (key above tab) to get into the debugger.

type: reset

click the exit button near the top left.

 

Does that help?

 

EDIT: Works on Mac. Did not work on Windows 7 Stella 4.6.1

Edited March 3, 2017 by iesposta

[DirtyHairy]

To play in Stella, start the game.

Hit the tilde (key above tab) to get into the debugger.

type: reset

click the exit button near the top left.

This suggests that the code relies on uninitialized values (CBS RAM, most likely) and is supported by the fact that running the game in 6502.ts/stellerator yield different results depending on the RNG seed involved. Note that the initial values of RAM (RIOT and CBS) should be considered undefined on startup, though real hardware acts predicatbly to some degree. Most emulators (inclduding Stella and 6502.ts) account for this by randomizing RAM contents, others just zero it. Also, unless you are replacing the ROM in an actual CBS cartridge, chances are that "real hardware" means "harmony cart" in this context, and this implies that the initial contents of the CBS RAM are determined by the ARM driver code running on the harmony's microcontroller, which I guess again differs from the behavior displayed by real hardware.

 

Mr SQL, I think you may be missing some initialization code there --- this will cause the code to act predictably and allow you to fix this reliably

Edited March 3, 2017 by DirtyHairy

[Mr SQL]

This suggests that the code relies on uninitialized values (CBS RAM, most likely) and is supported by the fact that running the game in 6502.ts/stellerator yield different results depending on the RNG seed involved. Note that the initial values of RAM (RIOT and CBS) should be considered undefined on startup, though real hardware acts predicatbly to some degree. Most emulators (inclduding Stella and 6502.ts) account for this by randomizing RAM contents, others just zero it. Also, unless you are replacing the ROM in an actual CBS cartridge, chances are that "real hardware" means "harmony cart" in this context, and this implies that the initial contents of the CBS RAM are determined by the ARM driver code running on the harmony's microcontroller, which I guess again differs from the behavior displayed by real hardware.

 

Mr SQL, I think you may be missing some initialization code there --- this will cause the code to act predictably and allow you to fix this reliably

 

The bug only showed up because I haven't added the initialization modules yet, but I think initialization code is also missing from Stella.

 

Stella should initialize CBS RAM low which it seems is happening in the Mac verison of Stella that iesposta observed when reset is issued.

 

I had to init CBS RAM high so the Atari Portable emu would recognize it, which also allowed this bug to surface. Previously I had initalized CBS RAM low so would never see it.

 

We're not dealing with static RAM so on real hardware the CBS RAM and Sara chips should be all zeros when powered on rather than randomized; perhaps the RIOT is static RAM or gets corrupted at powerup if it's contents can be randomized?

 

When I found a similar bug in SuperCharger memory emulation I was able illustrate it with real SuperCharger hardware; maybe someone with a socketed CBS RAM cart and an EPROM burner can tell us for sure.

[Flojomojo]

It looks cool, and it's very fast! Almost too fast to be "my" Defender. Any options to make it easier?

[DirtyHairy]

We're not dealing with static RAM so on real hardware the CBS RAM and Sara chips should be all zeros when powered on rather than randomized; perhaps the RIOT is static RAM or gets corrupted at powerup if it's contents can be randomized?

RIOT at least is static (you can check the MOS 6532 datasheet). I don't know any details about the RAM used by CBS, but even if it were DRAM (which I doubt as it would have required CBS to include the necessary refresh circuitry), the initial state may depend on external factors and be nondeterministic, so I wouln't depend on any particular initial value there. At any rate, imho, the initial state of electrical components that do not have any well defined behavior on power on is not the domain of emulators.

Edited March 3, 2017 by DirtyHairy

[Keatah]

At any rate, imho, the initial state of electrical components that do not have any well defined behavior on power on is not the domain of emulators.

Disagree, because then the emulator is behaving differently from real hardware.

[DirtyHairy]

Disagree, because then the emulator is behaving differently from real hardware.

No, it doesn't. It is acting different from real hardware + the harmony cart, which is to be expected as the harmony runs initialization code before the payload is started. You must realize that, while there is a reference point you can compare the emulation of history CBS games to (you can just pull out Mountain King and compare), there is no hardware implementation of Defender III that would define how the game should look like. If RAM were initialized properly, the constraints imposed by historic hardware would be enough to determine the behavior, but as it is, the behavior is determined by the initial state of a nonexistent hardware implementation.

 

An emulator is a model that tries to reproduce historic hardware faithfully. If you test the model outside the domain where behavior is fixed by the history hardware implementation, you are bound to get discrepancies. That said, a good emulator will still act as a sensible extrapolation of the historic hardware, but it will always stay an effective model.

Edited March 3, 2017 by DirtyHairy

[Zonie]

Did Buck say you could use his Thunderfigter?

[Jinks]

Tried this on Concerto cart 7800. I don't know whats going on in the game. the ship sprite looks nice the terrain is blocks that go by at light speed. Can sometimes get a glimpse of other bad guys but flash by ao fast can not make them out. The shots you fire are 15x slower than defender but the scrolling is 15x faster than defender.

[Mr SQL]

It looks cool, and it's very fast! Almost too fast to be "my" Defender. Any options to make it easier?

 

Tried this on Concerto cart 7800. I d4on't know whats going on in the game. the ship sprite looks nice the tertain is blocks that go by at light speed. Can sometimes get a glimpse of other bad guys but flash by ao fast can not make them out. The shots you fire are 15x slower than defender but the scrolling is 15x faster than defender.

 

Great feedback! I am adding a trainer mode to slow the action down, will post the new version soon

 

 

Disagree, because then the emulator is behaving differently from real hardware.

 

No, it doesn't. It is acting different from real hardware + the harmony cart, which is to be expected as the harmony runs initialization code before the payload is started. You must realize that, while there is a reference point you can compare the emulation of history CBS games to (you can just pull out Mountain King and compare), there is no hardware implementation of Defender III that would define how the game should look like. If RAM were initialized properly, the constraints imposed by historic hardware would be enough to determine the behavior, but as it is, the behavior is determined by the initial state of a nonexistent hardware implementation.

 

An emulator is a model that tries to reproduce historic hardware faithfully. If you test the model outside the domain where behavior is fixed by the history hardware implementation, you are bound to get discrepancies. That said, a good emulator will still act as a sensible extrapolation of the historic hardware, but it will always stay an effective model.

 

Keatah and DirtyHairy,

you both have excellent points and have brought up an interesting side discussion - should Stella and 6502.ts support the new Atari console even though it too is a virtual machine?

 

I think so, because the AFP should be percieved not as a rival emulator but as an Atari console that happens to run a VM.

 

Consoles set the standard and not the other way around; if an unmodified Atari console surfaces a bug in Stella because I make changes to support the console, then I think Stella should be modified to match; the other consoles arguably exhibit undetermined historic functionality but not the AFP.

 

This is just for thought as the next version I post will work in Stella, but wouldn't it be cool if Stella and 6052.ts could be patched for compatibility with the prototype too?

[Jinks]

As long as this works on an atari who cares about anything else...There a million ataris out there. The only worry is to get emulators to be accurate enough for testing games so they can work on real hardware not ever the other way around.

[Mr SQL]

Just posted new Defender III and Defender III Trainer ROM's at the top of the thread with some of the suggestions and more colorful scene transitions. These should run everywhere!

[Jinks]

Will try one of these nights..

[Mr SQL]

Defender III and Defender III Trainer for the Atari Flashback Portable and Retron77 are now running on the Commodore 64 Atari emulator! 

See the first post for the prg's, the Atari emulator is included in the Commodore prg binary and features pixel perfect and cycle precise emulation with texture mapped Commodore graphics.  

 

I will be releasing the new version of the emulator and development kit fully supporting Atari Flashback BASIC in addition to SuperCharger BASIC and Assembly after I check that I didn't break any working ROM's while enhancing the emulator. 

 

No changes were made to the code, the emu adds a virtual Atari 2600 system bus, virtual TIA and virtual RIOT allowing the ROM's to run natively at full speed on the 6510.

 

Extra features for PAL: If you have a PAL C64 you will see Defender III and the Trainer dynamically speed step from 60 Hz to 50 Hz.
There is also a new replacement chip available for the VIC-II that can toggle between PAL and NTSC playback rates that works great for D3.

 

Defender III is the sequel to Starblitz, like Defender and Stargate/D2. It adds another layer of parallex scrolling with metalic clouds above the city, and a  playable ending screen to complement the playable title screen and can be a little more challenging to complete the levels.

 

Which version you like better might be a matter of preference like Defender and Stargate, or may depend if you like playing Starblitz in 30 Hz mode with motion blur reduction activated.

D3 has no MBR filter by design and the minimal judder is part of the game - switch your focus from the Ship to the City and see the commodore graphics blend beautifully to new aesthetics. Hope everyone enjoys this game on the Portable Atari console and the Commodore 64!  

 

Commodore graphics design inspired by Parsec on the TI-99/4A.

 

[Flojomojo]

Thank you for making a trainer version for old slowpokes like me. 

[BIGHMW]

I think that we must clarify for those who may not know already (and I was one of those who just happened to stumble onto this thread) that this "Defender III" is not affiliated with the Williams Defender series as Robotron: 2084 was the third part in the official trilogy but rather a homebrew for the 2600 of the same namesake, much like Stern's version (never released) of Journey for the arcade (as featured in the 1983 game show Starcade both in gameplay, in the bonus round in one episode, and in another episode as a grand prize for winning the bonus round), is not the same version featuring the 80s supergroup Journey that Midway put out in 1983.

[Mr Hudson]

@BIGHMW weren’t you actually on “Starcade” back in the day?

[BIGHMW]

31 minutes ago, Mr Hudson said:

@BIGHMW weren’t you actually on “Starcade” back in the day?

Nope, I was only 17 back then but I DID watch it after it went into syndication and KTLA was airing it in th L.A. market, it was exclusively on SuperStation WTBS before being picked up for syndication.

[Mr Hudson]

@BIGHMW would be cool to bring it back. You could host!

[Mr SQL]

Defender III Gameplay Visual Instructional 

Recently had a chance to post these instructional playthrough videos for Defender III and Defender III Trainer showing how to use the drone weapon to do loop-de-loop maneuvers: 

 

Defender III is even more interesting to play on a classic Television

 

The New Flicker Free 256 Color mode is implemented for classic PAL and NTSC tube Television displays for the Atari 2600 version of Defender III (but not the Trainer version) with extra flicker free colors never seen before on each level. The video somewhat captures it and is more colorful because of the extended palette.