7800 vs.....

[DracIsBack]

For the Colecovision fans:

 

- Which games provide what you feel are the best graphics on the system?

- What games on the Colecovision play to its strengths and would be tricky on the 7800?

Edited August 16, 2008 by DracIsBack

[DanBoris]

The comparison between the Colecovision and the 7800 is a tricky one. The 7800 can do a 320 pixel wide display as compared to the Colecovision's maximum of 256 pixels, but the 320 mode is tricky to use in actual practice so most games use the 160 pixel wide mode. In the 7800's favor the 160 modes give you a lot more colors in a single sprite then the Colecovision can do, so the Colecovision will have higher resolution sprites, but the 7800's will be more colorful.

 

I think where the 7800 has the clear advantage is in scrolling capabilities. The Colecovision does have a few nice scrolling games but due to the way it's video hardware works there are a lot of limitations on how scrolling can be done.

 

I took a look at the few games that the two systems have in common and to me it's a toss up. Donkey Kong looks better on the Colecovision to me, but the graphics on the 7800 version are actually a little more detailed. On the other hand Choplifter looks much better on the 7800 with more colors used in the sprites.

 

Dan

[Gorf]

The comparison between the Colecovision and the 7800 is a tricky one. The 7800 can do a 320 pixel wide display as compared to the Colecovision's maximum of 256 pixels, but the 320 mode is tricky to use in actual practice so most games use the 160 pixel wide mode. In the 7800's favor the 160 modes give you a lot more colors in a single sprite then the Colecovision can do, so the Colecovision will have higher resolution sprites, but the 7800's will be more colorful.

 

I think where the 7800 has the clear advantage is in scrolling capabilities. The Colecovision does have a few nice scrolling games but due to the way it's video hardware works there are a lot of limitations on how scrolling can be done.

 

I took a look at the few games that the two systems have in common and to me it's a toss up. Donkey Kong looks better on the Colecovision to me, but the graphics on the 7800 version are actually a little more detailed. On the other hand Choplifter looks much better on the 7800 with more colors used in the sprites.

 

Dan

 

 

I do agree that the comparison is kind of strange. I have trouble with the fact that its a compare

between a Z-80 and 6502 system. It now introduces memory mapped I/O as opposed to I/O mapped

I/O and all that rot. From a coders point of view, its really two different worlds just on this premise

alone. From what I understand of the ColecoVision, you have to use an output command to feed the

vid chip AND write to its memory. In the 7800 you are building a list if I am not mistaken. Which is

harder to deal with? Again, another tricky subject.

 

The coder and the machine have everything to do with the outcome of the game's final look and feel.

The difference in features of the systems is enough to cause issues with making the game look as close

as possible. Of course there is also the bean counters and owners who forever get in the way of doing

things the right way, instead typically rushing things out the door.

 

I think if the proper time was taking on any system, you could get much better results than what was

sold to us by the big guns back in the day. I think the 7800, SMS, NES and Colecovision all have their

place in video gaming history. I personally like the 7800.. A ) because it's an Atari and B ) I like the

way the hardware works. The sound of course is inexcusable but it is what it is.

Edited August 16, 2008 by Gorf

[CV Gus]

DanBoris brings up an interesting point I should have mentioned.

 

This is 2008. The only new games for any of the older systems will be homebrew, so this is not as important now.

 

But back in "the day," ease or difficulty of programming was vital.

 

Say System A has built in scrolling, while System B doesn't (most else equal). However, System B has so much more raw processing power that it can handle smooth scrolling and plenty of on-screen action. In theory, both systems are pretty much equal. Let's use Super Cobra or Nemesis as an example.

 

Problem is, back then companies had budgets and schedules. If System A and System B can handle near-identical games, but System B takes more effort and time, chances are its games won't be as good as System A, unless the company wanted to invest more (whatever) into it.

 

"User friendly" had advantages.

 

Probably still does.

[Gorf]

DanBoris brings up an interesting point I should have mentioned.

 

This is 2008. The only new games for any of the older systems will be homebrew, so this is not as important now.

 

