atariksi Posted December 13, 2008 Share Posted December 13, 2008 but you haven't show 8+ sprites at 60hz ? I did show you a method of replicating HPOSes at 60hz, but Y positioning is limited. But they still are sprites. Link to comment Share on other sites More sharing options...
atariksi Posted December 13, 2008 Share Posted December 13, 2008 ...I stated CIA IRQ not copper-based irq. Copper is another hardware aspect which Amiga > Atari since it can modify the registers for you without involving CPU. Also note that Copper triggered IRQs have to be aligned on 4 low-res pixels (3.58Mhz/4). You came up with POKEY timer IRQs to have IRQs at exact screen positions. Copper IRQs just do that. It doesn't really matter if you use CIA, POKEY or Copper since it's the result what matters. I don't think it matters how video is encoded as long as the irq occurs consistently on a given pixel. Then I would please have an IRQ at the 3rd pixel in the topmost line please. .... You can have an IRQ at any tick of the 1.79Mhz which corresponds to two cycles at the 3.58Mhz color burst. The only time there's an exception is when you use the IRQ timer for display purposes then you have to take care that you arrange the IRQ to avoid the DMA refresh cycles or other DMA depending on the mode. >>I claim you CANNOT hit every 8th pixel on C64 consistently. C64 is less accurate regardless of where on the display. The 0.985Mhz is not accurate enough to do horizontal splits at any arbitrary 8th pixel. I don't think it can do every 16th pixel. >Both on Atari and C64 you have to sync the CPU to the display. IRQs don't do that, they can only set an IRQ flag at a certain point of display, but the CPU needs a delay from 0...7 cycles to actually react to that flag because it has to end the current opcode first. All split examples on A8 I've seen use WSYNC to sync the CPU 100% to display AFTER the IRQ. And then either WSYNC every line or cycle counting. On C64 it's similar, just that you don't have WSYNC and need timers/double-IRQs/DMA-cut etc for syncing. Once the CPU is in sync which can be done ONE TIME in the beginning of the IRQ, it will stay in sync until the end of the IRQ. That's how those demos doing register splits work. There's three methods to do sync mentioned in this thread-- WSYNC, kernels, and IRQ method (which I gave source code to). I just did a DLI and aligned the background code and EVEN THE DLI IS STABLE without using WSYNC! >I can't believe that I still reply to this. There are thousands of demos on C64 which place STA's at hundreds of accurate positions on the display. Every demo opening sideborder does it, every demo doing color split bars does it, every demo splitting modes does it, every demo doing FLI-modes does it etc etc. ... All I stated was that it was less accurate on C64. >In fact it's far more common to do it on C64 than it is on A8. More common does not mean better. Link to comment Share on other sites More sharing options...
Fröhn Posted December 13, 2008 Share Posted December 13, 2008 Then I would please have an IRQ at the 3rd pixel in the topmost line please. You can have an IRQ at any tick of the 1.79Mhz which corresponds to two cycles at the 3.58Mhz color burst. The only time there's an exception is when you use the IRQ timer for display purposes then you have to take care that you arrange the IRQ to avoid the DMA refresh cycles or other DMA depending on the mode. Again: The color burst does not matter. PAL A8 has 4.43 MHz color carrier freq but 1.77 MHz POKEY and CPU clock. Notice something? There's three methods to do sync mentioned in this thread-- WSYNC, kernels, and IRQ method (which I gave source code to). I just did a DLI and aligned the background code and EVEN THE DLI IS STABLE without using WSYNC! Then add some real code in the main program, or add a music. It's pseudo stable. Happens on C64 too if you use JMP as main loop and the remaining rastertime is dividable by 3. All I stated was that it was less accurate on C64. Which is only true in empty rasterlines. Once you enable a gfx mode... I claim you CANNOT hit every 8th pixel on C64 consistently. C64 is less accurate regardless of where on the display. The 0.985Mhz is not accurate enough to do horizontal splits at any arbitrary 8th pixel. I don't think it can do every 16th pixel. 0.985 = 8 pixels/cycle. Or for NTSC C64: 1.02 MHz = 8 pixels/cycle. Link to comment Share on other sites More sharing options...
Crazyace Posted December 13, 2008 Share Posted December 13, 2008 Here's an example of 26 players.PAL 50Hz. Cool - still only 4 players per line. Is there a bug? It looks like the colours are incorrect on some lines ( swapped between the 2 multicolour playerpairs ) or is that just a problem on the emulator Link to comment Share on other sites More sharing options...
Crazyace Posted December 13, 2008 Share Posted December 13, 2008 I claim you CANNOT hit every 8th pixel on C64 consistently. C64 is less accurate regardless of where on the display. The 0.985Mhz is not accurate enough to do horizontal splits at any arbitrary 8th pixel. I don't think it can do every 16th pixel. 0.985 = 8 pixels/cycle. Or for NTSC C64: 1.02 MHz = 8 pixels/cycle. For A8 : 1.79 = 4pixels/cycle, so really the A8 is more accurate than the c64 in this case. Link to comment Share on other sites More sharing options...
emkay Posted December 13, 2008 Share Posted December 13, 2008 Here's an example of 26 players.PAL 50Hz. Cool - still only 4 players per line. Is there a bug? It looks like the colours are incorrect on some lines ( swapped between the 2 multicolour playerpairs ) or is that just a problem on the emulator I'd have no problems with 4 player per scanline, If only the game behind it makes fun. Thousand sprites are not guaranteeing any gaming fun, but A proper relation between moving objects and gamelogic can. Link to comment Share on other sites More sharing options...
Fröhn Posted December 13, 2008 Share Posted December 13, 2008 For A8 : 1.79 = 4pixels/cycle, so really the A8 is more accurate than the c64 in this case. And that's what I am talking about all the time: In display area every 2nd cycle is ANTIC DMA which means: CPU can at best react on 8 pixels accuracy. And ofcourse this all doesn't really matter since the CPU IRQ jitter will add 0...7 cycles wait first, or 0...14 in ANTIC display area. I feel like a repeating vinyl... Link to comment Share on other sites More sharing options...
atarian63 Posted December 13, 2008 Share Posted December 13, 2008 This thread and the 'Amiga Sub-Forum' thread are now the top two... WTF?!? Did the Commodore guys decide to razz the Atari guys this Christmas? If it continues, us hardcore Atarians might have to stir up some shit on the Commodore forums... Sounds like fun though not really appreciated here so why be crappy during Christmas? Lets do it after Christmas! Link to comment Share on other sites More sharing options...
Tezz Posted December 14, 2008 Share Posted December 14, 2008 Cool - still only 4 players per line. Is there a bug? It looks like the colours are incorrect on some lines ( swapped between the 2 multicolour playerpairs ) or is that just a problem on the emulatorThe routine is useable within a game environment as it allows free use of the players anywhere on the screen, the colours are also independent like the positioning. There are several aproaches to plex the players for game use. If the game in question is more straight forward, a less flexible simple routine can be used instead and does not produce as much flicker and the colour line discrepancies you can notice in the previous example. The path they track is purposely keeping them enough apart in the example. I've attached the Our5oft demo "Unity" (I think it's been mentioned here before) if you watch the demo through for a few minutes, you'll see eight 3 colour players over the 3 mode screen at the bottom using the more common method. They are not changing the colours in their routine. I'll need to put something together to demonstrate several players together on the same line, I'm working still on the ongoing projects. Unity.zip Link to comment Share on other sites More sharing options...
Crazyace Posted December 14, 2008 Share Posted December 14, 2008 I'll need to put something together to demonstrate several players together on the same line, I'm working still on the ongoing projects. No problem, dont take time out specially - If I need something I'll just write my own code Link to comment Share on other sites More sharing options...
Barnacle boy Posted December 14, 2008 Share Posted December 14, 2008 We say it time and time again that most of Atari ML games run faster and smoother because it running at higher speed. Even with some DLIs and player/missile multiplexing routines, still runs quick. It does take a lot to bog down the A8 down to an equivalent speed as a Commodore 64. By that time it probably is running something that exceeds the # colors + sprites capable from theC64. Really? Can you show me some Atari games similar to c64 games like Katakis and Armalyte? If what you're saying it true, then the Atari should have games like these that run at the same speed (50fps) and have even MORE sprites moving about! That sounds awesome! I'll be disappointed if it turns out that you're just talking up the Atari beyond its capabilities. Link to comment Share on other sites More sharing options...
atariksi Posted December 14, 2008 Share Posted December 14, 2008 For A8 : 1.79 = 4pixels/cycle, so really the A8 is more accurate than the c64 in this case. And that's what I am talking about all the time: In display area every 2nd cycle is ANTIC DMA which means: CPU can at best react on 8 pixels accuracy. And ofcourse this all doesn't really matter since the CPU IRQ jitter will add 0...7 cycles wait first, or 0...14 in ANTIC display area. I feel like a repeating vinyl... You need to be careful: "In display area in Gr.8 every 2nd cycle is ANTIC DMA". Lower resolutions have lower dma requirements and inserting blank lines give you almost every cycle. You can repeat mistakes as much as you want, it won't make any difference. There's no jitter regardless of how much code I write since I can adjust the IRQ routine or main code so that it's always aligned. If you apply what you write to yourself, you would agree the C64 can't do the horizontal split. Link to comment Share on other sites More sharing options...
atariksi Posted December 14, 2008 Share Posted December 14, 2008 ...I claim you CANNOT hit every 8th pixel on C64 consistently. C64 is less accurate regardless of where on the display. The 0.985Mhz is not accurate enough to do horizontal splits at any arbitrary 8th pixel. I don't think it can do every 16th pixel. 0.985 = 8 pixels/cycle. Or for NTSC C64: 1.02 MHz = 8 pixels/cycle. If your C64 was exactly 1.79/2 Mhz, I would accept the 8pixel accuracy. Since it's not evenly divided, you will have problems getting it to trigger off irq at exact point consistently. Link to comment Share on other sites More sharing options...
atariksi Posted December 14, 2008 Share Posted December 14, 2008 I claim you CANNOT hit every 8th pixel on C64 consistently. C64 is less accurate regardless of where on the display. The 0.985Mhz is not accurate enough to do horizontal splits at any arbitrary 8th pixel. I don't think it can do every 16th pixel. 0.985 = 8 pixels/cycle. Or for NTSC C64: 1.02 MHz = 8 pixels/cycle. For A8 : 1.79 = 4pixels/cycle, so really the A8 is more accurate than the c64 in this case. He does reluctantly accept it's more accurate, but for Gr.8 (320*200) he's not accepting. Anyway, here's code for Stable DLI (no WSYNC): ;Example of display list interrupt on atari 800/400/600XL/800XL/XE/XEGS © 2005-2007 KSI ;Compile and boot this as an image disk on your atari computer. If you boot with BASIC cartridge, ORG_ = 1529 CASINI = 2 ;for trapping reset vector VCOUNT EQU $D40B COLBK EQU 53274 WARMSTART = 58484 ;HDR_ = 6 ;DW 0FFFFh ;DW ORG ;DW LastOffset-1 DB 0,3 DW ORG_ DW StartAdr Rts Pla StartAdr: LDA 560 ;LSB of ptr to display list (DL) STA 203 LDA 561 ;MSB of ptr to display list (DL) STA 204 LDY #2 ;intr on 3rd item of DL NXTDLVAL: LDA (203),Y ;CMP #65 ;BEQ DLISET ;EOR #$80 ORA #$80 ;set DLI bit in ANTIC display list STA (203),Y ;AND #$70 ;CMP #64 ;BNE NOTLMS ;INY ;INY NOTLMS: ;INY ;BNE NXTDLVAL DLISET: LDA #0 STA 54286 ;NMIEN LDA #StableDLI,L STA 512 LDA #StableDLI,H STA 513 LDA #128 STA 54286 ;NMIEN Lda #0 Sta 580 Lda #1 Sta 9 Lda #StartAdr,L ;get LSB of StartAdr Sta CASINI Lda #StartAdr,H ;get MSB of StartAdr Sta CASINI+1 ;For text mode, subtract 24*40+192*40+32 (DList) = 8672+DLI routine ;27510 - DMA cycles IdleLoop: ;Nop Jmp IdleLoop ;rts Rts ;*** Our display list interrupt subroutine; OS does BIT 54287, BPL, JMP [512] so 4+2+5 = 11 cycles. H/W ;*** vector jump from [65530]. DLI = 25 cycles. ;*** VCount register is not as accurate as POKEY POT counter so we we can use the POT(4) to get 8-bit scan-line ;*** count 0..228. StableDLI: PHA ;3 cycles Lda #39 Sta 53274 ;Nop Lda #96 Sta 53274 PLA ;4 cycles RTI ;6 cycles LastOffset: ;DW 2E2,2E3,StartAdr Link to comment Share on other sites More sharing options...
Tezz Posted December 14, 2008 Share Posted December 14, 2008 We say it time and time again that most of Atari ML games run faster and smoother because it running at higher speed. Even with some DLIs and player/missile multiplexing routines, still runs quick. It does take a lot to bog down the A8 down to an equivalent speed as a Commodore 64. By that time it probably is running something that exceeds the # colors + sprites capable from theC64. Really? Can you show me some Atari games similar to c64 games like Katakis and Armalyte? If what you're saying it true, then the Atari should have games like these that run at the same speed (50fps) and have even MORE sprites moving about! That sounds awesome! I'll be disappointed if it turns out that you're just talking up the Atari beyond its capabilities. More than likely you haven't been reading this 2000+ post thread or maybe this recurring subject of computer comparisions and the endless debate which arises like a recurring nightmare. To cut a very long story short... due to the vastly smaller market place share of the A8 in the years best remembered by the other 8-bit platforms, there have not been many programmers pushing the A8 and it was left neglected. Due to it's earlier architecture it is not straight forward in it's use of colours and available hardware sprites. It is powerful in many ways yet limited and restrictive in these things that the other 8-bits have out of the box. In the commercial environment of the later years the 8-bits ruled, very few firms were willing to invest time on a platform with too few customers. Needless to say that in this modern era whilst there are enthusiasts taking it to the level it is capable of, there is more to come from the A8 then has been seen so far. Link to comment Share on other sites More sharing options...
Barnacle boy Posted December 14, 2008 Share Posted December 14, 2008 So in other words, there's nothing really that can justify a statement like: "It does take a lot to bog down the A8 down to an equivalent speed as a Commodore 64. By that time it probably is running something that exceeds the # colors + sprites capable from theC64." Link to comment Share on other sites More sharing options...
+MrFish Posted December 14, 2008 Share Posted December 14, 2008 More than likely you haven't been reading this 2000+ post thread or maybe this recurring subject of computer comparisions and the endless debate which arises like a recurring nightmare. I'm afraid to go to sleep now... Link to comment Share on other sites More sharing options...
Allas Posted December 14, 2008 Share Posted December 14, 2008 27 - FROGGER 2 Atari screenshots Another game well ported on both platforms. The screenshots show the differences about he color applied on the game. Both games are colorful, but Atari have painted with better detail. The playability on Atari is very very good, the frog moves quickly and smoothly. C64 screenshots Link to comment Share on other sites More sharing options...
Allas Posted December 14, 2008 Share Posted December 14, 2008 28 - GALAXIAN Atari screenshots Atari is the king of the classics. That's one of the reasons why I prefer this machine. But really C64 is a pain without his sprites, I can't believe how bad is the playability on the C64 version. C64 screenshots Link to comment Share on other sites More sharing options...
Goochman Posted December 14, 2008 Share Posted December 14, 2008 28 - GALAXIAN Atari screenshots Atari is the king of the classics. That's one of the reasons why I prefer this machine. But really C64 is a pain without his sprites, I can't believe how bad is the playability on the C64 version. C64 screenshots One thing I wish could be fixed on the Atari version is the 'sprite' for the Flagship or whatever (the yellow guy) - This is a great port ruined by a lazy programmer who didnt use a different shape for the boss guy................ Link to comment Share on other sites More sharing options...
Barnacle boy Posted December 14, 2008 Share Posted December 14, 2008 14 - GALAXIAN 28 - GALAXIAN Did you run out of contenders already? Link to comment Share on other sites More sharing options...
atarian63 Posted December 14, 2008 Share Posted December 14, 2008 14 - GALAXIAN 28 - GALAXIAN Did you run out of contenders already? Is this Oswald again? Link to comment Share on other sites More sharing options...
Crazyace Posted December 14, 2008 Share Posted December 14, 2008 The funny things is that when I first saw Galaxian I really didn't like it on the A8 - Galactic chase seemed more like the original Arcade game. ( Everyone I knew who had a BBC would go on about their version of Galaxian being the best ) Link to comment Share on other sites More sharing options...
MaPa Posted December 14, 2008 Share Posted December 14, 2008 but you haven't show 8+ sprites at 60hz ? Here some old demo http://atari.fandal.cz/detail.php?files_id=15. Link to comment Share on other sites More sharing options...
emkay Posted December 14, 2008 Share Posted December 14, 2008 I've attached the Our5oft demo "Unity" (I think it's been mentioned here before) if you watch the demo through for a few minutes, you'll see eight 3 colour players over the 3 mode screen at the bottom using the more common method. They are not changing the colours in their routine. I'll need to put something together to demonstrate several players together on the same line, I'm working still on the ongoing projects. This seems to be the only real Demo on the A8 for showing off the possibilities. It's not only the player multiplexer that shows more 3 colour "sprites" where others used one colour.... At the heidth of 4/7 of a 240 line screen. The mode splitting cost almost all cpu cycles in that range. Allthough you see the Big scroller above. You see a hires dot sine "software sprite" solution, you see the shinethrough ball over the 16 colour image and you see small animations in the figures at the right side of the screeen. Music is played aswell. ... 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