Re-visiting Defender...

[+Trebor]

6 hours ago, PacManPlus said:

The reality now is (most likely) that more people will have the AtariVox than the XM or HSC at this point. ? The AtariVox is still being made, but the HSC, CCII, and possibly the XMs aren't.

FWIW, High Score Cart saving works under MiSTer FPGA as well.

 

Between owning a Concerto and an AtariVox+, I'm happy either way. 

 

I know you utilize Assembly (Maybe some C(+)), Bob; however, perhaps worth mentioning, 7800basic by default saves to both HSC and AtariVox/Savekey devices once set hssupport $#### is utilized. 

 

Completely speaking from the Peanut Gallery perspective, I don't believe being able to save to both devices, instead of only one type, should take up a noticeable amount of space difference as a result.  But humbly admit my nearly complete ignorance here and leave it to the programming gods. 

[tep392]

Hey @RevEng Are those 7800basic routines posted somewhere for us hardcore assembly programmers to use in our games?

I will have the need to save to both HSC/Atarivox in my next game.  I don't intend to use the HSC routines and will only need to save/load the scores and initials.

[RevEng]

For sure. The 7800basic github would be a good place to start...

 

The hiscore.asm file has the upper level hi-score table load/save. The link will bring you directly to the bits you're probably most interested in. The code earlier in the file is involved in the hiscore display and controls.

The 7800vox.asm has some convenience functions. (reading a series of bytes, writing a series of bytes to the vox, and detecting a vox)

i2c7800.inc is the low-level avox serial eeprom driver written by Alex Herbert, and minimally tweaked by me.

 

Instead of using regular atarivox eeproms per-game allocations, the driver uses a chunk of memory that Al put aside for the 7800, so we can use it like an HSC. i.e. the driver will search that chunk of memory for the game's ID+difficulty when loading/saving.

[Defender_2600]

Hi Bob, I'm glad you're back on Defender in 320 mode, it looks fantastic!

[Lord Thag]

This is probably my #1 most wanted 7800 port. Awesome. Can't wait to see how it turns out.

[Eagle]

https://github.com/r41n60w/planetoid-disasm

https://github.com/mikroman/planet/tree/Relocatable

 

 

[PacManPlus]

Hi guys:

 

So I did a stupid thing.

As you all know, Defender has a 'planet' which is far wider than the screen.  Everything happens on the entire planet, whether or not the current 'window' position (i.e. the screen) is showing it or not.  There's no hard scrolling (like SMB or Bentley Bear, or Scramble for that matter - forced in a direction)...  The planet wraps around, in either direction.  The screen is just a 'section' of that planet.

 

Why state the obvious?  Because I worked on the screen (window) first... putting the enemies in the attract mode, etc...  Once I started working on the planet itself, I found that I'm putting 'band-aids' with regard to how the enemies are handled on/off the screen.

 

It's clear to me now I should have started with the planet placing the enemies and not the 'window'.   

 

So, I'll need to start a good portion of this over again, for the third time. ? 

 

 

I know, kind of a rookie mistake; you'd never know that I've been doing this for almost 20 years now. ?

Edited November 23, 2021 by PacManPlus

[Goochman]

Ah bummer - but hey better to have caught now vs later!  Id take the Thanksgiving weekend off and enjoy time with family - maybe in your Turkey coma you'll have a breakthrough thought

[+DrVenkman]

35 minutes ago, PacManPlus said:

So I did a stupid thing.

You’ve done so many amazing things that it ultimately doesn’t matter.

 

I’m certain the new insight will ultimate help produce an amazing result. In the meantime, load up on tryptophan, enjoy some time with family or friends for awhile. You’ve earned it. 

[Yurkie]

1 hour ago, PacManPlus said:

Hi guys:

 

So I did a stupid thing.

As you all know, Defender has a 'planet' which is far wider than the screen.  Everything happens on the entire planet, whether or not the current 'window' position (i.e. the screen) is showing it or not.  There's no hard scrolling (like SMB or Bentley Bear, or Scramble for that matter - forced in a direction)...  The planet wraps around, in either direction.  The screen is just a 'section' of that planet.

 

Why state the obvious?  Because I worked on the screen (window) first... putting the enemies in the attract mode, etc...  Once I started working on the planet itself, I found that I'm putting 'band-aids' with regard to how the enemies are handled on/off the screen.

 