But back in "the day," ease or difficulty of programming was vital.

 

Say System A has built in scrolling, while System B doesn't (most else equal). However, System B has so much more raw processing power that it can handle smooth scrolling and plenty of on-screen action. In theory, both systems are pretty much equal. Let's use Super Cobra or Nemesis as an example.

 

Problem is, back then companies had budgets and schedules. If System A and System B can handle near-identical games, but System B takes more effort and time, chances are its games won't be as good as System A, unless the company wanted to invest more (whatever) into it.

 

"User friendly" had advantages.

 

Probably still does.

 

Exactly, as homebrewers are not being rushed by anyone. I think if companies had the tools

hombrewers have today, they'd have been a bit more productive. The PC world with all its

warts has come along way in how classic console developers can with much less hassle,

write code for a wide range of consoles. All kinds of sprite editors, cross asseblers, emulators

and the ability to run several applications on screen at once. GUI's were not common if at all

back in the day of the classic machine.

 

I think today its a lot easier for homebrewers. You can now use TASM for just about any processor

from a classic console and then some. A PC with MESS is an amazing mutli console development

system if you write a few batch files.

 

It's certainly a heck of a lot less clutter on the dev desk too. The only disadvantage is you always

need someone with a real dev kit to try it out and make sure it works on the real deal. However, you

no longer have to uplad anything. You have the bat file copy the bin the the proper software folder in

MESS, and you ALT+TAB over to an open MESS front end and lauch. Again, if it works on the emulator,

you just pray it will on the real thing.

 

 

[CV Gus]

So- let the Atari 7800 vs. ColecoVision comparison begin!

Notice the differences in Q-Bert himself, the ball, and the cube orientation.

 

 

But Q*Bert's Qubes showed that a much better looking Q*Bert was possible.

[CV Gus]

So- let the Atari 7800 vs. ColecoVision comparison begin!

Notice the differences in Q-Bert himself, the ball, and the cube orientation.

 

Well... let's be realistic here. At least you could play Q-Bert on the Colecovision!!!

 

With Warner's craptacular (albeit well-translated) line-up of fossilized rehashes for the 7800's 1984 launch, there was nothing really better on the 7800 in terms of originality/gameplay than what was already on the Coleco. How the hell do you launch a new system entirely with five-year-old games?

 

I guess there was Desert Falcon, but Zaxxon with a bird hardly constitutes new thinking.

 

It's no wonder Atari was dumped by Warner in exchange for promissary notes from Jack Tramiel. Looking at the brain-damaged 7800 launch plan, clearly Atari management went from smoking weed in the 70s to smoking copious amounts of crack by mid-80s.

 

 

To the Tramiels...talk about from the frying pan into the fire. The 7800 never had a chance.

 

Seriously, though, the game selection was nutty. Most of its games had already been done on the 5200 less than 2 years earlier (initial release was for Fall of 1984- I still have the 1984 game magazines about it).

 

If Joust and Dig Dug had been 100% completed on the CV, that really would have been a devastating blow for the 7800.

 

It seemed as though Atari had no idea what to do after 1983. The way the 7800 was managed looked like The 3 Stooges From Hell.

Edited August 16, 2008 by CV Gus

[AJ_Maine_Man]

Donkey Kong on the colecovision looks and plays better than the 7800

 

also Moonpatrol on the Colecovision looks better than the 7800 (on the 7800 the vehicle looks like crap)

[kenfused]

Donkey Kong on the colecovision looks and plays better than the 7800

 

also Moonpatrol on the Colecovision looks better than the 7800 (on the 7800 the vehicle looks like crap)

There's moon patrol for the 7800? I think you mean 5200?

[supercat]

From what I understand of the ColecoVision, you have to use an output command to feed the vid chip AND write to its memory. In the 7800 you are building a list if I am not mistaken. Which is

harder to deal with? Again, another tricky subject.

 

The issue isn't just ease or difficulty, but also speed. On the Atari 8-bit machines other than the 2600, one can store data at any address in video memory at any time. The video chip will 'steal' cycles when it needs them, but the code doesn't have to worry about that.

 

