Close to what Atari could have done?

[+Trebor]

http://www.classicgaming.com/tmk/dk-vic20.shtml

 

I was playing this just the other day. I must say quite shock to find: "How High You Can Climb?" and Pie Level screens. Not only that but it plays very well too. Really a well done port for such a limited system.

 

Nonetheless, I couldn't help but make the comparison to the 2600 - The graphics seem doable - although the mem size of 64kb - just a 'tad' too much for 2600. Anyhow, I'm still bothered by DK crummy port to the 2600, - and quite annoyed that so many ports (Even the 7800 and NES) lack the "How High You Can Climb" and Pie/Cement parts.

 

-Trebor

[DominiRican05]

Agreed, with just 2 stages the 2600 port of DK leaves a lot to be desired. Although the graphics were pretty solid, I wish they could've crammed in all the levels somehow, it gets redundant very quickly.

[Lord Thag]

Not quite, the two systems are vastly different, but the 2600 could definately do a better DK. Look at later 2600 games like Stargate and Solaris. The system is capable of much more. The Coleco port was intentionally bad, to make their own CV port look that much better. Maybe one day someone will tackle it.

 

The Vic-20 is an impressive port, isn't it? I just got one awhile back. Good little system that gets no recognition.

[Christophero Sly]

Atarisoft did much better than Coleco with DK ports.

[DominiRican05]

Wow never heard of the Vic-20 , time to do a little research.

[Laner]

Wow never heard of the Vic-20 , time to do a little research. 

876160[/snapback]

 

Basically, it was the precursor to the Commodore 64. 1Mhz 6502 CPU, 5K of memory, 22 character columns, etc. A very limited system, but at the time (1981-ish), the only really affordable home computer, listing at $299.

[Vic George 2K3]

Atari could have done far better than that for the 2600.

 

Or at least, GCC could have done a better job, since they were responsible for much of the Atari-manufactured arcade game ports for the 2600 from late 1982 to 1984.

 

I'd still pick the Coleco-produced 2600 version over the VIC-20 version.

[Lord Thag]

Basically, it was the precursor to the Commodore 64. 1Mhz 6502 CPU, 5K of memory, 22 character columns, etc. A very limited system, but at the time (1981-ish), the only really affordable home computer, listing at $299.

 

And it's one heck of a great gaming system. It's really fast, far more so than the C64 due to it's sprite handling (I'm assuming). Lots of very fun games on it too. I recommend Gridrunner, Star Post and Pharoah's Curse

[Foxsolo2000]

I heard that Coleco deliberatley did a poor job on their ports to the 2600 so as to wean gamers off the Atari and on to the Colecovision which offered three levels instead of two. I had a Vic 20 too (although I never had Donkey Kong for it) and going off subject slightly I saw an ad some years ago announcing that Street Fighter II had been done for the Vic 20 although I never saw a picture for it. Makes me shiver to think how bad it might have turned out.

Edited June 17, 2005 by Foxsolo2000

[sandmountainslim]

Agreed, with just 2 stages the 2600 port of DK leaves a lot to be desired.  Although the graphics were pretty solid, I wish they could've crammed in all the levels somehow, it gets redundant very quickly.

876154[/snapback]

Will Donkey Kong be the last of the "great wrongs" of early eighties arcade ports to be corrected? It would really be nice to see a decent version for the VCS.

Edited June 21, 2005 by sandmountainslim

[Zonie]

Wow never heard of the Vic-20 , time to do a little research. 

876160[/snapback]

you're kidding, right?

[supercat]

And it's one heck of a great gaming system. It's really fast, far more so than the C64 due to it's sprite handling (I'm assuming). Lots of very fun games on it too. I recommend Gridrunner, Star Post and Pharoah's Curse

876176[/snapback]

 

