classic battle atari 8bit vs commodore 64

[JamesD]

It would be interesting to know - exactly how much RAM did most C-64 games use up? Particularly those which did come on cassette.

Take for example - Sanxion, Delta, IO and such like.

 

In the Atari 400/800 era - the first cartridges were 8K - the likes of Star Raiders and Basketball - but 16K soon became the standard with Galaxian, Donkey Kong and the others. With the likes of Missile Command, Centipede and Qix - these should be able to fit within 8K? because of their simple graphics. But these were ROM cartridges - and I presume they worked fine with the 16K Atari 400.

Now when these were pirated - I don't think they'll work anymore with 16K Atari 400s because of them loading from cassette/disk? Perhaps the programmers/etc can say why they wouldn't. I would guess that most users had 48K as standard (by this time) - and there was not the need/desire to try modifying them so as to run on the 16K Atari 400s.

Of course there were games that loaded from tape - so as to run on 16K Atari 400s. Frogger, Shamus and Sea Dragon comes to mind. Games with more extensive graphics required a minimum of 32K to run - such as Blue Max? and others... 32K may seem to be an odd configuration - until you looked inside a Atari 800 and see that it had the 3 slots so as to take banks of 16K RAM to slot in. At that time even 16K RAM was not cheap.

As to 48K to 64K - for the Ataris - you have the first 2 Lucasfilm games - Ball Blazer and Rescue from Fractalus - and Dropzone being another landmark game. The later 2 Lucasfilm games - Eidolon and Koronis Rift however required 64K to run.

 

Harvey

I have no doubt a lot of games were well below the 64K limit.

Cassette games in particular are certain to be smaller.

You just didn't have to worry about trimming a program down from 17K to 16K, or from 50K to 48K in hopes of getting more sales.

 

When it comes to games like Ball Blazer, and Rescue from Fractalus, etc... it's pretty much a matter of that's what it's going to take, and if you want to play it, you need that much RAM.

 

[JamesD]

Of course, a poor choice of wording on my part. But then, really, I think fanboy is a poor choice of words too; as I describe it, blindingly loyal to something, ignoring facts and fair opinions. I'm an Atari 8-bit fanatic, but not a "fanboy."

I have my reasons for preferring it based on both technical facts and personal preferences accepting it's shortcomings and openly admitting them, compared to other similar computers, and finding them more acceptable considering other advantages, and find it a better ratio, in areas I prefer, to the shortcomings and advantages of the C64 or other 8-bits.

 

"

fanboy

noun

fan·​boy | \ ˈfan-ˌbȯi \

Definition of fanboy

: a boy or man who is an extremely or overly enthusiastic fan of someone or something

"

https://www.merriam-webster.com/dictionary/fanboy

[Gunstar]

 

 

"

fanboy

noun

fan·​boy | \ ˈfan-ˌbȯi \

Definition of fanboy

: a boy or man who is an extremely or overly enthusiastic fan of someone or something

"

https://www.merriam-webster.com/dictionary/fanboy

 

Yes. I wasn't looking for some dictionary definition for modern slang or colloquial English (Webster means little to me anymore, especially with slang). But you go ahead and let them define it for you.

Edited January 14, 2019 by Gunstar

[carlsson]

I might be mistaken, but regarding cartridges it seems to me that the Atari 8-bit supports larger cartridges, or more easily can bankswitch ROM into the memory map than the C64 can. I mean after the first batch of 16K cartridges in 1982-84, the cartridge market almost entirely dried up until the freezer cartridges in 1986-87 and onwards, and if it hadn't been for the ill-fated C64GS, we might never have seen those 128K, 256K cartridge games late into the C64's lifetime. Compare to Atari which seems to have had a continuous flow of cartridges even in the years between say 800XL and XEGS.

 

