VCS: Space Rocks

[SpiceWare]

Thanks!

I understand - closer to the arcade is why I've been making new ports based on Asteroids and Berzerk. The "just 4 room layouts" of the original 2600 Bezerk was one of the things that always annoyed me (others being just 1 shot for all those robots and that robots were always vertically separated, so explosions couldn't take out other robots). My take creates the 64,000 different rooms using the same technique as the arcade, I go over how that works in this blog entry, as well as corrects those other shortcomings:

http://www.atariage.com/forums/blog/148/entry-8142-there-be-walls/

Those are some nice boxes! The asteroids one shows a way to get the score plus graphically show the extra ship - use the playfield to draw the score. The score wouldn't look as nice as it does now though.



One thing I didn't cover on my decision to use DPC+ and ARM support. Fred Quimby (batari) used a lot of money to develop the Harmony and Melody boards. The stand-alone Melody boards(used to create single stand-alone games) haven't seen a lot of use yet, so he's not recovered his investment. I'm hoping that Space Rocks, Frantic and Stay Frosty 2 will help him recover his investment in the homebrew community.

Yes, there's a sequel to Stay Frosty under development. We ran into some real-life conflicts that caused it to be delayed. It has new objects, power ups (granting new abilities such as throwing of snowballs), new enemies, etc. It also supports multiple buttons via the Genesis gamepad (can still use a standard Atari joystick).

Main Menu
stayfrosty2.bin_56.jpg

Throwing a snowball
stayfrosty2.bin_30.jpg

[MacDLSA]

The drawing you see on the rear side of the Asteroids Arcade box is... Asteroids Arcade itself !
[Asteroids_Arcade_(2005_Eric Schwartz).zip]

Oh ! I thought Mr.Yarusso already sold many melody-based homebrews and/or hacks... but maybe I was wrong !

Well, keep up the honor of the VCS with your great jobs !!!
... and if one day you want a box for your cartridge(s) gimme a whistle !

[igorstellar]

Asteroid !!!!! !!!!

[Dr_Who]

Darrell, first of all some clarification : I don't think that today's programmers who's using DPC and/or Harmony cart, has less programming skills compared with others programmers who's use only the "simple" VCS hardware; indeed DPC/Harmony require more programming competency.

Second, I know very well that in VCS's era the use of bank switching and extra ram, etc…, was a normal way in order to publish a more complex and amazing games; this was the difference between an anonymous software house and the best company on the market : in one word, it was the business difference.

What I said in the previous post, is my point of view concerning the retro-programming scene : I prefer to see more games programmed with the "real" capability of the original machine (al least with DPC) , without the (great) stuff coming form the modern cartridge (Harmony). Simply, this points of view can be shared or not….

As far as the challenge of racing the beam, it's still there. Racing the beam describes the part of the program that draws the screen (it's also known as the Kernel) by updating the TIA (video chip) in real time. The ARM chip cannot talk to the TIA, only the 6507 can, so the limit of 76 cycles of code per scan line still remains. One of the challengest with the kernel is to make it so that you don't have any shearing in the graphics. If you look at the right side of this screen shot of Air Sea Battle, you'll noticed that the background colors are shifted at one point, that's shearing. It can also happen to the sprites and missiles. During the 76 cycles, there's only 22 cycles (during the Horizontal Blank, when the electron beam is moved to the start of the next scan line) in which you can update sprites, missiles, colors and not having shearing occur. 22 cycles isn't very many as, unlike modern CPUs, a single 6507 instruction takes from 2 to 7 cycles.