While I've not dealt with the particular video chip in the ColecoVision, I've dealt with some that are similar. To write a byte held in the A register to the address stored in HL, without advance preparation would require a sequence like:

  ld c,VID_REG1
 out (c),l
 out (c),h
 dec c
 out (c),a

Subsequent writes to consecutive addresses may be performed via OUT ©,A. I believe it's even possible to output multiple bytes with a looping OTIR instruction, but I'm not sure.

 

Looking at some of the documentation for the ColecoVision's video chip (TMS9918), it seems a lot better than some I've seen, but it still pretty limited. One major difficulty is that switching between reading and writing memory requires repeating a sequence like the above. To scroll practically, one must either keep a copy of the screen in "real" RAM, or else copy significant chunks to memory and then copy them back. Something like (let's copy the 736 bytes starting at address zero to address 32)

  ld de,704+16384 ; Starting address for first read (+16384 for read)
 ld h,my_buffer/256 ; Assume 32-byte buffer won't cross a page
 ld c,VID_REG1
 out (c),e
 out (c),d
 dec c
loop1:
 ld b,32; Number of bytes to read
 ld l,my_buffer & 255
 inir
; Now want to subtract 16384 (r/w flag) but add 32
 ld a,e
 add a,32
 out (VID_REG1),a
 ld e,a
 ld a,d
 adc a,192 ; Subtract 16384 from address, but add in carry
 out (VID_REG1),a
 ld d,a
 ld b,32; Number of bytes to write
 ld l,my_buffer & 255
 otir
; Now want to add 16384 but subtract 64
 ld a,e
 add a,192 ; Subtract 64
 ld e,a
 ld a,d
 adc a,63
 ld d,a
 and a,64 ; Test bit (trash A)
 jp nz,loop1

The performance of that would not be horrible (loops once per 32 bytes), but it would still be a lot slower than:

  ld hl,screen_base+735
 ld de,screen_base+767
 ld bc,732
 lddr

[Vigo]

The biggest issue with the TMS9918 and most of its deriatives (including the NES/SNES PPU, Master System/Genesis VDP, and the YAMAHA V9938/V9958, but NOT the PC-Engine VDP!) is that you can only write to VRAM in either VBLANK or forced blanking time, which kind of forces you to restrict yourself on how much video data can be manipulated per frame, and doing game calculations during active display. On the other hand, the video chip does very neat things as incrementing VRAM addresses after a write/read access, which, in combination of writing to a single register, can be faster than copying a memory mapped screen in CPU space.

 

The 9918 is one of the most copied chip designs in the 80's, almost every japanese console is based on its design philosophy, and in most cases, even has the exact video timing (10,73 / 5,37 Mhz pixel clock).

 

Btw, if you want to get an idea what the Colecovision could have done given more life time, just look at later MSX1 games.

 

http://www.youtube.com/watch?v=qHlTlLZ5a1I...feature=related

 

(Although these use the SCC soundchip)

 

My favourite MSX1 game:

 

 

(Hideo Kojima's (Metal Gear) first game)

 

It's the sequel to this Colecovision game:

 

http://www.youtube.com/watch?v=5fi_hzXcqr8

 

Which is also available on MSX (with MUCH better SCC sound):

 

http://www.youtube.com/watch?v=Vfxk0mTuFSo

Edited August 16, 2008 by Vigo

[Joey Kay]

To the Tramiels...talk about from the frying pan into the fire. The 7800 never had a chance.

 

No arguments here. Quite frankly, it's a shame Tramiel didn't stay on at Commodore. It may have made the players in both gaming and computing a LOT different today.

[Artlover]

The CV was available in 1983. There was no 7800 to purchase in 1983. That makes the CV years ahead because it was available years ahead. It doesn't matter if 7800s were sitting in warehouses, consumers couldn't buy one until 1986. It doesn't matter if the 7800 hardware was superior, it wasn't around when it would have made a difference.

Yeah. I wonder if the 7800 would have done any better had it been released when it was intended to instead of 2 years later. What was it, developed in 1983 with a scheduled release date of 1984. Tastes and technology change alot very quickly. 2 years is a LONG time to sit on something, especially something not upgradable.

Edited August 17, 2008 by Artlover

[Crazyace]

A 7800 with the effort put in to match the 2600 software would have been great..

 

The lack of fine scrolling on the Coleco and MSX videos hurts my eyes The still screenshots look great, but the movement is so jerky

[Vigo]

The lack of fine scrolling on the Coleco and MSX videos hurts my eyes The still screenshots look great, but the movement is so jerky

 

That's why Penguin Adventure plays to the Hardware's strength, because Pseudo 3D is something which the NES for example, couldn't do better, despite the fact that the NES hardware supports scrolling.

[Crazyace]

It's a pity that there was no timing exposed ( a la 6845 ) Did anyone ever try hacks to fool scrolling ( like the no border code for C64 and ST )? I guess anything like that wouldn't have been approved at the time by Coleco though.

[Vigo]

It's a pity that there was no timing exposed ( a la 6845 ) Did anyone ever try hacks to fool scrolling ( like the no border code for C64 and ST )? I guess anything like that wouldn't have been approved at the time by Coleco though.

 

Unfortunately, the 9918 has fixed screen parameters, so the only method for scrolling is VRAM copy.

 

The successor of the 9918, the 9938 however, can do fine scrolling:

 

 

(Space Manbow, great game, it just sucks that now, the poor 3,58Mhz Z80 is seriously getting in trouble...)

 

http://www.youtube.com/watch?v=PqF5tsT0c-o

 

And the 9938 capabilities allow for a very faithful rendition of XEVIOUS:

 

 

If you really need a cool computer system with lots of hidden gems, get an MSX2 machine!

[Crazyace]

I was well into the ST by the time the MSX2 appeared - I had a quick look on wikipedia - and it mentioned that the MSX2 only had vertical fine scroll?

( Not that the ST was much better - to get horizontal scrolling I had 8 copies of my screen, which did waste quite a bit of memory )

[Vigo]

I was well into the ST by the time the MSX2 appeared - I had a quick look on wikipedia - and it mentioned that the MSX2 only had vertical fine scroll?

 

Theoretically yes, but you also have a horizontal screen position register, which is used in Space Manbow for scrolling. That's why at the borders, you see characters disapperaring, because it moves the whole screen up to 8 pixels to the left, and then repositions it.

 

( Not that the ST was much better - to get horizontal scrolling I had 8 copies of my screen, which did waste quite a bit of memory )

 

No offense, but I think the MSX2 is much better equipped for scrolling games than the ST (except the weak 3,58Mhz Z80 CPU). The 9938 even can blit memory regions around in VRAM, plus it has 32 hardware sprites. The ST practically has only the 68000 to do all the dirty work.

[DanBoris]

Unfortunately, the 9918 has fixed screen parameters, so the only method for scrolling is VRAM copy.

 

I recently took a look at Matt Patrol, the Moon Patrol port for the Colecovision and the parallax scrolling it does is very impressive. I really didn't think that was possible on the Colecovision's hardware. Any idea how it was done?

 

Dan

[supercat]

I recently took a look at Matt Patrol, the Moon Patrol port for the Colecovision and the parallax scrolling it does is very impressive. I really didn't think that was possible on the Colecovision's hardware. Any idea how it was done?

 

I haven't seen the particular game in question, but one approach which can work well to allow fake smooth scrolling is to define character sets with pre-shifted copies of most shapes. For example, suppose a rock is 17 pixels wide by 16 pixels tall, and scrolls horizontally. One could define a total of 48 characters to display the rock at any horizontal position moving on one-pixel boundaries, or 24 characters to display it on two-pixel boundaries. The characters could be divided among one, two, or four character sets.

 

The biggest difficulties with this approach are (1) it uses up a lot of characters; (2) different shapes must have seven pixels of horizontal clearance between them; (3) it's not possible to use the ability to set independent foreground/background colors; (4) it only works when scrolling is either limited to one axis, or two 'pegged' axes (as with a Zaxxon-style scroller, though I'm not personally aware of any Zaxxon-style game using this technique). Note that for a Zaxxon-style scroller, a 17x17 shape would require 72 characters for one-pixel scrolling or 36 for two-pixel scrolling. If characters are scrolled in four-pixel increments (rather chunky, but still a big improvement on 8's) one would need 8 characters for a 12x12 shape or 18 for a 20x20 shape.

[Vigo]

Unfortunately, the 9918 has fixed screen parameters, so the only method for scrolling is VRAM copy.

 

I recently took a look at Matt Patrol, the Moon Patrol port for the Colecovision and the parallax scrolling it does is very impressive. I really didn't think that was possible on the Colecovision's hardware. Any idea how it was done?

 

There are some possibilities. The Colecovision has a whopping amount of 16kb VRAM, so there is lots of place to store preshifted tiles, where the graphics data is formatted like this:

 

tileset 0:

----*---
---***--
--*****-
-*******
********

tileset 1:

---*----
--***---
-*****--
*******-
********

tileset 3:


--*-----
-***----
*****---
******--
*******-

etc..

 

So fine scrolling would be achieved by a combination of updating the tiles and the character graphics pointer. The scrolling hills are very repetetive, which is an indicator that this technique might have been used. This technique however is severely limited. Another Possibility would be combining Sprites with character graphics.

 

s = sprite
c = character

		 ss
		ssss
	   ssssss
	  ssssssss
	 sccccccccs
	ssccccccccss
   sssccccccccsss
  ssssccccccccssss
 sssssccccccccsssss
ssssssccccccccssssss
  sssssssccccccccsssssss
 ssssssssccccccccssssssss

 

The only problem is now that the Coleco can only display 4 16x16 Pixel Sprites per line, which means only 2 mountains per line, so make em big!

Edited August 17, 2008 by Vigo

[Crazyace]

I was well into the ST by the time the MSX2 appeared - I had a quick look on wikipedia - and it mentioned that the MSX2 only had vertical fine scroll?

 

Theoretically yes, but you also have a horizontal screen position register, which is used in Space Manbow for scrolling. That's why at the borders, you see characters disapperaring, because it moves the whole screen up to 8 pixels to the left, and then repositions it.

 

Ok, that's how I to fine scroll using the 6845 - I guess you get a bonus with the 9938 that you can hide the sides using sprites

 

( Not that the ST was much better - to get horizontal scrolling I had 8 copies of my screen, which did waste quite a bit of memory )

 

No offense, but I think the MSX2 is much better equipped for scrolling games than the ST (except the weak 3,58Mhz Z80 CPU). The 9938 even can blit memory regions around in VRAM, plus it has 32 hardware sprites. The ST practically has only the 68000 to do all the dirty work.

 

No argument there , I'd have killed for a proper 'nibble' screen format, and ability to set the low byte of the display address..

 

The MSX2 did come out after the ST though - and given the smaller memory and use of the z80 I never looked at it much ( even though the graphics modes seemed better )

[carmel_andrews]

Whoever said the nes was an evolution on the coleco does'nt know what they are talking about, they couldn't be more different...Nes uses a 650x architecture and colecovision uses a z80 architecture, coleco uses of the shelf hardware to drive sound/graphics whereas the nes uses custom designed sound/graphics h/w (and that's coming from someone who would'nt be seen dead with either console)

 

Also the comparison betw. the msx series and the coleco is also way of base, the only thing that connects these machines is the variants of z80 they use, a better comparison would have been a sega 8bit thingy and the msx...as the sega 8bit thingy is adapted from the msx

Edited August 18, 2008 by carmel_andrews

[Crazyace]

Not really, they're both 8 bit machines, with video chips containing seperate vram

Both character based machines with sprites

Both MSX and Coleco use z80 and a form of TI VDP chip ( as does the Sega system )

 

I consider them different to the Atari/C64/7800 style where the video ram is just part of the normal cpu memory system.