Primordial Ooze

Now that all the reproduction carts are sold, will you provide the game rom for download? Sincerely, Primordial Ooze

We it's been almost a month and 100+ views and not a single reply has been made. There has been 13 downloads of the source code, yet still no solutions? Can someone please look into this as i really want to start this up again. Sincerely, Primordial Ooze

I am using Eckhard Stolberg's light gun detection routing modified to work on the right controller port. However for some reason the detection code doesn't work as the cross-hair sprite isn't moved to where the player fired his light gun. I have tested my lightning with his GUNTEST binary to verify that my light gun isn't at fault and verified that the light gun is working. I have attached the latest version of my source code for reference. Any assistance in this matter would be greatly appreciated. Sincerely, Primordial Ooze

I'm glad you got it working! Persistence pays off. Now I wish I had a light gun. It sorta works the lightgun detection code isn't determining the correct position of the lightgun, in fact the crosshair isn't being shown at all . By the way how many people actually have lightguns? Sincerely, Primordial Ooze

Thank you very much!!! Finally after a whole week trying to get it to work i finally managed to do it. I followed your suggestions now as well as cycle counting everything and now it works. With that in mind I would like to release the updated binary and source code as a Christmas present. Link MERRY CHRISTMAS! Primordial Ooze

Sorry about that. Believe it or not I've never had any problems with running out of cycles so I've never really need to know the difference in cycles and thus never learned the difference between ZP and ABS addressing. Thanks for that link. It's still a bit confusing but here gos: Cite: Link I have attached the source code with the corrected timing cycles. Please let me know if i am correct. Sincerely, Primordial Ooze

No! I'm telling you that ZP and ABS are two different addressing modes and you must put the correct number of cycles down for each. So which one is ZP and which one is ABS? Sorry I'm still a little new to this. Sincerely, Primordial Ooze

All my code fits in a single page so basically your telling me to change all the sta's cycles to 4's? Sincerely, Primordial Ooze

What do you mean sta zp? I don't remember seeing lda #1 sta zp Anywhere in my code. Ok fixing. Sincerely, Primordial Ooze

Thanks for the encouraging words. When all looked bleak you picked me up and helped me on my way. I'm not gonna give up, not yet! Thanks i have done a paramilitary cycle count and would like to know what the next step would be to fix the graphical errors. I have attached the latest version of the source code for reference.

I'll never work! First off this is quite an advanced game requiring custom lightgun code. Second on a 4k Batari rom your only left with 2k of rom space. Third Batari is only useful for learning to code simple games(NO OFFENCE!). Finally i'm quite experienced with assemble language as i have created c64 and spectrum 48k games in assembly language. Sincerely, Primordial Ooze

Its what you have to do in order to make a viable game on the 2600. There are good online resources to help you and the 6502/6507 datasheet is online too. Well i've tried to move the code around to no avail. I am at a point where the project has come to a complete stop. I was hoping to have something to show for the Christmas season, but it looks very bleak. Sincerely, Primordial Ooze

That seems like a lot of work. This project is starting to get the best of me and i may end up abandoning it. Isn't there another way besides counting cycles? Sincerely, Primordial Ooze

Thanks for that image. I read the tutorials and know how a game image is drawn on a tv screen. However i'm having a bit of difficulty trying to associate the timing with my code as my project is getting quite complex! Anyway based on the image and the following quote Session 2: My guess is the code should be between dey ; subtract one off the line counter thingy bne ScanLoop or ScanLoop sta WSYNC Please let me know if i'm correct and advise me which one is the correct answer. Any assistance would be greatly appreciated. Sincerely, Primordial Ooze

When I run it in Stella and step through the program in the debugger, it looks like GRP0 is being set before the scanning beams reach the duck, but COLUP0 is being set after the scanning beams have passed the duck, so it's probably related to timing more than anything. I don't know if the duck will always be at the same spot on the screen or will be moving around on the screen. If it will always be at the same spot then you may just need to update the x index before you load the colors, or rearrange the color table a bit-- in other words, when you set GRP0 to the left of the duck, you're setting the graphics for that line, but when you set COLUP0 to the right of the duck, you're setting the color for the *next* line, if you see what I mean. Otherwise, if the duck will be moving around on the screen, you'll want to see if you can reorder some of the instructions so GRP0 and COLUP0 are always set during the HBLANK period. Ok, where exactly in code does the horizontal blank period occur? Is it the part of the code where the controller checking and game logic occurs considered the horizontal blank period? Any assistance would be greatly appreciated. Sincerely, Primordial Ooze

Thanks, i managed to do exactly what you said and got a stable scanline count. What i would like to know is if i did it correctly because for some reason, my player0 is slightly messed up having pixels where there shouldn't be(see beak) and colors that shouldn't be(beak is black, back of head color is incorrect). Once we manage to get these bugs fixed i will test it on a real atari and let you know the results. Any assistance would be greatly appreciated. Sincerely, Primordial Ooze

No! If your kernel takes exactly 76 cycles per scan line you don't need a WSYNC. Ok well i added the additional WSYNC as per your instructions and it didn't seem to make a difference. Could please take a look and see what I'm doing wrong as after trying to figure it out by myself and posting the source code a few time, i really seem to be between a rock and a hard place. Any assistance would be greatly appreciated. Sincerely, Primordial Ooze

By working out the CPU cycles for the work required in the game. There is no other way on the 2600. So what your saying is a 2/3/4 line kernal is simply additional WSYNC's in the correct cycle count places? Sincerely, Primordial Ooze EDIT: I added an additional WSYNC where the 2nd line should start along with a comment on it and it still doesn't seem to solve my problem. I have attached the latest revision of my source code.

I was thinking about upgrading my kernel into a 2 line kernel as stated above you said adding WSYNC randomly will make my kernel unrobust. So how do i start in terms of creating a 2 line kernel? Sincerely, Primordial Ooze

If you can't fit the work required into one scan line you need to create a 2, 3, or 4 line kernel (as required) for your game. You need to work out how many cycles the code for each scan line will take. If you randomly add WSYNCs you won't end up with a robust kernel. Ok, so where exactly do i start? Sincerely, Primordial Ooze

Sorry i was very busy today doing a million things at a time! It's attached this time! Nope, no wonder why the screen went all black... EDIT:Fixed How exactly would i do that cause at this point I'm completely stumped. All i'm doing is displaying 2 sprites and a playfield nothing too complex. Are you saying if i add 2 WSYNC's will solve my problem cause i'm been at it for a bit now.

I changed all the loops that used the INTIM register to bpl like you said and now all i'm getting is a black screen. The 199 lines timer code is related to the lightgun routine posted by Eckhard Stolberg and not my code. I also changed that code to 191 lines and still am getting a black screen. It seems like we are going backwards instead of forwards. I have attached the modified source code for reference. Any assistance would be greatly appreciated. Sincerely, Primordial Ooze

You forgot to add your attachment. -B Sorry, it's been attached now. Sincerely, Primordial Ooze

Hi, I just finished adding the crosshair sprite into the game and am having difficulties. For some reason when i added the code for the crosshairs, my scanline count went up to 343 which is way too high. I figured it had something to do with the lightgun detection code and disabled the call to the routine, except my scanline count remained the same at 343. I can't see how displaying 2 sprites will cause the scanline count to jump to 343. I have attached the latest version of the source code for reference. Any assistance would be greatly appreciated. Sincerely, Primordial Ooze

Update: Post has been moved to the 2600 programming section to keep the thread less cluttered and on topic. Sincerely, Primordial Ooze