Favorite 8-Bit Game Never Ported To The Atari Series

[Heaven/TQA]

check out c=hacking issues... i think in one of them there is a doc about fractalus on c64... i guess it was the superCPU turbo board adaptation?

 

unfortunatly i never found out on the net how really the game works from math point of view... as it is a cheat...

 

and julian from factor5 even mailed me once that lucasfilm is hiding this stuff like hell (or maybe it's lost...)

 

hve

 

ps. c64 might be slower but has 512 (?) redifinable charset, 8 sprites, color ram... that's all... still in some cases atari can not compete... (read carefully...in some cases... )

[Sharky]

 

Sharky -- G&G was started on the XL (I know I was doing it), but whilst we got geat background look and feel, much more like the arcade than the C64 version (grey gravestones rather than blue on level one etc), we had little luck with the sprites.

 

 

Still a shame, althought surely there could of been a work around in some way, and who needed sprites for GNG . Althought Sprites are much better, but then again, Commodore 16 produced a passable GNG without the use of Sprites it looks has I believe the C16 had no hardware sprites.

[Jetboot Jack]

C16 GNG was horrific....

 

It looked terrible and moved worse....

 

Character blocky movement, nasty

 

sTeVE

[Bryan]

I believe the C64 (can anyone verify this?) runs on a even/odd clocking scheme, where the CPU and VICII never conflict, and this is why the CPU clock is so low, and VICII can maintain a high bandwidth.

 

i'm not a hardware bod, but the VIC-II interrupts the CPU 25 times a frame to pull in each character line of data - that anything the CPU is up to or DMA transfers from or to a RAM expansion. Similarly, sprites take a couple of cycles from each rasterline they're passing over so the VIC-II is getting priority there as well.

 

Okay, so the CPU does stop for VIC. My bad. It would seem that it would need to do it more than 25 times a frame unless it read all 8 lines of char graphics in one shot (quite a long time for the CPU to be down).

 

-Bry

[Bryan]

This is a paradox ... half bus speed / double resolution.

So there must something be on the C64 I still don't know.

 

Here's what the 64 must read to do a full row of text:

 

40 bytes of character data

40 bytes of color data (I assume the 2 colors are in 1 byte)

40 bytes of graphics data * 8 = 320 bytes

 

Total = 400 bytes

 

The Atari reads:

1 byte (or 3 if new Address) from the DLIST

40 bytes of character data

320 bytes of graphics data

 

Total = 361 bytes

 

These bytes are read in real time, stopping the CPU intermittently as the line is drawn.

 

I don't know how the 64 does RAM refresh, but on the Atari it would consume another 65 cycles.

 

-Bry

[Sharky]

C16 GNG was horrific....

 

It looked terrible and moved worse....

 

Character blocky movement, nasty

 

sTeVE

 

True! But ive only recently discovered GNG for the C16 on emulators.

 

But at least GNG did come to C16, no matter how bad it is/was.

A passable Double Dragon came to Atari 2600 but not Atari 8bit computers.

 

But it did come to the Atari ST 16bits though, a pity thought the 8bit and 16bit Ataris werent compatible with each other.

[Sheddy]

For pseudo 3D like Space Harrier uses, the advantages are reduced because the C64 can resort to lobbing large gobs of coloured data around at a reasonable rate of knots and it gets the advantage of the larger hardware sprites on top of that.  Look at the later work of Chris Butler, when he wrote C64 Space Harrier it was pretty much the first of it's kind (Encounter covered the idea of large char based objects at speed but Harrier had more detail) and as he honed what he was doing the results improved until his final game, Turbocharge for System 3, blitzed Harrier for look and speed (having Robin "Armalyte" Levy on the graphics helped... =-)

 

Agreed. Turbocharge is a much better psuedo 3d game than Space Harrier

The design of Robin Levy's graphics is very cleverly done, to try and make up for the lack of masking where things have to overlap.

 

Given the tight release schedule from Elite (I believe they had less than 6 months to produce the game), it is not surprising Chris didn't get to perfect the graphics on Space Harrier in a similar way. His (understandable) fetish for single loader games at the time wouldn't have done it any favours either. I really wish they didn't have to have rushed it so - the C64 version could have been pretty good, instead of very average. (Still it looks better than the Amstrad version, which doesn't even have filled sprites, but vector representations)

 

