Atari v Commodore

[atariksi]

Sorry, you claimed that GTIA couldn't do 1 color clock scroll. I also mentioned GPRIOR mode 0 so if resolution was important I would have talked about that rather than GTIA scrolling and color re-use.

 

It was an assumption because i'd never seen it done; when you explained how the theory works i accepted it despite no working examples and after that point was concerned with how a game using it would look from amongst other things a design perspective. And again, still a moot point because we were talking character modes and you brought up the GTIA, taking us off at a tangent.

I'm not sure how a 1 color clock scroll (160 pixel) would be possible in a GTIA mode. The scroll register is in Antic which will simply delay the data to GTIA by however many cycles. GTIA doesn't know the data is delayed, so you should simply get a corrupted screen for all odd settings of HSCROL.

 

How can you actually move the pixel borders except by switching between modes 9 and 10?

 

That's what I suggested that you toggle Gr.9/11 with Gr.10 and limit yourself to 9 colors (max). So you set the palette of Gr.10 to correspond to same colors as Gr.11 or shades for Gr.9.

[Lazarus]

What about the four CIA timers? You can easily sync those to the screen refresh and have 2 IRQs and 2 NMIs at screen positions you want.

Yeah, you can sync up to VBlank but then how do you keep that sync given the BA cycles throw off the cycles you are counting on the code. See my example posted in my next message.

BA doesn't matter for the timers. They simply stay in sync.

[andym00]

Yeah, you can sync up to VBlank but then how do you keep that sync given the BA cycles throw off the cycles you are counting on the code. See my example posted in my next message.

 

You don't, the Timers count the cycles for you, and the interrupt latency for you.. If you want an interrupt to occur during a badline, then so be it.. You know it's not going to happen.. You clearly take that into account when you make the choice to utilise this method.. If that's a problem you don't, you do it another way.. But you'd use something like this when it's a suitable weapon of choice.. Obviously it's not a solution for everything, but there's problems for which this is a solution like no-other in terms of speed and code flexibility, and it also opens up many other avenues of opportunities..

[andym00]

Well, the background code has to divide evenly into the cycles remaining for the background task. In the example below of stable VBI (w/o WSYNC), see the idle loop where code is 17 cycles but can also be other factors that divide evenly into cycles remaining.

[snip]

 

Obviously, I'd be very worried if that wasn't the case

Edited September 25, 2009 by andym00

[oky2000]

 

More Lame examples post atari peak. Worthless

 

 

I doubt very much comparing budget games is worth the effort, no budget game is going to be utilising the full potential of either machine because they are cheap games developed in a very short space of time, there is simply not enough time/money to devote to doing anything like the advanced coding in full price game so I don't see the point of Rockfords repeated budget crap game comparisons. Sure one might be better than the other but neither is using the machine properly and so proves very little about either machines capabilities.

 

OK then, today another high budget game from the "golden era of Atari"

 

24 - SUPER ZAXXON

 

C64

C64

C64

 

The C64 version has better sound, graphics, sprites, handling more colours and plays more smoothly. The poor atari version works in lower resolution and plays slow and jerky (even though the play area is much smaller ). C64 proves its superiority again.

 

ATARI

ATARI

ATARI

 

See that's better, a worthwhile comparison. Both Zaxxon and Super Zaxxon (and both PAL and NTSC versions which makes four different Zaxxon games on the C64) are better than Zaxxon and Super Zaxxon on the A8 I agree. The NTSC versions look more like the Coleco versions on the C64 (can't be bothered to google loads of links for the 6 games mentioned above sorry)

[oky2000]

Except that the PET was never designed to do anything other than display business applications on its monochrome 80-column screen.

 

That seems irrelevant to my post - fact is the PET was the FIRST generation Commodore computer in 1977, a contemporary of the Atari 800 (1979), TRS 80 (1977) and Apple 2 (1977)...

 

It's abilities were not in question - just that it was a machine (like those other 1977-1979 systems) that was sold to real people not electronics engineers...

 

sTeVE

 

But comparing a PET (all iterations from 77 to much later Super PETs etc) to a VIC/C64 is like Comparing a VT Terminal to a VCS and proclaiming the VT terminal is crap compared to the VCS. The whole original comment is irrelevant in any sense to the discussion anyway.

[oky2000]

8x faster? possibly more actually. For planar modes you have to load, OR a bit in (or AND it out) and store 8 times, that's 3 operations per bit, 24 operations total (excluding how you get the and/or masks to start with). chunky is a load and store to get a pixel onscreen. potentially it could be up to 20 times faster like-for-like.

 

