Atari v Commodore

[Wolfram]

Atari 8 bit computers are great computers. Their display system is flexible, making a lot of things possible. Over time, what is possible continues to escalate. This is a great thing.

 

same thing happened on c64 too. games got better and better through its commercial lifetime. in 82 you see 2600 like stuff, at the end of the lifespan c64 had amiga/pc titles. Sound&GFX is still being improved until today just like on a8.

 

SIO / XIO might not be the fastest thing there is, but it is great systems engineering and programming, particularly when 8K of ROM is considered.

 

I dont know whats XIO is, but SIO is nothing special. daisy chaining of devices was there before and after atari. commodore did it before/after atari aswell.

 

 

This will piss the C= guys off, but frankly, I would take a Color Computer 3, over the C64.

 

just take it. 1/100th or less of the software than on c64. no fan community. it must be big fun. .. and I'd take a speccy over a8 better software support again, more fans. etc.

 

 

Since the CPU is a 6809, and it can clock up to nearly 2Mhz, it's got plenty of horsepower for moving objects done straight up, old school software with display buffering, or just drawing in the blanking. Your choice.

 

2mhz is just not enough, to make up for scrolling and sprites with cpu alone. any coder will tell you.

[Wolfram]

SIO2PC for Atari clearly wins, at $50 it's an end-all-be-all storage solution and also emulates all other devices.

 

 

okay you win! poor c64, shouldnt have an intelligent drive, because 30 years later that means a disadvantage VS the times when it mattered and was a clear advantage.

[potatohead]

The C64 was an advance because it DID use alternating phase for it's color. That's the only way to get to 320 pixels on a composite signal path.