Guess they wouldn't have been able to dip into their toolbox of routines used on previous games either, to speed up development - as you say, it was pretty new territory.

[emkay]

This is a paradox ... half bus speed / double resolution.

So there must something be on the C64 I still don't know.

 

Here's what the 64 must read to do a full row of text:

 

40 bytes of character data

40 bytes of color data (I assume the 2 colors are in 1 byte)

40 bytes of graphics data * 8 = 320 bytes

 

Total = 400 bytes

 

The Atari reads:

1 byte (or 3 if new Address) from the DLIST

40 bytes of character data

320 bytes of graphics data

 

Total = 361 bytes

 

These bytes are read in real time, stopping the CPU intermittently as the line is drawn.

 

I don't know how the 64 does RAM refresh, but on the Atari it would consume another 65 cycles.

 

-Bry

 

 

Well... this is what I am talking about.

 

The XL has ~1,79MHz and DMA pulls down CPU-Speed

The C64 has ~1MHz and DMA pulls down the CPU in a much heavier way.

 

Heck... this is like to compare a 3GHz(800) P4 with a 1,7GHz(533) P4....

 

Look at MOOD. On the XL/XE it might have to run in quadruple speeds even by a higher resolution!

 

To fill the main Screen only 1K of memory is needed to be handled(PMg).

Then look how C64 is speeded up by softwaretricks.

By using of character-clusters for graphical objects, the CPU has only to calculate on screen-ranges.

And please don't think by the word "Charmode" at some blocky graphics like in mood. The MCS pictures are Charmode too

[TMR]

Here's what the 64 must read to do a full row of text:

 

40 bytes of character data  

40 bytes of color data (I assume the 2 colors are in 1 byte)

40 bytes of graphics data * 8 = 320 bytes

 

The only thing that actually needs to be pulled in during the badline is screen data because character sets are referenced by pointer and can be changed at any point including halfway across a line so there's no overhead for them (VIC-II doesn't steal any power from the 6510 for that job, at least). If memory serves, the colour memory is sat on a stand-alone chip next to the VIC-II and i believe the CPU or bus aren't involved in reading it so no overhead there either. Character colour is one nybble, the off bits are coloured by the background colour register.

 

In total, that's 1,000 bytes of data fetched over a frame in 40 byte blocks every eight rasterlines during the visible screen. The only time it's more is if sprites are in operation and the CPU load is variable because each sprite has different timing requirements. Since any rasterbar style effect on the C64 requires timing within two or three cycles (there is no equivalent of WSYNC, everything is done manually) most coders know roughly what time is being grabbed where.

[TMR]

And please don't think by the word "Charmode" at some blocky graphics like in mood.

 

Mood doesn't use character mode, it's in bitmap Half FLI. The image you're seeing is being generated through the colour attributes and they're forced to change 50 times a screen instead of 25 using a "feature" of the vertical smooth scroll register. Depending on how the Half FLI is implemented, it requires either 2K or 3K and, in the latter case, 1K of that can't be double buffered.

[TMR]

But it did come to the Atari ST 16bits though, a pity thought the 8bit and 16bit Ataris werent compatible with each other.    

 

That's one thing i always moaned about; why didn't the 16bit Ataris just use an enhanced version of the 8bit graphics architecture - it's worked out far better than the way the ST is arranged...!

[TMR]

Okay, so the CPU does stop for VIC. My bad. It would seem that it would need to do it more than 25 times a frame unless it read all 8 lines of char graphics in one shot (quite a long time for the CPU to be down).

 

Basically, the VIC-II pulls the 40 bytes of character data needed for each character line but the font data is read on the fly and if there is an overhead it's a constant we're not aware of. On a PAL machine, we get 63 cycles on an average rasterline and drop 40 for a badline (not including when sprites are on the lines). The VIC-II must have some pipe directly to the RAM because it's possible to change the font at any point in a rasterline including halfway across the screen (i've vertically split fonts before now).

 

Actually... if there is an overhead, it must happen every processor cycle!

