Jump to content

Just Jeff

+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

Everything posted by Just Jeff

  1. I had no idea EOR would do that. Unbelievable. I went through each possible move on page 41 and it checks out! I've known for a while what EOR does, but never could figure out what use it could be for anything... And I forgot about the Horizontal Blank... So I assume we are using up 22 cycles in the subsequent code then, not 19 until the RESP0- right?
  2. I was typing this up before your later posts... Thanks for the debugger guidance- I knew pretty much none of that. I don't think I ever even noticed the left window.. And its especially nice to see the labels in the assembly code on the right instead of the random labels it would have generated itself. And the break is cool.. So, if I have this straight, This little loop immediately follows a WSYNC which can only place a player at 15 color clock increments from the WSYNC. Even though we are outside of the kernal, there is no harm in doing this now. The divide loop is making those 15 color clock jumps. EOR is switching the right three bits- 0's to ones, and 1s to zeros... I'm still not sure why...Are we converting this remainder to two's compliment negative? I know that TIA's direction of the x-axis is backwards. Then they are moved into the correct position HMP0 for an eventual HMOVE to happen later. But.. By the time we RESPO, isn't our course position timing off? Didn't we use like 19 more cycles to get to it?
  3. Thanks! I'm going to run through the steps today. I did consider that the shifts were just for moving the positions of the bits for some reason, but I think the EOR threw me off of that. Also, I've read through the Stella guide several times. And, (uncharacteristically for me with all of this stuff), the latest read-through was a breeze. I felt like I had at least a 95% understanding, except for all of the schematics which I only skimmed because they didn't seem very relevant. (feel free to correct me if I'm wrong on that) I guess I only understood HMMO, etc. as useful for relative movement, not fine tuning something stationary. I've used the debugger a few times as well, I can advance through the code step by step, but don't have any knowledge about it beyond that and hope to learn more about it. It looks like it has a lot of capability.
  4. Would you be able to elaborate or do a walk-through example on the code below? I cannot understand how it fine tunes the X position. It looks to me like the EOR would make the position's value meaningless, and then the ASLs would multiply that number. Thanks: PosObject: sec sta WSYNC DivideLoop sbc #15 ; 2 2 - each time thru this loop takes 5 cycles, which is bcs DivideLoop ; 2 4 - the same amount of time it takes to draw 15 pixels eor #7 ; 2 6 - The EOR & ASL statements convert the remainder asl ; 2 8 - of position/15 to the value needed to fine tune asl ; 2 10 - the X position asl ; 2 12 asl ; 2 14 sta.wx HMP0,X ; 5 19 - store fine tuning of X sta RESP0,X ; 4 23 - set coarse X position of object rts ; 6 29
  5. I'm afraid I don't know anything at all about Batari. Maybe someone else can answer that one. Also, there is a list on Atariage specifically for Batari where you could ask. As for learning 6502 assembly, I do recommend it. Its not as hard as it looks.
  6. I'm not the greatest at DASM but it looks like kernel.asm is either in the wrong directory or that kernel.asm is not named what you think it is named. Are you sure you are trying to assemble the file- kernel.asm because the collect files will usually it will look something like this: dasm collect.asm -f3 -ocollect.bin If I were assembling a collect file, I would get into the right folder first: cd DASM cd dasm then... dasm collect.asm -f3 -ocollect.bin or if you really have a file called "kernel", then it would look similar- dasm kernel.asm -f3 -okernal.bin
  7. Ahh.. Now it makes sense. Thanks. So, why write it this way? Is it to make it a sort of all-purpose code that you can paste into any program?
  8. I guess I'm pretty lost on this one and might have to drop it for now. I read through half of the DASM.txt and so much of it was above my head that I wasn't getting anything out of it. I read Collect #10 and I could follow, except for the terms "endif, and "ifconst", and the rest that I was specifically looking for- just not getting it. I could only figure that they were used in conjunction with the LFSG. I did learn what LFSG was- pretty cool.. and downloaded JEdit which I figured I'd have to start using eventually anyway. (It says its an editor for the "mature" programmer. uh-oh..) My idea after completing Collect #4 with some difficulty was to just go ahead and read through one of your more complete versions of a Collect assembly to get a sense of as many parts as possible of the entire program. I've been really enjoying that and learning a lot.. Thanks for the help!
  9. Good Morning, I'm looking through some code and found some commands I don't recognize.. what are these Basic-looking commands? They're not really indented which makes me think they are labels for a subroutine, but they repeat which makes me think they can't be. Random: lda Rand8 lsr ifconst Rand16 rol Rand16 endif bcc noeor eor #$B4 noeor sta Rand8 ifconst Rand16 eor Rand16 endif rts
  10. Thanks! It took me quite a few reads to digest it. I can follow it.. Don't ask me to recite it though! So: DASM knows that * - HumanGfx is the "distance" from where HumanGfx started, making HUMAN_HEIGHT equal to that number of positions-right? One other thing.. I understand setting the carry flag, but why does DCP set the carry flag here? What's the logic of that? Is it just something you know or does it make sense somehow? I don't see what's carrying over..
  11. Good Morning, I'm having a difficult time distinguishing between each Human variable. Could you please explain? Does Humandraw = the Y position of the player on the screen? Why decrement it in the scan loop? Does HumanPtr = the line of the player's graphic to be drawn now? HUMAN_HEIGHT = ??? Also I don't understand this syntax. The asterisk mainly: HUMAN_HEIGHT = * - HumanGfx Thanks!
  12. Ohhh.. I kept thinking that this was being applied to the number graphics, not the location of the number graphic in memory; that you were masking the 10s digit, then taking the ones digit and "offset"ing to the left for some reason. But that made no sense, of course.. Thanks again!
  13. Hello.. Could you please explain why the digits are multiplied by 5? I'm not sure I understand what "offset" means here.
  14. Good Evening. Could you please elaborate on what these instructions do? macro.h SEG.U VARS Thanks!
  15. Right there on page 41. I can't believe I made basically the same mistake as I did when I tried to ENABL... I checked the HMOVE register over and over, but not HMBL.. Thank you.
  16. Thanks- I like that instruction link a lot... I think I could use some help figuring out why my ball doesn't move. In my start up code, I have: LDA #1 STA CTRLPF STA HMBL ;Ball Speed Then in the main loop I have: LDA #2 STA VSYNC STA WSYNC STA WSYNC STA WSYNC STA HMOVE ;Move Ball and this is in the kernel: CheckBall CPY Ball BNE NoBall LDA #2 STA ENABL NoBall Does anything look wrong? Its an HMOVE immediately after a WSYNC, 1 is a legitimate speed for HMBL. The ball shows up (sort of) but doesn't move.. Thanks!
  17. I started giving it a shot a couple of weeks ago and its not as hard as I thought it would be. Have you tried Kirk Israel's Atari 2600 101 on the programming page? I highly recommend it. He explains just about everything on a very basic level- understandable baby steps. If you've been going through other people's code and getting lost, its good for you as well. He's writing really basic stuff that you can figure out how to alter or add to pretty quick. Also, have you read through the Stella manual or Assembly in One Step?
  18. Thanks! Is it fair to say that the BITabs doesn't really produce anything useful here? The instruction causes consistent cycles, and also performs a mini-branch, but whatever value is the result, is not used- correct?
  19. Good Morning.. Can anyone explain this a little bit? I've never seen the DCP command before (looks like it means decrement and compare but I can't find documentation on it) Also, I have no idea how the .byte even does anything here. I thought .byte just placed data in memory. lda #HUMAN_HEIGHT-1 ; 2 15 - height of the humanoid graphics, subtract 1 due to starting with 0 dcp HumanDraw ; 5 20 - Decrement HumanDraw and compare with height bcs DoDrawGrp0 ; 2 22 - (3 23) if Carry is Set, then humanoid is on current scanline lda #0 ; 2 24 - otherwise use 0 to turn off player0 .byte $2C ; 4 28 - $2C = BIT with absolute addressing, trick that ; causes the lda (HumanPtr),y to be skipped
  20. Awesome. I get it. Thanks! My little games I've been trying to write always run into kernel issues so I'm sure it will come in handy.
  21. Thanks.. Its making some sense but: Are you saying some of the locations the stack pointer runs through are registers for graphics and other stuff? I guess I imagined that it only looks at program code locations. I think I have a good idea of the processor status register, but can't grasp why we would have Z the way we wanted for D1 for ENABL.
  22. Wow- that's really advanced. Pushing processor status on to the stack? I'm not sure why that would work since all I know is the stack keeps track of addresses for subroutines. Now, if I could only figure out why that ball isn't moving...
  23. Ug... Thank you- it works! Looks Like the Stella Programming Guide is wrong; The ball graphics register works just like the missile registers. Writing a “1” to the enable ball register (ENABL) enables the ball graphics until the register is disabled.
  24. Hello Everyone! I'm new to the forum.. It nice to be here. I've been trying to write my first program but ran into a seemingly simple issue that I cannot resolve. I have a playfield and two players that I can move but when I tried to add a ball, it never shows up. Here is the code: ;CheckBall ;CPY Ball ;BNE NoBall LDA #1 STA ENABL ;NoBall I put in the semicolons to rule out the other code as the issue. Shouldn't this code at least produce a vertical line? The Stella debugger does show the that it runs through the code. Elsewhere in the program I tried to get it to move as well: LDA #1 STA CTRLPF STA HMBL ;Ball Speed and... MainLoop LDA #2 STA VSYNC STA WSYNC STA WSYNC STA WSYNC STA HMOVE ;Move Ball Anyone know what I missed? Thanks!
  • Create New...