Atari v Commodore

[emkay]

For A8 : 1.79 = 4pixels/cycle, so really the A8 is more accurate than the c64 in this case.

 

In double scanline mode (Gr.7) you have this every second scanline:

 

The double CPU clocks are there where Antic fills a whole scanline without any CPU work. Using such tricks on other 8bits results in a blank/blank line, where Antic is drawing from it's buffer instead.

So if people reach a count of 30 Softwaresprites in standard modes, you can push it up then to 4 times of them in double scanline mode.

 

It's no miracle that Space Harrier is that fast. But it's worth wondering why only Sheddy is using this as given.

[Heaven/TQA]

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

 

any chance to get binaries instead of the source???

[Heaven/TQA]

Here's an example of 26 players.

PAL 50Hz.

 

looks not bad...

 

any chance to get the sources, too? I would like to have a look... possible to move the sprites completly random? how much code is used? how much CPU time is left?

[Crazyace]

but you haven't show 8+ sprites at 60hz ?

 

Here some old demo http://atari.fandal.cz/detail.php?files_id=15.

 

Thanks, that's an interesting demo ( not sure if it's changing the colours on all the sprites, but it looks quite nice ) ...

 

B1 E2 W1 E2 S1 O2 F1 T2 ( 1/2 is the colour )

 

P0 P1 P2 P1 P0 P3 P2 P1 ( First P1 reuse is xpos only as graphic is same )

 

I haven't looked at the code, but that's how I'd do it

[Crazyace]

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.

 

 

...

 

The demo is really cool for the midline screen changes from 320 -> 80 -> 160 , but it's not showing more than 4 players per line ( The missile shine through effect is pretty nice )

[Crazyace]

For A8 : 1.79 = 4pixels/cycle, so really the A8 is more accurate than the c64 in this case.

 

In double scanline mode (Gr.7) you have this every second scanline:

 

The double CPU clocks are there where Antic fills a whole scanline without any CPU work. Using such tricks on other 8bits results in a blank/blank line, where Antic is drawing from it's buffer instead.

So if people reach a count of 30 Softwaresprites in standard modes, you can push it up then to 4 times of them in double scanline mode.

 

It's no miracle that Space Harrier is that fast. But it's worth wondering why only Sheddy is using this as given.

 

Do you really see a 4x improvement? Using antic D rather than E only saves you an extra 40 cycles every 2 lines?

[emkay]

The demo is really cool for the midline screen changes from 320 -> 80 -> 160 , but it's not showing more than 4 players per line ( The missile shine through effect is pretty nice )

 

It's a simple thing the PMs can be re-used, but when doing this on the graphics mode, there is not much time left per scanline.

 

Thinking about player handling, re using them per scanline and to do this at every frame, it would make sense to save cycles and memory by switching the player DMA off for using the shapes only...

 

In a scrolling action game you could do a real multiplexer then. Having the Protagonist to the left, all players could be re-used from the middle to the right of the screen... It would't take as much as CPU cycles than this graphics mode splitting.

[miker]

but you haven't show 8+ sprites at 60hz ?

 

Here some old demo http://atari.fandal.cz/detail.php?files_id=15.

 

Here are 8 sprites at single line, too.

(Bitter Reality - Dragonbobs part):

[emkay]

Do you really see a 4x improvement? Using antic D rather than E only saves you an extra 40 cycles every 2 lines?

 

And Antic draws a full scanline without CPU help. With "other 8Bits" you would have a blank line every second line. Or you would have to copy the previous line, which cost at least 200 cycles where the 6502 in the A8 can do almost 400 cycles for game-calculations...

[Heaven/TQA]

thanks Miker.... haven't watched Bitter Reality for ages... very cool!

 

Rzog Plasma is still one of the best incl. the msx...

 

the mega scroller after the rzog plasma is made by midline changes only... so you can see the DMA sucking in the first half of the screen...

Edited December 14, 2008 by Heaven/TQA

[Rybags]

Maybe not 4x.

 

Bitmap D vs E, you have a letoff every 2nd scanline where there's only 9 (refresh) instead of 50 DMA steals (assuming the preceding line has ordinary 1 DList + 9 refresh + 40 bitmap byte fetches).

 

Still, a significant saving.

 

Character modes aren't so generous. e.g. Mode 5 vs Mode 4. Since Antic doesn't buffer the bitmap fetches for reuse, it still fetches them every scanline. You only gain by having less "Badlines".