[TMR]

c64 might be slower but has 512 (?) redifinable charset, 8 sprites, color ram... that's all... still in some cases atari can not compete... (read carefully...in some cases... )

 

The C64 only gets 256 characters in a font but the hardware sprites are capable of either being 24x21 pixels with 1 colour or 12x21 pixels 3 colours each, all 8 have an independent colour and can be recycled as long as only 8 exist on one rasterline. The current record (set by Crossbow/Crest) stands at 120 sprites using no tricks and 144 using crunching to make them finish early and allow for more uses.

 

Sorry for the large block of posts, i was at the seaside with the kids for the day! =-)

[emkay]

And please don't think by the word "Charmode" at some blocky graphics like in mood.

 

Mood doesn't use character mode, it's in bitmap Half FLI. The image you're seeing is being generated through the colour attributes and they're forced to change 50 times a screen instead of 25 using a "feature" of the vertical smooth scroll register. Depending on how the Half FLI is implemented, it requires either 2K or 3K and, in the latter case, 1K of that can't be double buffered.

 

This is mainly what I thought.

Similar to the colour attributes you can program the PMg for the res. of 40x100. A lineup in charmode for a 3D engine is possible in Basic in a very fast way.

So you have 6 colors the easiest way and can use the prior register to add colors by overlay.

Then it is possible to create different chars for borders to enhance the resolution.

And you can align characters in a way like this:

 

0 4 8 c

1 5 9 d

2 6 a e

3 7 b f

 

Fit this on the screen and you have a graphics window with a linear memory map in which precached objects can be copied in. By using allways:

 

 

 

0 4 8 c 0 4 8 c 0 4 8 c

1 5 9 d 1 5 9 d 1 5 9 d

2 6 a e 2 6 a e 2 6 a e

3 7 b f 3 7 b f 3 7 b f

0 4 8 c 0 4 8 c 0 4 8 c

1 5 9 d 1 5 9 d 1 5 9 d

2 6 a e 2 6 a e 2 6 a e

3 7 b f 3 7 b f 3 7 b f

 

You can also resize the graphicswindow etc...

 

You need only one memory (128 Bytes) change, to change up to the whole screen, if needed.

But i think, you know this technique already.

 

Charmode uses 1000 Bytes at 25 charmodelines though...

 

...

 

 

and so on... and so on

[emkay]

But it did come to the Atari ST 16bits though, a pity thought the 8bit and 16bit Ataris werent compatible with each other.    

 

That's one thing i always moaned about; why didn't the 16bit Ataris just use an enhanced version of the 8bit graphics architecture - it's worked out far better than the way the ST is arranged...!

 

Well the graphics architecture of the 8-bits is in the AMIGA already.

[Bryan]

But it did come to the Atari ST 16bits though, a pity thought the 8bit and 16bit Ataris werent compatible with each other.    

 

That's one thing i always moaned about; why didn't the 16bit Ataris just use an enhanced version of the 8bit graphics architecture - it's worked out far better than the way the ST is arranged...!

 

Cuz.. Jack says, "make it cheep!"

 

-Bry

[Heaven/TQA]

good mornin' ladies... another happy day in paradise...

 

what i ment with 512 chars on c64 is that on atari we can redefine 128 different ones while on c64 you have more... with inverse, caps lock etc... it was so on my vic-20 and has to be on c64... ok... screem ram you can just hold a byte so it is just 256... but 256 "real" ones while on atari the upper 128 are generated by the hardware (inversed).

 

everbody knows why the amiga is like the 8bit ataris... thanks for the design team behind it...

 

hve

[Nukey Shay]

Um...DLI's. With DLIs you can have a unique character set on every modeline.

 

Question for those playing the home game:

Why is it "a unique" and not "an unique"?? U is a vowel, isn't it?? +50 pts.

 

Another example:

He shot a unicorn...he shot an unicorn...it doesn't work. There are just no unicorns to shoot

 

This is why spelling bees are only won by ugly little girls

[TMR]

what i ment with 512 chars on c64 is that on atari we can redefine 128 different ones while on c64 you have more... with inverse, caps lock etc... it was so on my vic-20 and has to be on c64...

 

