classic battle atari 8bit vs commodore 64

[JamesD]

Just remember that C64 sprites are multi-color, and you have to overlay PM graphics over each other for the same result, so some of that sprite re-use you are talking about would deal with that rather than separate sprites. It's going to come down to what are you doing with it.

It's really easy to have animated multi-color sprites on the C64, but you can't use sprites to add more colors to a graphic like you can on the Atari, which has more colors to choose from in the first place.

 

Not sure about the sprites not being able to add more colors to a graphic on 2nd thought.

[flashjazzcat]

Technically, the VIC II uses DMA for all RAM reads. It just means it reads from RAM directly instead of the CPU having to feed it data (like a Sinclair ZX-80).

The VIC II reads the character # of the font to display, then it reads the corresponding byte of the font, and foreground/background attribute for that character.

It doesn't need to read the entire 8 bytes from the character font, but you have the right idea.

In order to make DMA take place direct from an IDE interface, a piece of hardware would need to sit between the VIC II and the system... which would be complicated.

Thanks for explanation. I take it from this that it's basically impossible to redirect the base address of the character data to an arbitrary address, which is all the SIDE player does in order to achieve the desired effect. Either that or the character data isn't fetched every frame, which would likewise be a major stumbling block.

[carlsson]

In both text mode and bitmap mode, the VIC-II can see 16K at a time. You can redirect which block of 16K it should read and write to. Two of the blocks have ROM shining through RAM, the other two blocks don't. In all four blocks, you can redirect the font in text mode to RAM for custom characters if that is what you mean by base address of character data.

[flashjazzcat]

Basically, yes. What needs to be accomplished is fundamentally a bit-mapped display (whether via text mode or otherwise) with each byte residing at the same address, and for the address to be that of the IDE data register. I guess it's pure luck that this is possible on the A8.

[carlsson]

So the Atari probably is better (or being easier) to display full motion video from an external source, while the C64 is far easier (trivial even) to paint each character in its own colour in text mode, up to as many as the palette supports.

[flashjazzcat]

I wouldn't argue with that for a moment. The lack of character cell attributes on the A8 is extremely restrictive, despite the larger palette.

[tschak909]

tell me about it, it's the reason I haven't tried to implement color in PLATOTERM on the Atari.

 

-Thom

[+mytek]

Not having an easy way to individually color text, is the one thing that stood out with the Atari vs the C64. Big mistake if you ask me .

[tschak909]

well, to be fair, the C64 was able to leverage a few years worth of semiconductor improvements...

 

-Thom

[Kyle22]

Well, guys, I skipped over he last part of this because i is all the same. IMhO, The only Good Commie (Commodore or Communist) is a DEAD Commie.

 

Long Live Atari!

 

 

Edit: Forgot to include the picture.

 

Enjoy.

 

Edited February 15, 2019 by Kyle22

[bruno_j]

Atari still have some aces in the hole:

 

Thread on Polish Atari forum about this project: http://atarionline.pl/forum/comments.php?DiscussionID=4865&page=1#Item_20

[carlsson]

well, to be fair, the C64 was able to leverage a few years worth of semiconductor improvements...

 

When it comes to the colour matrix, the Atari 400 (lacking one) was released 11 months ahead of the VIC-1001 (having one). Yes, the VIC-20 has much lower resolution, no sprites at all, worse sound etc yadda yadda but looking at this one isolated feature that is how it stands.

 

Actually as a feature that is quite interesting:

 

TI-99/4 (Nov 1979) used the VDP which has a system where characters are ordered in 32 groups of 8 characters each: @ABCDEFG in one group, HIJKLMNO in one group etc. Each group shares a unique combination of background and foreground colours. If you want A to appear in different foreground colours, you need to switch to a custom font where A is redesigned multiple times. Properly used, you can get rather nice backgrounds but pretty horrible for text screens. The VDP in a version updated for bitmap screens later was used in the MSX, Colecovision and a myriad of other systems.

 

Intellivision (early 1980) has two colour modes: the (in)famous Color Stack mode where you define 4 background colours you can cycle through and then set foreground individually for each character, or the FG/BG mode where you set a combination of foreground and background for each character at the expense of fewer colours to choose from and access to less of the ROM font.

 