Finally someone gets what I am talking about!

 

For the rest............I was only talking about screen memory format in terms of displaying frames in Doom style games, planar is nothing but a disadvantage IN THIS CASE when after spending 10000s of cycles calculating what your next frame should look like in 256 colours the Amiga then has to mess about generating this 256 colour screen by manipulating 8 separate bit planes independently as opposed to one single 8bit value to be written somewhere to set the same single pixel.

...

As far as copying data from off-screen buffers to video area, it's not going to be 800% slower. You would update one plane at a time not write to 8 planes for every pixel. Or you can do 32 pixels at a time on each plane:

 

Move.l (a0)+,P1Ofs(a4)

Move.l (a1)+,P2Ofs(a4)

Move.l (a2)+,P3Ofs(a4)

Move.l (a3)+,(a4)+ ;assume one plane is at 0 offset

 

Bit planes were kept for compatability and it was cheaper to expand and clean up the original chipset than redesign it again to add completely alien screen modes like chunky pixel VGA style. AAA and other chipset prototypes do not use bitplanes except for legacy Amiga screen modes and there's a good reason why

 

It's good that they kept backward compatibility. That's the problem in modern graphics cards-- they all have their own methods of accessing the screen and different I/O ports so you are forced to go through some API and thus not being able to take full advantage of the hardware.

 

 

What 'you' do is irrelevant, the Amiga chipset needs to manage 8 bit planes on the A1200/A4000 AGA Amigas, whether you want to change 1 pixel or none or all 320x256 at once makes no odds the Amiga chipset still needs to work with 8 seperate bitplanes for every pixel of a 256 colour screen of any resolution. The simple fact is for the flavour of the month (Doom style FPS games) it made the Amiga look technologically far worse than it was to the novice computer purchaser.

 

I have already stated that planar is not a problem in essence, look at Super Stardust 96 and Lotus Turbo Challenge 3 on PC and you will need a 100mhz Pentium PC to play these games in the same fluid manner as a 14mhz 50% CPU speed crippled 68020 based A1200 Amiga so clearly it is manipulation of the situation of PeeCee marketeers when everyone wanted their own version of Doom. PCs were quick and dirty (everything is done via CPU+software) and chunky pixel modes as standard therefore it was the perfect machine for 256 colour Doom clones. Doing the game in less colours obviously helps on planar systems bet I was talking about doing perfect clones of Doom VGA and Amiga AGA ie technically identical resolution and max colours.

 

*no FAST RAM on A1200 as stock and without it the machine runs at 50% maximum effective CPU speed approx for stuff like Starglider II)

[Rockford]

25 - YOGI BEAR & FRIENDS IN THE GREED MONSTER

 

C64

C64

C64

 

The C64 version has MUCH better sound & music, graphics, sprites, more colours and plays smoothly. The ugly Atari version doesn't have music and works slower (even though the play area is smaller ). C64 wins easily again.

 

ATARI

ATARI

ATARI

[atarian63]

25 - YOGI BEAR & FRIENDS IN THE GREED MONSTER

 

C64

C64

C64

 

The C64 version has MUCH better sound & music, graphics, sprites, more colours and plays smoothly. The ugly Atari version doesn't have music and works slower (even though the play area is smaller ). C64 wins easily again.

 

ATARI

ATARI

ATARI

Waste of time example again. there are some rare occasions in the 83-84 period but mostly by a wide margin Atari wins easily!

Edited September 25, 2009 by atarian63

[emkay]

Either way, swings and roundabouts.. I'm just curious to explore the avenues available to me on this machine.. And someone essentially saying 'that's not how we do it round these parts boy' without any explanation as for why achieves nothing bar rubbing me up the wrong way

 

Now the friendly aquisition gets a polemic touch?

 

Not addressed to only you...

Edited September 25, 2009 by emkay

[ThomSW]

OK Rockford, now tell us which is your

out there.

 

(btw. how a handicapped machine which breaks ingame sound to play FX, sigh...)

 

Still not convinced.

 

Rockford's current rating: C64 sucks because of ya and such!

 

------------

 

To all the rest non-atarians here - isn't it time to thank him, no? ;->

[desiv]

Waste of time example again. there are some rare occasions in the 83-84 period but mostly by a wide margin Atari wins easily!

 

And you're saying you didn't sell more C64 software in your unbiased computer store?

 

Must be quality, as you say, is the reason Atari software outsold C64 software everywh..er in your store.....

 

desiv

 

