AtariAge Forums Community Blog List http://www.atariage.com/forums/index.php?app=blog Community Blog List Syndication Fri, 20 Nov 2009 18:21:28 +0000 editor@atariage.com (AtariAge Forums) IP.Blog 60 <![CDATA[HatNJ's Blog - My 1st Entry]]> Im on here all the time so might as well use the goodies]]> Fri, 20 Nov 2009 17:59:00 +0000 Planet Bob - Playing Return of the Jedi (C64)
What, no vectors?!? :o

Posted Image

Well, Atari probably figured that they wouldn't get away with yet another recycling of the old Star Wars vector coin-ops, so they returned to more common raster grahpics to finish the Trilogy.

Of course I choose the C64 version. And it's horrible. I kinda understood the poor C64 versions of the vector games, but delivering such a mess for RotJ is insulting the unstoppable 8-Bit juggernaut. The C64 definitely can do a much better job at some diagonal scrolling sprite game!

Everything looks rushed, from graphics to sonics - and partially it's just buggy! On the surface the gameplay is there: You get the Endor part, the Deathstar destruction and from the 2nd round onwards also the alternating walker / space shooting parts.

The fun from the Arcade (or the 16-Bit conversions) is almost gone though. The collision detection is flawed, there's no noticable enemy AI, the graphics seem to stutter and the animation is choppy. It kinda feels like a prototype: All required elements were quickly thrown into the game and then they just shipped it, without bothering much about a polishing phase or even some more beta testing...

It's pretty short - so the torture ended fast. Just like the other games of the series, the 4 phases repeat just over and over again, with only little changes from the second round onwards.

Some future day the "Playing..." series may see another Atari Arcade conversion in the form of "Blasteroids", but first it'll continue with something else.

Greetings,
Manuel]]> Thu, 19 Nov 2009 21:51:00 +0000 <![CDATA[Mord's Blog - Maze Realms (v0.020)]]>

In this version I've redone the status bar. In this game the only things it will need is the player's magic/power bar, so I've removed the extra things. The color of the status bar (the blue part) will actually serve a purpose to indicate to the player when they step into a magic field. I'll be changing the default color to probably a gray color to indicate the absence of a magic field. This will be a function of room AI which I will be adding in a bit later. Also, I backported the cycle 73 HMOVE code I wrote for the new Action RPG code base which allows me to pull off the status bar's repositioning without the ugly h-bars. :) One sprite is repositioned right before the start of the power bar, the second is repositioned immediately following it. I do notice the gate of the castle seems to be moved. I don't recall changing it's coordinates in the init code so I'm guessing there's an issue with using the cycle 73 code. I'll look into that more and hopefully have it figured out and fixed by the next version.

The status bar overall is vertically more compact because of these changes. This means the game field can be larger, which is something I've been meaning to do since before v0.018.

Otherwise, all the other changes in the code are are speed optimizations. In some cases I only trimmed a few cycles off. In others I found entirely different ways to do things or realized a couple things were entirely pointless! (I use to zero both hardware sprites at the end of each frame up until now. Not necessary since if I just point their ItemSlot to FF, the code assumes they're empty.)

I'm not entirely sure what I'm going to do in the next version. It's a toss up between re-adjusting/re-naming the item slots or redoing the room loader. Either of those two options will probably be time consuming.

Attached Image
]]> Thu, 19 Nov 2009 16:02:00 +0000 The Southsider - New PoP Kernel Atari 2600 PoP project again now that the Harmony software is essentially done. I am making no promises on getting it finished, but I intend to do a bit more work on it to see where it goes. At the very least, I want to include the excellent sprites that LS_Dracon has produced. The first thing that I have done is to completely rewrite the kernel:

Attached Image


From the screen-shot, it looks almost identical to the old kernel, but there are two important differences.
  • The old kernel had only a single ball sprite for the sword, which I intended to flicker between the player and guard. The new kernel displays separate missile sprites for the player and guard, and so it can display the swords flicker-free.
  • The old kernel had blank lines for repositioning above and below the floors. The new kernel displays the playfield without any gaps at all.

This new PoP kernel is probably the most complex Atari 2600 kernel that I have written so far. It doesn't use any self-modifying code or extra RAM, yet it displays an asymmetric playfield with two player and two missile sprites in full colour (glitch-free). It also uses my favourite mid-kernel repositioning trick to display the playfield without any gaps. Note that both the player1 and missile1 sprite are repositioned mid-kernel. The only restriction is that the player missile sprite can't be drawn on the same lines as the floor, but we probably don't need the missile on these lines anyway.

I have attached the binary and source for the new kernel. You can move the player (no animation) with Joystick 0, the guard with Joystick 1 (keys G & J on Stella), and change the playfield colours with Fire.

The next step is to merge this kernel with the previous PoP code. I will probably also convert the game from Supercharger format to another bankswitching type. The Supercharger 6K format is quite limited, and the Harmony cart can now support many other types.

Chris

Attached File  kernel.bin (4K)
Number of downloads: 15
Attached File  newpopsrc.zip (13.49K)
Number of downloads: 6]]> Thu, 19 Nov 2009 08:22:00 +0000 <![CDATA[atari2600land's Blog - Fun with Tetris]]> here's a link to the latest version (as of 11/18/09.) I'm getting a little sick of Tetris, though, after playing the NES and Game Boy versions for research/inspiration. But nevertheless, I will press on working on my 2600tris. A couple of people are downloading each version, and I want them to tell me what they think of it. Now if you excuse me, I must go and not play Tetris any more today. ;)]]> Thu, 19 Nov 2009 02:00:00 +0000 <![CDATA[Robin Gravel's Blog - Naturette 10th anniversary]]>
In 1999, the game Naturette was released.

