Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About rallyrabbit

  • Rank
    Space Invader

Profile Information

  • Gender
  • Location
    North Carolina (USA)
  1. 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.
  2. 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.
  3. 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?
  4. 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....
  5. 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
  6. 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?
  7. 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.
  8. 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.
  9. 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....
  10. 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!
  11. 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 :-/
  12. A little update as it has been a few weeks. I put most of your changes and omissions (some I chose not to do), also found some more small places to save some ROM space. I'm really unhappy with how some of the game was coded, definitely not how I would have coded some of this stuff. So I've been making some notes on how to re-code large portions of this while preserving the game if I need to. So far, I am going to avoid big changes unless I need to. Right now, working on getting an algorithm for the cityscape that works properly. Trying to play with using a RAM model like in the original defender or using a graphics model that fits how defender works today.
  13. Ok, cool, I was trying to go through the code and see what you did. I wasn't sure what the intended result was, so I was going through line by line to see what changed. I'll start merging now. So, while I am working on combining, let me ask your opinion. I was wanting to do some similar to defender that once your ship gets below a certain point, that allows the smart bomb use (although that would have some challenges in game such as this where it stands now. So, I'd have to remove the checks for joystick 2 for this, but would have to have a "height" check somewhere to replace the use of it. Any opinions here?
  14. Now back to this after work has calmed down.... What all have you changed overall. Just a did a diff with my code and trying to figure out what to merge. Added a bunch of comments. Which I am incorporating. But running the program is pretty much a blank screen (so assuming you are ripping stuff out)? Looks like just title screen, end of wave screen and the radar/score? I've done a bit of work trying to get graphics like the original defender with a newer twist (not sure I like it yet), isolate enemy speeds (not adjusted yet), changed a lot with colors, things like graphic area consolidation and reduction of sapce, changed some screen, no dogfights, no warps (got rid of warp screens), no stargate (reused that graphic area), took some of the defender arcade lessons form the enemy tables, trying to isolate sounds (not sure I like my enemy shot sound yet, but it is what it is for now), trying to do some color adjustments elsewhere and all over the place. Fixed the score on the end of wave screen. Made the digits look like original defender. Took out my cityscape that didn't work. Removed inviso mode stuff so far. Tried to comment the code based on what I think is going on. Took some mountains changes from defender arcade as well that'll go away eventually. Added my initials to title screen until I get closer to completion. Again, scalpel. So I finally see how mountains vs destroyed planet are done (its an adjustment to the index). not I am trying to see how I can do a simply cityscape and see what are the base cycles I need to do it to see if I kill everything and scanline time. Working out ideas for now. That leaves some of the bigger things left: 1) Figure out how to do smartbomb from joystick 1 below mountain level (still working this out) 2) Cityscape algorithm and see if I can do it in space available and without killing scanline timeframe 3) Adjusting enemy speeds across waves so that the game doesn't get so impossible so fast defender1.asm defender2.asm
  15. not sure I've through that far ahead, but that's a good point. I think you could technically let the humanoids reside in the top of builds, therefore its not a problem, or I'll illegitimately have to figure something else out which will take a bit of research.
  • Create New...