Even then, you don't save as much as you might think.

 

First line of character mode: 1 DList + 1 Refresh + 40 character + 40 charmap

Subsequent lines of character mode: 9 Refresh + 40 charmap

 

Interesting Demo there anyway. I'm currently working up another PMG assisted graphics mode. It'll use 4x stretched objects mixed with Mode E (Gr. 15 ).

It'll have overlap of P0/P1 and P2/P3 and the corresponding missiles in the centre part of picture. That covers 80 pixels of 160.

Then, reuse 2 of the players and reload of the graphics. Placed left and right of the centre objects will allow an extra 64 pixels.

 

End result will be pictures allowing (in the middle part) - 7 luma values with some restrictions by mixing PMG pairs in multicolour player mode, underlayed with normal mode E bitmap graphics. 5 luma values allowed for the rest of picture with the exception of the first and last 8 pixels.

 

 

The kinda sad part of the Antic design is the Refresh. Despite what many might argue, they would have been better placed starting near the extreme RHS of a normal display, then continuing into the HBlank period, instead of messing us up being near the left of screen.

Edited December 14, 2008 by Rybags

[Crazyace]

but you haven't show 8+ sprites at 60hz ?

 

Here some old demo http://atari.fandal.cz/detail.php?files_id=15.

 

Here are 8 sprites at single line, too.

(Bitter Reality - Dragonbobs part):

 

I like the party bit better , where the scroller is just changing the colbk

 

Again that's only moving the positions, leaving the graphics and the colours the same ... It's probally even easier , as the paired players share the same X coords

I think the dragon bob would be technically more impressive to me if the bobs/picture showed underneath the scrolling pm's in someway.

[Crazyace]

Do you really see a 4x improvement? Using antic D rather than E only saves you an extra 40 cycles every 2 lines?

 

And Antic draws a full scanline without CPU help. With "other 8Bits" you would have a blank line every second line. Or you would have to copy the previous line, which cost at least 200 cycles where the 6502 in the A8 can do almost 400 cycles for game-calculations...

 

Ok - I didn't realise you were including a line copy, makes sense now.

 

Wouldn't you be able to double lines on the C64 using a vscroll change each line? ( Again, this would be a question for Frohn, or Oswald ) - or use double height sprites?

Not as nice as Antic though in this situation.

[Crazyace]

The demo is really cool for the midline screen changes from 320 -> 80 -> 160 , but it's not showing more than 4 players per line ( The missile shine through effect is pretty nice )

 

It's a simple thing the PMs can be re-used, but when doing this on the graphics mode, there is not much time left per scanline.

 

Thinking about player handling, re using them per scanline and to do this at every frame, it would make sense to save cycles and memory by switching the player DMA off for using the shapes only...

 

In a scrolling action game you could do a real multiplexer then. Having the Protagonist to the left, all players could be re-used from the middle to the right of the screen... It would't take as much as CPU cycles than this graphics mode splitting.

 

I did think about this as a possibility for a 'nemesis' style game, but it would be limiting if you wanted left/right motion as well. I think software sprites for aliens may be better - maybe reusing players for laser shots.

[Crazyace]

thanks Miker.... haven't watched Bitter Reality for ages... very cool!

 

Rzog Plasma is still one of the best incl. the msx...

 

the mega scroller after the rzog plasma is made by midline changes only... so you can see the DMA sucking in the first half of the screen...

 

Didn't think of that - I thought it was intentional to show the technique wasnt just h/w scrolling

[Crazyace]

Interesting Demo there anyway. I'm currently working up another PMG assisted graphics mode. It'll use 4x stretched objects mixed with Mode E (Gr. 15 ).

It'll have overlap of P0/P1 and P2/P3 and the corresponding missiles in the centre part of picture. That covers 80 pixels of 160.

Then, reuse 2 of the players and reload of the graphics. Placed left and right of the centre objects will allow an extra 64 pixels.

 

End result will be pictures allowing (in the middle part) - 7 luma values with some restrictions by mixing PMG pairs in multicolour player mode, underlayed with normal mode E bitmap graphics. 5 luma values allowed for the rest of picture with the exception of the first and last 8 pixels.

 

 

The kinda sad part of the Antic design is the Refresh. Despite what many might argue, they would have been better placed starting near the extreme RHS of a normal display, then continuing into the HBlank period, instead of messing us up being near the left of screen.

 

