Jump to content

rallyrabbit

New Members
  • Content Count

    56
  • Joined

  • Last visited

Everything posted by rallyrabbit

  1. Oooo the problem was my coding, optimized some code and calculated cycles and current scanline wrong. So that's good, now back to testing and looking at the last city change.
  2. So far no dice, comparing code back to the point that it worked to see what I changed that lead to this
  3. As soon as I get done with housework, I'll go into the symbol file and start looking at the paging. The end of my radar code is (which uses for previous bit but retains some of what I was doing to get the bottom bar). I would say you are probably right about paging since this code caused one of the above branches to fail (too long)..... LF360: STA WSYNC ;3 LDX #$F0 ;2 PF0 makes radar to the entire screen STX PF0 ;3 LDX #$FF ;2 give to an unused register to save for PF2 next line STX PF1 ;3 LDA #$83 ;2 sides+the tab in the lower center of the radar STA PF2 ;3 STA WSYNC ;3 JSR LF92E ;6 looks like it is designed to waste cycles STX PF2 ;3 JSR LF92E ;6 looks like it is designed to waste cycles LDX #$03 ;2 NOP ;2 NOP ;2 @55 STA ENABL ;3 STA VDELP1 ;3 STA NUSIZ0 ;3 STA NUSIZ1 ;3 @67 CLC ;2 @69 STA PF2 ;3 STA PF1 ;3 @75 STA PF0 ;3 BCC LF3A2 ;2 always branch to update game area I will say when I use your code only in my file, it does not seem to have the radar glitch as often (rarely), this is your code for the same bit: LF360: DEY ;2 16/21/26/31/36/41/46/51/56 BNE LF360 ;2 19/24/29/34/39/44/49/54/58 STA ENABL ;3 61 STA VDELP1 ;3 64 STA NUSIZ0 ;3 67 STA NUSIZ1 ;3 70 LDA #$7E ;2 72 STA PF2-2,X ;4 00 INX ;2 BNE LF3A2 ;3 LF395: JMP LF553 ;3 You're looping rather than me trying to force things with the timing (like the original code did) Here's my latest... which is still not 100% what i want because I am still dealing with the radar issue. Something else I noticed as soon as I put in your radar code vs the old radar code I was using is the fact that the ship goes up to the top of the play area but the ship image (and enemy images) get cut off. This should me Roughly speaking, here's the changes I made and some info on it: 1) Title Screen (part of design espire did for Defender Arcade that was not adopted) 2) End of Wave Screen changed 3) Firebomber changed into Atari 2600 Defender Bomber 4) Lander changed into Atari 2600 Lander 5) Mutant changed into Atari 2600 Mutant 6) Big Red changed into Atari 2600 Baiter 7) Phred changed into a Atari 2600 Baiter that shoots Removed Bonus/dogfight Stages 9) Score digits are the digits used in Atari 2600 Defender 10) Removed Inviso 11) Radar changed to look like Atari 2600 Defender in color, border now takes up the full screen 12) Graphics for Extra Ships and Smart Bombs changed to a vector format 13) Scoring for pods is now 1000 points 14) Ship was changed (not like Stargate or Atari 2600 Defender) 15) Bonus for people at end of stage is 100 points 16) City added instead of mountains when planet is not destroyed (to give a look and feel more like Atari 2600 Defender) (Nukey Shay) 17) Removed Hypersace risk of exploding and losing the ship 18) Hypersapce can be used with Player 1 fire button while at the top of the playing area and pushing up while firing. There is no limit on hyperspace. NOTE: When a Hyperspace is used successfully, the ship will not fire a laser. NOTE: When a person is abducted, hyperspace can be used to jump to the abduction (like the old startgate worked previously) 19) Smart Bombs can be used from player 1 fire button when at the bottom of the city or space area if planet destroyed). NOTE: People in the city can still be shot if at the level to use smartbomb. NOTE: When a Smart Bomb is used successfully, the ship will not fire a laser. 20) Removed Munchie, Phred, Yllabian Space Guppy as eneoies 21) Sounds of enemies shooting has been changed to be more similar to Atari 2600 Defender 22) Removed the platforms under the people when planet isn't detroyed 23) The color of the people on the planet matches Defender Arcade 24) Scoring for picking up falling people is not cumulative increasing, it is a standard 500 points 25) Stargate is no longer in the play area or the scanner 26) Retained and use the dynamo that comes out in attack 2 of waves 27) First attack of each wave contains Landers, Dynamo, Bombers with Pods (after wave 5) 28) Second attack of each wave contains Baiters that do not shoot, Bombers and Landers 29) Baiters that can shoot are introduced singly after lengths of failing to end the wave after the second attack occurs 30) Wave multiplier for increasing enemy speed is slowed down by half to get better longer game play out of a typical game (one of the big complaints of defender II/stargate/defender arcade is how short the games are because it is too hard). 31) End of wave "person" bonus text now doesn't look goofy (it actually flows with the rest of the text) 32) Only the Dynamo and POD remain as they were in Defender II/Stargate. All other images are "static" (all 4 graphics represent the same graphic). I still have the options for no hits, invincible, etc on for debugging, I also have not removed the original stargate code as I use it to test with occasionally. defender city v16.bin
  4. Unfortunately I didn't remove that code.... I just repurposed it elsewhere for a different function. I currently have 130 bytes free in bank 0 and maybe 80 bytes free in bank 1 - that's with me still trying to out my radar glitch.... On a side note, in both yours and in mine, I am finding a lot of radar glitches. Lots of phantom blips showing up from time to time. I'm trying to deal with that tonight. You may have seen from my bins that I am trying to go with a full solid bar side to side below the radar. so when I actually set PF0 (0xF0), PF1 (0xFF), PF2 (0x83) and back to 0x00 for all three at the end of the radar update before updating the scanlines for the playing area - it tends to get worse. This all of course is being done in the area around LF360
  5. You're right, the code is actually LD2B8 to LD2F5 that is the core of the gating, where LD282 to LD2B8 is actually just deciding special circumstances. Cool.
  6. IT's weird, I traced it down to that too, but that code is not doing what I thought it would be doing.....
  7. Do you happen to know where the Stargate code is for when the player hits a stargate. I have an idea.
  8. Man! Been working on isolating that glitch for the past two hours... that's that I guess, thanks. I got a lot of the other final stuff in, scoring, enemy tables for the various waves, title screen, graphics as I want them, removing more dead code, changed how hyperspace and smart bombs work to get it back to one controlled game play etc.
  9. Not sure if that is giving me what I wanted. Playing around with it a bit....
  10. Not sure I am following completely here. So take this bit: F407: ;66 LDA #$FF ;2 68 .byte $2C ;4 72 What's the different in this and: F407: ;66 LDA #$FF ;2 68 NOP NOP (as many NOPs to get the same spacing in ROM)
  11. Sir this is incredible. I was trying to use a single graphics set and bit shift may way through it, which was taking way too many cycles. I had to free up enough contiguous space, but this is way more optimized. I also was kicking off the draw by doing the framecounter & 0x01 to lead to a branch, where the LSR and Branch actually saves a cycle. So, I need to clean up the graphics I want to use and test a bit and add in some other play code that I want to implement that is pretty straight forward. This leads into the last question, do you know where the game scales the speed of the enemies based on the current playing wave?
  12. I think I found a problem and worked out a solution for a slight glitch in your demo routine. If the Index Y enters the city routine at 0x1, it'll decrement to 0xFF in the routine and general either cause an overflow in the screen (TIA) control or jumps into non-code area abnormally (depends). I solved that, but seems that you fixed it as well. So, cool either way. One question on some syntax you use: LF407: ;66 LDA #$FF ;2 68 .byte $2C ;4 72 LF400: ;58 LDA (object_color_vector),Y ;5 63 The line ".byte $2C" On the surface this looks like RAM storage space. But, on execution from the LDA to the LDA for the color, $2C seems to be intrepretted as an opcode (instruction) but stella jumps over it. WHat's this syntax instructing to do here?
  13. I worked out that problem. I am still having some issues. I didn't adopt your change to the planet_state and planet_vector, so I am having some trouble living with what I adopted. That's my next hurtle before I start trying to plan out the rest of the changes. Your City routine is interesting, it wasn't the way I was going to approach it, but gosh, yours is way more optimized than what I sketched out. Back to work, hope to have something a bit more ready next week.
  14. I wasn't assembling with -f3. Strip out those two bytes and it was ok. All right. I am not sure I 100% get all your changes just yet, but it used the bulk of how you were doing the Draw City routine and how to call it and where to jump out. I smoothed it a bit with a different algorithm off the frame counter to make the flickering a little faster (every other frame). I used the byte for the inviso units for the pointer. But I retained all the planet state and planet vector that existed before (that's part of what I don't quite get in what you did). I was having the data from PF0/1/2 bleed through to the top of the next frame. So I cleared PF0/1/2 at the end of LF53B before it switches to bank 0 after a frame is complete. Now, one oddball thing I cannot figure out is that your code, the humans can survive when the ship flies (scrolling) left to right. In my, the humans get detroyed when they hit a building. I am not entirely sure why, that's what I've been debugging for the past two days. Then I have a code exception on planet destruction that I have to work out too, but I think I know what that problem is.
  15. Oh my, this is news. And actually changes my approach. This is exactly why I've been looking for schematics and stuff what replacements to see what to do. None of the new homebrew cartridges are 4k, so people are doing this somehow. Defender Arcade is a prime example (F8SC), so obviously others have done this..... how? So, either use that from a Stargate or Defender Cart? What do new homebrew people use here? Update, I just read about the Melody Board.... maybe that is the right path? I'd never heard of the Harmony until I ran across it yesterday, which then lead me to the Uno. SO thanks for that idea too.
  16. Nice changes, I am working through what you did vs I did now. It's close. Right now with the original code (where I no longer show mountains), Stella is indicating that it is outputting at a solid 60hz. However, once I've started adding changes (mine and your) I start seeing some random points where it drops to 59hz or up to 61hz. It isn't constant, but I also haven't isolated the exact situations causing it either. Once I get that sorted i'll post another assembly file. Also, how do you assembly you source? Every time I attempt it is 2 bytes too big.
  17. Hi all, Is there a master list somewhere of the type of PROM that games require. For instance, a lot of games are 4k. Some are 8K, but I have seen a ton of different schematics of 8k cartridge board with page switching techniques. Further, some add external RAM on the cartridge board too. I know I am asking for a specific example which is Atari 2600 Stargate/Defender II. 1) Does anyone make a PCB For this or have a layout/schematic for it 2) Suggestions on the 8K chip to use that performs the proper bank switching correctly 3) What external RAM chip to use 4) Schematic for how to lay this out so I can try and make one In my example, I'm making a hack/game but have no real way to test on a unit without going and killing a Defender II/Startgate cartridge, but this doesn't help me make more than 1. Kinda wondering, what do people do here?
  18. Looking through it and comparing. One thing I found in your demo code was that before the DEY before LF42A, these lines are needed otherwise the stars on the first iteration of index Y of play area will be more like lines instead of dots (STA NUSIZ1 is not though): AND #$F0 ;2 STA CTRLPF ;3 Still going through the rest to see how to apply, clean it up....
  19. Mine looks pretty bad too. I am trying to figure out if I am jumping back at the right point of the main kernel too... my flicker so far is WAY too slow
  20. Ok, but jumping out of the kernel and into the minikernel I am making, don't I need to jump back into the kernel at some point after I draw the city piece during the flicker? Maybe back to LF457 or would maybe LF444?
  21. I also do not fully understand why they didn't use the whole game display area (see the gap). I assume maybe because of the TIA defect where the "lines" show up.... but I made the radar lower bar go the whole length of the screen easily enough.
  22. Ok, cool. Wow. Thank you sir. Let me give it a shot and some attempts to see what I can get out of this. Back to my original question on the city. When you say clear my PFs after I draw the city, is that simply setting PFs to 0x00 after the last horizontal line it taken care of because that doesn't seem to work.
  23. Are you sure that the original Defender doesn't flicker? My assumption on flicker was that you have, what, 60 frames per second on NTSC. Best I can tell in the original defender is that the city was updated on each frame, but the ship and all enemies were not and were flickered. So back to stargate. I was thinking something like frame 1 might have ship/enemies; frame 2 might have city, and back to 1 and so on. So, in looking at that, I added only two instructions to do a Load, compare and branch and believe it or not, those 8 cycles were too much and killed the display code. Best I can tell, there are 4 cycles free. I'm going to be honest, this may kill it for me. I just don't get enough about the display loop and TIA to understand where I can make compromises....
  24. I pulled everything else except a compare, branch and Load Accumulator and those 12 cycles were too much for it to handle! At this point, I'm not sure what else to cut out. I guess losing the starfield could be an option. But best I can tell that is 16 cycles at most. Do you know why this routine deals with the ship and planet vector twice in the same loop? Got any suggestions? I wasn't expecting this to be this tight!
  25. Well, Now let me post to solicit ideas. I created a ROM graphics area for the cityscape and successfully killed off the mountains. So, to make the cityscape show, I tried using the Defender mentality and did something like this (this is grossly simplified as it doesn't contain the bit shifting of the ROM area to match ship movement. Roughly, in this example I am loaded cityscape from a static area that doesn;t rotate based on ship movement). So this basically creates a cityscape that is static in how it shows. LF444: LDA (_ram94_shipVector),Y ;5 STA GRP1 ;3 ;rr marker LDA (_ram9B_planetVector),Y ;5 makes stars/mountains. ; _ram9B is FE00 for mountains ; _ram9B is FE1C for no mountains ;marker CMP #$FF BNE LF444a ; LDA #$0F ; LSR ; LSR ; STA WSYNC ; STA _ram84_invisoUnits LDA $96 ; sets the playfield color? STA COLUPF LDA LFCDE,Y STA PF0 LDA LFCDE,Y STA PF1 LDA LFCDE,Y STA PF2 LDA #$00 ;end marker LF444a: STA ENAM1 ;3 STA ENABL ;3 So basically, I re-used the area FE00 in Bank 2 that defines that starfield and mountains area and use a marker instead of the mountains to indicate where to start building the city down. At that point, I update the playfield with the cityscape. This allows the enemies and the ship to migrate below the skyline. And it actually works. But I have two problems. it seems that the extra processing in this area causing un-intended consequences for the horizontal update timing (screen jumps) and sometimes I get scren jumps, stella indicating that my screen rate goes over 60hz (typically with enemies on the screen too). So, I am struggling with the code addition and timings I need to maintain. Any suggestions? Updating the playfield seems to work for the bottom of the screen (I have other problems with it that I can debug out), but it bleeds into the radar area and score/extra lives/bombs) my guess is because this uses the playfield too. Am I missing something to allow playfield area updates where I am trying without bleed through on the top half (I attached a screenshot of this) Really could use some help/advice. I am feeling better with my progress, but this is attempt #10 on an algorithm and how to do it over the course of a few weeks. So obviously I am struggling :-/
×
×
  • Create New...