Jump to content

Recommended Posts

DEFENDER III

post-30777-0-84149900-1488477636_thumb.jpg

 

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 by Mr SQL

Share this post


Link to post
Share on other sites

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 by iesposta

Share this post


Link to post
Share on other sites

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 :P

Edited by DirtyHairy

Share this post


Link to post
Share on other sites

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 :P

 

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 by DirtyHairy

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by DirtyHairy

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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! :)

Share this post


Link to post
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.

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