PacManPlus
-
Posts
6,089 -
Joined
-
Days Won
35
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Blog Comments posted by PacManPlus
-
-
Thanks, Eric, GroovyBee - and everyone else for the compliments :)Actually, I found the source code to the arcade game on line. So, I'm trying to see how much of it (if any) I can apply to the 7800 version. The only problem is, there are many things about z80 code I don't follow.Below is the 'IQ' module, which is the module for wall detection. Knowing that the 7800 does things *very* differently than the screen buffer of the arcade, I'm still trying to see if I can apply anything to this port:
.title "WALL DETECTER AND AVOIDANCE CONTROL".sbttl "FRENZY".ident IQ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~; Intelligence;_______________________________.insert EQUS; DURL refered to thru out this program stands for; Down,Up,Right,Left bits in directions and wall encoding.DOWN == 3UP == 2RIGHT == 1LEFT == 0;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~; Check walls and avoid them;_______________________________;a=new DURL, c=old DURL, ix->vector, iy->mansIQ:: push b ;save tracker push d mov l,D.P.L(x) ;get height thru mov h,D.P.H(x) ;pattern pointer mov e,m inx h mov d,m xchg mov d,a ;save DURL inx h ;skip x bytes mov a,m ;y lines (height) mov c,a ;for down test srlr a ;h/2 adi 1 ;(h/2)+2 mov e,a ;number of lines to test mov h,P.Y(x) ;get current position mov l,P.X(x); Regs: HL=YXpos, E=height, c=DURL to test; Down tests bit DOWN,d jz ..TU push h mov a,c ;height of pattern adi 3 ;margin of error add h ;offset to look mov h,a ;at for wall color push d mvi e,5 call testx ;check for white below pop d pop h jz ..TR ;if ok check right,left res DOWN,d ;else forget that direction jmp ..TR;up tests..TU: bit UP,d jz ..TR push h mvi a,-3 add h mov h,a push d mvi e,5 call testx pop d pop h jz ..TR res UP,d; jmp ..TR;right tests..TR: bit RIGHT,d jz ..TL push h mvi a,11 add l mov l,a push d call testy pop d pop h jz ..done res RIGHT,d jmp ..done;left tests..TL: bit LEFT,d jz ..done push h mvi a,-3 add l mov l,a push d call testy pop d pop h jz ..done res LEFT,d; jmp ..done..done: mov a,d ;final result DURL pop d pop b ret;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~; Test in X direction;_______________________________; input: h=Y, l=X, c=DURL; output: Z if robot color in that boxTestx: dcr l ;test -1 line inr e..x: call CheckBox rnz exaf ;save test results mov a,l ;get x adi 2 ;add 2 mov l,a exaf ;now return test results dcr e ;number of times to look jnz ..x ret ;returns Z;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~; Test in Y direction;_______________________________; input: h=Y, l=X, c=DURL; output: Z if robot color in that boxTesty: dcr h inr e..y: call CheckBox rnz exaf ;save test results mov a,h ;get Y adi 2 ;add 2 mov h,a exaf ;now return test results dcr e ;number of times to look jnz ..y ret ;returns Z;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~; Check pixel for use;_______________________________CheckBox: push h ;save YX call RtoAx# ;in hl out hl,a ani 0fh ;save shift&flop bit Flop,a jz ..fl xri 0Fh ;flip flop and shift..fl: xri 07h ;reverse shift di ;using magic out MAGIC res 5,h ;convert magic->normal addr mov a,m ;get normal screen sta TEMP+(1<13) ;magic scratch ei lda TEMP ;normal scratch ani 1 ;check it pop h ;restore YX ret;---------------+; get durl bits |;---------------+; input: h=x l=y; output: a=durl bits for room xy is in; used by man,robot to check for others in squareWallIndex:: mov a,l ;get y position sui 8 ;edge of first room mvi e,0 cpi 48 ;1st row jrc ..sk mvi e,6 ;2nd row cpi 48*2 jrc ..sk mvi e,6*2 ;3rd row cpi 48*3 jrc ..sk mvi e,6*3 ;4th row..sk: mov a,h ;x pos sui 8 ;edge of first room dcr e..xlp: sui 40 ;room x width inr e jrnc ..xlp xchg lxi b,WALLS ;->walls array mvi H,0 ;add index dad b mov a,m ;get durl for room xchg ret .end
For instance, the 'WallIndex' function - WTF is 'sui'? I get 'push' and 'pop' have to so with the stack (like PHA and PLA in 6802) 'mov' I also get, but some of it (lxi?) is really confusing me. I'll have to check some on-line resources of Z80 assembler. In the meantime, can anyone give me a nutshell version of what this is doing? The comments help, but they stop just short of aiding me in understanding what is going on.
-
@EricBall - Thanks for the info, but remember there are other things to consider (like if the *middle* of the sprite runs into a horizontal maze wall (or one with two 'bubbles' horizontally)... things like that.
@SpiceWare & Moycon - Thanks!... but I'm not even close to having something playable yet
@GroovyBee - I actually *have* special ordering of the indirect characters already (it took me a while to get this order)
You will see - moving from $80-$87 you have vertical, horizontal, vertical, horizontal, followed by 4 'L' shaped characters. The pattern then repeats, until $C0 where all of the extraneous maze pieces are. This way I can AND the character with $0F (after checking for a negative number so I know I hit a maze) and just check for $00/$02, $01/$03, and $04 or greater. The $C0 chars and above are special cases. Although I see that if I put the two vertical pieces as $00 and $01, and the two horizontal pieces as $02 and $03, I can AND the character with $0E and just check for $00, $02, and $04 (BPL).I was thinking of tables for the shots, depending on where they are hit, which character replaces the one that the shot collides with. Not sure how tables would help with this type of collision, though.
BTW, I am doing this in 320A mode, with 16 High (max) sprites.
Thanks,
Bob
-
Cool
I find I am similar to you, except my low end is 10:00.
Prince has two long songs that I actually listen to (every once in a while) completely through: America (12" version) 21:53 and Cloreen Baconskin 15:30. Good for long drives.
He also has a really funky B-side song "La, La, La, He, He, He" 10:43 which is on the flip side of the 12" for Sign-O-The Times.
KISS' 100,000 years (live version from Alive!) is 11:03
I occasionally listen to Donna Summer's Love to Love You Baby (16:53) and Try Me, I Know We Can Make It (17:55)
'Love to Love You' moreso because I love the breakdown of instruments down to the bass guitar only. They then bring the others back in one at a time. Those session musicians are very underrated and should have had more acknowledgement.
Led Zeppelin's live version of 'Dazed and Confused' lasting almost 27 minutes is a cool listen (if you like Jimmy Page's guitar)
I also make my own extended versions of songs (been doing that since I'm little) so if I don't like a remix or if one isn't available, I make my own.
-
Hey Jeff:
Very Cool!
You can absolutely post the editor whenever you are ready.
Thanks again for all your help -
Bob
-
Thanks for the kind words :)FWIW, I actually tried to get the tethering on Space Duel. The game suffers from slowdown when there are many 'rocks' on the screen, so trying to add the table lookup for tethering would have made it that much worse. So I dropped it.Actually, at the time I was programming this, I was in contact with Owen Rubin, who was giving me a few pointers from when he programmed the arcade game. He was trying to find the source code to handle the tethering, but he couldn't. He eventually ended up giving me a small list of things that weren't exactly like the arcade, once I sent him a 7800 and a Space Duel cart for helping me. :)BTW, thanks for the props on Asteroids Deluxe as well. The Killer Satellite was a pain to program! BTW, I didn't include the thrust in the original Asteroids 'hidden' game because I ran out of sprites.
-
There's the song "I" by KISS, it's on "Music From The Elder" (1981)
Madhouse, another Prince offshoot, had their album's titles reflect the number (i.e. Track 1 was called '1', Track 2 was '2' and so on). Not sure if that counts, only because they tended to spell out the titles ("One" instead of '1') From 1986.
-
Very nice
-
YES!!!! Looking forward to this
-
Hey Jeff:
Looks cool
I apologize for not getting you the information sooner. Not only am I making carts for Jr., but I'm making Super & SI for GoodDealGames. Plus I have to learn Java to program the Blackberry (real fast).
BTW, Super Pac-Man does graphics the same way as Jr.
The graphics for PMC, however does them the same way as the original 7800 Ms. Pac-Man. As far as I know this is the only game that GCC stored the graphics this way. (It was a real pain figuring that out in the very beginning). It's done that way because the actual used graphics are held in RAM and are just copied from the ROM to save space.
I will get you the decode information for 320B (320A is the same as the way Jr. & Super Pac is set up, just with 1 'bit-per-pixel' instead of 2.)
160x4 is (as you may have guessed) 4 bits-per-pixel and 320B is just an *insane* way of holding graphic data. It's something like every odd bit is adjacent graphic data... and even is the other half... I'll try and look at it when I get home and get you an example.
Thanks - and great work!
Bob
-
BTW, you should try holding down 'Pause' and the second player fire button while the monsters are being introduced in attract mode.
-
VERY NICE!
I like this. A Lot. Great work!
BTW, I'll try and get you those bitmap sprite definitions soon, just trying to figure out how to set up an example and explain it... Something I'm not good at doing.
Bob
-
Looks Great, Jeff
I didn't have time to see about changing Ms. Pac-Man to allow for vertical tunnels. Trying to get all of these carts made for Jr.
I beg to differ about the sprite hacking tools - there aren't *any* that will allow for all modes: 160x2, 160x4, 320A, and 320B. I personally use Tile Molester and hacked it a little to get it to work with 160x2 and 320A.
If you were to create functional Sprite Editor that can handle all four modes (there actually are more, but these are the most used) and put out source .byte data, I would be forever grateful.
I've been meaning to do that for 2 years. Never could get around to it. Bob
-
Hey Jeff:
Excellent work! I wish I had this when I was making the mazes
it would have went a lot faster.BTW, the Pac-Man Collection and Ms. Pac-Man store the mazes in the exact same way, just in half the size. Super Pac-Man is *completely* different, due to the odd layout of the maze itself.
Can't wait to see this in action!
Bob
-
Wow - only took me two years to pick it up and get back into it again. :-/
-
My condolences to you and your family.
-
Hey Walter:
I'll see if I can find some screen shots and take a look at it.
I'm adding as many options from the 2600 version as possible, so hopefully it won't get dull quick. I kind of wanted to keep this one at 16K, but I'll what I've got once I'm finished (I know it's a 32K bin at the moment, but I'm going to reduce it).
BTW, I am now about 3/4 done with what I set out to do, so I am now moving this to the 'Homebrew' forum and starting a thread there.
-
Thanks Walter
BTW - Nevermind about the sound issue. When I try it on the real thing, there's no delay.
I've added the UFO sound, and the UFO death sound. Just need to add the 'bonus ship' sound.
No update bin yet, as I want to start on the attract mode and selection screen.
-
More sounds added (Player death, Shot, Invader hit) - update in first post
... although there's one thing which puzzles me: It seems like the sounds are a frame behind the animation, no matter where I put the call to the sound subroutine in the main loop
Does anyone know what that may be?Bob
-
Thanks, Bob, and thank you Supercat
Ok - my beginning of working with sound for this game led me to a discovery: the invader's "march" sound isn't in time with the movement! Only the first few invader hits keep the same time, then they start to separate. This gap increases as more invaders are cleared from the screen. I always thought they were exactly the same. :-/
It's not that noticable in the arcade because of the 'delay' (the arcade actually moves one invader per frame). It is noticable here, but I think it's ok.
Update in first post.
(still, so far so good with the CPU cycles)
Bob
-
Ok, some good news now. I enabled 'Dual Player Mode' and the screen didn't jump with both players on the screen (shooting), both invader shots, the invaders, and the ufo!
I wish there was some way to tell how many cycles I have left before I start getting screen jumps / slowdowns.
Now I start to work on sound. Then 'attract mode'. Then player options.
Bob
-
Thanks Supercat - I guess I misread the code then.
Please don't be annoyed with me, but I just don't understand the DLI code that you wrote there.
This is the part that actually scares me; when I don't understand something I think I should, I truly feel like I'm becoming more stupid as I get older. *Especially since I am a programmer by trade* (although we use C, C++ and C#)
If I'm struggling with a simple game like Space Invaders, I can forget about doing anything more complicated :-/
-
Thanks again Walter
WE HAVE COLLISION DETECTION FOR INVADERS SHOTS!
This game is now actually playable
Supercat, I have not implemented your code yet (although I think I will have to, I can't have much CPU time left per frame). There might be one issue with it - If you recall, I am only using 8 pages of RAM for the Shield. There are 16 lines for the shield, therefore I started the first 8 rows in <$shields>, and added the last 8 rows in <$shields+$20> (being that each RAM line is only $20 long). Does the code you wrote assume all 16 rows of RAM are each contiguous page?Update in first post.
-
Thank you Supercat
Thanks Walter!!!
Ok - next step
Things Added:
1) UFO point table based on player's shot (but for now it doesn't match the arcade yet)
2) Slowed UFO down to more closely match arcade speed
3) Added Invader shots (no collision detection yet)
I need to work on the frequency of the invader shots.
In the arcade, they don't seem to *constantly* shoot at you. There seems to be a variable delay between them. Also, most of the invader shots seem to be in the player's general area, with one or two not so close. Need to try and replicate that.
Updated bin and screenshot in first post.
-
Sounds cool Allan
Ok, I've updated the following things:
1) Shots are not auto-fire (like the arcade) and delay when hitting something.
2) Invaders now start at the correct row for each level (had to do a little adjusting for the difference in the size of the screen)
3) YOU CAN NOW SHOOT BETWEEN INVADERS! did some closer collision detection, It may appear for a shot to go through the very edge of an invader but it seems to work ok.
Let me know if I should adjust anything. But, please remember, even though the bitmap for the invaders is based on 16 pixels (two bytes in 320A mode), everything is accessed as 8 pixels (two bytes in 160 mode). That caught me quite a few times while doing this.See first post for attachment.
Supercat: Can you elaborate on this line: "hit: ; Assume Y indicates where we are within the shot" Is this the y position of the shot within the 16-pixel shield area?
Also, is there a way I can use the interrupt to check if a console switch was hit and store the value in a variable?
...I'm saving the sound for last.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Difficulties with Frenzy's Maze
in PacManPlus' Blog
A blog by PacManPlus in General
Posted
Thanks again, Eric
I will be looking more at the code for the arcade version of Frenzy as I get more into the game logic.
I forgot to post this this morning:
Regarding the maze collision detection, *I GOT IT!*
I arranged the maze pieces like this:
$80-$8F = full horizontal width section
$90-$AF = "L" shaped sections
$B0-$BF = full vertical height sections
$C0-$CF = lower-left corner sections only
$D0-$DF = upper-left corner sections only
$E0-$EF = lower-right corner sections only
$F0-$FF = full character (like the power plant sections)
I then stripped the high bit and lower nybble, and shifted right twice. This leaves the two lower bits open for X and Y position within the character.
I shifted the X coordinate and the Y coordinate of the sprite within the maze cell character until I got it down to quarters:
It looks like this:
So if a certain point of the sprite occupies the top-right corner, it will be the "10" value.
That value got added in to the character cell above, and then it was just a table lookup for a $01 or $00 to see if it was valid or not.
For the X positioning, I had to look at every third raster, otherwise there were some spots where the player could move horizontally through a horizontal maze edge. The same applies to vertical checking.
I think I sill be ok, CPU Clock-Wise, as it looks like Frenzy/Berzerk only moves one robot per frame (that's why they start out slow and get faster as more are killed).
Here is the code (it works!) Please let me know what you think, and if you think it could be made more efficient:
; OBJECTPF - CHECK FOR OBJECT/PLAYFIELD COLLISION (ONLY APPLIES TO PLAYER / ROBOTS) SHOTS AND EVIL OTTO HAVE THEIR OWN ; INPUT: X - OBJECT NUMBER, MXLIST - X OFFSET TO MOVE, MYLIST - Y OFFSET TO MOVE ; OUTPUT: UPDATED MXLIST, MYLIST, A=0 OK TO MOVE IN DESIRED DIRECTION, A>0 NOT OK TO MOVE IN DESIRED DIRECTION ; USES: A, Y, TEMP0, TEMP1, (TEMP2, TEMP3 USED IN GETCHAR), TEMP4, TEMP5, TEMP6, TEMP7, TEMP8, TEMP9, TEMP10, TEMP11, TEMP15 OBJECTPF LDA OTLIST,X CMP #OTTOKILL ;IF THE OBJECT TYPE IS OTTO OR GREATER, SKIP BMI OPFCONT ;LESS? CONTINUE ON RTS ;NOPE - EXIT OPFCONT LDA #$00 STA TEMP4 ;HORIZONTAL EDGE (LEFT OR RIGHT - DEPENDS ON DIRECTION OF MOVEMENT) STA TEMP5 ;VERTICAL EDGE (TOP OR BOTTOM - AGAIN, DEPENDS ON DIRECTION OF MOVEMENT) STA TEMP6 ;RETURN FLAG TO INDICATE A COLLISION (0 = NO COLLISION, >0 = COLLISION) LDA MXLIST,X ;CHECK FOR HORIZONTAL MOVEMENT BNE OPFHORZ ;MOVING HORIZONTALLY; GO ON JMP OPFVERT ;NOT MOVING HORIZONTALLY; SKIP TO VERTICAL OPFHORZ BMI OPFHORZL ;MOVING LEFT, SKIP THIS NEXT PART LDA #$03 ;MOVING RIGHT; USE RIGHT EDGE OF OBJECT (POSITIONING IS STILL DONE IN 2-PIXEL INCREMENTS) STA TEMP4 OPFHORZL LDA #$00 STA TEMP15 ;THIS WILL BE USED TO CHECK EVERY TWO RASTERS TO SEE IF THERE IS A COLLISION LDA HPLIST,X ;GET THE HORIZONTAL POSITION CLC ADC TEMP4 ;ADD IN LEFT OR RIGHT EDGE ADC MXLIST,X ;ADD IN MOVEMENT STA TEMP8 ;SAVE NEW X POSITION FOR LATER JSR HTOC ;CONVERT TO COLUMN STA TEMP1 ;SET UP COLUMN VARIABLE FOR 'GETCHAR' LDA TEMP8 ;WE NEED THE HORIZONTAL OFFSET WITHIN THE CHARACTER AND #$02 ;THERE ARE 4 POSITIONS ACROSS (MOVES IN INCREMENTS OF 2), SO ONLY KEEP THE 2ND BIT STA TEMP10 ;THIS IS NOW THE HORIZONTAL POSITION OF THE OBJECT WITHIN THE SCREEN CHARACTER (LEFT = 00/RIGHT = 10) OPFLOOP LDA VPLIST,X ;GET VERTICAL POSITION CLC ADC TEMP15 ;ADD IN VERTICAL RASTER OFFSET STA TEMP9 ;SAVE NEW Y POSITION FOR LATER JSR VTOZ ;CONVERT TO ZONE STA TEMP0 ;SET UP ZONE VARIABLE FOR 'GETCHAR' LDA TEMP9 ;WE NEED THE VERTICAL OFFSET WITHIN THE CHARACTER AND #$04 ;THERE ARE 8 POSITIONS VERTICALLY, WE ONLY WANT 'TOP' AND 'BOTTOM', SO ONLY KEEP THE 3RD BIT LSR ;SHIFT RIGHT TWICE LSR STA TEMP11 ;THIS IS NOW THE VERTICAL POSITION OF THE OBJECT WITHIN THE SCREEN CHARACTER (TOP = 00/BOTTOM = 01) JSR GETCHAR ;GET THE CHARACTER AT THIS POSITION BPL OPFNEXT ;MAZE PIECES ARE ONLY NEGATIVE (> $80) AND #$70 ;STRIP OUT HIGH BIT AND LAST FOUR BITS LSR ;SHIFT RIGHT TWICE TO LINE UP WITH 'X' AND 'Y', WHICH WILL BE 'ORA'D IN LSR ORA TEMP10 ;OR THE X POSITION IN ORA TEMP11 ;OR THE Y POSITION IN TAY LDA OBJALLOW,Y ;SEE IF THIS POINT IS ALLOWED TO OCCUPY THE SPACE IT IS IN BEQ OPFNEXT ;YEP, NO COLLISION LDA #$00 ;NO, NOT ALLOWED TO MOVE IN THIS DIRECTION STA MXLIST,X INC TEMP6 ;INCREMENT COLLISION FLAG BNE OPFVERT ;WE CAN'T MOVE, NO NEED TO CHECK THE REST OPFNEXT INC TEMP15 ;ADD 3 TO TEMP15 INC TEMP15 INC TEMP15 LDY OTLIST,X ;GET OBJECT TYPE LDA OBJBE,Y ;GET OBJECT HEIGHT CMP TEMP15 ;ARE WE PAST IT? BPL OPFLOOP ;NO, CONTINUE OPFVERT LDA MYLIST,X ;CHECK FOR VERTICAL MOVEMENT BNE OPFVERT2 ;MOVING VERTICALLY; GO ON JMP OPFEXIT ;NOT MOVING VERTICALLY; EXIT OPFVERT2 BMI OPFVERTU ;MOVING UP, SKIP THIS NEXT PART LDY OTLIST,X ;MOVING DOWN; USE BOTTOM EDGE OF OBJECT LDA OBJBE,Y STA TEMP5 OPFVERTU LDA #$00 STA TEMP15 ;THIS WILL BE USED TO CHECK THE LEFT AND RIGHT SIDE OF THE OBJECT MOVING VERTICALLY LDA VPLIST,X ;GET THE VERTICAL POSITION CLC ADC TEMP5 ;ADD IN TOP OR BOTTOM EDGE ADC MYLIST,X ;ADD IN MOVEMENT STA TEMP9 ;SAVE NEW Y POSITION FOR LATER JSR VTOZ ;CONVERT TO ZONE STA TEMP0 ;SET UP ZONE VARIABLE FOR 'GETCHAR' LDA TEMP9 AND #$04 ;THERE ARE 8 POSITIONS VERTICALLY, WE ONLY WANT 'TOP' AND 'BOTTOM', SO ONLY KEEP THE 3RD BIT LSR ;SHIFT RIGHT TWICE LSR STA TEMP11 ;THIS IS NOW THE VERTICAL POSITION OF THE OBJECT WITHIN THE SCREEN CHARACTER (TOP = 00/BOTTOM = 01) OPFLOOP2 LDA HPLIST,X ;GET THE HORIZONTAL POSITION CLC ADC TEMP15 ;ADD IN HORIZONTAL EDGE STA TEMP8 ;SAVE NEW X POSITION FOR LATER JSR HTOC ;CONVERT TO COLUMN STA TEMP1 ;SET UP COLUMN VARIABLE FOR 'GETCHAR' LDA TEMP8 ;WE NEED THE HORIZONTAL OFFSET WITHIN THE CHARACTER AND #$02 ;THERE ARE 4 POSITIONS ACROSS (MOVES IN INCREMENTS OF 2), SO ONLY KEEP THE 2ND BIT STA TEMP10 ;THIS IS NOW THE HORIZONTAL POSITION OF THE OBJECT WITHIN THE SCREEN CHARACTER (LEFT = 00/RIGHT = 10) JSR GETCHAR ;GET THE CHARACTER AT THIS POSITION BPL OPFNEXT2 ;MAZE PIECES ARE ONLY NEGATIVE (> $80) AND #$70 ;STRIP OUT HIGH BIT AND LAST FOUR BITS LSR ;SHIFT RIGHT TWICE TO LINE UP WITH 'X' AND 'Y', WHICH WILL BE 'ORA'D IN LSR ORA TEMP10 ;OR THE X POSITION IN ORA TEMP11 ;OR THE Y POSITION IN TAY LDA OBJALLOW,Y ;SEE IF THIS POINT IS ALLOWED TO OCCUPY THE SPACE IT IS IN BEQ OPFNEXT2 ;YEP, NO COLLISION LDA #$00 ;NO, NOT ALLOWED TO MOVE IN THIS DIRECTION STA MYLIST,X INC TEMP6 ;INCREMENT COLLISION FLAG BNE OPFEXIT ;WE CAN'T MOVE, NO NEED TO CHECK THE REST OPFNEXT2 INC TEMP15 ;ADD 1 TO TEMP15 LDA #$03 ;RIGHT EDGE OF OBJECT CMP TEMP15 ;ARE WE PAST IT? BPL OPFLOOP2 ;NO, CONTINUE OPFEXIT LDA HPLIST,X ;SAVE HORIZONTAL POSITION AND COLUMN CLC ADC MXLIST,X ;OBJECT MOVEMENT STA HPLIST,X ;UPDATE HORIZONTAL POSITION LDA VPLIST,X ;SAVE VERTICAL POSITION, ZONE AND OFFSET CLC ADC MYLIST,X ;OBJECT MOVEMENT STA VPLIST,X ;UPDATE VERTICAL POSITION LDA TEMP6 ;LOAD 'A' WITH THE COLLISION FLAG RTS OBJBE .byte $0F,$0F,$0C,$0C,$01,$06,$06,$06,$0F,$0F,$06 OBJALLOW .byte $01,$01,$00,$00,$01,$01,$00,$01 .byte $01,$01,$00,$01,$00,$01,$00,$01 .byte $00,$01,$00,$00,$01,$00,$00,$00 .byte $00,$00,$00,$01,$01,$01,$01,$01I will post a WIP bin soon.
Thanks!
Bob