I kid.. I'm a kidder.. I love both...

From my perspective tho, the pics lean towards the 64, even tho you have a reason for almost every one.

[popmilo]

...Waste of time example again.

No, its not waste of time... It shows just what was happening after your so much loved period, before 83....

 

In 1990, money moved away from 8bit to 16bit computers...

Bedroom coders made what they could with machine in their spare time...

And you have games like turrican and mayhem on c64, and games like Yogi on A8...

I think A8 programmers (like polish wave of games that was produced at that period) did best they could.

And I don't think they were worse coders than C64 coders...

 

Just that A8 was simply more difficult (in some cases impossible) to develop certain games for...

 

That is why you get games with 16 colors background and >8 sprites in an average bedroom coders C64 game (Authors of "Mayhem" made one of the prettiest games on commodore just so that their mother could play it in spare time...)...

 

And you get 4-5 color background, and few sprites on A8 because thats easy.... that is straightforward process ...

They are not even bad games, I played some of Polish arcade adventures and it was time well spent...

 

...there are some rare occasions in the 83-84 period but mostly by a wide margin Atari wins easily!

So atari wins in 83-84 ... How nice from you to limit comparing to the timeframe that suits your needs

[carmel_andrews]

Except that the PET was never designed to do anything other than display business applications on its monochrome 80-column screen.

 

That seems irrelevant to my post - fact is the PET was the FIRST generation Commodore computer in 1977, a contemporary of the Atari 800 (1979), TRS 80 (1977) and Apple 2 (1977)...

 

It's abilities were not in question - just that it was a machine (like those other 1977-1979 systems) that was sold to real people not electronics engineers...

 

sTeVE

 

But comparing a PET (all iterations from 77 to much later Super PETs etc) to a VIC/C64 is like Comparing a VT Terminal to a VCS and proclaiming the VT terminal is crap compared to the VCS. The whole original comment is irrelevant in any sense to the discussion anyway.

 

 

 

 

 

Slightly incorrect, according to the book 'home computer wars', commodore already had the VIC chip already released in 1978 (about the same time atari were ready with the original 400/800) unfortunately tramiel had this CRAP idea about getting MOS (later called CSG-Commodore semiconductor group) to selling VIC chip technology to any other VG or Computer company (instead of incorporating the tech. into their existing hardware), it wasn't till the 400/800 were released nationally across US that tramiel gave peddle the go ahead to using the VIC chip in an updated Pet/CBM machine (i don't know if that ever materialised as Peddle was spending too long in developing it and having arguments with tramiel) and about the same time someone at commodore had the idea of a 'sub 300usd' computer to compete with the apple 2 and atari systems, initially both tramiel and most of the commodore management were against it (because it would use the same video chip that peddle was using with the updated pet/cbm system) but because peddle was taking way too long in developing this updated pet/cbm machine, tramiel relented and allowed the development of the sub 300usd computer, which eventually became the vic20

[atariksi]

8x faster? possibly more actually. For planar modes you have to load, OR a bit in (or AND it out) and store 8 times, that's 3 operations per bit, 24 operations total (excluding how you get the and/or masks to start with). chunky is a load and store to get a pixel onscreen. potentially it could be up to 20 times faster like-for-like.

 

Finally someone gets what I am talking about!

 

For the rest............I was only talking about screen memory format in terms of displaying frames in Doom style games, planar is nothing but a disadvantage IN THIS CASE when after spending 10000s of cycles calculating what your next frame should look like in 256 colours the Amiga then has to mess about generating this 256 colour screen by manipulating 8 separate bit planes independently as opposed to one single 8bit value to be written somewhere to set the same single pixel.

...

As far as copying data from off-screen buffers to video area, it's not going to be 800% slower. You would update one plane at a time not write to 8 planes for every pixel. Or you can do 32 pixels at a time on each plane:

 

Move.l (a0)+,P1Ofs(a4)

Move.l (a1)+,P2Ofs(a4)

Move.l (a2)+,P3Ofs(a4)

Move.l (a3)+,(a4)+ ;assume one plane is at 0 offset

 

Bit planes were kept for compatability and it was cheaper to expand and clean up the original chipset than redesign it again to add completely alien screen modes like chunky pixel VGA style. AAA and other chipset prototypes do not use bitplanes except for legacy Amiga screen modes and there's a good reason why

 

It's good that they kept backward compatibility. That's the problem in modern graphics cards-- they all have their own methods of accessing the screen and different I/O ports so you are forced to go through some API and thus not being able to take full advantage of the hardware.

 

 