VIC-1001 (October 1980) lets you select the foreground for each character but only one background colour. You can enable multicolour mode at the expense of half the resolution (similar to the GTIA modes if I'm not mistaken), but the two extra colours still are the same for the entire screen unless you get into raster line tricks. The C64 from July 1982 is roughly the same in this regard.

 

[ fast forward a few years, at the expense of possibly missing out some important systems like the BBC Micro ]

 

ZX Spectrum (April 1982) lets you select foreground and background for each character, though from a very small palette. Each character can be bright or not but that attribute then affects both background and foreground.

 

So when comparing all of those, the ZX Spectrum with the least advanced graphics hardware, has the easiest way to paint each character with a different background and foreground.

[Jetboot Jack]

I always quite liked the extra mode (Graphic 2 mode) for the TMS9918A (Ti99/4a) chip that has 2 colours per 8 pixels in in each character pixel row, not truly free color use, but quite sophisticated in and in the right hands (Konami MSX) does some nice stuff (also seen on the Colecovision)...

sTeVE

[carlsson]

Yes. To be honest the Speccy doesn't have a text mode at all, it always operates in bitmap mode and soft plots characters which is why BASIC is unable to recognize UDG when you read the screen, as that routine simply compares pixel data with the ROM font to detect matches. Once you work in various bitmapped modes, the conditions are different.

[JamesD]

Thanks for explanation. I take it from this that it's basically impossible to redirect the base address of the character data to an arbitrary address, which is all the SIDE player does in order to achieve the desired effect. Either that or the character data isn't fetched every frame, which would likewise be a major stumbling block.

It's not just a question of whether or not you can change the base address of the character data.

It has to be configured to read just from the IDE interface address range.

IDE memory maps everything for commands, status, read/write, into a small address range.

Basically, you are only reading or writing 8 or 16 bits at a time, unless your interface supports DMA.

 

I don't know what the Atari video player is doing to accomplish that, maybe a large display list that constantly changes the address, but the VIC II can't do that.

The VIC II would read from the entire address range for the font. or screen data.

An additional piece of hardware could accomplish this by sitting between the VIC II's address lines and the buss.

You'd basically output the address of the IDE port for the upper address lines during the necessary cycles.

That requires knowing exactly what the VIC II is doing during a given cycle.

 

Something similar has been done before.

The SAM chip in the TRS-80 CoCo lets you map the 6857's video on any 2K address by manipulating the addresses going to the buss.

SAM even gives the 6847 additional graphics modes by manipulating those pins on the fly based on the data being read.

SAM came out in 1978.

The NEC Trek lets you switch between 6847 color sets so you can have 8 colors on screen in 4 color modes.

This isn't difficult with the 6847, because the modes are set by making pins high or low rather than making changes in registers.

Too bad Motorola didn't offer more color choices.

With the VIC II, you'd be limited to manipulating addresses, but it's possible.

It would just be easier to use DMA to transfer data from the IDE interface.

 

Edited February 15, 2019 by JamesD

[JamesD]

well, to be fair, the C64 was able to leverage a few years worth of semiconductor improvements...

 

-Thom

When it comes to the colour matrix, the Atari 400 (lacking one) was released 11 months ahead of the VIC-1001 (having one). Yes, the VIC-20 has much lower resolution, no sprites at all, worse sound etc yadda yadda but looking at this one isolated feature that is how it stands.

...

Yeah, it's not so much semiconductor improvements as much as it is the idea.

Many arcade games are largely character based, so I wonder if something similar had existed even before the VIC.

[carlsson]

General Instruments was developing the GIMINI chipset in 1977, which somehow became the AY-3-8900 STIC. It might've been mostly feature complete by the summer of 1978, and for sure the Intellivision was test marketed late 1979. I'm not sure if that would be the first mass market home system which allows for individually setting foreground and background. Systems like the Bally Astrocade should be considered. You know the 6847 based systems better than me, so we can eliminate the APF M-1000/MP-1000. I believe the Odyssey^2 generates a raster based display like the 2600. Not sure about the Apple ][ which colour capacities it has in text mode. Arcade games tend to be custom designs, though I don't know how Atari's own arcade games looked and behaved. As the lower resolution 20 column mode on the A8 supports 4 (?) foreground colours, it couldn't have been an entirely alien thought to Atari, just that they prioritized other graphics features.

[JamesD]

[_The Doctor__]

what is that terrible music? I'd rather watch the short short video clip with the sound off or digitized sound from the show. awful!

Edited February 21, 2019 by _The Doctor__

[shoestring]

I think the music is pretty cool.

 

Its just that your ears arent yet adjusted to the harshness of the SID

Edited February 21, 2019 by shoestring

[Magic Knight]

Shame it never continued, I was looking forward to Crocket and Tubs speaking with Sid accents ;0)

[emkay]

Seems they do justice to the copyright laws. As soon as Youtube found a music track that sounds somehow "copyrighted" , you get their attentions, and possibly you lose the right for earning money with the video.

Similar things seemed to happen with the Star Wars demo. Some seconds of the real music, you lose all commercial rights of the video.

[carlsson]

I suppose the majority of those who make demos and upload on YouTube aren't there to make money on those videos anyhow. I know a lot of people make their living on the site, but then it usually is other type of content. Getting the video silenced or removed is one thing, not being able to make a few cents from advertisements shouldn't be a major matter.

[Kyle22]

Use a FREE SPEECH site. YT sucks. https://www.brighteon.com/

 

Try it, they won't delete your video.

[youxia]

Seems they do justice to the copyright laws. As soon as Youtube found a music track that sounds somehow "copyrighted" , you get their attentions, and possibly you lose the right for earning money with the video.

Similar things seemed to happen with the Star Wars demo. Some seconds of the real music, you lose all commercial rights of the video.

 

Isn't youtube one of the biggest piracy sites though? Any time I want to look up some obscure track/album it's already there - nevermind the popular stuff. Plus films. Plus links for games and soft...