I made a little flash for Naturette 10th anniversary.

http://robingravel.c...om/rette10e.htm


WARNING: THIS MOVIE CONTAINS NUDE PEOPLE OF ALL AGES.

Please check my old topics for more information about Naturette games.


Enjoy


Robin Gravel

Edited: the link is fixed.]]> Tue, 17 Nov 2009 23:50:00 +0000 <![CDATA[DanBoris' Tech Blog - CARD Math Part 2]]>
Here is the Action! program and it’s dis-assembly:

CARD I

PROC MAIN()
I=2
I=I+2
RETURN


0E6C: .BYTE 00,00
0E6E: 4C 71 0E    JMP  $0E71      

;I=2
0E71: A0 00       LDY  #$00     
0E73: 8C 6D 0E    STY  $0E6D      
0E76: A9 02       LDA  #$02     
0E78: 8D 6C 0E    STA  $0E6C    

;I=I+2  
0E7B: 18          CLC        
0E7C: AD 6C 0E    LDA  $0E6C      
0E7F: 69 02       ADC  #$02     
0E81: 8D 6C 0E    STA  $0E6C      
0E84: AD 6D 0E    LDA  $0E6D      
0E87: 69 00       ADC  #$00     
0E89: 8D 6D 0E    STA  $0E6D      
0E8C: 60          RTS


Most of what is here we have discussed before so I won’t go into great detail. As you can see since I is initialized to the value 2 the INY optimization can’t be used so two loads and stores are performed. It’s interesting to note that a different register is used for each byte. I am not sure why the compiler chooses to do this, although in the end it doesn’t affect program size or performance.

The add part of the program is standard 6502 16-bit math, adding the lower byte, then adding the upper byte which also handles and carry from the lower byte.]]> Tue, 17 Nov 2009 21:15:00 +0000 (Insert stupid Blog name here) - Homebreviews index - part 3
Reviews added since the last index are labeled New. All reviews are for Atari 2600 homebrews, unless otherwise noted.

5/5
4/5
3/5
2/5
1/5
]]> Tue, 17 Nov 2009 10:35:00 +0000 Bubsy Bobcat Fan Blog - Mr. Batty Works - Bubsy Fan Art
Or maybe this was a site of artists.. anyway...

http://nsider2.com/forums/index.php?showtopic=432917&st=0

Attached Image]]> Tue, 17 Nov 2009 02:38:00 +0000 <![CDATA[EricBall's Tech Projects - Propeller breaks the space time continuum]]>
The Propeller is different from most processors in there are no dedicated ALU registers. Instead, any 32 bit entry in processor RAM may be used as a register. Thus processor RAM can be looked at as a 512 entry register file. Or 496 instructions (16 of the registers are dedicated to I/O), with each instruction taking a single register. Or 496 32 bit data values. It is even possible (and sometimes necessary) to modify an instruction using ALU operations.

In the program I'm working on, I've programmed two 16.16 x 0.16 fixed point multiplies; multiplying one value twice (by cos & sin). In pseudo code:
  frac = fixed & 0xFFFF
  int  = fixed >> 16
  frac_cos = cos * frac
  int_cos  = cos * int
/* because the algorithm destroys the inputs, they must be reloaded */
  frac = fixed & 0xFFFF
  int  = fixed >> 16
  frac_sin = sin * frac
  int_sin  = sin * int

Now, in a normal speed optimization, you'd look and see that the same value is being calculated twice. So to speed things up, you save the value (more space) so the calculations don't have to be done again. But in PASM this sometimes doesn't save any time and ends up taking additional space!
  mov  frac, fixed       // frac = fixed
  and  frac, H0000FFFFF  // frac &= 0xFFFF   H0000FFFF is a register which has the appropriate value preset
  mov  sav_frac, frac    // sav_frac = frac  save the value in a temporary register
...
  mov  frac, sav_frac    // reload value

As you can see, calculating the value requires 2 instructions. Saving the value requires 1 additional instruction, and the reload is an instruction. So calculating the value requires the same number of instructions as save+reload, but the save+reload requires an extra register (sav_frac). So save+reload isn't any faster and requires more space!

Obviously this is a simple example which only required one instruction to calculate each value. But the converse is also true. In another part of the program I am finding it's better to maintain additional variables rather than calculating the necessary value from the loop counters.]]> Mon, 16 Nov 2009 19:23:00 +0000