What 'you' do is irrelevant, the Amiga chipset needs to manage 8 bit planes on the A1200/A4000 AGA Amigas, whether you want to change 1 pixel or none or all 320x256 at once makes no odds the Amiga chipset still needs to work with 8 seperate bitplanes for every pixel of a 256 colour screen of any resolution. The simple fact is for the flavour of the month (Doom style FPS games) it made the Amiga look technologically far worse than it was to the novice computer purchaser.

 

I have already stated that planar is not a problem in essence, look at Super Stardust 96 and Lotus Turbo Challenge 3 on PC and you will need a 100mhz Pentium PC to play these games in the same fluid manner as a 14mhz 50% CPU speed crippled 68020 based A1200 Amiga so clearly it is manipulation of the situation of PeeCee marketeers when everyone wanted their own version of Doom. PCs were quick and dirty (everything is done via CPU+software) and chunky pixel modes as standard therefore it was the perfect machine for 256 colour Doom clones. Doing the game in less colours obviously helps on planar systems bet I was talking about doing perfect clones of Doom VGA and Amiga AGA ie technically identical resolution and max colours.

 

*no FAST RAM on A1200 as stock and without it the machine runs at 50% maximum effective CPU speed approx for stuff like Starglider II)

 

It's not what "I" do. There are examples where planar is better even with SAME number of colors. I know some word processors used colors in such a way that they can update the fonts just by writing to one bitplane although the software itself used 4 bitplanes for coloring the side bars and other items. And no, I don't think just for supporting Doom's 256 chunky buffer, all hardware in the world should be modified.

 

And here's another point-- the VGA speed is not much affected by the processor speed. The I/O bus speed runs at it's own pace regardless of the processor speed. On ISA-based VGA cards with 16-bit data bus, the max was about 2MB/second memory -> VGA memory transfer and you don't get any better whether you use 12Mhz or 25Mhz CPU. I have a Pentium 90Mhz with PCI VGA currently and the VGA writes are at 30MB/second and on another system with 1Ghz CPU, the VGA writes are at 32MB/second.

[atariksi]

What about the four CIA timers? You can easily sync those to the screen refresh and have 2 IRQs and 2 NMIs at screen positions you want.

Yeah, you can sync up to VBlank but then how do you keep that sync given the BA cycles throw off the cycles you are counting on the code. See my example posted in my next message.

BA doesn't matter for the timers. They simply stay in sync.

 

The background code has to use the same cycles else you get jitters of when the IRQ triggers off.

[atariksi]

Yeah, you can sync up to VBlank but then how do you keep that sync given the BA cycles throw off the cycles you are counting on the code. See my example posted in my next message.

 

You don't, the Timers count the cycles for you, and the interrupt latency for you.. If you want an interrupt to occur during a badline, then so be it.. You know it's not going to happen.. You clearly take that into account when you make the choice to utilise this method.. If that's a problem you don't, you do it another way.. But you'd use something like this when it's a suitable weapon of choice.. Obviously it's not a solution for everything, but there's problems for which this is a solution like no-other in terms of speed and code flexibility, and it also opens up many other avenues of opportunities..

 

Yeah, I wasn't trying to trigger off IRQ during badline but on same point without having to resync (resolve the jitters again). Obviously, if you want IRQ to occur on same point, it can't be a DMA cycle or refresh cycle.

[atariksi]

Then maybe the fastpotscan trick might be a better solution.

 

Once the IRQ is executed, read the fastpotscan register ONE time (it is reset at a fixed position), and do a void/dummy instruction of 1 up to 7 cycles to counter-effect the previous delay.

 

I remember some person (Peterm) showing how to use RANDOM (53770) to count cycles by setting some bit in poly-counter register.

[atariksi]

Well, a quick thought on this would be to use maybe 2 timers instead. The jitter is mainly caused by uncertainty in number of cycles used for the last instruction executed before the IRQ. This can be from 2 up to 6 (or 7) cycles.

 

We can do this by using f.e. 2 pokey channels. 1 channel at 15khz and another at 1.79mhz baseclock.

The 2nd timer is, say 12 cycles later than the 1st.

 

The 1st is used to balance the timing uncertainty. Do a string of NOP instructions, and wait for next IRQ. ($fffe should be pointed directly to the start of the NOP string). Then the uncertainty for the next interrupt, 12 cycles later is still 1 or 2 cycles.

 

So, I think there's a way to at least reduce the uncertainty to 1 or 2 cycles instead of 1 up to 7.

 

