Atari v Commodore

[atariksi]

Bignononia "ported" the Atari C64 version over to the Amiga. It's actually pretty good and has an additional screen if you grab all of Pauline's items. Actually check out all of their conversions. They released Zaxxon and Popeye among others.

 

Never knew about that - found a

, the extra screen starts at 5:10.

 

They should have improved the colors. Barrels/flames look weird compared to Atari 8-bit version.

[Assem]

For anyone who has never read the Archer MacLean Interview from a few years back here is a link:

 

Archer MacLean Interview

 

He says the following about the Dropzone conversion to the C64:

 

"Squeezing the hardware in the Atari 800 to its limits and making it better than anything else then available. What was more amazing to me was the challenge of making it work on the less capable Commodore 64. It was a real nightmare implementation, but I did it. "

 

I still look at the Dropzone game now and wonder how he did some of the things he did. Does anyone know what graphics mode/techniques he used in Dropzone?

 

 

Another good interview is one with Peter 'BoulderDash' Liepa. The interview is here (click the link on left panel 'Interview : Peter Liepa') :

 

http://www.boulder-dash.nl/

 

When asked "Have you created any programs/games other than BD (on any system)? Perhaps BD is your only game ever. If so, why did you stop?"

 

he replies..... "I stopped working on videogames because I couldn't stand the platforms that came after Atari. I know you are a C64 fan, but I found it unappealing, and the IBM PC was much worse. The Amiga had a reputation as a wonderful graphics platform, but I don't know that game development on the Amiga was financially that viable. There are other reasons that I stopped. One is that the game industry had booms and busts, another was that game creation in those days was fairly solitary. So I just happened to move on to other things, namely 3D workstation computer graphics. I think that PC graphics finally caught up in the mid-90's to what I thought would be a decent gaming platform, but by then I had been out of the games world for a long time."

Edited January 30, 2009 by Assem

[atariksi]

It seems anyone who programmed in the early 1970s/1980s gets that experience of optimization of squeezing cycles/memory which is lacking in modern days. Now, if you need to do a fast square root of a 24-bit number, you just construct a 32MB look-up table or something like that...

[Crazyace]

32MB lookup table - you'd probally get fired from any programming job

 

Nowadays most programmers expect sqrt to be fast in hardware...

[atariksi]

32MB lookup table - you'd probally get fired from any programming job

 

Nowadays most programmers expect sqrt to be fast in hardware...

 

The point was people would take the easy way out since so much memory and processor speed is available rather than think out a better approach.

 

Normally, in a tight algorithm where you are dealing with only registers, it's not just a matter of calling FSqrt built into the Pentium chips. You need to take into account that you are converting integer->float and after the answer going from float->integer (w/proper rounding off). For integer type square-roots, it's faster to do some algorithm and/or look-up table. Here is one algorithm that's good for small numbers (w/cycles given for 486 processor):

 

;EBX=FLOOR(SQRT(EAX))

Xor EBX,EBX ;1 cycle

SqrtEAX: Sub EAX,EBX ;1 cycle

Inc EBX ;1 cycle

Sub EAX,EBX ;1 cycle

Jns SqrtEAX ;3 or 1 cycle

Dec EBX ;1 cycle

 

So if you wanted to print the distance to the tower in Landscape without screwing up the timing, you would need some integer square root algorithm...

[Crazyace]

I think on the 487 the sequence fild / fsqrt / fistp is 16+87+34 = 137 cycles ( 3+70+6 on pentium ) compared to 6n+6 cycles for the integer routine, so if the distance is >23 it's quicker to use the fp sequence.

[atariksi]

I think on the 487 the sequence fild / fsqrt / fistp is 16+87+34 = 137 cycles ( 3+70+6 on pentium ) compared to 6n+6 cycles for the integer routine, so if the distance is >23 it's quicker to use the fp sequence.

 