There are only 256 characters in the font; inversion is just the latter 128 characters (and is optional on custom fonts) and lower case is handled by a second font so can't be displayed at the same time without splitting the font pointer in some way. The same applies to the VIC, but the C16 and Plus/4 can do hardware inversion as an option.

[RJ]

Because the "u" in "unique" & "unicorn" is pronounced as "yoo-", a sound that starts w/ a consonant (in this case, "y") just like "yak" or "yawn" & not a vowel ("under", "upset"). We'd never say "an yak" or "an yawn" would we? It helps to think of the words as "yunicorn" & "yunique". Get it?

 

Now, what's the past tense of brake, as in to stop a car? Is it broke, or braked? (Hint: spelling is important!)

[emkay]

check out c=hacking issues... i think in one of them there is a doc about fractalus on c64... i guess it was the superCPU turbo board adaptation?

 

 

The most impressive thing on the C64 is, how the users are trying to think about on how the machine can be used better and be advanced in several functions.

1. Get more colors in higher resolutions

 

But all that I can see is allways a max res of 320x200 with 16 (block-)colors or 160x200 in flickering resulting colors of up to 128 ?

 

2. Get better sound...

 

SID is a musical wonder of its time. But, equal how many CPU speed is used to gain better sound, it sounds allways like SID.

 

3. Increase system speed. I think there are many jokes around. By allways optimizing ML the system will look something faster, but it will not really get faster anyway.

 

 

So every bit of better or faster looking graphics is suggesting a faster machine to the viewer.... that is the whole trick.

 

 

 

By taking a look at the ~5years older ATARI architecture...

 

The "so bad" POKEY is possible to sound like SID or YM or is able to sound like AMIGA though.

 

Belonging to the XL/XE graphics, there is really nothing that I am satisfied with...

 

Exeptions are NUMEN (bumpmapping etc.), Sheddy's Space Harrier and... ofcourse my MCS Pictures

 

Even in most new Demos are very heavy design-lacks in graphics and the sound is mostly to harsh...

By looking today at the Demoscene, the XL/XE still has no name because of those faulty democreations....

 

On the C64 the Design in graphics and sound has the highest priority. So at the end the machine is looking and sounding better.... so it must be a better machine which anyone is praising a deus-x machina

 

 

The graphics design in Demos still sucks on the ATARI X and by using the same tricks like on C64....

The soundvarieties of POKEY are still proven but not the musical-quality.

The graphics qualitiy in DEMOS is still at 30% ... i guess.

The Screenshots of TMRs Intro is still an exeption of 60%

 

Well this would better fit into "Games are crap", but it is depending heaviely on the Design. Speed is secondary. And the lack in enhancing gamedisigns on the XL/XE was the main problem to convert games.

[TMR]

The most impressive thing on the C64 is, how the users are trying to think about on how the machine can be used better and be advanced in several functions.

1. Get more colors in higher resolutions

 

But all that I can see is allways a max res of 320x200 with 16 (block-)colors or 160x200 in flickering resulting colors of up to 128 ?

 

Actually, part of the fun is trying to improve the colour resolution rather than the number of colours - have a look at Digital Magic by Crest which has X-FLI, which increases the colour depth considerably (there's a screenshot of Digital Magic below (no tricks, no merged interlaced frames, that's a 16 colour single frame grab from CCS64) X-FLI runs 192x168 in this image but has since been made to run up to 200 pixels high).

 

It's also possible to mix colours without interlace with quite a bit of success, although it only works properly on a real C64 because the balances aren't quite right on the emulators yet. It's just a matter of placing alternating lines of two colours with the same luminance like light red and medium grey together and they blend. A quick example (combined with interlace, but the flickering is close to non-existant on a real C64) is the mixing on the second intro screen of Attitude 6.

 

2. Get better sound...  

 

SID is a musical wonder of its time. But, equal how many CPU speed is used to gain better sound, it sounds allways like SID.

 