There were some very good games for the VIC-20 (e.g. Rally X [mangled into Radar Rat Race], Omega Race, and Jelly Monsters [mangled into Cosmic Cruncher?]), but it really wasn't all that great as a gaming platform. The video controller had no sprite capability whatsoever, and the screen thus consisted of a (typically) 22x23 grid of character boxes. Each box would contain either an 8x8 matrix of pixels that were either a foreground color (one of eight, chosen per-character) or a background color (one of sixteen chosen for the whole screen), or else a 4x8 matrix of double-wide pixels chosen from foreground color (1 of 8, per-character), border color (1 of 8, screen-wide), background color (1 of 16, screen-wide), and "auxilliary color" (1 of 16, screen-wide).

 

Most games performed all action in per-character increments. In Snakman, for example, the pac-creature and ghosts both moved in 8-pixel increments. Although some games worked fine with such constraints (e.g. Rally X) it generally made Vic-20 games "clunky". A few VIC-20 games used tricks to allow smooth motion, but the color restrictions often resulted in color bleeding which was impossible to eliminate [e.g. in Jelly Monsters, dots near the pac-man or ghosts would turn the color of the pac-man or ghosts in question].

 

The VIC-20 could certainly do many things the Atari 2600 could not; many things that were trivial on the VIC would be impossible on the 2600 (unless one was willing to accept an insane amount of flicker). On the other hand, the Atari could also do many things the VIC could not. Pitfall is not a terribly tricky cartridge from a graphics perspective, but it would be beyond the abilities of the VIC-20 to do a really good port. A few cartridges manage to use interesting tricks to work around the VIC's limitations (e.g. Demon Attack) but the approaches used there are pretty limitted.

[Feralstorm]

2600 Donkey Kong was a 4K cart, so bumping up to 8K or more would go a great length toward a better DK game.

 

Coleco DK isn't that bad really, just kinda repetetive and a bit limited by havng only one barrel/foxfire per floor to avoid flicker

[Lord Helmet]

Agreed, with just 2 stages the 2600 port of DK leaves a lot to be desired.  Although the graphics were pretty solid, I wish they could've crammed in all the levels somehow, it gets redundant very quickly.

876154[/snapback]

Will Donkey Kong be the last of the "great wrongs" of early eighties arcade ports to be corrected? It would really be nice to see a decent version for the VCS.

877964[/snapback]

 

 

Someone will tackle this eventually. We just need a programmer that can handle the 6502 to come along that loves DK.

[DominiRican05]

Wow never heard of the Vic-20 , time to do a little research. 

876160[/snapback]

you're kidding, right?

877968[/snapback]

 

Nope. I'm from the NES era, so I'm not really familiar with anything before then, with the notable exception of the 2600 and a few other systems such as the Colecovision.

[Godzilla]

If you really want to see what the 2600 can do with donkey kong, take

a look at my mock ups which inspired lost monkey to make a very rough

proof of concept rom just to show i wasn't smoking wacky weed :-)

 

http://www.atariage.com/forums/index.php?s...onkey+kong+mock

 

though certainley, it would need an adavie like level of coder to achieve reality, and some scanlines may not have as many colors per scan line as i am using, depending. (but im not using more colors per scan line than the 2600 can and has handled,)

[+SpiceWare]

although the mem size of 64kb

876124[/snapback]

That's got to be wrong. While the VIC had an address space of 64K, a lot of it was already used up by things like BASIC, the KERNEL and the existing RAM. If I remember correctly, ROM cartridges available in 4KB, 8KB and 16KB. while RAM could be 3KB on up to 24KB. Cartridges could contain both ROM and RAM as well.

Edited June 21, 2005 by SpiceWare

[LocalH]

Basically, it was the precursor to the Commodore 64. 1Mhz 6502 CPU, 5K of memory, 22 character columns, etc. A very limited system, but at the time (1981-ish), the only really affordable home computer, listing at $299.

 

And it's one heck of a great gaming system. It's really fast, far more so than the C64 due to it's sprite handling (I'm assuming). Lots of very fun games on it too. I recommend Gridrunner, Star Post and Pharoah's Curse

876176[/snapback]

