Jump to content

Nukey Shay

Members
  • Content Count

    21,873
  • Joined

  • Last visited

  • Days Won

    4

Nukey Shay last won the day on July 8 2011

Nukey Shay had the most liked content!

Community Reputation

1,619 Excellent

1 Follower

About Nukey Shay

  • Rank
    Sheik Yerbouti
  • Birthday 03/27/1965

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    The land of Gorch
  • Interests
    Classic gaming

Recent Profile Visitors

56,609 profile views
  1. Your scanner begins at cycle 60 instead of cycle 61...so all the writes to the GR registers are off by 1 cycle. Quick fix: Leading up to the scanner, A is loaded with the value 2 at both F322 and F344. Change the 2 bytes at F344 to be D0 00 instead of A9 02. That new branch will burn the missing cycle (A still holds a 2 from F322).
  2. A robot was programmed to believe that it liked herring sandwiches, and a sandwich was placed in front of it. Whereupon the robot thought to itself, "Ah! A herring sandwich! I like herring sandwiches." It would then bend over and scoop up the sandwich in its scoop, straighten up, and in so doing cause the sandwich to slip straight back off the scoop and fall on to the floor. Whereupon the robot thought to itself, "Ah! A herring sandwich…" Replace the robot with Atari Basic, the herring sandwich with the line of code it is attempting to parse, and the poorly-designed scoop for the combination of = and NOT following one another. No error code generated...it's too busy trying to get ahold of that tasty sandwich.
  3. If X or Y do contain $hex values, you'd need to convert them to decimal before BCD arithmetic. It might be easier to use a conversion table in Rom for such a case. It's wiser just not to use those specific variables for anything BUT decimal mode, so no conversion is necessary.
  4. Variables, Rom data, registers, doesn't matter. They need to contain numeric digits only when being used for BCD. Those that hold values only up to 9 could be safe in certain cases when BCD is not invoked (when it's guaranteed that a carry or borrow isn't going to happen to/from the 1's column in the result).
  5. Not seeing the phantom blips you mentioned (?) Gotta make sure that the radar display loop is NOT crossing a page (0 free cycles here). What bins? I can't find any you posted (I'd have a better understanding of what your games problems are if you did). BTW moving setup code out of the display bank provides enough space to add the city gfx table (208 bytes for 20 pixel version).
  6. Yup...gotta be $hex values only. Decimal mode then treats $00 - $99 as base 10 values 0 - 99. You also cannot use any other method other than ADC and SBC when doing your math (unless you know for a fact that it won't result in a carry or borrow from either column).
  7. Code areas used for spacing to keep branches in check still need editing if the city/stargate options are changed. This edit is stable for displaying the 20pixel city without a stargate: Defendr2.asm Def2.bin
  8. Removing that code provides enough free space to add Defender's full city gfx...just a couple of branch pagecross glitches to iron out.
  9. = and NOT are conflicting comparison operators in such a case. Use ? A = (NOT B) instead.
  10. Stargate disable added to assembly. Also, I used the cycles wasted in the city code to improve player ship visibility. Defendr2.asm
  11. Correction: The code between LD282 and LD2F5 (+ the 2-byte data table LDE15 and the store at LD117).
  12. Look at the code below LD20B...this is the routine that checks which type of object was hit when a collision occurs. If it is object #$10 (stargate), a branch is taken to LD282, which checks if you are still in a lower wave number (<11) and carrying 4 humanoids or more for a level skip. Otherwise, routine LD2B8 sets which area of space to warp (abducted humanoid sections take priority here). The original branch and the code between LD282 and LD2E0 can be erased for a version of the game which does not use a stargate (e.g. Defender).
  13. The bank that the SystemStart exists in is ALL of them. The important thing is whether all banks can reach the "cold start routine" that SystemStart banks to when the 2600 is powered up (bank status is unknown at powerup). Make sure that the address specified by the reset vector ($xFFC and $xFFD) in every bank is indicating the SystemStart address (using the above method, the code that the macro generates needs to exist at the same location in every bank). Have you tried letting Dasm generate a list when you assemble? Use the L switch -l followed by a text file name. You can check that to see if the macro code and system vectors are being placed correctly. If you are unsure, post one.
×
×
  • Create New...