Jump to content

kensu

Members
  • Posts

    120
  • Joined

  • Last visited

Profile Information

  • Gender
    Female
  • Location
    Pewaukee, WI
  • Currently Playing
    Jawbreaker 2600, Dragonstomper and other Starpath goodies.

Recent Profile Visitors

5,550 profile views

kensu's Achievements

Chopper Commander

Chopper Commander (4/9)

19

Reputation

  1. I'm thinking of looking into developing a light-gun game, and want to see if there's a big enough audience to justify it. Edit: Dammit, I cut off the "I have both" option. Could a mod add "I have both" as option 1 and move everything else down?
  2. In this case I really just need to determine the scanline so I can enable the DLI to change the PM color register. The one I'm trying at this moment is: (MYPMBASE+YPOS+512)/4, with those variable having their most common meanings. Doesn't seem to be working, though. There's plenty of reasons why that might be, though.
  3. Has anyone come up with a good formula for translating PM screen coordinates to position in the character buffer array and vice-versa? Below are some notes I made on the subject for my breakout clone (this is in graphics mode 17), but it's still a little off. The top line of the topmost brick is y=16. The bottom of that brick is at y=20. The bottom line of the lowest brick is y=40 The left edge of the playfield is x=42 the left side is x=210 46 is the left edge of the brick, 61 is the right side. The right side of the last brick is 205 Each brick has a width of 15. (possibly 16? The bricks are two characters) Each row is 10 bricks or 20 characters long. There are 6 rows of bricks. So take all together: The four corners of the bricks: NW: 46,16 NE: 205,16 SW: 46,40 SE: 205,40 Width of bricks: 159 Height of bricks: 24 Each brick is 15 wide and 4 tall. 46 + (159/) 100,25: where am I? 100-46 = 54 -> 54/15 = 3 -> column 3 25-16 = 9 -> 9/4 = ~1: Row 2 (it's actually column 4, bottom of row 2) 49,15 is brick 0,0. 49-46 = 3 /0 = Column 0 18 - 16 = 2 / 0 = Row 0 Column is zero-indexed, but row is not?
  4. Yep, worked like a charm, I pinned a Thanks trophy to the message with the code that fixed it. Thanks!
  5. It might be Zero Page address zero, which I think is clear for variable use. I wonder why it always has a starting value of 3? This also explains a lot of weird issues I've been running into with Action!, and why I couldn't really understand how dereferncing of variables worked. Action appears to be much closer to the metal than I thought, and just using my knowledge of C wasn't enough.
  6. That's very strange, if you remove the brackets it will loop through the colors in a different order (3,4,5,0,1,2). I think what's happening here is similar to what happens when you use something like "Byte x=$FF" where it sets up the variable as a direct reference to that spot in memory without having to do any dereferncing with the ^. In this case it seems to be using Action's memory allocation routine to find a free spot in memory and then assigning that variable as a reference to it. I still don't understand why it has a different result from just a normal assignment.... I wish we could ask the author of the original example, but this code is from 1984, if they were still around I doubt they'd remember why they did it that way.
  7. Hmm, the Graphics 1 (for BASIC and Action!) display list is: 112 112 112 70 128 157 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 adr 0 1 2 3 4 5 6 7 8 9 1011121314151617181920 Bacially the first 6 of those 6s are turned into 134 (6 with bit 7 set). So if I wanted it to start on the first line, I would want to change offset 5, but that's actually the high component of the address of the beginning of the screen buffer. So what do I do in this case? Also, if it starts on offset 6, which would be the first line of the screen, why are the first two lines the original color, instead of just the first line? As I recall, aren't there two mode lines per row?
  8. I incorporated a modified verison of the DLI routine from this Action! program into a character set redefiniton program I'd previously written, which draws six rows of Breakout-style bricks. This actually works, but it only changes the color of rows 3-6, no matter how I modify it, I can't get the first two rows to change. Those lines do have DLI enabled, but the Playfield Color 1 (0) is only changed starting with the third line. DEFINE RTI="$40", PHA="$48", PLA="$68", TXA="$8A", TAX="$AA", TYA="$98", TAY="$A8", JMP="$4C" BYTE CHBAS = $2F4, PMBASE = $D407, RAMTOP=$6A, NMIEN=$D40E, COLP0=$D016,WSYNC=$D40A, COUNT=[0] CARD SDLSTL=560, VDSLST=512 BYTE ARRAY COLTABLE(0) = [$42 $74 $C4 $18 $00 $0E] BYTE ARRAY DLIST PROC DLINT() BYTE DUM [PHA TXA PHA TYA PHA] DUM=COLTABLE(COUNT) WSYNC=1 COLP0=DUM COUNT ==+ 1 IF COUNT=6 THEN COUNT=0 FI [PLA TAY PLA TAX PLA RTI] PROC INIT_GR() GRAPHICS(1) SETCOLOR(0,2,10) SETCOLOR(1,5,12) SETCOLOR(2,0,0) RETURN PROC DLSETUP() BYTE I INIT_GR() NMIEN=$40 DLIST=SDLSTL VDSLST=DLINT FOR I = 6 TO 11 DO DLIST(I)=134 OD NMIEN=$C0 RETURN PROC CHANGE_CHARSET() BYTE ARRAY NC0 = [255 128 128 128 128 128 128 255 255 1 1 1 1 1 1 255 ] CARD MEMTOP MEMTOP = RAMTOP - 8 MEMTOP = MEMTOP * 256 ZERO(MEMTOP,512) MOVEBLOCK(MEMTOP,57344,512) MOVEBLOCK(MEMTOP+8,NC0,16) CHBAS = MEMTOP/256 RETURN PROC MAIN() CARD SAVMSC=$58 BYTE I CHANGE_CHARSET() DLSETUP() FOR I = 0 to 120 STEP 2 DO POKE(SAVMSC+I,1) POKE(SAVMSC+I+1,2) OD DO OD RETURN (for some reason I can't edit the code portion, Change_Charset() and DLsetp() are in the wrong order in the main procedure) A couple of additional questions for Action! experts. Why is count set to [0] instead of 0? I'm beginning to understand that anything in brackets is not actually an array, but some sort of machine code instruction, but I'm not clear on why it's done this way (if you remove the brackets there's a different result.) Also, why is Coltable dimensionalzed with a size of 0? This is the only example I've seen where an inline array declaration dimensionalizes the array, much less saying it's empty when it has a size of 6.
  9. Finally figured this out, Mapping The Atari is your friend! RAMTOP is not a memory location, it's a page reference. Specifically where the Atari thinks the last page of memory is. Pages are 256 bytes long, so you multiply by it to the get the address. What does puzzle me is the RAMTOP-8 part, specifically the -8, I've seen other programs that use -16. I'm assuming this number can be larger depending on how much RAM you have installed?
  10. A different game, but I heard somewhere that the code for Flappy Bird is insanely simple. I mean, like Breakout simple.
  11. I wrote the following progam in Action! so that I could determine the exact coordinates of the screen in the Breakout-clone I'm writing to learn the system. Whenever the x or y coordinates are less than 100 the third digit switches between several different values, always in the same order. I'm not quite sure what causes this, but it reminds me of the energizers in Jawbreaker. Anyone have a clue on this? Also, does anyone have a better way of converting the byte values so they display correctly on the screen? BYTE PMBASE=$D407, RAMTOP=$6A, SDMCTL=$22F, GRACTL=$D01D, P0H=$D000, P0C=$2C0, P1C=$2C1, SP0=$D008, CHBAS = $2F4 CARD SAVMSC=$58 CARD POINTER MYPMBASE BYTE ARRAY CROSSHAIR = [56 16 56 16 56] BYTE XPOS, YPOS PROC SLEEP(BYTE ITS) BYTE I,J,K FOR I = 0 TO ITS DO FOR J=0 TO 10 DO K = 100/20 OD OD RETURN PROC init() ;variable declarations CARD PMTOP ;code PMTOP = RAMTOP - 8 PMBASE = PMTOP MYPMBASE = PMTOP * 256 GRAPHICS(1) SETCOLOR(0,5,7) SETCOLOR(1,1,10) SETCOLOR(2,10,5) SETCOLOR(3,13,2) SETCOLOR(4,0,0) SDMCTL = 46 GRACTL = 3 XPOS = 100 YPOS = 100 P0H = XPOS P0C=88 RETURN PROC SETUP_PMGRAPHICS() Zero(MYPMBASE+512,128) MoveBlock(MYPMBASE+512+YPOS,CROSSHAIR,5) RETURN PROC CHANGE_CHARSET() CARD MEMTOP = MYPMBASE BYTE ARRAY NC1 = [255 128 128 128 128 128 128 255] BYTE ARRAY NC2 = [255 1 1 1 1 1 1 255 ] ZERO(MEMTOP,512) MOVEBLOCK(MEMTOP,57344,512) MOVEBLOCK(MEMTOP+2*8,NC1,8) MOVEBLOCK(MEMTOP+3*8,NC2,8) CHBAS = MEMTOP/256 RETURN PROC DRAW_BRICKS() BYTE I FOR I = 0 to 119 STEP 2 DO POKE(SAVMSC+I,2) POKE(SAVMSC+I+1,3) OD RETURN PROC MAIN() BYTE STVAL,I CHAR ARRAY XCORD(4),YCORD(4) INIT() CHANGE_CHARSET() SETUP_PMGRAPHICS() DRAW_BRICKS() DO STVAL=STICK(0) IF STVAL=11 THEN XPOS = XPOS -1 FI IF STVAL=7 THEN XPOS = XPOS + 1 FI IF STVAL=14 THEN ZERO(MYPMBASE+512+YPOS,5) YPOS = YPOS - 1 MoveBlock(MYPMBASE+512+YPOS,CROSSHAIR,5) FI IF STVAL=13 THEN ZERO(MYPMBASE+512+YPOS,5) YPOS = YPOS + 1 MOVEBLOCK(MYPMBASE+512+YPOS,CROSSHAIR,5) FI P0H=XPOS STRB(XPOS,XCORD) STRB(YPOS,YCORD) FOR I=0 TO 3 DO XCORD(I) = XCORD(I) - $20 YCORD(I) = YCORD(I) - $20 OD MOVEBLOCK(SAVMSC+600,XCORD+1,3) MOVEBLOCK(SAVMSC+605,YCORD+1,3) SLEEP(5) OD RETURN
  12. I was just re-reading the section of De Re Atari which disusses the way that scanlines and such work; I've been kind of annoyed how PM graphics can go beyond the visible side of the screen. But then I remembered something, the invisible area right beneath the screen is where Closed Captions are stored (at least in NTSC TVs). Has anyone played around with this? I know the screen buffer won't let you write to these areas, but you can move a player there. Has anyone played around with this? Sadly the VMU I have my 800XL connected to doesn't have CC capability.
  13. Is there any way to detect collisions between the color in register 0 and a player object? Everything I've read so far says that only collisions with the colors from Registers 1-4 can be detected. However I ran across a message on this forum which suggested that in certian modes (17, I think) it's possible to detect these collisions. Alternatively, is there a way to change which registers the character set uses for color so I can detect a collision between a player object and a character? Otherwise I basically need to scrap all the code I've written and start over.
  14. Here is the full code. It's kind of embarssig, but I've only been coding on the Atari for a couple of weeks now. BYTE PMBASE=$D407, RAMTOP=$6A, SDMCTL=$22F, GRACTL=$D01D, P0H=$D000, P1H=$D001, P0C=$2C0, P1C=$2C1, SP0=$D008, SP1=$D009, POKR=$D20A, CHBAS = $2F4, P0COL = $D005, IN_PLAY, HITCLR = $D01E CARD SAVMSC=$58 CARD POINTER MYPMBASE DEFINE TRUE="0" DEFINE FALSE="1" BYTE XPOS BYTE BALLX BYTE BALLY BYTE STUCK INT VECTORX INT VECTORY BYTE ARRAY GBAT = [255 129 255] BYTE ARRAY GBALL = [0 8 28 8 0] PROC SLEEP(BYTE ITS) BYTE I,J,K FOR I = 0 TO ITS DO FOR J=0 TO 10 DO K = 100/20 OD OD RETURN PROC init() ;variable declarations CARD PMTOP ;code XPOS = 228-PADDLE(0) BALLX=XPOS+4 BALLY=97 STUCK=TRUE VECTORX=1 VECTORY=-1 GRAPHICS(0) SETCOLOR(2,0,0) SETCOLOR(4,2,8) PMTOP = RAMTOP - 8 PMBASE = PMTOP MYPMBASE = PMTOP * 256 XPOS = 228-PADDLE(0) BALLX = XPOS+4 BALLY = 97 STUCK = TRUE VECTORX = 1 VECTORY = -1 SDMCTL = 46 GRACTL = 3 P0H = XPOS P1H = BALLX IN_PLAY=TRUE RETURN PROC setup_pmgraphics() SP0=1 Zero(MYPMBASE+512,128) MoveBlock(MYPMBASE+512+100,GBAT,3) Zero(MYPMBASE+640,128) MoveBlock(MYPMBASE+639+BALLY,GBALL,4) P0C = POKR P1C = POKR RETURN PROC CHANGE_CHARSET() BYTE ARRAY NC1 = [255 128 128 128 128 128 128 255] BYTE ARRAY NC2 = [255 1 1 1 1 1 1 255 ] BYTE ARRAY NC3 = [126 70 66 66 66 66 66 126] BYTE ARRAY NC4 = [66 66 66 126 98 98 98 98] BYTE ARRAY NC5 = [126 66 64 126 6 6 70 126] BYTE ARRAY NC6 = [16 16 16 24 24 24 24 24] BYTE ARRAY NC7 = [126 16 16 16 24 24 24 24] BYTE ARRAY NC8 = [16 16 16 24 24 24 0 24] BYTE I CARD POINTER J, OLD_START CARD MEMTOP MEMTOP = MYPMBASE ZERO(MEMTOP,512) FOR I = 0 TO 512 DO J = MEMTOP + I OLD_START = CHBAS + I J^ = OLD_START^ OD MOVEBLOCK(MEMTOP+8,NC1,8) MOVEBLOCK(MEMTOP+16,NC2,8) MOVEBLOCK(MEMTOP+24,NC3,8) MOVEBLOCK(MEMTOP+32,NC4,8) MOVEBLOCK(MEMTOP+40,NC5,8) MOVEBLOCK(MEMTOP+48,NC6,8) MOVEBLOCK(MEMTOP+56,NC7,8) MOVEBLOCK(MEMTOP+64,NC8,8) CHBAS = MEMTOP/256 RETURN PROC draw_bricks() BYTE I FOR I = 0 to 239 STEP 2 DO POKE(SAVMSC+I,1) POKE(SAVMSC+I+1,2) OD RETURN PROC display_message() BYTE ARRAY MSG = [3 4 0 5 4 6 7 8] MOVEBLOCK(SAVMSC+495,MSG,8) RETURN PROC DESTBRICK(BYTE COL, BYTE ROW) CARD SAVMSC=$58 CARD TARG TARG = ROW*40 + COL*2 ZERO(SAVMSC+TARG,2) RETURN PROC DBXY(BYTE X, BYTE Y) BYTE ADJX, ADJY, COL, ROW ADJX = X - 40 ADJY = Y - 10 COL = ADJX/8 ROW = ADJY/10 DESTBRICK(COL,ROW) RETURN PROC COLDEC() BYTE OCCUR BYTE ARRAY MSG = "Collision!" OCCUR = PEEK(P0COL) IF OCCUR > 0 THEN MOVEBLOCK(SAVMSC+495,MSG,10) ZERO(HITCLR,1) ELSE ZERO(SAVMSC+495,10) FI RETURN PROC main() init() ;Boilerplate CHANGE_CHARSET() draw_bricks() setup_pmgraphics() ;initalize player missile graphics ; main loop WHILE 1=1 DO XPOS = 228-PADDLE(0) P0H = XPOS ;Set the value of STUCK to false if the button is pressed. IF IN_PLAY=TRUE THEN IF PTRIG(0)=0 AND STUCK=TRUE THEN STUCK=FALSE FI IF STUCK=TRUE THEN BALLX = XPOS+4 ELSE SLEEP(5) BALLX = VECTORX + BALLX IF VECTORY = -1 THEN MoveBlock(MYPMBASE+639+BALLY,MYPMBASE+640+BALLY,3) ZERO(MYPMBASE+642+BALLY,1) ELSE MoveBlock(MYPMBASE+639+BALLY,GBALL,4) FI BALLY = VECTORY + BALLY FI P0C = POKR P1C = POKR P0H = XPOS P1H = BALLX IF BALLX > 200 THEN VECTORX = -1 FI IF BALLX < 40 THEN VECTORX = 1 FI IF BALLY > 110 THEN DISPLAY_MESSAGE() IN_PLAY=FALSE ZERO(MYPMBASE+639+BALLY,5) FI IF BALLY <= 10 THEN VECTORY = 1 FI COLDEC() FI OD RETURN
  15. Not quite sure what I did wrong, but: BYTE OCCUR BYTE ARRAY MSG = "Collision!" OCCUR = PEEK(P0COL) IF OCCUR > 0 THEN MOVEBLOCK(SAVMSC+495,MSG,10) ZERO(HITCLR,1) ELSE ZERO(SAVMSC+495,10) FI Causes a minature version of everything (playfield, graphics, etc) to appear in the center of the screen. It stays in sync with the larger version as well. Has anyone ever seen anything like this? The only thing I can think of is that it might have something to do with graphic modes and interrupts, but I don't know much about how those work.
×
×
  • Create New...