Heaven/TQA Posted January 6, 2002 Share Posted January 6, 2002 feel free to test it... still no game engine implemented but - pal/ntsc fix (eckhard... you are welcome...but colors not yet fixed) - the arcadish big sprites "READY" & "GO!" are implemented... beware... turn sound off... ;=) it is still far from completion but i am on my way... ;=) the hard things are done... (why are demo coders always spend more time on useless "moving sprites" routines than being on the game engine? ;=)) http://www.s-direktnet.de/homepages/k_nadj/a7800.html comments/critics welcome... Heaven Quote Link to comment Share on other sites More sharing options...
Eckhard Stolberg Posted January 7, 2002 Share Posted January 7, 2002 The game screen looks good now (except for the colours). I like the big messages. The lower square always shows the last line though, even if that square is disabled. The title screen still has some garbage lines at the bottom, but there are fewer than in your last demo. Ciao, Eckhard Stolberg Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 7, 2002 Author Share Posted January 7, 2002 hi eckhard, what do you mean exactly with "The lower square always shows the last line though, even if that square is disabled." ??? i hope not that the "bases" are gone when they are disabled. they should be dark... ("lum"=2 or 4) and thanks... i will check the logo... Quote Link to comment Share on other sites More sharing options...
Eckhard Stolberg Posted January 8, 2002 Share Posted January 8, 2002 If the bases should still be visible in the 'disabled' state, you should probably use a bit brighter colours. On my PAL system, they are hardly visible. I only noticed them when you told me that they should still be there. What I meant was this: The lower base is purple in PAL. It's square consists of several scanlines. In the 'disabled' state the last scanline of the lower square is still showing in bright purple. Maybe you forgot to update the last display list that contains this base? Ciao, Eckhard Stolberg Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 9, 2002 Author Share Posted January 9, 2002 aaaarg.... like @ cafeman... try the baby out on real machine not on emulators and the pain starts... ok. i will increase the luminance of the unlite bases... and the last scanline? maybe my dli switches to soon into $43 mode for the textlines... btw. why the hell is the dlis gone when not updating the vector after each vbl? i use the "jsr WaitVBLANK" from dan boris... but when using DLIs i have to set them directly after this call again & again otherwise they are gone f.e. jsr WaitVBLANK lda # sta dliv lda #>dli1 sta dliv+1 ... jsr WaitVBLANK lda # sta dliv lda #>dli5 sta dliv+1 NMI jmp (dliv) rti maybe because of acessing some hardware registers which resets the maria? ORG $4f00 WaitVBLANK: WaitVBoff: bit MSTAT bmi WaitVBoff WaitVBon: bit MSTAT bpl WaitVBon rts Quote Link to comment Share on other sites More sharing options...
Eckhard Stolberg Posted January 9, 2002 Share Posted January 9, 2002 Sorry, but I'm not sure that I fully understand your question. As long as you don't want to call a different interrupt routine, there should be no reason to rewrite the jump vector for your interrupt routine. The only problem that I could see would be if you were not using the right part of the RAM. Remember that you only have the area from $1800 to $27FF for RAM. And two 192 bytes large parts of that area are also mapped to be accessed from the zeropage and from the stack. So if you for example put your jump vector in the zeropage, and then overwrite the corresponding addresses in the $1800-$27FF area, it might appear as if the jump vector would get lost for no reason. Ciao, Eckhard Stolberg Quote Link to comment Share on other sites More sharing options...
+Propane13 Posted January 11, 2002 Share Posted January 11, 2002 quote: Originally posted by Heaven/TQA: aaaarg.... like @ cafeman... try the baby out on real machine not on emulators and the pain starts... Hey Heaven/TQA: I've had a little experience with the DLI. So, here's what I can tell you: 1) The 7800 Programming Manual is imprecise: DLI's occur after the last line of the previous zone is *READ* into Line RAM, and not when the last line of the previous zone is *WRITTEN* from Line RAM. So, if you have 16 scanlines in a "zone", because of the way Line RAM works, screen output will look like this: Read Line 1 Read Line 2, Draw Line 1 : ; ; Read Line 15, Draw Line 14 Read Line 16, Draw Line 15 Well, the DLI will occur when Line 16 is done being read, which means that it'll occur when the previous scanline (line 15) is being written to. So, that could be the cause of your "off by one" error, and leave the last scanline of your base lit when the button is pressed. A possible fix: If you have 16-line zones, make them 15-line zones preceded by a 1-line zone. In that 1-line zone, set up your DLI for the previous 15-line zone, but make the graphics go through the whole thing, i.e.: Graphics A ---- 1 Graphics B, and DLI for graphics A area ---- 1 Graphics B 2 Graphics B 3 Graphics B : 15 Graphics B ---- 1 Graphics C, and DLI for graphics B area ---- etc... 2) I'm not sure if I understand your second question, but yes: If you have DLI's going, make sure that your MainLoop has calls to JSR WaitVBlank. The reason for this is because you want all calculations happening during VBlank. If they happen when the screen is being drawn, then there can be some "process" issues. The DMA can fire up, and whatever you have in your accumulator could end up unpredictable (residue from a DLI being called, because the accumulator, x, and y are not saved on an ISR... only the status flags and return address are). So, the call to JSR WaitVBlank will keep your MainLoop synchronized at every 60Hz, which is good because you don't have to sample the joystick any more than 60x per second, and it will also prevent processor and DMA contention with a DLI. Of course, I have had experience with both of these problems, and have fixed them as best I could (as I've tried to suggest a solution) but the causes behind them are just theories. If anyone wants to add on/correct me, please feel free. AFAIK, the emulator ignores these real-time issue for now (At least the DOS one did). Still, I'm thankful that it's available (thanks Dan)! -John K. Harvey Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 11, 2002 Author Share Posted January 11, 2002 great info & tips. i check them out this weekend... c ya, guys in next version.... the next version will have - intro music (if the gyruss music will work i recieved from the star fire guys) - 1 player easy mode ready to play - the gfx bugs fixed more Quote Link to comment Share on other sites More sharing options...
Eckhard Stolberg Posted January 11, 2002 Share Posted January 11, 2002 @John: Your explainations sound plausible. But instead of making your DLL more complicated, I'd suggest using one more STA WSYNC. This will halt the processor until the start of the next scanline, which would solve your problem just as well. And if you are using interrupts, it's always good to save the acuumulator, the x- and the y-register to the stack and restore them just before the RTI. Otherwise there is always a chance that the interrupt might happen, when the state of one of there registers is still needed. The DMA halting the processor shouldn't be much of a problem, unless you are doing some timed action. But during the game calculation that is probably not very common. So there is no real need to cram the game calculations into the VBLANK time. You can also use a DLI at the end of the visible screen to call your game logic function. Ciao, Eckhard Stolberg Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.