Regarding Kiwilove's question, I had a look at Delta by filling the entire memory with $AA, then loading it and going through all decrunch, cracker intros etc. It is a little hard to tell without studying the code in detail, but the majoriity of RAM between $0800 and $D800 seems to be filled. That is 52K right there. There is parts higher in memory that are filled too, in particular between $E000 and $EA00 as well as $EB80 to $EC70 and $EFD0 to $FFFF (and no, I'm not looking at the Kernel ROM at that point). Some of that might be leftovers from the decruncher, but in total it might reach 58K, not counting screen matrix and the lower 1K which surely is used as well.

[flashjazzcat]

Yes. I wasn't looking for some dictionary definition for modern slang or colloquial English (Webster means little to me anymore, especially with slang).

 

You'd better not look at the urban dictionary definition, then.

[JamesD]

I might be mistaken, but regarding cartridges it seems to me that the Atari 8-bit supports larger cartridges, or more easily can bankswitch ROM into the memory map than the C64 can. I mean after the first batch of 16K cartridges in 1982-84, the cartridge market almost entirely dried up until the freezer cartridges in 1986-87 and onwards, and if it hadn't been for the ill-fated C64GS, we might never have seen those 128K, 256K cartridge games late into the C64's lifetime. Compare to Atari which seems to have had a continuous flow of cartridges even in the years between say 800XL and XEGS.

 

Regarding Kiwilove's question, I had a look at Delta by filling the entire memory with $AA, then loading it and going through all decrunch, cracker intros etc. It is a little hard to tell without studying the code in detail, but the majoriity of RAM between $0800 and $D800 seems to be filled. That is 52K right there. There is parts higher in memory that are filled too, in particular between $E000 and $EA00 as well as $EB80 to $EC70 and $EFD0 to $FFFF (and no, I'm not looking at the Kernel ROM at that point). Some of that might be leftovers from the decruncher, but in total it might reach 58K, not counting screen matrix and the lower 1K which surely is used as well.

8K and 16K are supposedly easy. But I can't find a single source that says how large any carts are.

https://www.c64-wiki.com/wiki/Cartridge

 

*edit*

I guess I didn't look hard enough.

"C64 cartridges can map anywhere in the CPU's address space, ... The cartridge port has 14 address lines, so only 16k of ROM can be accessed."

https://en.wikipedia.org/wiki/Commodore_64

 

 

*edit*

I'm guessing additional banking hardware could be added, and it appears that is what Retro Innovations is doing.

Edited January 14, 2019 by JamesD

[shoestring]

 

As for video, I already said that was one thing the C64 wasn't good at. Not enough colors, and not a fast enough drive. Same goes for the C128.

 

 

Not sure if it's been mentioned in this thread but Dolphin DOS was a very good hardware / firmware upgrade ( both the 1541 drive and the c64 unit )

 

It really shows how fast c64 loading can be when it's done right. The mod allows the drive to be connected via the parallel interface and the 1541.

[JamesD]

 

Not sure if it's been mentioned in this thread but Dolphin DOS was a very good hardware / firmware upgrade ( both the 1541 drive and the c64 unit )

 

It really shows how fast c64 loading can be when it's done right. The mod allows the drive to be connected via the parallel interface and the 1541.

I don't know what the hardware is, but given the clock speed of the C64, I think I'd want some DMA support for video playback.

Even if it's fast enough, you still have to deal with the video limitations.

You could certainly play some sort of video but it wouldn't look like TV, it would look like full screen C64 animation.

That's not necessarily a bad thing, but you'd have to design video specifically for it to get the best quality.

You might get reasonable quality without doing that, but it won't look as nice.

On the Atari, Plus/4, and some other machines, you could just render or film footage and play it back.

The quality may not be perfect, but you don't have to create a special video.

 

*edit*

You do have to create a special file for each machine.

Edited January 15, 2019 by JamesD

[Heaven/TQA]

Honestly... you can not write through ROM to RAM like

On C64 but luckily switch off ROM.

 

But stock Atari XL/XE have only 64k-2k RAM for code. As d000-d7ff is not available for code like on C64.

 

Its more like a very creative marketing blub....

[Heaven/TQA]

