Jump to content

Just Jeff

+AtariAge Subscriber
  • Content Count

    454
  • Joined

  • Last visited

Everything posted by Just Jeff

  1. What would happen if code was running in RAM and hit address $00ff? (assuming the stack was clear or saved)
  2. Hi- Is this an appropriate place to look for trades? I have extra Odyssey 2 games boxed w/ manuals I'd like to trade for some I don't have. If you are looking to do the same, let me know.. I can offer: Alpine Skiing!, Alien Invaders Plus!, Armored Encounter!/Sub Chase!, Blockout!/Breakdown!, Computer Golf!, K.C. Munchkin, Las Vegas Blackjack!, Showdown in 2100 A.D., Speedway!/Spin-out!/Crypto-Logic!, Thunderball! Also 2 loose carts with no box/manual- Bowling!/Basketball!, and Electronic Table Soccer! I don't need Baseball!, Cosmic Conflict!, Freedom Fighters!, Football!, Invaders from Hyperspace!, KCs Crazy Chase!, Out of This World!/Helicopter Rescue!, Pick Axe Pete!, Pocket Billiards!, UFO!, War of Nerves!, nor anything I mentioned in the previous paragraph, of course.
  3. Here's a little more progress for this week.. I think the top bands came out nice and I've started the map (right of the red line) in earnest. You can see one of the two limitations of the red when it has to interact with black in the 4th row. I just can't update two players and playfield all on that same line when the (game's) playfield is present on the same horizon. You see it again on lines 4 and 5 but I'll be able to get rid of that the same way I did in rows 1 and 2. Right now the ball is drawing the red line, so I'm going to switch that out with P1 missile so the ball (VDEL on) can mitigate some of it. I believe line 8 will be the most restricted, with the playfield unusable- Only the ball will be available for that color. In any case, these are just patterns, and they can simply be designed around the issue so it won't show. As always.. if anyone knows of another way, I'd love to hear it.
  4. 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).
  5. 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.
  6. 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.
  7. 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.
  8. 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
  9. 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?
  10. 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.
  11. 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?
  12. Dang it! Thanks for the help everybody. I stuck 12 bytes in the macro as a spacer. 64K EF autodetected:
  13. 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.
  14. 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?
  15. 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)?
  16. 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
  17. Yeah I had to look around a bit for my stuff on that. I like the asl idea though. Thanks.
  18. 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!
  19. Good Morning, I used Distella to disassemble Chopper Command but the bin didn't run when recompiled with DASM. I found missing assembler instructions such as ORGs SEGs and the Processor spec. It runs now with issues. I'll continue fixing it up but I'm curious- Did I use Stella wrong? Is there a switch I should have added? I used -a only. I made notes of my changes in the attached asm- just search for semicolons to see them. The second attachment is my current .bin. The third attachment is the original .bin if someone wants to disassemble to compare results. Thanks! CPRCMD.asm CPRCMD.asm.bin Choprcmd.bin
  20. Nice! Yeah for longer samples, you'll have to use bank switching. I don't recall exactly, but I think generally you only get 3 seconds or so of speech into 4 K. Of course you can adjust the quality to get more or less than that. I don't recall offhand seeing speech that didn't have a blank screen either, though I'm sure its out there. Its a matter of holding the sample routine's hand... every 100 cycles more or less... without ever letting go. Easily said, but it will get in the way of everything you do in the vertical blank, kernel, overscan, subroutines, indexes, and surely other things. And you'll pay for it with degraded game and graphics quality as well. And.. you mentioned sampling a song- even harder because you can't vary the rate much- you'll go out of tune. I made a half-hearted attempt a while back. (attached) It's got the stable kernel, but the speech is still not right. It takes a few seconds for you to realize its saying "Hello" really really slowly. Maybe its time to debug it. SpeechKernel10.asm SpeechKernel10.asm.bin
  21. Woops. Sorry about that.. I was in a little bit of a hurry getting ready for work. Correct files attached now.. For my samples I used Audacity on its crappiest quality- I believe it was 8 bit mono audio at the slowest rate. Then I ran it through something called Wav2Atari which is written in Perl. It converts .wavs to the 4 bit format you're going to want. Not sure what you mean by deltas to decide which note to import. With samples, your not working with notes directly, you're building the waves with your data. hello.asm HELLO.BIN
  22. Are you playing one nibble at a time here? I'm not sure how your compiler is dealing with these hex numbers but I think you should be processing one hex digit at a time (0-F only). Typically, you would store two 4 bit nibbles in one byte, use the byte as is for the right nibble, then lsr 4 times to use the left nibble. Example attached. It looks like it wastes about 130 cycles between wave changes (not notes) hello.wav
  23. Ahh thanks, that was the missing piece. I saw Thomas mention something like that but it didn’t click because I had no idea that was a thing. Everyone here seems to know it without having to say. All those years of math in school and I don’t recall ever seeing it. Here’s my interpretation: Div6: SUBROUTINE ; divide player position by 6 ; rors are necessary for larger numbers sta temp ; Store the value for recycling. 1/3 is the convergence of 1/4 + 1/16 + 1/64 + 1/256... lsr ; Shift significant bits (of 2 bit pairs) over 1 adc #$15 ; = %00010101. Round up if the 2 bit pair was 3? lsr ; Now we are at 1/4 the original number. The results here will be divided 3 more times for the 1/256 portion adc temp ; Add that to the original number for round 2 (Original # plus 1/4) ror ; lsr ; Divide that by 4. The results here will be divided 2 more times for the 1/64 portion adc temp ; Add that to the total number for round 3 (Original # plus 1/4 plus 1/16) ror ; lsr ; Divide that by 4. The results here will be divided 1 more time for the 1/16 portion adc temp ; Add that to the total number for round 4 (Original # plus 1/4 plus 1/16 plus 1/64) ror ; lsr ; Divide that by 4 for final result. Original can be discarded now. Result is 1/4 plus 1/16 plus 1/64 plus 1/256 ;Make it divide by 6 lsr ;
  24. Well I've looked at this multiple times this week, manually worked through it with various values and it always works. I made a spreadsheet to try to observe what happens, why and when.. and I still have no solid idea why this works. My guess is that the adc #$15 (%00010101) is seeding the value to affect the carry for some reason and that repeatedly dividing by four, then adding the original amount back in, somehow works out to dividing by 3. Also thinking that binary 3 behaves differently than decimal 3, being that its a fraction of the base in decimal, but 1.5 times the base in binary. Would someone care to comment it so I might get a better grip on it? Also, did I get any of it right? Thanks
  25. Hello.. I'm trying to divide the 160 color clocks by 6. If I wanted to divide by 6, should I just put an lsr right at the top of this (before storing to temp)? Should I do anything with the carry?
×
×
  • Create New...