It's more than 23 (result of sqrt) since FP sequence does memory reads/writes which are slower than register operations (especially on Pentium). For larger numbers, my integer algorithm is more useful after porting to 6502 and other processors that don't have floating point coprocessor. On Pentium, the branch will take 0 cycles due to branch prediction. Also, if you were doing something like sqrt(A*A-B*B), you need to do some clipping since Fsqrt gives "Square root of negative number" errors whereas the integer algorithm clips to 0.

 

If you start accessing memory than then for 24-bit number, using a 32MB look-up table, it's one memory cycle on Pentium: Mov EAX,[EAX*2+Offset SqrtTable]. The challenge would only be to reduce the memory useage while maintaining less cycles/sqrt than FP unit by combining the algorithm w/look-up table.

[Crazyace]

If you were calculating sqrt(A*A-B*B) you would probally keep everything in fp , rather than just the sqrt - you get 80bit precision - also on a newer intel chips there are the SSE instructions as well ..

I think an arbitary lookup into a 32MB table taking a single cycle is rather naive - you need to consider the cache

For an integer sqrt I'd probally look at a binary chop ( if there was no integer sqrt )

With no table rely on (a+b)^2 = a^2 + 2ab+b + b^2 - and have b a power of 2 , so each time 2ab and b^2 are just shifts. It's a more complex routine than yours - but it get's the answer in less iterations.

On a 6502 use a table, 256 16bit entries would be enough to seed a 16 bit sqrt .. for 8 bit ( where your routine would have 15 iterations at most ) a single 256 byte table would give the answer quicker

[supercat]

To compute the integer square root of any number from 1 to 65535, one need only compute the square root of numbers in the range 16384 to 65535. A 192-entry table (one entry for each 256 units of range) could be used to get an answer within +/-1 of the correct result. So do the rough lookup and then refine it.

[Crazyace]

You're correct, as the step between squares (2n+1) is >256 when n>127 , so it would actually be slower to calculate the sqrt of some smaller number range ( via normalising for example )

 

I'm sure there are some other topics around on the best 6502 math routines anyway

[atariksi]

If you were calculating sqrt(A*A-B*B) you would probally keep everything in fp , rather than just the sqrt - you get 80bit precision - also on a newer intel chips there are the SSE instructions as well ..

I think an arbitary lookup into a 32MB table taking a single cycle is rather naive - you need to consider the cache

For an integer sqrt I'd probally look at a binary chop ( if there was no integer sqrt )

With no table rely on (a+b)^2 = a^2 + 2ab+b + b^2 - and have b a power of 2 , so each time 2ab and b^2 are just shifts. It's a more complex routine than yours - but it get's the answer in less iterations.

On a 6502 use a table, 256 16bit entries would be enough to seed a 16 bit sqrt .. for 8 bit ( where your routine would have 15 iterations at most ) a single 256 byte table would give the answer quicker

 

Pentium instructions can be used since almost everyone has at least a Pentium. Even if you keep everything in FP for sqrt(a*a-b*b), you still have to check for the negative values and eventually transfer to the EAX,EBX,ECX,EDX,ESI, EBP or EDI registers. Sometimes, a slight rounding issue causes a*a-b*b to be negative when it actually should be zero. Cache is good for repeated reads from same location but FP transfer to registers also does writes... Never used SSE or heard of them must be pretty new.

[the maddestman]

This has been a VERY interesting thread, it took me a few days to read it from start to finish!

 

BTW, RE: SSE, it was introduced by Intel with the Pentium III in 1999, and then AMD followed suit by adding SSE instructions with the Athlon XP in 2001. So yeah, SSE is fairly new compared to the good old 6502

 

For the record, I prefer the architecture of the Atari 8 bits over the architecture of the C64.

[atariksi]

This has been a VERY interesting thread, it took me a few days to read it from start to finish!

 

BTW, RE: SSE, it was introduced by Intel with the Pentium III in 1999, and then AMD followed suit by adding SSE instructions with the Athlon XP in 2001. So yeah, SSE is fairly new compared to the good old 6502

 

