cd-w

You will need to use Stella 3.6.1 or later. Chris

Thanks - I appreciate your efforts to make the game as close to the arcade version as possible. A demo version of Star Castle is going to be available on the AA stand at PRGE, but it will be the older version before your changes. Chris

Do you have the source for timer_test.bas.bin - I'm not completely sure how the calculation is being performed? Chris

Sure: testTIMINT_flawed - both BEFORE and AFTER are 0x00. testTIMINT_withDelay - both BEFORE and AFTER are 0x00, except when the delay is either 0 and 255 when AFTER is 0x80. timer_test - for 1T the values at the bottom are: 00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10 timer_test - for 8T the values at the bottom are: 00, 01, 09, 17, 25, 33, 41, 42, 43, 44, 45 timer_test - for 64T the values at the bottom are: 00, 01, 65, 129, 193, 257, 321, 322, 323, 324, 325 timer_test - for 1024T the screen just turns black and nothing is displayed Chris EDIT: Actually 1024T just takes a while before anything is displayed - the values are: 00, 01, 1025, 2049, 3073, 4097, 00, 00, 00, 00, 00. The last 5 numbers (all 00) are in a different color than normal.

I'm going to be taking a break from Atari 2600 homebrewing for a while due to real-life considerations. I will still be lurking around the forums, but I won't have any time for coding for some time. Fortunately the various projects that I have been involved in are in good hands: Chetiry will be released at the PRGE later this month and will be available in the AA store shortly after. Star Castle is being partially rewritten by Thomas Jentzsch - he has made excellent progress and should have something to show soon. LS_Dracon has made some awesome progress on the PoP sprites recently. Batari will be proceeding with Harmony 2, but neither of us have had any time for it recently. My contributions to project "Bruce" are on hold for now, but it was always going to be a multi-year project. I'll hopefully be back to coding in a year or so, but I don't want to make any promises at this point. Chris

I'm not sure if this is relevant to PAL consoles, but on my PAL Jr the numbers are completely different from Stella: test1: 192246 test2: 64249 test3: 192248 test4: 192245 test5: 192245 Chris

One small feature request - can you add a "blip" sound when an option is changed on the menu screen. Sometimes it can be difficult to be sure the option has actually changed, particularly the color options. I think AUDC=5, AUDF=24, AUDV=8 for a few frames makes a reasonably nice sound. Chris

Good point - I keep forgetting that the ARM in the Harmony doesn't have a divide unit. How about: 1) Dropping the "bonus life" option from the menu and just hard-wiring it to 10K, or making it a feature of the level type (kids=2K, easy=5K, normal=10K, hard=20K). 2) Storing the easter-egg text as non-ASCII? If you have less than 64 letters you could pack 4 characters into every 3 bytes, i.e: AAAAAABB BBBBCCCC CCDDDDDD Chris

The new sound effects are awesome - they complement the game nicely. How about: int HexToBCD(int value) { return ((value / 10) << 4) | (value % 10); } EDIT: I just noticed this function isn't actually used

Looks very impressive! I hadn't heard of the Firebee before. Chris

I'm glad you could save a few more bytes. I can't see any more optimisations without rewriting the code. The main area for optimisation is probably still the menu, as it is taking up a lot of space. It feels like it should be possible to replace most of the menu code with a function like this: void set_menu_option(char *datastream, char *options, int case) { my_memcpy(datastream, options + (case << 4), 4*sizeof(short)); } And you would just call it for each section of the menu: set_menu_option(gMenuOptionsDatastream[MENU_LEVEL_ID], &menu_level_options, MM_LEVEL); However, I'm not sure if this could be made to work for all the different options ... Chris