With a little bit of luck it's even possible to do all by just using one timer, redefined by alternating tasks.

 

I thought about that something like that, it's the same as the double irq method on the 64.. Trigger a raster, clear irqs, and set irq for next line and then nop until irq arrives..

1 or 2 cycles would be better than nothing, at least it narrows the window of re-positioning that's possible.. I think you know what I've been trying

I'll give that a go and see, though I seem to be eating through Pokey timers like they're going out of fashion..

 

And the worst case I think is 9 nine cycles using illegals, but it's not very often you'd use the 9 cycle stuff unless you're trying to break your stable irqs..

 

Ideally it'd be something as simple as this:

IRQ:
    inc $ffff
    nop
    ..

But the reality is there's much more to do.. You need to ack the IRQ as well, which means A needs saving as well, unless there's some magic trick for ack'ing irq on the A8.. Some trick involving RMW instructions and the fact that IRQST is the same address as IRQEN ?

So you'd end up with something like:

      sta zp_a     ; 3
      lda #<.nops  ; 2
      sta $fffe    ; 4
      lda #0       ; 2
      sta IRQEN    ; 4
      lda #xx      ; 2
      sta IRQEN    ; 4 (21)
.nops: 
      nop
      ..

So there's a large overhead (21 cycles + jitter+ irq entry (7 cycles)) on that already, maybe too much to be practical, with a absolute minimum of 30cycles or so just to get into the interrupt.. Which is too much to be practical once you throw in the RTI (and we haven't done anything yet either), unless you let it run for >1 iteration within each interrupt to amortise the irq overheads..

 

Yes, there is a way to ack the Atari IRQ with RMW-- just do INC on 53774 or DEC or ROL or ASL but you just have to make sure you know how other timer channels are affected. It's easy if you are only using IRQ stuff only for timers.

[atariksi]

That's the answer I was expecting from Emkay..

I meant at any chosen cycle.. With a timer source, that isn't related to the scanline position, I meant is there a way to read and fixup cycles based upon some modulo count of elapsed cycles ? Any source available to allow some correction for interrupt jitter.. That doesn't involve WSYNC and burning clock cycles like they're going out of fashion..

You can also use POKEY timers and waste a sound channel or two.

 

Or have your timers run at same frequency as your notes and not waste a sound channel. Or use the DAC portion of the sound channel for simulating 5-bit DACs with another sound channel.

[Lazarus]

BA doesn't matter for the timers. They simply stay in sync.

The background code has to use the same cycles else you get jitters of when the IRQ triggers off.

Pretty much the same on Atari and C64 or anything else.

 

However an IRQ which has to be stable and only doesn't jitter when it uses a very predictable amount of time is of no use. Real world routines aren't simple as that and you always have to de-jitter your IRQs.

Edited September 25, 2009 by Lazarus

[atariksi]

You could in theory use a spare PADDLEx register, and if the POTGO sequence was started during VBlank at an exact known time, use that to help with syncing.

 

The thing is... you have WSync, which in 98% of cases gives the HALT until near enough the exact spot you need.

 

In the other 2%, e.g. if you had a narrow-screen situation like NRV is using with "Project M", the 6 cycles or so of jitter doesn't really matter since you can just have the Timer occur such that your screen changes would coincide to an offscreen area.

 

 

You can also use POTGO in Fast mode, which in effect turns the PADDLEx registers into cycle counters, although it's only good for 2 scanlines.

 

I think I remember now-- you had a discussion with Peteym on using RANDOM to count cycles. Perhaps, you have the code or he does.

[atariksi]

BA doesn't matter for the timers. They simply stay in sync.

The background code has to use the same cycles else you get jitters of when the IRQ triggers off.

Pretty much the same on Atari and C64 or anything else.

 

Sorry, you just missed the last 25 or so posts. We are trying to avoid jitters with least overhead. That's the subject being discussed.

[atariksi]

VGA was around for over half a century before the Amiga A1200 was released so they had plenty of time to examine it and test it out

 

er...

 

My math may be shaky, but.. 1992 (1200 release) - 50 (half a century) = 1942.

 

Wow! VGA was way ahead of its time.

 

desiv

 

Believe it or not, in some graphical scenarios, Amiga still outdoes the modern PC graphics cards (that are standard on most machines).

[Lazarus]

Sorry, you just missed the last 25 or so posts. We are trying to avoid jitters with least overhead. That's the subject being discussed.

And you posted a routine which "avoids" jitter by using a very very special case which you will never encounter in real programs.