For the record, I prefer the architecture of the Atari 8 bits over the architecture of the C64.

 

Just found the spec for SSE-- just another extension like MMX. Doesn't really integrate into the core instruction set although does a bit better than MMX. In fact, it only does SQRTs for SINGLE precision FLOATs. Still better to use some integer algorithm or if you want to use floats, mine as well use double precision floating point coprocessor. You do something like SQRT(A*A-B*B+C*C-D*D) with each variable 12-bits and your FLOATs start losing information.

[Godzilla]

Wow, I thought I'd never see this thread slow down So, in the spirit of the actual original topic of the thread, I offer:

Edited February 20, 2009 by Godzilla

[Godzilla]

NECROMANCER

 

http://www.atarihq.com/reviews/atari8/necromancer.html

 

http://www.lemon64.com/?mainurl=http%3A//w....php%3Fid%3D691

 

Everything in this game is better in the atari version, imho, smoothness, controls, gameplay, speed, the cool transformation effects of the trees, colors, etc.

Edited February 20, 2009 by Godzilla

[atariksi]

Wow, I thought I'd never see this thread slow down So, in the spirit of the actual original topic of the thread, I offer:

 

Perhaps, people want to see something new either for C64 or Atari that is not imitation of something that already was done.

[Rybags]

Atari can do interlace... although it's been done on others before.

 

C-128 apparently can do it in '64 mode... the newer VIC-II is required.

[Fröhn]

Atari can do interlace... although it's been done on others before.

 

C-128 apparently can do it in '64 mode... the newer VIC-II is required.

C128 also has that 2nd video chip dedicated for 80 characters display which has real interlace mode built in.

[atariksi]

Atari can do interlace... although it's been done on others before.

 

C-128 apparently can do it in '64 mode... the newer VIC-II is required.

 

Yeah, real interlace is new on Atari since it's not been done on Atari before (at least not knowingly). But it should be consistently do-able across all Atari 8-bit computers to be considered a feature of the machine. Similarly, for C64 -- no that useful in having it work on a particular machine because of some quirk.

[frogstar_robot]

Yeah, real interlace is new on Atari since it's not been done on Atari before (at least not knowingly). But it should be consistently do-able across all Atari 8-bit computers to be considered a feature of the machine. Similarly, for C64 -- no that useful in having it work on a particular machine because of some quirk.

 

But then exploiting interlace is still new on the A8. It may well be impossible on the C-64 but all we really know is that the C-128 has an 80 column chip as well as a VICII quirk that can't be exploited on the C-64. But there may be other ways of doing it on the C-64.

[atariksi]

Yeah, real interlace is new on Atari since it's not been done on Atari before (at least not knowingly). But it should be consistently do-able across all Atari 8-bit computers to be considered a feature of the machine. Similarly, for C64 -- no that useful in having it work on a particular machine because of some quirk.

 

But then exploiting interlace is still new on the A8. It may well be impossible on the C-64 but all we really know is that the C-128 has an 80 column chip as well as a VICII quirk that can't be exploited on the C-64. But there may be other ways of doing it on the C-64.

 

It's more useful if it works on more machines (and monitors). Exploiting C128 features incompatible with C64 isn't that useful given the majority of the userbase just like using 128K memory on 130XE isn't that useful given majority userbase is like 48K..64K RAM.

[potatohead]

Why wouldn't the A8 interlace be usable on the majority of machines?

 

If one does a 2 color display, even a 16K machine can make use of the feature. From what I've seen it's not all that CPU intensive, leaving just the display memory requirements. Most other things remain intact.

 

Code has been shown to work on NTSC, and PAL.

Edited February 23, 2009 by potatohead

[Godzilla]

are there any screenshots of what this interlace allows?

[Thorsten Günther]

But then exploiting interlace is still new on the A8.

 

As new as 1982 (SAGA Adventure #6 "Strange Odyssey" had interlaced graphics).

 

 

Thorsten

[Rybags]

I just had a look - no interlace there.

 

Just looks like they do colour change tricks.