Jump to content

BNE Jeff

+AtariAge Subscriber
  • Content Count

    451
  • Joined

  • Last visited

Community Reputation

88 Excellent

About BNE Jeff

  • Rank
    Moonsweeper

Profile Information

  • Gender
    Male
  • Location
    Virginia
  • Interests
    Atari 2600 programming.
  1. Well I spent the past few weeks working on it here and there, and did ok taking care of the above issues with an elaborate scheme using the ball, missiles, playfield changes and more. It was pretty functional, but with limitations. Then when I started on a routine to populate the play field with the different colors from RAM, I stumbled upon an illegal opcode that made all that work completely obsolete, used no kernel time, none of the objects, and allowed 100% of all possible configurations, 100% of the time. Random generated playfield arrangement. I knew my routine would generate an illegal opcode, but thought it would be harmless. In reality, it blew up the kernel with a 6 cycle code. So I tweaked my routine, to give me a different, hopefully harmless code ($87). The kernel ran, but I was getting some odd, mustard colored squares in addition to the red, yellow, and blue. Once I read up on $87 (SAX), I thought hey, I can use this for a cursor color (rearranging what a,x. and y were holding would give me gray as the fourth color. It took me a few more minutes to realize that my red and blue only had one bit in common, and a minor change to one could give me a black cursor (note the red is darker now). It took a few more minutes to realize, my playfield limitations could be completely resolved this way as well. So, now it works better and the ball and missiles are free for other possible uses (Note the red divider line that appears in the original game is now there).
  2. Good Morning, I found a game called Amado that I think can be done in a reasonable amount of time. Originally thinking that the map on the right could not be displayed in the same horizon as the (full, top two rows of) playfield, I'm giving it a shot anyway and I think It might work. Here's what I have so far. (Note, the map on the right will only occupy 32 scanlines when finished): Spiceware showed me how to run a kernel in RAM, so I'm doing that here. The shortcomings I still have are: 1. PF2 is symmetrical, so only one black square is available in that area via the ball. Being able to cram 2 more store PF2s would allow unlimited playfield designs and free up the ball. 2. I still have not represented the player's current position in any way. 3. I've deliberately made the last column red so I'd have red in the map on the right. This won't work in a game, so I'll need another store #RED to the background crammed in there. I've got a few ideas involving using missiles display two squares at strategic locations but I dunno.. Sounds like that might be overly complicated. I feel like my handling of line index / a,x,y, and a is already needlessly messy. Any ideas?: jmp ZProutineRAM ;3 67 because will be in RAM eventually RAMKernel: SUBROUTINE ; ZProutineROM: ; This all is loaded and runs in RAM .loop sta WSYNC ;3 0 ;This can eventually be removed lda #%00100100 ;2 2 ;Vertical grid lines sta PF1 ;3 5 ; Register Update Allows for one register update per scan line lda MapSec1,x ;4 9 ;New pattern for either P0,P1,or PF ldy MapReg1,x ;4 13 ;Specifies which register to update sta 0,y ;5 18 ;Store the map pattern to that register. Can this be reduced to 4 cycles somehow? ldy #BLUE ;2 20 ;Restore the colors to the registers ldx #YELLOW ;2 22 lda #RED ;2 24 stx COLUBK ;3 27 1st column These stores are changed in the black horizontal bands above so that loads are not needed. sty.w COLUBK ;3 30 2nd column Needs to be @ cycle 31 or 32 sta.w COLUBK ;4 34 3rd column 4 cycle stores keep them in line with the beam but 2 cycle ops could be used in some spots instead. stx.w COLUBK ;4 38 4th column Perhaps missiles could replace one or two of these but I still have nothing displaying a cursor that sta.w COLUBK ;4 42 5th column will show what spot the player is on sty.w COLUBK ;4 46 6th column stx.w COLUBK ;4 50 7th column MapOperand: ldx #%00001111 ;2 52 Represents the red in the map via PF1. This operand is updated in the above register update. sta COLUBK ;3 55 I'm cheating here because I forced red in the last column. This will not work during a game. stx PF1 ;3 58 This won't match P0 and P1 changes verticlly. dec RAMKernelCount ;5 63 ldx RAMKernelCount ;3 66 bne .loop ;3,2 69,68 jmp JumpOutofRAM ;3 71 ZPsize = *-ZProutineROM Note: I still have plenty of time left to set stuff up in the black horizontal bands.
  3. Do you know a good way to get the assembler to label the ZProutineROM routine once its loaded into RAM? For example, if you had lda #%10011001 somewhere in ZPRoutineRAM, and wanted to change it on the fly to lda #%11111111 could you: lda #%11111111 sta MySpecialRAMLabel+1 ;(the operand portion of that load) I think this could be figured out manually, but while writing, it would be great if a labelled location could be figured by the assembler.
  4. OK yeah I fixed it- Thanks... And I see the ZPsize too which would eliminate the jmp issue I mentioned. Though that looks like it can be risky if I don't manage RAM appropriately.
  5. Thanks! So that looks really straight forward if I understand it correctly. Like this?: ZProutineRAM ds 16 ldy #15 InitZP lda ZProutineROM,y sta ZProutineRAM,y dey bpl InitZP ZProutineROM: ;read 3 bytes of garbage from here up. Be careful about the jump to RAM ;address because it can change. I think I might use iny and cpy #15 instead. lda #SomeNumber ; 2 bytes sta SomeRegister ; 2 bytes lda ($44,X) ; 6 bytes jmp KernelEnd ; 3 bytes
  6. Good Morning, Can anyone please tell me a good way to get Dasm to put op codes and operands in RAM? I'll be running some code there for speed but looking up the op codes and then storing that number seems like it might be more difficult than it has to be. Best I can think of is defining some op codes as constants and then loading and storing them such as: LDAImmediate = $A9 ; Load the accumulator with an immediate And then to write lda #20 in the RAM code, my ROM code would be something like: lda #LDAImmediate sta $80 lda #20 sta $81 Is this a decent method or is there something better?
  7. Yes.. it wastes space, but don't worry about it at this point. Go ahead and use the align 256 while you are still writing since it automatically re-arranges code for you as you make changes. If you eventually run out of space, its fairly simple to remove the align 256 and re-arrange your code to put something on the page break that won't be affected by it- probably some graphics that aren't timed so tightly, or maybe a subroutine that gets called outside the kernel.
  8. Did you seed Random with a value? If not, it looks like its going to be zero every time. If you step through on the debugger, do you see new values on each frame?
  9. Dang it! Thanks for the help everybody. I stuck 12 bytes in the macro as a spacer. 64K EF autodetected:
  10. Thanks.. I was able to switch using this. It was generally identifying the ROM as 4K although for some of my attempts, it thought it was a 64K Megaboy.
  11. Thanks.. I see a problem in the list file.. As noted before, the bankswitch addresses end 16 bytes before the end of the ROM space (why? I don't know). To place the reset and IRQ vectors in the right place, I added a second RORG to the macro. Its being ignored. ORG $FFFC is not being generated by RORG $1FFC. This is the case on all of the banks. 177 ffe0 ORG $FFE0 0 ffe0 BANKS_AND_VECTORS 1 ffe0 RORG $1FE0 2 ffe0 3 ffe0 00 SelectBank0 .byte.b $00 4 ffe1 00 SelectBank1 .byte.b $00 5 ffe2 00 SelectBank2 .byte.b $00 6 ffe3 00 SelectBank3 .byte.b $00 7 ffe4 00 SelectBank4 .byte.b $00 8 ffe5 00 SelectBank5 .byte.b $00 9 ffe6 00 SelectBank6 .byte.b $00 10 ffe7 00 SelectBank7 .byte.b $00 11 ffe8 00 SelectBank8 .byte.b $00 12 ffe9 00 SelectBank9 .byte.b $00 13 ffea 00 SelectBank10 .byte.b $00 14 ffeb 00 SelectBank11 .byte.b $00 15 ffec 00 SelectBank12 .byte.b $00 16 ffed 00 SelectBank13 .byte.b $00 17 ffee 00 SelectBank14 .byte.b $00 18 ffef 00 SelectBank15 .byte.b $00 19 fff0 20 fff0 RORG $1FFC 21 fff0 00 10 .word.w SystemStart 22 fff2 00 10 .word.w SystemStart 179 fff4 The macro code: MAC BANKS_AND_VECTORS ; end of every bank RORG $1FE0 ;WAS RORG $FFF4 SelectBank0 .byte $00 SelectBank1 .byte $00 SelectBank2 .byte $00 SelectBank3 .byte $00 SelectBank4 .byte $00 SelectBank5 .byte $00 SelectBank6 .byte $00 SelectBank7 .byte $00 SelectBank8 .byte $00 SelectBank9 .byte $00 SelectBank10 .byte $00 SelectBank11 .byte $00 SelectBank12 .byte $00 SelectBank13 .byte $00 SelectBank14 .byte $00 SelectBank15 .byte $00 RORG $1FFC ;Added because there is blank space. .word SystemStart ; RESET .word SystemStart ; IRQ ENDM What am I doing wrong there? I do see that my old RORG reflected a 64K ROM space with $FFF4 (even though it was a 32K game), I'm only reflecting 4K here with $1FFC- does that matter?
  12. The jump table- right? MAC JUMP_TABLE ; start of every bank RORG $1000 And my 16 banks will ORG $0000, $1000, $2000, … F000- right? Does the bank with ORG $1000 need to be the one that contains my SystemStart (@ the reset vector)?
  13. I'm having trouble getting this one to work. Would it look like this? Also, it looks like it wastes 12 bytes between the last hot spot and the reset vector (So I added a RORG): MAC BANKS_AND_VECTORS ; end of every bank RORG $1FE0 ;WAS RORG $FFF4 SelectBank0 .byte $00 SelectBank1 .byte $00 SelectBank2 .byte $00 SelectBank3 .byte $00 SelectBank4 .byte $00 SelectBank5 .byte $00 SelectBank6 .byte $00 SelectBank7 .byte $00 SelectBank8 .byte $00 SelectBank9 .byte $00 SelectBank10 .byte $00 SelectBank11 .byte $00 SelectBank12 .byte $00 SelectBank13 .byte $00 SelectBank14 .byte $00 SelectBank15 .byte $00 ; .word SystemStart ; NMI used for banks 7 and 8 RORG $1FFC ;Added because there is blank space. .word SystemStart ; RESET .word SystemStart ; IRQ ENDM
  14. Yeah I had to look around a bit for my stuff on that. I like the asl idea though. Thanks.
  15. Oh yeah it's way better that DiStella. I was able to get a good DiStella disassembly with the additional switches, but once I disassembled with Stella, I dropped it entirely. The Stella disassembly is nice!
×
×
  • Create New...