SID can sound like POKEY, AY and a number of other chips without really trying that hard, but doing stuff like overdriving parts of a music driver can produce sounds that the SID hasn't done before. As example of that, GRG/SHAPE/Blues Muz's Electronic Transfer (included with the just released music collection Speed by Onslaught, SHAPE and Creators) which is multi speed speed SID tune with samples. Since samples take a lot of CPU time, the music driver and indeed the collection's outfit need to slot into the gaps so they can't be using more than about half the available cycles.

 

3. Increase system speed. I think there are many jokes around. By allways optimizing ML the system will look something faster, but it will not really get faster anyway. So every bit of better or faster looking graphics is suggesting a faster machine to the viewer.... that is the whole trick.

 

That's just part of demo writing, trying to get more out of the machine than it's design specs say should happen. For an idea of scale, Odie and i experimented with writing back to RAM with unrolled loops and managed about 2K of data shifted in a frame (we had to drop playing music for that) so anything that appears to be doing more is using either an undocumented VIC-II feature or some seriously hammered code. As another example, check 4K Intro released by AEG/Smash Designs and Axis/Oxyron at Breakpoint 2003 where they managed a 160x100 stretching rotozoomer at 25FPS over the entire screen.

 

The graphics qualitiy in DEMOS is still at 30% ... i guess.

The Screenshots of TMRs Intro is still an exeption of 60%

 

Aww, that's so sweet... and he hasn't seen the improved version yet! =-)

[TMR]

Oh, nearly forgot - the 4K Intro with the 160x100 rotozoomer can be downloaded with issue 6 of Attitude, it's near the end of the directory on the second disk side.

[emkay]

TMR

 

>Actually, part of the fun is trying to improve the colour resolution rather than the number of colours

 

Heck... that pictures are the ugliest I allmost seen on C64. There must be a handycap too by creating x-fli pics...

 

>It's also possible to mix colours without interlace with quite a bit of success

 

This is allmost possible on all PAL systems.

 

 

>SID can sound like POKEY, AY and a number of other chips without really trying that hard, but doing stuff like overdriving parts of a music driver can produce sounds that the SID hasn't done before. As example of that, GRG/SHAPE/Blues Muz's Electronic Transfer

 

Well if I am on an Island and had to chose by two SIDs on the only available C64 there, I would chose Electronic Transfer and Nemesis the Warlock they are mainly the best SIDs.

The musical experince of ET is glorious. But it still sounds like SID.

Even I know some tune named "modulation.sid" this sounds quite near to YM but the difference is still there.

 

 

>As another example, check 4K Intro released by AEG/Smash Designs and Axis/Oxyron at Breakpoint 2003 where they managed a 160x100 stretching rotozoomer at 25FPS over the entire screen.

 

Naaa... this is 100% a Charmode trick... I guess. By following the animations you see allways a blockwise rotation around the main rotator and in the blocks allways the same rotation happens...

But it is a very clever usage of hardware-abilities.

[TMR]

Heck... that pictures are the ugliest I allmost seen on C64. There must be a handycap too by creating x-fli pics...

 

CPU load and there are still attribute restrictions, but regardless of opinion (and i rather like that pic) it's doing quite a bit more than the officials specs for 320x200 graphics say it should.

 

Well if I am on an Island and had to chose by two SIDs on the only available C64 there, I would chose Electronic Transfer and Nemesis the Warlock they are mainly the best SIDs.

The musical experince of ET is glorious. But it still sounds like SID.

Even I know some tune named "modulation.sid" this sounds quite near to YM but the difference is still there.

 

Check 4-Mat/Cosine's conversions of a couple of AY tunes from the Spectrum - they're not perfect AY emulations because we didn't want them to be but the gist is there.

 

Naaa... this is 100% a Charmode trick... I guess. By following the animations you see allways a blockwise rotation around the main rotator and in the blocks allways the same rotation happens...

But it is a very clever usage of hardware-abilities.

 

The hardware isn't helping apart from offering a character based screen (which, obviously, the Atari can happily support) and all the work is being done by the code. i think it's generating blocks of font and screens to display them on the fly and optimising as much as it can, either way it's pretty impressive to watch it working.

 

That's what i mean about demo code, the trick is in making it look like you're doing more than you actually are; in this case, it's doing quite a bit anyway 'cos it all crunches down to 4K...