Playing with a lot of retro hardware Atari seems the most expandable for years... thanks to SIO etc we had early on stuff like flashcard devices very cheap compared to other platforms now catching up with help of arduino or pi.

[JamesD]

I wasn't looking for this, but here is a simple IDE interface for the C64:
https://github.com/ytmytm/c64-ciaide

 

And a plug in C64 IDE interface.
http://www.ide64.org/
Speed comparison.
http://singularcrew.hu/idedos/perf.php

Compute's Gazette Oct 85 issue appears to have a BASIC add on called XBASIC, with graphics and sound commands for the C64.
A bit late for when I was young though.

http://www.jbrain.com/pub/cbm/mags/cg/

[carlsson]

Some useful stuff in XBASIC, though a lot of syntactic sugar that probably slows down more than you gain simplicity. I mean a command to set the border colour while you still need to know the colour numbers, only makes you memorize BRDR instead of 53280. The command to define a sprite still requires you to find a suitable memory block, POKE your data in whichever way you come up with and then call the command to direct it to that pattern. If you don't know how to convert a pattern of 24x21 pixels into data and the order to store the bytes, you're lost anyway.

[JamesD]

Playing with a lot of retro hardware Atari seems the most expandable for years... thanks to SIO etc we had early on stuff like flashcard devices very cheap compared to other platforms now catching up with help of arduino or pi.

The CoCo has had IDE for a long time. Since the early to mid 90s I think.

But then it was easy to add a driver for OS-9

 

The C64 IDE board development supposedly started in 1994.

The hardware was done long before the firmware though.

The first production board seems to have been from 1997.

 

I know cables that let you hook the C64 to a PC, or a floppy to a PC have been around a long time as well.

And Drivewire let you hook the CoCo to a PC via serial port... in the late 80s?

[JamesD]

Some useful stuff in XBASIC, though a lot of syntactic sugar that probably slows down more than you gain simplicity. I mean a command to set the border colour while you still need to know the colour numbers, only makes you memorize BRDR instead of 53280. The command to define a sprite still requires you to find a suitable memory block, POKE your data in whichever way you come up with and then call the command to direct it to that pattern. If you don't know how to convert a pattern of 24x21 pixels into data and the order to store the bytes, you're lost anyway.

Given BASIC's desire to convert numeric constants to floating point, BRDR might actually be faster.

Converting from ASCII to float uses division, which is one of the slowest things in the math library. At least if it's like other versions.

As for the other stuff... I'm sure you are right.

[carlsson]

You could also waste a variable, BRDR = 53280 and use POKE BRDR,NN through rest of your program. Unfortunately BASIC on the C64 only has 2 significant letters unlike on the Atari where all letters (or at least up to a far greater length, not sure) are significant.

 

Besides Simons' BASIC which perhaps was the closest to an official extention you could plug in, I have been looking at The Tool by Micro Application which was also sold by Handic as Tool 64 and possibly by other Commodore outlets on other markets. The Tool has some commands for text windows, structured input fields and hires graphics but nothing on sprites or sounds, though it has some other commands for programming like renumber, trace, dump variables, if-then-else etc plus a DOS wedge.

[JamesD]

You could also waste a variable, BRDR = 53280 and use POKE BRDR,NN through rest of your program. Unfortunately BASIC on the C64 only has 2 significant letters unlike on the Atari where all letters (or at least up to a far greater length, not sure) are significant.

 

Besides Simons' BASIC which perhaps was the closest to an official extention you could plug in, I have been looking at The Tool by Micro Application which was also sold by Handic as Tool 64 and possibly by other Commodore outlets on other markets. The Tool has some commands for text windows, structured input fields and hires graphics but nothing on sprites or sounds, though it has some other commands for programming like renumber, trace, dump variables, if-then-else etc plus a DOS wedge.

Yeah, creating constants for variables is the usual approach for MS BASIC variants.

*edit*

The variable lookup might take longer than parsing that string though.

 

 

I bought a Simon's BASIC cart and never used it. The syntax or some of the commands were odd if I remember right.

 

