Atari v Commodore

[Wolfram]

This is ludicrous.

 

Atariksi, you're like the guy who keeps dropping farts in a room and sits there loudly blaming someone else.

 

It's ammazing how atariksi turns almost every argue into a debate of who said what, and then it all gets lost in hell. TMR, me, now you. atariksi is the chuck norris of all forums. He'll strangle you in the who said what in 3-4 posts, and then you'll die a slow and painful death

[atariksi]

It does remain faster on A8 even with all DMAs enabled. It's 40 DMA cycles per scanline for normal display (32 for narrow, 48 for overscan) unless you use lower resolution text/graphics modes (Graphics 1/2/etc.) or lower color depth modes than it's 20 DMA cycles or 10 DMA cycles/scanline. There's also one DL byte DMA (which as discussed previously) pays off bigtime for one DMA cycle. So you get 64 DMA cycles/scanline in say a standard mode like 320*200*2 or 160*200*4 (114-9-40-1=64) but after 200 scanlines you are back at 105 cycles/scanline free so overall speed remains faster than C64 CPU.

 

So, when using higher resolution w/o overscan the Atari still has approx. 30% more cpu-cycles left per frame (according to my mental arithmetic wich might be off by a mile), is that correct?

 

Now if you start enabling scrolling, overscan, etc. you see Atari has to do a lot less work from the CPU perspective.

 

Agreed. LMS Scrolling is a nice feature, and "overscan" on the C64 is quite costly when it comes to extending the displayable area into the side borders. At least disabling the top/bottom border is a piece of cake, though.

 

It's 29868 cycles/frame total on Atari so you subtract off whatever cycles you used up. But the flexibility is there to make the size of the screen you like with a DL so DMA cycles are not fixed.

[Barnacle boy]

This is ludicrous.

 

Atariksi, you're like the guy who keeps dropping farts in a room and sits there loudly blaming someone else.

It's ammazing how atariksi turns almost every argue into a debate of who said what, and then it all gets lost in hell. TMR, me, now you. atariksi is the chuck norris of all forums. He'll strangle you in the who said what in 3-4 posts, and then you'll die a slow and painful death

LOL. You did try to warn me several pages back, but I just kept wading into that swamp, right past the sign saying "Quicksand".

[Bryan]

5 pounds says this thread gets locked within 100 posts of my one (unless some peeps behave)

 

I personally want this thread to keep going. Am I wrong, or is this the longest thread on this forum now?

 

 

When it hits 200 pages, all participants get a free set of steak knives!

Do you think it's a good idea to give these guys knives?

[atariksi]

But, out of curiosity, what is the typical amount of cycles stolen due to DMA accesses of the custom chips on the Atari? How does it change depending on the graphic mode, and/or the number of sprites?

 

For instance, IIRC the C64 loses ~1075 cycles/frame in all screen modes with screen output enabled and all sprites disabled. With all sprites on you lose additional 2-5 cycles for each sprite-pixel-row VIC has to display.

The A8 loses:

 

9 DRAM refresh cycles per rasterline (2808 cyles per PAL frame, 2358 cycles per NTSC frame)

 

bitmap 160x192 @ 4 colors / bitmap 320x192 @ 2 colors / bitmap 80x192 @ 16 colors:

7680 cycles per frame + ~200 cycles for display list

 

text mode 40x24 characters:

8640 cycles per frame + ~30 cycles for display list - 192 refresh cycles not executed

 

Modes with less bytes/rasterline also need less cycles, i.e. double pixel height modes will only eat half the cycles.

 

PMs eat 5 cycles per rasterline every rasterline if enabled.

 

A8 wins. You have to look at cycles remaining in the frame-- if I set up a 160*192*4 display, I need 40*192 DMA cycles + 9 refresh * 262 + about 200 bytes of DMA for DL that gives:

 

29868 - 10238 = 19630 cycles free per frame which is more than C64.

[atariksi]