The VIC-20 is technically slightly faster than the C64 due to the way the C64 handles character fetches. The 6502/6510 is a two-phase processor - and in both the VIC-20 and the C64, the video chip runs on phase 1, while the CPU runs on phase 2. The VIC-20 has enough phase 1 cycles to fetch all the character and color data that it needs to. The C64 has enough phase 1 cycles to fetch the bitmap data and some of the sprite data, but if you have more than 2 sprites (I think, don't quote me on this), then the VIC-II eats phase 2 cycles to prevent corrupted graphics. Also, every 8 scanlines, the VIC-II needs to steal 40 cycles from the 6510 in order to fetch character cell and color data (this is called a 'badline'). This is why you can disable the screen on the C64 and gain a small amount of speed, but you can not do the same on the VIC-20. This also details why Commodore had to release the 1541 - the VIC-20 with 1540 is actually faster than the C64 with 1541, simply because of the badlines. That's also why the 1541 had a 1540-mode, so that you could use it with a VIC-20 and gain full speed.

 

Here is an article detailing the VIC-II's operation in the C64 down to the cycle level. I'm not aware of any similar VIC-20 documents, but I'd imagine it's somewhat simpler due to the lack of badlines and hardware sprites.

Edited June 21, 2005 by LocalH

[supercat]

If you really want to see what the 2600 can do with donkey kong, take

a look at my mock ups which inspired lost monkey to make a very rough

proof of concept rom just to show i wasn't smoking wacky weed :-)

 

You're smoking wacky weed if you think the 2600 can do that. Generally, every scan line must be made up of the following items:

 

- The playfield (background), which is 40 quad-width pixels wide, consisting of two colors (background and foreground). Use of more than two colors is possible, but will generally limit what else can be done.

 

- Two player sprites, which are eight pixels wide and one color each. These may be shown at single, double, or quad width; if single-width, up to three copies may be placed at intervals of precisely 16 or 32 pixels [two copies may be placed 64 pixels apart by using wide spacing with the middle one missing]. The three copies may be different shapes OR different colors, but must generally share one or other attribute.

 

- Two missle sprites, which are 1, 2, 4, or 8 pixel wide [selectable] solid strips. Multiple copies will be drawn if and only if the corresponding sprites are also shown multiply. The missles must be the same colors as their corresponding player sprites.

 

- The ball, which is a 1, 2, 4, or 8 pixel wide strip the same color as the playfield foreground.

 

Those are all the things you get. In a few cases, it may be possible to go beyond these restrictions slightly with very tricky coding techniques (e.g. Galaxian shows 7 copies per scan line of one of the player sprites) but they'd be a good starting point for any display-design mockup. Moving a sprite by more than 7 pixels between scan lines generally requires that there be a scan line on which the sprite does not appear. Further, it is generally not possible to move two or more sprites independently on the same scan line (if two sprites are moved in fixed relationship with each other, that can often be done on one line).

[supercat]

The VIC-20 is technically slightly faster than the C64 due to the way the C64 handles character fetches.

878307[/snapback]

 

Different vintages of Commodore 64/128 had different numbers of characters per scan line.

 

My first machine had 262 scan lines of 64 cycles each.

 

The replacement VIC-II chip had 262 scan lines of 65 cycles each.

 

My Commodore 128 had 263 scan lines of 65 cycles each.

 

The processor clock was synchronized with the character clock at precisely 3.579545/3.5 MHz. This is, interestingly, 16% slower than the Atari 2600's 3.579545/3 MHz.

 

I don't know what the derivation of the VIC-20's clock was, though character clocks might have been 3.579545/7 and thus processor clocks 3.579545/3.5. Anyone know?

[LocalH]

Different vintages of Commodore 64/128 had different numbers of characters per scan line.

 

My first machine had 262 scan lines of 64 cycles each.

 

The replacement VIC-II chip had 262 scan lines of 65 cycles each.

 

My Commodore 128 had 263 scan lines of 65 cycles each.

 

The processor clock was synchronized with the character clock at precisely 3.579545/3.5 MHz.  This is, interestingly, 16% slower than the Atari 2600's 3.579545/3 MHz.

 

I don't know what the derivation of the VIC-20's clock was, though character clocks might have been 3.579545/7 and thus processor clocks 3.579545/3.5.  Anyone know?

878497[/snapback]

I'm not sure about the VIC-20, but I know that the C64 clock relationships have been documented as based upon the dot clock, since that's what the VIC-II handles, and the VIC-II pretty much drives the rest of the system. Quote from the aforementioned "VIC article", in the "important signals" section:

 

øIN  This is the feed for the pixel clock of 8.18 MHz (NTSC) or 7.88 MHz (PAL) that is generated from the crystal frequency. Eight pixels are displayed per bus clock cycle (ø2).

 

ø0  From the pixel clock on øIN, the VIC generates the system clock of 1.023 MHz (NTSC) or 0.985 MHz (PAL) by dividing øIN by eight. It is available on this pin and fed into the processor which in turn generated the signal ø2 from it.

 

There was also a table I saw in the textmag Commodore Hacking, which detailed the exact Hz value for each the CPU along with the dot clock, cycles/line, and number of lines, on each video standard (including the two different NTSC VIC-IIs, one with 64 cycles and one with 65). PAL C64's always have 63 cycles and 312 lines. I wasn't aware that there were two different 65-cycle VIC-IIs, however.

 

I'm also mostly sure that the SID runs at the CPU clock rate - the pitch is slightly higher on NTSC as compared to PAL, running the same tune.

Edited June 22, 2005 by LocalH

[supercat]

I'm not sure about the VIC-20, but I know that the C64 clock relationships have been documented as based upon the dot clock, since that's what the VIC-II handles, and the VIC-II pretty much drives the rest of the system. Quote from the aforementioned "VIC article", in the "important signals" section:

 

The dot clock is derived using a PLL which operates as a frequency multiplier to boost the colorburst-based frequency to 8181817Hz. IIRC, it multiplies a 1438180Mhz (common crystal, 3579545*4) signal by 4/7.

 

BTW, I believe Atari 8-bit computers just use a 1438180Mhz clock divided by two for the pixel clock, which gives them somewhat wider pixels than the C64. This results in somewhat slower processing, and also a wider screen display. This is why the Atari defaults to only using the center 38 columns with its BASIC cartridge.

[DEBRO]

The Coleco port was intentionally bad, to make their own CV port look that much better.

876156[/snapback]

I've heard this before and I have to disagree.

 

The Coleco DK was done by Garry Kitchen. He did this game as a contractor and it was his second VCS game (Space Jockey was his first). He learned to program the VCS by reverse engineering the system and some early Atari games on his Apple ][.

 

I disassembled DK a couple of years ago and Garry used some nice tricks to get this game to fit in 4K.

 

I don't think the execution was intentionally bad. It was probably the best he could do at the time. He later went on to do Keystone Kapers and Pressure Cooker for Activision.

Edited June 22, 2005 by DEBRO

[Feralstorm]

I remember back when I was a kid, I tried to draw what I thought Donkey Kong would look like on the 2600. I had no real idea about 2600 limitations back then, but my concept was kinda similar in look to 2600 Pac-Man. The big thing about it was that the ramps didn't slope, looking something like the first screen of Kangaroo. I was impressed 2600 DK actually had sloping ramps at the time.

 

A better 2600 DK could be quite tough, since accurate recreations of two of the four screens would require assymetrical playfields.

 

ADDITION: Mostly for fun, I mocked up a couple screens of what an improved Donkey kong might look like, building on the looks of the Coleco game, and allowing for some flickering.. Only the ramps and rivets screens so far, because it's easy.

 

Also worked up a little idea for What Donkey Kong himself could look like if made from two player sprites intead of one double-wide.

Edited June 25, 2005 by Feralstorm

[Feralstorm]

Mockup concepts for the remaining two screens. Trying to keep these somewhere in the realm of believability.