320 px only for luma. On chroma you will not even get 160 px resolution (that's why you get strange edges with different chromas in that resolution too).

 

And A8 video signal is pretty much the same as the C64 one: The video chips generate a chroma carrier and luma based on the pixels they display. This causes "jumps" in the chroma wave because the phase is suddenly switched from one pixel to another. No NTSC/PAL device is able to decode that correctly, so you get a lot of side effects like shadows, artifacting and inaccurate edges when the chroma phase of two pixels is too different.

 

The 320 resolution of the C64 is simply switching luma & chroma at a higher rate. Luma will be visible, chroma will "mix" with strange results but that also happens on 160 px res. Chroma is VERY low resolution, but luckily the visibility of the luma is far stronger so people hardly notice it apart from the shadows I mentioned. As a little difference the C64 has a small filter added which reduces artifacting effects a bit.

 

Got a capture card? We should settle this. The signals are quite different in terms of their color generation. Most capture cards offer a straight video option. Make sure this is the case. Turn off de-interlacing and filters, if the thing has them. Most PC capture cards have an S-video mode too. Do this with it:

 

Connect everything so that a composite display appears. Then switch to S-video mode, without changing any cables. This should be luma only, and it's been the case on all the cards I've tried.

 

You should now see a monochrome screen.

 

If so, take a minute and do this on the C64.

 

Setup the 320x200x2 mode and map some colors into the color memory.

 

Draw a set of vertical lines. Do every other line, one set of even ones and one set of odd ones.

 

||||| |||||

 

Pick a color, such as red, or blue.

 

Draw another set of vertical lines, just the same way as was done for the monochrome ones.

 

|||| ||||

 

Now capture a frame and look things over. Heck, post it here. Let's check it out.

 

The monochrome lines should be vertical lines in the freeze frame. (be sure the combine frame or de-interlace options are turned off)

 

The color lines should be a checkerboard pattern, where the pixel position varies every other scan line. On the other frame, the checkerboard is reversed.

 

.0

0

.0

0

 

When I did that kind of thing with the C64, on a composite display, I saw the checkerboard. I don't have a C64 now. Somebody here does, and has a capture card. Won't take but 20 minutes. Let's sort this bit out.

 

If the colored lines are vertical lines, like the monochrome ones are, maybe thinner, then the color timing is fixed. If a checkerboard pattern is seen, or at the least, the position of the pixels is shifted vertically, like I've drawn above than the color timing is interlaced.

[potatohead]

[stuff deleted here]

 

2mhz is just not enough, to make up for scrolling and sprites with cpu alone. any coder will tell you.

 

You didn't read the post. I said for doing some technical computing, I added the CoCo 3 to the collection. And it would be my choice because I've got an Atari for retro gaming / scene stuff. The nice CPU is more than adequate for anything I would want the machine to do.

 

And maybe you've not looked at what a full 2Mhz gives you! On that machine, there is NO CPU cost for graphics. CPU runs at full clock, no matter what resolution is in play. It's no C64 or Atari for scrolling + moving objects. Totally give you that. But it's more than capable of great game experiences. Think "Rescue on Fractalus" without slow frame updates, not "Turrican". Anyway, my point was not to go CoCo 3 -vs- anything. It was simply about there being plenty of Atari stuff going on to keep me happy, and what would motivate me to obtain another machine. Hell, I can't play all the Atari stuff, nor do I want to. I want to be setup to see new stuff, and play favorites.

 

Adding another 2GB library is too much.

 

A C64 would be more of the same kinds of stuff I'm already doing on Atari. All good, but given I know the Atari machine well, and things are happening, I'm good with that. Flip it around, and I know you are having a great time on your C64. All good. Some of us have time for more machines, and I'm sure adding a C64 makes perfect sense! Game on!

 

XIO refers to the Atari software OS code that interfaces with SIO in POKEY. The two together provide device independent I/O for the Atari. Each device gets associated with an assembly language handler. That rolls up to Atari Basic where I/O operations happen in a consistent fashion, meaning a very new device developed today could talk to a BASIC or ML program written years ago, given the handler is provided. That process is documented and consistent.

 

Having a "smart disk drive" didn't really get anybody much in the end did it? It's a nice thing to have it compute something. (cool actually)

 

But really, a disk is data read and write. When the smartness of the drive gets in the way of that, and when software kludges are layered in there as well, building simple, useful, compatible things is more expensive. In the here and now, that means $$$ and Atari wins that hands down, just like others here have said. On Atari it's simple, cheap, fast and compatible. From the reading I've done, on C64, you have to lose one of those things. Pick one!

 

IMHO, that's good system engineering. Something that is not present in the C64, where I/O devices are concerned. Lots of kludges, with fast load carts and such...

Edited April 18, 2009 by potatohead

[Fröhn]

When I did that kind of thing with the C64, on a composite display, I saw the checkerboard. I don't have a C64 now. Somebody here does, and has a capture card. Won't take but 20 minutes. Let's sort this bit out.

Depending on the color I choose I get a checkerboard or not (U doesn't change sign every rasterline while V does). Btw, the same happens on A8. Ofcourse this is expected, because the +/- sign on the V is a core element of PAL. Without it, the signal could not be decoded.

 

Decoding works as follows:

 

C = color carrier

U = blue-yellow distance

V = red-cyan distance

 

C is just modulated U+V or U-V depending on rasterline.

 

To get U and V back from a C signal, the decoder simply does the following:

 

U = (C_this_rasterline + C_previous_rasterline)/2

 

and:

 

+/-V = (C_this_rasterline - C_previous_rasterline)/2

 

This is why you HAVE to get that checkerboard for some colors but not on others. Colors which use lot's of U but little V will give you straight vertical lines, colors with lot's of V will give you checkerboards.

 

If I use seperate chroma/luma the color I choose changes nothing on the luma output ofcourse.

[potatohead]

OH CRAP.

 

You are in PAL...

 

Yeah, you are gonna see the checkerboard. Bummer.

 

Any chance at an NTSC go?

 

PAL output then is very similar between the two machines. Interesting! That's worth the exchange right there. Thanks!

 

That's not true on NTSC.

 

An A8 will render vertical stripes regardless of the pixel color. The width of the stripe changes with color, and it's position changes slightly too.

 

I'm near positive an NTSC C64 will render the checkerboard on NTSC.

Edited April 18, 2009 by potatohead

[Fröhn]

Any chance at an NTSC go?

No, NTSC machines are hard to get over here.

 

PAL output then is very similar between the two machines. Interesting! That's worth the exchange right there. Thanks!

 

That's not true on NTSC.

I'm not sure what you meant with that Apple2 comparision though. Did you mean that the A8 generates colors by luma artifacting like Apple2?

[potatohead]

It does.

 

The chroma signal is basically added to the luma signal. In the simplest case, it's just wired to the same output. Probably there is a resistor there to balance levels, but they are added together.

 

When a hue is specified on Atari, a little burst of color info is output. The hue requested determines when it's output, with respect to the color reference. In the end, it's just a little pixel.

 

Doing the same thing with a micro, basically generates Atari colors. And it can be done with just a pixel stream, where the pixel clock is equal to the one used in the Atari to generate hues. Take a 160 mode pixel, divide that by 16, and output 1/16 of a pixel, and you will get that Atari color the same way the Atari does.

 

One difference between the Atari and the Apple, is the chroma pixels are added to the luma ones, so it's not just a little tiny pixel. More like a wide pixel, with a smaller one imposed on it. The Atari colors fill more of the screen and don't have that sharp look Apple colors do. Apple color pixels are seperated by nothing but black. Atari ones do have the luma data carrying through, for a fuller look on the TV.

 

A high frequency boils down to a small pixel. All pixels are is frequency over time, plotted on the TV scan line.

 

Build a display system that can output small pixels, and you get lots of colors, because the two are basically the same thing!

 

That is why the Color Computer 3 screenie I linked, works the way it does.

 

Chroma generators, like those seen on the Atari, VCS, CoCo, etc... just do artifacting, then add that to the luma, and the result is a composite signal. That is what composite is --an addition of the various signals onto one wire for transport to the display. Artifacting really is just generating high frequency data to be seen as color.

 

Took me forever to sort that out.

 

Started with wondering how the Apple gets it's colors and why we see stripes on a monochrome display. That same monochrome display would show stripes on lots of computers, but not the C64! Back then, that got me to thinking about these things and it's been some tinkering ever since.

 

The best thing that has happened (and the most fun) was getting the Propeller micro, where these things can be coded up directly. It's possible to make damn near any video display you want. It's only got 6 lumas though, without making a custom DAC circuit But all the color options are there at least! The DAC thing isn't hard. Either get a chip, or build a resistor ladder. Most people use the reference circuit though, so that's where I stay because then others can run stuff on their boards.

 

The key to sharp 40 column text on the NTSC TV lies in the interlacing of the color signals, for that 320 pixels of color info. The C64 did this, the Atari did not. That's part of why 320 mode is one 1.5 colors. There literally exists no mechanism in the GITA to provide 320 pixel addressable color, because of how the color is generated.

 

The Atari method does yield good text, because the luma change doesn't artifact all that much. On an NTSC machine, a switch to GR 0 in black and white will show red / blue fringes. With the blue on white text, it shows blue and maybe light blue green fringes. Very easy to read as the whole works is basically constrained to a small portion of the color wheel.

 

On a C64, lower contrast colors look good, but high contrasts are possible. What ends up happening on NTSC is significant, visible dot crawl as the color interlacing can be readly seen. On PAL, it appears to smear and smudge some. Difference between the two formats. I'll have to get a PAL machine of some kind, or run some PAL code on the Prop as I don't understand this fully yet.

Edited April 18, 2009 by potatohead

[+wood_jl]

SIO2PC for Atari clearly wins, at $50 it's an end-all-be-all storage solution and also emulates all other devices.

 

 

okay you win! poor c64, shouldnt have an intelligent drive, because 30 years later that means a disadvantage VS the times when it mattered and was a clear advantage.

 

Clear advantage? More like achilles heel, for sure. Doesn't the 1541 run like 300 characters per second, or 2400 baud? Maybe that's the slowest (std) speed, but SUPER slow. So they used some tricks with special loaders (etc) to speed it up. Guess what? That doesn't make it fast. It may have been a clear advantage over 2400 baud normal speed, but not an advantage relative to other 8-bit system's drives. The A8's drives weren't particularly fast compared to Apple, but they were compared to C64. 19,200 > 2400. So it was a disadvantage 30 years ago (relative to A8) and it's a disadvantage now (relative to A8 peripheral emulation). So now, just exactly what is that "clear advantage?"

Edited April 18, 2009 by wood_jl

[Fröhn]

It does.

 

The chroma signal is basically added to the luma signal. In the simplest case, it's just wired to the same output. Probably there is a resistor there to balance levels, but they are added together.

Yes, just like on C64 composite output.

 

When a hue is specified on Atari, a little burst of color info is output. The hue requested determines when it's output, with respect to the color reference. In the end, it's just a little pixel.

Apple2 colors are all luminance based: Because the pixel clock is exactly 2x the color carrier frequency, you can use luma changes to output four different colors (0000, 0101, 1010, 1111). The Apple2 doesn't have an explicit chroma signal.

 

On A8 you can do both. Since the NTSC A8 pixel clock is exactly 2x carrier freq too, you can also do Apple2-style artifacting colors. But A8 also can generate colors via it's seperate color carrier generator feeded by the GTIA chroma bits of the color registers. That's just the same as how the C64 generates it's colors, except for that on A8 you can set chroma/luma values directly and on C64 you have a lookup table which maps 9 luma levels and 10 chromas to the 16 different colors.

 

Concerning 320x200: On A8 there is a circuit which forces monochrome in that mode (however, with PMs you can circumvent that). On C64 they simply didn't care for the possibility of heavy artifacts when using the right pixel patters, so 320x200 has color just like 160x200.

[Fröhn]

Clear advantage? More like achilles heel, for sure. Doesn't the 1541 run like 300 characters per second, or 2400 baud? Maybe that's the slowest (std) speed, but SUPER slow.

I think it's about 4-5000 baud including disk access (not pure bus transfer speed). But that's just the original firmware.

 

So they used some tricks with special loaders (etc) to speed it up. Guess what? That doesn't make it fast.

I have to disagree. Good fastload routines achieve up to 10 kB/sec including disk access. Pure bus speed would be 30 kB/sec there. SIO is quite slow compared to that.

 

So it was a disadvantage 30 years ago (relative to A8) and it's a disadvantage now (relative to A8 peripheral emulation). So now, just exactly what is that "clear advantage?"

There is no "clear" advantage but it can easily be faster than SIO and you got a 2nd CPU + RAM which you might use for other stuff too.

[potatohead]

Apple actually does more colors, because there is a pixel shift bit, that moves the pixels relative to the color reference for two other colors. That yields 6, plus the white pixels are shifted slightly, and are white only because two of them are packed together.

 

An explicit chroma signal, of the type generated by the Atari is just controlled artifacting. The pixel clock on that one is 2400 pixels per scan line, or 15 pixels per 160 mode pixel, where only one is lit at a time, based on the hue value.

 

Let's put it this way. On a 2400 pixel display, following that same constraint, Atari colors would be reproduced, without a dedicated chroma circuit.

 

All the thing does is load a counter with the hue value, then when the count is done, it outputs a small pixel. Or, if you want to think of it as a frequency, it's a cycle of a higher frequency. One and the same...

 

This is why Atari colors don't have saturation control. More data is needed, and greater control over that output is needed.

 

On that 2400 pixel display again, let's say 16 pixels are at luma 2, and that there are 8 lumas. That's a fat, monochrome pixel. Wouldn't look any different than an Atari pixel. Now, take one of those 16 pixels and crank it to luma 8. Now you've got a color pixel! If the Atari had luma control in it's chroma generator, then saturation would occur. It doesn't. BTW: The Apple double high-res mode, just does smaller pixels, so you get more colors. The difference between Apple and Atari is the Atari does output luma info and chroma info, for fuller looking pixels. Apple just outputs pixels, and where they are is the color they are.

Edited April 18, 2009 by potatohead

[potatohead]

Atari has easy peripheral connects these days. Cheap, robust, effective, and they work with everything.

 

That's nice.

 

If speed is needed, then use the parallel bus on the newer machines. No worries.

 

And, if I'm not mistaken, a handler can be written to still talk to the older software with no worries. Nice huh? Instead of a software kludge that has to be tracked considered, etc... a hardware solution is added, then integrated into the system as any other device is.

 

IMHO, Atari has this one hands down.

Edited April 18, 2009 by potatohead

[Wolfram]

So they used some tricks with special loaders (etc) to speed it up. Guess what? That doesn't make it fast.

 

guess what it's faster than a8 ever will be. it was faster when it mattered. and now when it doesnt matters anymore you take the advantage which made it faster and turn the tables and make it a disadvantage. very creative arguing I have to admit.

[Wolfram]

If speed is needed, then use the parallel bus on the newer machines. No worries.

 

 

yeah. c64 alone vs the whole line of a8 computers.

 

we can argue like that too:

 

I'll take plus4 for nr of colors and ability to display them, c128: 80 column display, diskspeed, CPU speed, etc.

[potatohead]

The Atari way of doing peripheral I/O is the more robust way.

 

Edit: And you forgot the device independent I/O. So, your older Atari user can use SIO, the newer one parallel, and both run the same software written before either option was realized.

 

That's the systems engineering bit again.

 

If I'm not mistaken, the C64 has parallel capability right? Has serial too, right?

 

What it does not have is the OS structure in place to make effective use of it, without add-ons and kludges. That diminishes the value of the things over time.

 

 

Here again, we've got:

 

OH SHIT! THIS GUY IS SELLING THE IDEA THAT THE C64 ISN'T THE SHIT.

 

DAMMIT! SPRITES AND COLORS AND SID ARE ALREADY ON THE TABLE.

 

DIDN'T WORK. SOME OF THESE LEVEL HEADED ATARI GUYS JUST SUCK.

 

MUCH EASIER TO JUST DISTRACT AND MAKE NOISE. WHAT TO DO?

 

I KNOW!

 

SAY IT. THE C64 IS THE SHIT. JUST SAY IT! SAY IT! SAY IT! SAY IT!

 

 

 

 

 

Wolfram, dude.

 

Laugh. It's funny. It's gotta be, or the alternative is grim, no?

 

Have a good weekend.

Edited April 18, 2009 by potatohead

[Heaven/TQA]

Jesus...

[Fröhn]

An explicit chroma signal, of the type generated by the Atari is just controlled artifacting. The pixel clock on that one is 2400 pixels per scan line, or 15 pixels per 160 mode pixel, where only one is lit at a time, based on the hue value.

It doesn't really matter how the chroma signal is achieved. Those 2400 clocks are no "picture elements" (pixels), they are just possible phase shift steps. All that matters is what is achieved: A phase shift with a near-sinus (filtered square wave) color carrier.

 

Let's put it this way. On a 2400 pixel display, following that same constraint, Atari colors would be reproduced, without a dedicated chroma circuit.

Yes, like on Apple2. But as I said: It is not like on Apple2 where the chroma is just luma pixels. It's a real carrier signal.

 

All the thing does is load a counter with the hue value, then when the count is done, it outputs a small pixel. Or, if you want to think of it as a frequency, it's a cycle of a higher frequency. One and the same...

To get a nice square wave which can be filtered down to a sine wave you need 50% set pixels. Like this: 0000000111111100000001111111

 

This is why Atari colors don't have saturation control. More data is needed, and greater control over that output is needed.

Yes, same is true for C64 and +4 colors. No saturation control, the amplitude of the color carrier is always the same except for greyscale where the color carrier is turned off.

 

On that 2400 pixel display again, let's say 16 pixels are at luma 2, and that there are 8 lumas. That's a fat, monochrome pixel. Wouldn't look any different than an Atari pixel. Now, take one of those 16 pixels and crank it to luma 8. Now you've got a color pixel!

Yes but that's not how A8 video works. A8 has luma pixels, and A8 has a color carrier signal too. No Apple2 luma only display, look here:

 

http://www.atarimax.com/jindroush.atari.org/achgtia.html

 

LUM0-LUM3 are the luma bits which are then DA converted, the COLOR pin already has the phase shifted color carrier.

 

If the Atari had luma control in it's chroma generator, then saturation would occur.

I never said that it has. In fact I know pretty well that all those composite based 8 bit computers have the same amplitude for the color carrier for all colors.

[potatohead]

If you add all those lumas together with the chroma, you have composite.

 

The same thing then can be done with a single pixel stream, period.

 

Thanks for the discussion though. Time to let Wolfram go bat shit nuts again over I/O.

[frenchman]

Basically Wolfram signed on here to claim C64 superiority which, as a matter of fact, didn’t happen. He showed us some ZX Spectrum type pictures on the C64, enjoys the ZX Spectrum over the Atari XL, and couldn’t show us anything on C64 which would not be possible on Atari XL.

I think he’s also a bit jealous of ZX Spectrum as that computer outsold the C64 5 – 1 in the UK, and he is clearly a ‘most software = most quality’ believer. The ZX Spectrum had a larger software range in the UK, so he’ll enjoy ‘tape loading’ during the 80s, when ‘real’ computers all had fdds, and his believe must be that the ZX Spectrum has the best games, even beating the C64. Yes, the Spectrum has more software than C64, so it must be good, according to the gospel of Wolfram. Next thing he’ll claim the ZX Spectrum sound beats pokey.

Remember Oswald; ‘any other platform but Atari freak’, later this deluded person was going to claim that the Fairchild was technically better than VCS and had better games. I reckon, Wolfram = Oswald. What a loser.

[Wolfram]

The Atari way of doing peripheral I/O is the more robust way.

 

Edit: And you forgot the device independent I/O. So, your older Atari user can use SIO, the newer one parallel, and both run the same software written before either option was realized.

 

That's the systems engineering bit again.

 

If I'm not mistaken, the C64 has parallel capability right? Has serial too, right?

 

What it does not have is the OS structure in place to make effective use of it, without add-ons and kludges. That diminishes the value of the things over time.

 

 

C= had this thingie you call SIO before a8 came out, including the device independent I/O.

Edited April 18, 2009 by Wolfram

[emkay]

real colors? like the c64 has fake colors ? I dont get it. A bit incorrect tho, for 256 colors you have to halve the resolution vertically.

Also: Every 2nd rasterline has to be close to black and the saturation is halfed because of chroma 50:50 mixing from one rasterline to another with every 2nd rasterline having no chroma signal. PAL only ofcourse, since NTSC doesn't do that rasterline color carrier mixing. It's a nice mode but not a perfect mode.

 

You can do the following:

 

gr.9 line for 16 lumas

gr.10 for the offset of the pixel, by a half pixel

gr.9 line for 16 lumas

gr.10 for the offset of the pixel, by a half pixel

gr.9 line for 16 lumas

gr.10. for the offset of the pixel, by a half pixel

 

So you get a simple interleaving.

 

Make it intelaced then with every second frame:

 

gr.10 for the offset of the pixel, by a half pixel

gr.9 line for 16 lumas

gr.10 for the offset of the pixel, by a half pixel

gr.9 line for 16 lumas

gr.10. for the offset of the pixel, by a half pixel

gr.9 line for 16 lumas

 

On a standard TV set the eye recognizes a resolution of 160x240 with 256 colours then.

 

This may get even more interesting by the fact that Antic can be "adjusted" with some small programming to set interlaced lines to half a line heidth. Resulting in something like

 

160x480 256 colours.

 

But, you can do mode interleaving with all resolutions ... hires and 16 colour modes for example. In a perfect instance you get something like hires with 16 colours then.

 

.... just to mention it ...

[dwhyte]

Commodore 64 designers ripped off the Atari's lower case font... Atari and C64 lower case text is identical... There's a little piece of Atari in every C64...

 

 

 

Mwa ha ha ha ha...

Edited April 18, 2009 by dwhyte

[Wolfram]

Commodore 64 designers ripped off the Atari's lower case font... Atari and Commodore lower case text is identical... There's a little piece of Atari in every C64...

 

 

 

Mwa ha ha ha ha...

 

http://en.wikipedia.org/wiki/PETSCII

 

The character set was largely designed by Leonard Tramiel (the son of Commodore CEO Jack Tramiel) and PET designer Chuck Peddle. Peddle claims the inclusion of card suit symbols was spurred by the demand that it should be easy to write card games on the PET (as part of the specification list he received).[2] The VIC-20 used the same pixel-for-pixel font as the PET (although the characters appeared wider due to the 22-column screen). The Commodore 64, however, used a slightly re-designed, heavy upper-case font that was basically a thicker version of the PET font. The reason for this was the higher resolution of the C64 which caused color artefacts when using the thin PET font. The result looked similar to the Atari font which is why some people believe that the C64 font is a copied and modified version of the Atari font, but since the PET font can be converted to the C64 font with a small program, this theory is out of question.

[dwhyte]

The result looked similar to the Atari font which is why some people believe that the C64 font is a copied and modified version of the Atari font, but since the PET font can be converted to the C64 font with a small program, this theory is out of question.

 

I read the same article before writing my post Trollfram... Now, if the PET font can be converted to the C64 font with a small program--therefore nullifying what I'm saying--does that mean the PET font can be redefined as the C64 font? Or the C64 font can be redefined with the PET font? Either or, if case 1 then the PET is redefined with Atari lower case text. If case 2 then the C64 has the PET's lower case which is different than the A8's...

 

 

 

SUCKA!!!!

Edited April 18, 2009 by dwhyte