what you have is so called DMA steeling which depends on the gfx mode and scanline as far as have understood there is no interleaving like on c64...so the 1,77/1,79 MHZ is still there (VBL, HBL)... so actually the CPU speed "lost" depends on the DMA workload of Antic. but even in worst case scenarios the CPU remains faster... (or is there any situation where we fall behind the 9000000 Hz of the C64?

 

I strongly doubt so.

 

But, out of curiosity, what is the typical amount of cycles stolen due to DMA accesses of the custom chips on the Atari? How does it change depending on the graphic mode, and/or the number of sprites?

 

For instance, IIRC the C64 loses ~1075 cycles/frame in all screen modes with screen output enabled and all sprites disabled. With all sprites on you lose additional 2-5 cycles for each sprite-pixel-row VIC has to display.

 

You want to give a breakdown for all DMA cycles used on C64 with and without ALL sprites; it's worth hearing from a different person than Frohn all the time.

[Fröhn]

29868 - 10238 = 19630 cycles free per frame which is more than C64.

Yes about 30% more cycles. Not 80% which you imply when you pull out your 1.77 vs 0.985 MHz comparision and by far not the "A8 is 2x faster than C64" which you often said already.

 

EDIT: 30% when comparing PAL machines. When comparing NTSC machines the difference is 20%.

Edited April 23, 2009 by Fröhn

[landgraf]

You want to give a breakdown for all DMA cycles used on C64 with and without ALL sprites; it's worth hearing from a different person than Frohn all the time.

 

Well, ok. This is off memory for PAL timing, so Wolfram or Fröhn may correct me if I get something wrong:

 

Theoretically, you have 312 scanlines a 63 cycles = 19656 cycles total.

 

For each of the 25 character rows, VIC has to steal 40 cycles for fetching color nibbles from color ram and character pointers from screen ram (that also applies to bitmap mode, the screenram data will then serve as additional color information instead of character pointers).

 

Actually, VIC tries to take over the bus by setting BA low 3 cycles before it actually needs it for DMA, but in the end the total number of stolen cycles depends on what the CPU is doing at that point. If it is performing a memory write accesses, it can continue operation, so it can be anything between 40-43 cycles.

 

Assuming the worst case without sprites you got 19656-25*43=18581 cycles/frame (?).

 

With sprites it gets a lot more complicated. Sprite data fetch takes 2 DMA cycles + 3 cycles overhead per sprite line. That overhead is again caused by BA going low 3 cycles before the DMA takes place, but the total overhead will vary depending on which sprites are used and where they placed vertically. In the best case, all sprites take 21*8*2+21*3=399 cycles, tn the worst case 21*8*5=840 cycles/frame.

[Wolfram]

You want to give a breakdown for all DMA cycles used on C64 with and without ALL sprites; it's worth hearing from a different person than Frohn all the time.

 

Well, ok. This is off memory for PAL timing, so Wolfram or Fröhn may correct me if I get something wrong:

 

Theoretically, you have 312 scanlines a 63 cycles = 19656 cycles total.

 

For each of the 25 character rows, VIC has to steal 40 cycles for fetching color nibbles from color ram and character pointers from screen ram (that also applies to bitmap mode, the screenram data will then serve as additional color information instead of character pointers).

 

Actually, VIC tries to take over the bus by setting BA low 3 cycles before it actually needs it for DMA, but in the end the total number of stolen cycles depends on what the CPU is doing at that point. If it is performing a memory write accesses, it can continue operation, so it can be anything between 40-43 cycles.

 

Assuming the worst case without sprites you got 19656-25*43=18581 cycles/frame (?).

 

With sprites it gets a lot more complicated. Sprite data fetch takes 2 DMA cycles + 3 cycles overhead per sprite line. That overhead is again caused by BA going low 3 cycles before the DMA takes place, but the total overhead will vary depending on which sprites are used and where they placed vertically. In the best case, all sprites take 21*8*2+21*3=399 cycles, tn the worst case 21*8*5=840 cycles/frame.

 

you got the sprites wrong. 312 lines * 8 sprites * (3 byte wide + 1 sprite pointer access) + 312* the BA mumbo jumbo 0-3 cycles, best case would be be using 200 lines? my calculation definitly show worst case - theoreticalc . bear in mind the BA behaviour happens only once if you use all 8 sprites, VCII will know it has the bus already when getting to do the DMA of the next sprite and no need to re-request it from the cpu.

 

oh forgot that VICII will perform these sprite readings at 2mhz, so numbers should be halved by two... I'll leave it to Fröhn to do the correct math

Edited April 23, 2009 by Wolfram

[landgraf]

you got the sprites wrong. 312 lines * 8 sprites * (3 byte wide + 1 sprite pointer access) + 312* the BA mumbo jumbo 0-3 cycles, best case would be be using 200 lines? my calculation definitly show worst case - theoreticalc . bear in mind the BA behaviour happens only once if you use all 8 sprites, VCII will know it has the bus already when getting to do the DMA of the next sprite and no need to re-request it from the cpu.

 

oh forgot that VICII will perform these sprite readings at 2mhz, so numbers should be halved by two... I'll leave it to Fröhn to do the correct math

 

Well, I always get confused when doing math, so usually I just add some INC $d020/d021 to the critical sections to able to see where it happens rather than have to calculate that stuff

 

For the BA mumbo jumbo, I was under the impression that if you stagger all 8 sprites vertically (eg. first at Ypos 0, next at 21, 3rd 42 ...) you get the overhead for each line of each sprite? But I might be wrong again.

[+CyranoJ]

When it hits 200 pages, all participants get a free set of steak knives!

 

We're on page 324. I want my knives!

 

I'm only seeing 195 pages - maybe you have different settings

 

Yay! Let's argue about Atari Age forum display settings!

 

PS. My settings are better than your settings. And they use less CPU time. And possibly the joystick port works better, but frankly, who really cares?

[atariksi]

29868 - 10238 = 19630 cycles free per frame which is more than C64.

Yes about 30% more cycles. Not 80% which you imply when you pull out your 1.77 vs 0.985 MHz comparision and by far not the "A8 is 2x faster than C64" which you often said already.

 

EDIT: 30% when comparing PAL machines. When comparing NTSC machines the difference is 20%.

 

I don't have any PAL system (except Amiga 1200) so I never made a comparison like 1.77 vs. 0.985Mhz. However, looking at it logically, Atari can shut down DMAs by scanline basis or full screen and get the 27510 cycles/frame (NTSC). Also, as I pointed out to you before, certain things that take a few cycles and where timing is critical, the CPU speed matters more than frame timing-- so updating consecutive DACs during HBlank is in fact happening at 1.78979Mhz since cycle time is 558ns. DMA cycle just means you lose that cycle for CPU useage (you lose 558ns).

 

All this worst case/best case stuff would make the timing tougher especially in kernels.

[atariksi]

you got the sprites wrong. 312 lines * 8 sprites * (3 byte wide + 1 sprite pointer access) + 312* the BA mumbo jumbo 0-3 cycles, best case would be be using 200 lines? my calculation definitly show worst case - theoreticalc . bear in mind the BA behaviour happens only once if you use all 8 sprites, VCII will know it has the bus already when getting to do the DMA of the next sprite and no need to re-request it from the cpu.

 

oh forgot that VICII will perform these sprite readings at 2mhz, so numbers should be halved by two... I'll leave it to Fröhn to do the correct math

 

Well, I always get confused when doing math, so usually I just add some INC $d020/d021 to the critical sections to able to see where it happens rather than have to calculate that stuff

 

For the BA mumbo jumbo, I was under the impression that if you stagger all 8 sprites vertically (eg. first at Ypos 0, next at 21, 3rd 42 ...) you get the overhead for each line of each sprite? But I might be wrong again.

 

So if you have sprites moving around, you have to self-modify the code in the kernel to maintain same total cycle time.

[Wolfram]

For the BA mumbo jumbo, I was under the impression that if you stagger all 8 sprites vertically (eg. first at Ypos 0, next at 21, 3rd 42 ...) you get the overhead for each line of each sprite? But I might be wrong again.

 

yeah. but if you put all 8 sprite on the same Y pos BA stuff will happen only once each line again, as sprite DMA is hard wired, first it reads sprite 0 (if needed), then sprite 1 (if needed) etc. now if you use every 2nd sprite 4x you're fucked with 4x BA shite. if you use sprites 0 1 2 3 only one BA is needed. all this is happening in a rasterline on the left/right sides of the screen.

Edited April 23, 2009 by Wolfram

[Wolfram]

So if you have sprites moving around, you have to self-modify the code in the kernel to maintain same total cycle time.

 

 

that heavily depends on what you want to do. for a game multiplexer you dont need "same totaly cycle time". for moving sprites around opened sideborders/horizontally splitted rasters it has to be done and there are other methods.

[frogstar_robot]

5 pounds says this thread gets locked within 100 posts of my one (unless some peeps behave)

 

I personally want this thread to keep going. Am I wrong, or is this the longest thread on this forum now?

 

 

When it hits 200 pages, all participants get a free set of steak knives!

Do you think it's a good idea to give these guys knives?

 

Maybe the Super Chamois would be wiser.

[Bryan]

I'm gonna distract everyone by having at look at the peripheral line:

 

In 400/800 beige we have:

 

410 cassette drive

810 diskette drive

820 drum printer (a very *interesting* 40 column printer)

822 thermal printer (nice & quiet)

825 80 column printer (full-on Centronics model)

830 300b acoustic modem (WarGames!)

835 300b direct connect modem

850 rs-232 & printer interface module

also...

CX-85 keypad

 

In XL Brown/White we have:

 

1010 cassette drive

1050 diskette drive

1020 color plotter

1027 LQ printer

1025 80 column printer

1029 80 column programmable printer

1030 300b modem

also..

CX-77 touch tablet

CX-75 light pen

CX-22 trackball

 

XE gray:

XC11 and 12 cassette drives

XF551 DS diskette drive

XM301 300b modem

SX212 1200b modem

XEP-80 80-column adapter (with a MOS 6551!)

XMM801 80-column printer

XDM121 80-column daisy wheel printer

 

So Atari certainly gave you a lot of choice.

[Wolfram]

I'm gonna distract everyone by having at look at the peripheral line:

 

In 400/800 beige we have:

 

410 cassette drive

810 diskette drive

820 drum printer (a very *interesting* 40 column printer)

822 thermal printer (nice & quiet)

825 80 column printer (full-on Centronics model)

830 300b acoustic modem (WarGames!)

835 300b direct connect modem

850 rs-232 & printer interface module

also...

CX-85 keypad

 

In XL Brown/White we have:

 

1010 cassette drive

1050 diskette drive

1020 color plotter

1027 LQ printer

1025 80 column printer

1029 80 column programmable printer

1030 300b modem

also..

CX-77 touch tablet

CX-75 light pen

CX-22 trackball

 

XE gray:

XC11 and 12 cassette drives

XF551 DS diskette drive

XM301 300b modem

SX212 1200b modem

XEP-80 80-column adapter (with a MOS 6551!)

XMM801 80-column printer

XDM121 80-column daisy wheel printer

 

So Atari certainly gave you a lot of choice.

 

this is just a list of disk drives not that not made it into production:

 

SFD 1001

1541D

1542

1543

1551

(SFS 481)

1561

1563

1565

1570

1571-II

1571CR

1572

1582

1590

1591

8060

8061

8062

8280

[Barnacle boy]

Barnacle boy is obsessed with farts and shit, and showing no proof of C64 winning over A8.Wolfram and Frohn are German, so their side of the argument is like....I VILL WIN THIS WAR, no matter what, even if I have to change my tactics.

Hmm... how insightful of you to say I was "showing no proof of C64 winning over A8". Are you not aware that I wasn't even trying to make any such claim during the whole bounding box discussion?

 

I wonder if you're able to make even one comment in this thread that isn't the product of blind bias coupled with idiocy.

[Bryan]

Yeah, I didn't include Atari's vaporware. I had a chance to buy an 815 drive at one point and I wish I had.

 

Atari didn't produce another true double density drive until the XF551 (although the 1050 could be upgraded and there were many 3rd party options).

 

 

btw... discussing old computers is much more fun when you don't give a shit who wins.

Edited April 23, 2009 by Bryan

[Fröhn]

So if you have sprites moving around, you have to self-modify the code in the kernel to maintain same total cycle time.

That's what IRQs are for.

[youki]

I'm gonna distract everyone by having at look at the peripheral line:

 

In 400/800 beige we have:

 

410 cassette drive

810 diskette drive

820 drum printer (a very *interesting* 40 column printer)

822 thermal printer (nice & quiet)

825 80 column printer (full-on Centronics model)

830 300b acoustic modem (WarGames!)

835 300b direct connect modem

850 rs-232 & printer interface module

also...

CX-85 keypad

 

In XL Brown/White we have:

 

1010 cassette drive

1050 diskette drive

1020 color plotter

1027 LQ printer

1025 80 column printer

1029 80 column programmable printer

1030 300b modem

also..

CX-77 touch tablet

CX-75 light pen

CX-22 trackball

 

XE gray:

XC11 and 12 cassette drives

XF551 DS diskette drive

XM301 300b modem

SX212 1200b modem

XEP-80 80-column adapter (with a MOS 6551!)

XMM801 80-column printer

XDM121 80-column daisy wheel printer

 

So Atari certainly gave you a lot of choice.

 

this is just a list of disk drives not that not made it into production:

 

SFD 1001

1541D

1542

1543

1551

(SFS 481)

1561

1563

1565

1570

1571-II

1571CR

1572

1582

1590

1591

8060

8061

8062

8280

 

1570 and 1542 has been produced. The 1570 was a 1541 drive relooked for the C128 , and the 1542 was a Black 1541 drive but using parallal transfert instead of serial but works only on C16/plus 4 .

[landgraf]

btw... discussing old computers is much more fun when you don't give a shit who wins.

 

Yes, it's like bragging about the "most advanced steam engine"-award in the age of space-flight

[Fröhn]

this is just a list of disk drives not that not made it into production:

Some of those drives have been in production. I own two 1551s and one 1570 for example.

[Wolfram]

btw... discussing old computers is much more fun when you don't give a shit who wins.

 

Yes, it's like bragging about the "most advanced steam engine"-award in the age of space-flight

 

actually that would be an interesting topic. I'd like to see why and how one is better than the other, what are the slight tweaks that brings advantages