Some more very small optimisations: 1) saucer_respawn_time could be done as 240-(x*40) 2) Use loops for this code: // make sure we don't conflict with a reposition of Player 1, which takes 2 scanlines if ((gEventBallDataStream[y-1] & 0xA1) == 0xA1) position = -3; if ((gEventBallDataStream[y-2] & 0xA1) == 0xA1) position = -4; if ((gEventBallDataStream[y-3] & 0xA1) == 0xA1) position = -5; // make sure we don't conflict with a reposition of Player 0, which takes 2 scanlines if ((gEventBallDataStream[y-1] & 0xC1) == 0xC1) position = -3; if ((gEventBallDataStream[y-2] & 0xC1) == 0xC1) position = -4; if ((gEventBallDataStream[y-3] & 0xC1) == 0xC1) position = -5; e.g: for (i = 0; i < 3; ++i) { if ((gEventBallDataStream[y-(i+1)] & 0xA1) == 0xA1) position = -(i+3); } 3) Use an inner loop: for(i=0;i<3;i++) { SCORE_PF0L[2+i] = SCORE_PF0L[1]; SCORE_PF0L[7+i] = SCORE_PF0L[6]; SCORE_PF1L[2+i] = SCORE_PF1L[1]; SCORE_PF1L[7+i] = SCORE_PF1L[6]; SCORE_PF2L[2+i] = SCORE_PF2L[1]; SCORE_PF2L[7+i] = SCORE_PF2L[6]; SCORE_PF0R[2+i] = SCORE_PF0R[1]; SCORE_PF0R[7+i] = SCORE_PF0R[6]; SCORE_PF1R[2+i] = SCORE_PF1R[1]; SCORE_PF1R[7+i] = SCORE_PF1R[6]; SCORE_PF2R[2+i] = SCORE_PF2R[1]; SCORE_PF2R[7+i] = SCORE_PF2R[6]; } becomes: for(i=0;i<3;++i) { for (j = 7; j >0; j-=5) { SCORE_PF0L[j+i] = SCORE_PF0L[j-1]; SCORE_PF1L[j+i] = SCORE_PF1L[j-1]; ... } } 4) PF_1_DIGIT_MASK and PF_02_DIGIT_MASK are basically the same values but with 2->1 and 1->2. There must be an optimisation in there but I'm not sure exactly how! Alternatively you could use the upper 4 bits for PF_1_DIGIT_MASK and the lower 4 bits for PF_02_DIGIT_MASK and mask/shift depending on which value you need. Since you are already shifting, the compiler can hopefully optimise without needing more instructions, e.g: (PF_1_DIGIT_MASK[display[1] + i] >> 4) << 5; // compiler optimises to << 1

I couldn't find any large wins this time, but I think you may be able to save some bytes by doing: 1) Moving the shift operation inside the random function, so you would call it like Random32(15): unsigned int Random32( unsigned int mask) { static unsigned int random = 0x02468ace; random = (random >> 1) ^ (unsigned int)(-(random & 1u) & 0xd0000001u); return (random & mask); } 2) Packing the arrays to save bytes, e.g. the values in PF_1_DIGIT_MASK only require 2 bits each to store, so you could pack 16 of them into a single 32-bit integer: 2<<30 | 0 <<28 | 3<<26 .... 1<<4 | 2<<2 | 1<<0 You can then extract the value using a small function, e.g: unsigned char extract_pf1_data(int[] packed, int position) { return (packed[position/16] >> ((position%16) * 2)) & 0x3; } Hopefully the bytes needed to call this function will be less than the number originally used! 3) The vector_three_on array could be calculated (2^(x+3))-(2^x) I think. 4) In the InitSpriteShotDatastreams function - if the queues are contiguous then a single memset could be used to zero all of them? 5) When calling InitShip, the x & y values are always shifted by FRACTION_BITS. You could move this shift inside the function: gSpriteX[player] = x << FRACTION_BITS; gSpriteY[player] = (y- << FRACTION_BITS; 6) In the PrepSpeedRange function, the SPEED_RANGE and SPEED_BASE calculations could be moved inside the loop: for (i=0;i<3;++i) { SPEED_RANGE[i] = (level >> (2-i)) + 4; SPEED_BASE[i] = (level >> (6-i) + base_adjust; ... }

Red for Communism (and also a hint for an upcoming game release)!