Of course, everything you say is true , and there are some fixed points : ARM cannot communicate with TIA, the limit of 76 cycles per scan line remains, and racing the beam is still there. But "racing the beam" may be also simplified using ARM or DPC+, as highlighted by Philsan (then I don't know which words are yours or Nathan)

DPC+ adds a "coprocessor" (based on the DPC found in Pitfall 2) that speeds up sprite drawing. It normally takes 18 cycles (per scan line!) to draw a sprite, with DPC+ it takes 5. There's only 76 cycles per scanline, so that's a significant savings.

So, racing the beam is still there, but to pass from 18 cycles to 5 cycles is a great simplification, which allows you to add some more stuff in a single scan line

There's an ARM CPU in the Harmony/Melody cartridge, DPC+ provides a way for the Atari to run ARM code. In a normal Atari game, the 1 MHz 8-bit CPU only gets to spend 27% of it's time processing the game logic as the other 73% is spent drawing the screen. With the Harmony I can call the 70 MHz 32-bit ARM CPU to process the game logic. I can't run the ARM code while the Atari's CPU is drawing the screen, as that's when the ARM is acting like a "coprocessor", but it's a big speed boost.

I know, ARM code can not be processed while 6507 is drawing the screen, and can only assist the cpu when it process the game logic; there is no other way. But Durrell, you know that is not forbid - when possible - to process a small portion of game logic in the video kernel section.

Try to image this scenario : I must draw 4 sprites very close to each other, roughly in the center of the screen; the four sprites must be different in shape (but same dimension) , the pointers are stored in ram , with zero page indirect indexed access in routine (is only an example, take it as is...errors including...):

ldy #8
sta WSYNC
jsr Draw
….
.…
Draw
lda (Pointer_Sprite1),y
tax
lda (Pointer_sprite2),y
stx GRP0
sta GRP1
sleep 10
lda (Pointer_Sprite3),y
tax
lda (Pointer_sprite4),y
stx GRP0
sta GRP1
sta WSYNC
dey
bne Draw
rts

Now, image that I must move the value of pointers stored in ram into another portion of ram , need for processing the next frame , and - for whatever reason - that I have not enough free space or free cycles in the logic game section in oder to do the job , so I decide to do it in the video kernel section (usually movement operations involving ram are done in logic section)

.…
Draw
lda (Pointer_Sprite1),y
tax
lda (Pointer_sprite2),y
stx GRP0
sta GRP1
sleep 10
lda (Pointer_Sprite3),y
tax
lda (Pointer_sprite4),y
stx GRP0
sta GRP1
	lda Pointer_Sprite1,y
	sta OldValue_Sprite1,y
	lda Pointer_Sprite2,y
	sta OldValue_Sprite2,y.....
sta WSYNC
dey
bne Draw
rts

The result is that is very difficult , or impossible , to insert additional code , for example managed the code for showing a missile in the next scan line.
Is also obvious that if you have an ARM, this could provide for operation of moving - quickly and efficiently - the values stored in ram in the logic game section , freeing space in video kernel. In other words, having an ARM could have a positive impact also in the optimization of the kernel. Not more, not less...

Others considerations in the example above: you know Darrell , that if I need to move horizontally all these sprites together , I need to change the "Sleep" value (indeed not only sleep value, but also instruction with 3 machine cycle if needed, and so on...) in order to maintain the correct spacing between the sprites ; this is really what I mean for racing the beam, often the most misused term, imho...

Last but not least, I've posted my ideas concerning DPC/Harmony in the tread of Space Rocks, just because they are mentioned; indeed I have nothing against you or Space Rocks

Regards, Mirko

[SpiceWare]

Darrell, first of all some clarification : I don't think that today's programmers who's using DPC and/or Harmony cart, has less programming skills compared with others programmers who's use only the "simple" VCS hardware; indeed DPC/Harmony require more programming competency.

No worries - I understand your viewpoint and did not take it as a slight in any way. There are a number of people who hold that same viewpoint, so I just wanted to explain why I did not feel the same way.

So, racing the beam is still there, but to pass from 18 cycles to 5 cycles is a great simplification, which allows you to add some more stuff in a single scan line

That it is, though 18 is the "usual" routine. When I wrote Stay Frosty I was able to get that down to 13 cycles by using a mask:

   LDA (SpritePtr),y  ; 5
   AND (SpriteMask),y ; 5
   STA GRP0           ; 3

The mask is a bunch of $00 in ROM surrounding a number of $FF in the middle(the number being the height of the sprite).


Back in 82, Commodore(!) did the same thing we are doing with the Harmony and built a "computer in a cartridge" that worked hand-in-hand with the 2600 to turn it into a personal computer. They demoed it to Atari and it became the basis for the unreleased Graduate. Even more impressive, they were able to drop TIA updates down to just 3 cycles so you could do the following:

http://www.atarimuseum.com/videogames/consoles/2600/a3000.html

  STA GRP0   ; 3
  STA GRP1   ; 3
  STA COLUP0 ; 3
  STA COLUP1 ; 3
...

Page 28 of the design notes for the Graduate shows how they figured out the timing to "BUS STUFF" - the cartridge overrides the data bus, thus controlling the value that gets written to the TIA registers.

http://www.atarimuseum.com/archives/pdf/videogames/2600/graduate_design_notes.pdf

Supercat, in the private Harmony development forum at AtariAge, did a Harmony demo using bus stuffing to display this:
bus master.jpg

If you're interested, here's a public discussion about bus stuffing over at AA.

http://www.atariage.com/forums/topic/183085-bus-stuffing-like-the-graduate/

But Durrell, you know that is not forbid - when possible - to process a small portion of game logic in the video kernel section.

Of course, I did that in Stay Frosty. Each platform defines a "zone". After the last scan line of a platform is drawn, some prep work is done to start the next zone. Likewise when displaying the menu in Medieval Mayhem, after each option is displayed it needs to figure out if it's at the end (as the menu scrolls up and down). If not, it deciphers and preps to display the next option and value.

The "been there, done that" is part of why I've been interested in utilizing the Harmony. I plan to work on the ColecoVision after finishing Space Rocks, Frantic and Stay Frosty 2.

http://www.atariage.com/forums/blog/blog-148/cat-115-colecovision

CV.jpg

[Dr_Who]

Thanks Darrell, as always you are a mine of information.
As soon as I will have some spare time, I'll read the info about the Graduate , looks very interesting (who gave the names Fred, Wilma and Pebbles is a genius )

BTW, more I try to understand the Atari 2600, more I realize that - except a few key points - there's not a single way to program this machine, but you're forced to "think out of box" ...probably no other console has this characteristic .



P.S. You've a PM

[SpiceWare]

who gave the names Fred, Wilma and Pebbles is a genius

That's very common in IT. One place I worked had two Wang VS systems named Tom and Jerry. Another place had two AS/400 systems named Abbott and Costello. In each case one system was for development, the other for production.

except a few key points - there's not a single way to program this machine, but you're forced to "think out of box" ...probably no other console has this characteristic .

Yep, that's what makes in fun

P.S. You've a PM

I think this mean's you're full:

Si sono verificati i seguenti errori con il tuo invio
Dr_Who ha superato la sua quota di messaggi privati e non può ricevere ulteriori messaggi finché non libera un po' di spazio.

[SpiceWare]

I do plan to look into showing the remaining ships graphically instead of numerically.

Probably not going to do it graphically after all. Omegamatrix at Atari Age posted this slick kernel idea that I'm currently working on incorporating into Space Rocks.

Two Scores2.jpg

This kernel will let me show a 6 digit score and a 1 digit lives remaining for both players without using any flicker. This method works by simulating 7 segment displays where segments are turned on/off to show each digit. The sprites and missiles are arranged to always show 8 888888 888888 8. The playfield is set to have priority over the sprites (so the sprites hide behind the playfield). The playfield pixels are turned on to "hide" the disabled LED segments. By using the playfield to control the digits, TIA only has to be updated 6 times. If you had to update each sprite by itself, that would take 14 TIA updates.

[SpiceWare]

This is what it looks like so far.

spacerocks.265.jpg

Is there a way to disable the JPG conversion for image attachments? I uploaded a 640x240 PNG that was 1.9 KB. As a JPG it's been shrunk down to 427x280, yet takes up 7.8 KB (a 4 times bigger file size ). The JPG looks significantly worse than my original PNG (which you can see here at AtariAge).

[Dr_Who]

In my opinion: there're already so many objects on the screen (luckly!), and I think that to show both players's score , may create too mess...it's my feeling...I think that only one score could be enough.
If you have max 3 "lives", I guess that you can easily do a graphic indication of the ramaining ships using "missile0" or missile1" or "ball", playing with their size (4 clocks/8 clocks) - more or less like I done with Ufo Attack - , arranged on vertical strip , instead of horizontal.

XXXX                                                        (ML0/ML1/BL 4 clocks size)
XXXXXXXX                                                 (8 clocks size)
XXXX                                                        (4 clocks size)
                                                               (ML0/ML1/BL disable)
XXXX
XXXXXXXX
XXXX

XXXX
XXXXXXXX
XXXX

Hope you don't

[SpiceWare]

Hope you don't

If I was only going to support alternating 2-player games, then showing just 1 score at a time would be fine. However, I'm planning to have at least 2 game variations where both players play at the same time. Because of that, I think it would be best if both scores were visible.

[SpiceWare]

Builds with the new score kernel have been posted.

http://www.atariage.com/forums/blog/148/entry-9156-new-scorelives-kernel/

[SpiceWare]

new build with 2 player support

http://www.atariage.com/forums/blog/148/entry-9204-2-player/

[SpiceWare]

new build with ship improvements

http://www.atariage.com/forums/blog/148/entry-9210-ship-revisions/

[MacDLSA]

Hi Darrell.
!!! great improvements, as always !!!

Heh, I did not take the "role of bugfinder" since the Daphne Team's Dragon's Lair-Italian version years...
_Well, I set the game in b/w vector mode and I saw when the asteroids are on an "intermediate" size they became "solid", as you can see in the pic above
spacerocks20120611_NTSC.bin.jpg
_It also would be nice to add some "smoothing" to the ship when it is in "vertical" positions, but I think that all the pixels around are already "took" .
_What about adding the original "thumping" bng sound "BOOO-boo-BOOO-boo..." ?
_All the other things are really great, except of game's speed...
You know, as I already said, I think that speed has a huge matter in the original Asteroids' gameplay...