Sounds interesting - about wide enough to implement an 'alternative reality' style display? Is it possible to combine it with a midline Antic F to Antic E switch? Then you could combine text with 8 colour 160res graphics

 

...I guess the refresh was put there as the cpu would be slow during display anyway... For me I'd have preffered 8 bit wide missiles ( even if they still shared the Player colours )

[Rybags]

There's all sorts of combinations you could do.

 

Using narrow DMA would probably unlock some more.

 

I did some playing around... once a Player has started to display, you're entirely free to reload it's graphic and position register.

So, with precise timing and good coding, you can have A/X/Y loaded with subsequent data that you'll need.

 

Time the first Store operation such that the last cycle of the instruction coincides around where the Player is starting.

 

I'm not sure if there's enough time to do another (ie a third) load/store of graf/position data. In such a case, the positional layout I have would probably need to change. Maybe we could position the first player such that only 6 bits of it is used, then we might have enough cycles freed up to move more stuff around.

Edited December 14, 2008 by Rybags

[Allas]

28 - HENRY'S HOUSE

 

Atari screenshots

 

In this game C64 did the best effort to create a multicolored game. Use many colors and use his ability to mix med and hi-res cells. Despite all, Atari is the best version because is more colored. A good technical example how Atari beat a C64.

 

C64 screenshots

Edited December 14, 2008 by Allas

[Albert]

I've never seen Henry's House. Looks like a pretty interesting game.

 

..Al

[potatohead]

The screen shot comparisons make this one of the best VS threads in a long while.

 

Thanks Alias!

[patjomki]

28 - HENRY'S HOUSE

 

In this game C64 did the best effort to create a multicolored game. Use many colors and use his ability to mix med and hi-res cells. Despite all, Atari is the best version because is more colored. A good technical example how Atari beat a C64.

 

O.K. In this thread we've seen a lot games that are better on ATARI than on C64, there have been mentioned a few that are better on C64 than on ATARI. There are a lot of games missing on ATARI, a few on C64 (e.g. Yoomp!) but can someone of the C64 fans give an example of an impressive CURRENT game (not older than 3 years).

 

I believe the lineup for games NOW is better on ATARI (until proven otherwise).

 

Regards,

 

patjomki

[Crazyace]

That last C64 screenshot with the skulls looks completely different from the others ... at first I thought it was a spectrum screenshot as it's all highres ( not multicoloured ) but it has the c64 sprites... strange.

The screen with the cuckoo clock and TV looks better on the C64, but others look better on the A8

[emkay]

That last C64 screenshot with the skulls looks completely different from the others ... at first I thought it was a spectrum screenshot as it's all highres ( not multicoloured ) but it has the c64 sprites... strange.

The screen with the cuckoo clock and TV looks better on the C64, but others look better on the A8

 

What makes me wondering most is that on the C64 the skulls are "smiling" and on the A8 they look "sad".

 

But in Henry's House some Hires even on the A8 could have been the cream on the pie

[Tezz]

Henry's House was always the good example of how more games should have been presented with effort on the A8. Chris Murray did a fine job with it. According to AtariMania Chris Murray has written that it originated on the C64 and was going to be called home sweet home hence the cross stitch looking logo on the title screen, I always wondered about that.

 

What makes me wondering most is that on the C64 the skulls are "smiling" and on the A8 they look "sad".

Strange. I never noticed the difference until they were shown side by side like that! Edited December 14, 2008 by Tezz

[atariksi]

...

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.

...

To be complete regarding Amiga timer IRQs, Atari IRQ is better than Amiga CIA IRQ. Amiga Copper is as accurate as Atari's IRQ (1.79Mhz; that should be 3.58Mhz/2 as low-res on amiga is hi-res on atari 8-bit). So Amiga copper method>Atari since it does not have the refresh/DMA to worry about. It's not all the same since IRQ routine executes code whereas copper lets you write to custom chips located from $DFF000...$DFFFFF). You can trigger off IRQ from a Copper instruction but it still flickers between pixels (I tried it) although it does not diverge like CIA IRQ. Also, the delay between triggerring IRQ varies depending on the CPU speed of the Amiga (7.16Mhz...50Mhz). I still need to try to see how quickly I can trigger off the Amiga audio interrupts and use them for timers.