Some space optimization suggestions: 1) Make ship_shot_x and ship_shot_y unsigned char arrays, and shift by FRACTION_BITS after loading the value, i.e. (ship_shot_x[direction] << FRACTION_BITS) 2) In the menu, replace the cases with memcpy, e.g: case 1: gMenuOptionsDatastream[MENU_PLAYERS_ID*10 + 0] = OPTION_2PLAYER_1; gMenuOptionsDatastream[MENU_PLAYERS_ID*10 + 1] = OPTION_2PLAYER_B; gMenuOptionsDatastream[MENU_PLAYERS_ID*10 + 2] = OPTION_2PLAYER_A; becomes: static const unsigned short player_options[][3] = {{OPTION_2PLAYER_1, OPTION_2PLAYER_B, OPTION_2PLAYER_A}, {OPTION_2PLAYER_2, OPTION_2PLAYER_B, OPTION_2PLAYER_A}, ...}; my_memcpy(gMenuOptionsDatastream[MENU_PLAYERS_ID*10], player_options[MM_PLAYERS], 3*sizeof(unsigned short)); 3) When loading PF data use a loop instead of expanding every case, e.g: SCORE_PF1L[0] = (PF_1_DIGIT_MASK[display[1] + 0] << 5) + (PF_1_DIGIT_MASK[display[2] + 0] << 3) + (PF_1_DIGIT_MASK[display[3] + 0] << 1) + (PF_1_DIGIT_MASK[display[4] + 0] >> 1); becomes: static const char position[] = {0, 1, 5, 6, 10}; for (i = 0; i < 5; ++i) { SCORE_PF1L[position] = (PF_1_DIGIT_MASK[display[1] + i] << 5) + (PF_1_DIGIT_MASK[display[2] + i] << 3) + (PF_1_DIGIT_MASK[display[3] + i] << 1) + (PF_1_DIGIT_MASK[display[4] + i] >> 1); SCORE_PF2L[position] = (PF_02_DIGIT_MASK[display[4] + i] >> 1) + (PF_02_DIGIT_MASK[display[5] + i] << 1) + (PF_02_DIGIT_MASK[display[6] + i] << 3); SCORE_PF0R[position] = (PF_02_DIGIT_MASK[display[7] + i] << 7); SCORE_PF1R[position] = (PF_1_DIGIT_MASK[display[7] + i] << 7) + (PF_1_DIGIT_MASK[display[8] + i] << 5) + (PF_1_DIGIT_MASK[display[9] + i] << 3) + (PF_1_DIGIT_MASK[display[10] + i] << 1) + (PF_1_DIGIT_MASK[display[11] + i] >> 1); ... } 4) The vector_one_on array is just ^2, i.e. vector_one_on[x] -> (x+1)^2;

The ship warp-in effect and slower explosion look great now.

The warp-in looks good, but I think it needs to be offset slightly as the ship appears to the right of the effect? The fast asteroid explosions look great, but I preferred the slower animation on the ship explosion. Perhaps you could start the ship explosion quickly and have the final frames a bit slower? I can't wait for the arcade sound effects and then this game will be close to a perfect port. Chris

The explosions look awesome - I really like how this game is turning out.

Than would be nice, but I don't think anyone has produced new Atari cases for some time. Curt said something about considering it, and I think Fred (batari) has had managed to make one using Makerbot ...

Got my copy in the UK on Friday - thanks for the speedy shipping Al! It looks and plays great. I played an earlier version at the vgXpo way back in 2005 and I'm pleased to say that it is just as impressive 7 years later! Chris

The ship acceleration feels perfect now. The game looks really nice - the large high-rez rotating sprites are very different for the 2600 (even with ARM assistance). My only complaint now is that the ship explosion looks a bit weak - is there any space for a better effect? I really hope you finish this one and don't get distracted Cheers, Chris

Very nice - I haven't played this for a few weeks. The ship movement is much better now. I think the acceleration could be very slightly faster, but otherwise it feels spot on. Is there much left to do now? Chris

Excellent work from Nathan as always - the game is really coming along great! The only thing I don't like is the movement of the ship. It feels a little bit sluggish in acceleration, and the deceleration seems a little too jerky (when friction is enabled). Would it be possible to tweak this a bit to closer match the arcade version? Chris

The ARM code is just for the bank-switching and high score loading and saving. The game is pure 6502. Chris

Just posted up a new blog entry on my version, in case anyone is wondering what has happened to it. Chris