It's clear to me now I should have started with the planet placing the enemies and not the 'window'.   

 

So, I'll need to start a good portion of this over again, for the third time. ? 

 

 

I know, kind of a rookie mistake; you'd never know that I've been doing this for almost 20 years now. ?

Even as awesome as you are , you still make mistakes. ? 

[+cjherr]

For all you do for this community, step away, relax, have fun with your family, enjoy the holiday, and don't worry about Defender for a while. It will be what (and when) it will be. Happy holidays!

[desiv]

2 hours ago, PacManPlus said:

I know, kind of a rookie mistake; you'd never know that I've been doing this for almost 20 years now. ?

Good thing I don't ever do that at work...

<my staff laughing hysterically in the background>

OK, well sometimes...  Infrequently, it can

<more laughing>

SHUT UP!!!

 

[RevEng]

3 hours ago, PacManPlus said:

I know, kind of a rookie mistake; you'd never know that I've been doing this for almost 20 years now. ?

Each game is a new problem landscape, and iteration of the approach is going to happen as you learn the terrain. This is doubly true for arcade conversions, where you're striving to match the arcade experience on dissimilar hardware, and usually starting with a naive barebones test to ensure the display will work as intended.

 

If you didn't make bad turns in your designs, it would mean you're doing the same kind of game over and over again.

 

[mimo]

so I'm guessing it's *STILL* not finished ?

[+Karl G]

Yeah; I think of code-rewriting as a normal part of the game development process. Although I can get frustrated sometimes when I have to rewrite code, I'm often left with a good feeling after I've done so ("Gosh, this is much less ugly than the way I was doing it before!").

[nadir]

9 hours ago, PacManPlus said:

I know, kind of a rookie mistake; you'd never know that I've been doing this for almost 20 years now. ?

I get it.  I've been a professional programmer for 25 years and I can still totally botch a first round coding test interview.  Sigh.  Writes complex business algorithm one day, next day can't do a simple join/split example...

[+swlovinist]

You have our support Bob!   We will wait and encourage you from the sidelines!   You are an amazing programmer and I know that you take pride in creating your games.   Thank you so much for sharing your progress with us.  

[Zonie]

Many thanks for this awesome project.

 

[Defender_2600]

On 11/16/2021 at 2:47 PM, PacManPlus said:

I started from scratch as I wanted to use 320B mode and I had an idea for the terrain (use 320A mode for that).

 

Hey Bob,

 

I was thinking that using 320A mode for the terrain then in that area it will not be possible to use 320B mode for sprites. However, since you are using 320B mode for sprites, it is possible to use 320D mode for the terrain.

 

The 320D mode has the advantage of being 1bpp (as 320A) and, for the terrain, it can be used (without combination restrictions) for momochromatic sprites / tiles, *only* with color C2 (PO C2 and P4 C2).

 

320D 1bpp can also be used for the star field for which you can use the colors C2 and C3, so for the stars you have 4 colors available from two palettes (320D and 320B share the same PO and P4 palettes).

 

 

 

 

 

 

Edited December 6, 2021 by Defender_2600

[PacManPlus]

Hey Marco!

Thank you!

 

With that one, I'll have to see.  Right now, I'm only scrolling that last 8 zones (the ones that have the terrain in them).  Trying to save cycles ahead of time, as I know with the amount of enemies/shots on the screen and the things going on off-screen,  I'm going to need them.

 

When all of the enemy/shot movement is done, I'll revisit this and see what I can do.  I need to revisit the flashing color as well, so it matches the arcade.

 

Having said that, I was finally able to get the scanner done (also in 320A mode because of memory... but there will be different colors for the different enemies), and the enemies on the planet to reflect in the scanner (so there will be a WIP milestone video soon).

 

Bob

Edited December 6, 2021 by PacManPlus

[PacManPlus]

As mentioned, new video

 

 

[+cjherr]

Looks brilliant as usual, Bob!

[+sramirez2008]

The scanner and functionality look great?  

[BIGHMW]

Absolutely gorgeous!!! Beats my 5200 version and that in itself was great too.

[Goochman]

I never understood why Atari never applied this level of attention to detail in their conversions.  Defender probably wouldve been a nice addition to the 7800 even though it was an older title.  It didnt see alot of console release.