Edited January 15, 2019 by JamesD

[JamesD]

Here is the speed of the C64 IDE interface vs other options:

[carlsson]

Jolly gosh, you're right. Test program to change the border 1000 times in a row:

 

Using BRDR: 136 ticks

Using POKE 53280: 479 ticks

Using POKE BR: 196 ticks

 

 

I suppose the same can be said about most of the sprite commands too, though many people still would miss a way to define sprites.

 

This particular extension is located at $C000 so it doesn't steal any BASIC RAM unlike cartridges that map into $8000.

[JamesD]

Jolly gosh, you're right. Test program to change the border 1000 times in a row:

 

Using BRDR: 136 ticks

Using POKE 53280: 479 ticks

Using POKE BR: 196 ticks

 

xbasic-brdr.gif

 

I suppose the same can be said about most of the sprite commands too, though many people still would miss a way to define sprites.

 

This particular extension is located at $C000 so it doesn't steal any BASIC RAM unlike cartridges that map into $8000.

After seeing the code, I can see why BRDR is faster. BRDR appears to be a new keyword token.

Once tokenized, it only takes 1 byte, and that's used to call the BRDR function

[Heaven/TQA]

The ide solution I used to write Gnork demo to 1541. but they are nearwhere as good as our Atari solutions due to complex 1541 (trackloader, fast loaders). Whats far better is that 1541pi I got recently which supports everything so demos work.

[+Stephen]

I don't know what the hardware is, but given the clock speed of the C64, I think I'd want some DMA support for video playback.

Even if it's fast enough, you still have to deal with the video limitations.

You could certainly play some sort of video but it wouldn't look like TV, it would look like full screen C64 animation.

That's not necessarily a bad thing, but you'd have to design video specifically for it to get the best quality.

You might get reasonable quality without doing that, but it won't look as nice.

On the Atari, Plus/4, and some other machines, you could just render or film footage and play it back.

The quality may not be perfect, but you don't have to create a special video.

 

*edit*

You do have to create a special file for each machine.

Entirely not true. Check these videos out from 9 years ago - the video playback beats the pants off of what our Ataris can do in both video and audio qualitry.

[Faicuai]

Entirely not true. Check these videos out from 9 years ago - the video playback beats the pants off of what our Ataris can do in both video and audio qualitry.

 

That is NOT 60 fps video, from a linearly-coded multi-MB/GB FILE (limited only by solid-state storage capacity), and PROCESSED BY host's CPU+GPU+RAM+AUDIO hardware, ONLY.

 

The architecture of the C64 does not lend itself for it. Plain and simple. It simply does not have the muscle to handle 60fps video & audio playback in the same model / context as it happens with today's modern PCs

 

And anyone here that works with video encoding / decoding, day in and out, will know this perfectly well.

Edited January 15, 2019 by Faicuai

[Faicuai]

Here is the speed of the C64 IDE interface vs other options:

 

 

About 106 Kbytes/sec on both my Atari 800 & XLs (on PBI/HD partition), and up to up 500 Kbytes/ sec during ANTIC-driven video-playback.

Edited January 15, 2019 by Faicuai

[flashjazzcat]

About 106 Kbytes/sec on both my Atari 800 & XLs (on PBI/HD partition)...

Which test yields the figures you're observing?

[+Stephen]

 

That is NOT 60 fps video, from a linearly-coded multi-MB/GB FILE (limited only by solid-state storage capacity), and PROCESSED BY host's CPU+GPU+RAM+AUDIO hardware, ONLY.

 

The architecture of the C64 does not lend itself for it. Plain and simple. It simply does not have the muscle to handle 60fps video & audio playback in the same model / context as it happens with today's modern PCs

 

And anyone here that works with video encoding / decoding, day in and out, will know this perfectly well.

Well it certainly does not look like static animated 16 colour C64 screens which anybody with a set of eyes can plainly see. This is what I was replying to in my original post ("it wouldn't look like TV, it would look like full screen C64 animation").