7800 vs.....

[Crazyace]

Hi,

 

The two screenshots show the 160 mode and the 320 mode. The scrolling is 160pixel res as the HW scrolling on the 7800 is fixed to that res ( same as the 5200 )

 

Do you have a .bin version of this for us Cuttle Cart owners?

 

I've put one in the zip here, though you should be able to build it from the source if you want to change anything.

code.zip

[DracIsBack]

Hi,

 

The two screenshots show the 160 mode and the 320 mode. The scrolling is 160pixel res as the HW scrolling on the 7800 is fixed to that res ( same as the 5200 )

 

Do you have a .bin version of this for us Cuttle Cart owners?

 

I've put one in the zip here, though you should be able to build it from the source if you want to change anything.

 

Great stuff! Hope you can turn this into a game someday!

[supercat]

Unless the video processor is capable of looping then it can't do this, and I think for something to be Turing complete it must at least be able to operate on its own indefinitely after being bootstrapped. I don't know if Jaguar's video processors can loop but they'd have to be able to to even have the power of finite state machines.

 

The hardware to make a video processor loop on that sequence would be pretty simple. Since the video processor wouldn't do anything without some support hardware, and nor for that matter would other microprocessors (as distinct from microcontrollers), the need for minimal interface hardware doesn't have much to do with the question of whether a chip is 'Turing complete'.

[Gorf]

Unless the video processor is capable of looping then it can't do this, and I think for something to be Turing complete it must at least be able to operate on its own indefinitely after being bootstrapped. I don't know if Jaguar's video processors can loop but they'd have to be able to to even have the power of finite state machines.

 

The hardware to make a video processor loop on that sequence would be pretty simple. Since the video processor wouldn't do anything without some support hardware, and nor for that matter would other microprocessors (as distinct from microcontrollers), the need for minimal interface hardware doesn't have much to do with the question of whether a chip is 'Turing complete'.

 

Yes the OPL can be st to run on its own.

[Classic Pac]

I think the 7800 was a good system but it suffered from both lack of licensing and the lack at Atari on what makes a really good 8 bit game. Take Scrapyard Dog, in my opinion it could have been a Mario threat. Except Atari wanted to make the game more a matter of challenges, (like that lame music match game) and making early levels just about impossible to finish. All the game needed was a bit of tweeking, and it could have been one terrific game.

[Gorf]

I think the 7800 was a good system but it suffered from both lack of licensing and the lack at Atari on what makes a really good 8 bit game. Take Scrapyard Dog, in my opinion it could have been a Mario threat. Except Atari wanted to make the game more a matter of challenges, (like that lame music match game) and making early levels just about impossible to finish. All the game needed was a bit of tweeking, and it could have been one terrific game.

 

Correct.

 

Hardware was never Atari's issue....for the most part, they were always well ahead of the game

in many respects...the development turned to shit and fast. Under Bushnell at first, things were

not so bad. Then as time went on and Warner bought them it eventually got to the point where

Atari felt the need to mistreat and neglect the developers....this statement is based on talks with

MANY former employees and contractees of Atari. Rush jobs to get garbage that could have been

gold out the door. What were they running for? They had the time to take the time. People at one

time waited on every sneeze at Atari back in the day. As they screwed the fan base and dealers

and developers more and more, less people and pretty much no one today trusts much of what they

have to say.

 

The Jaguar, 5200 and 8 bit game consoles and the 7800 should have ruled the day after the 2600.

They blew it on all of these.

 

This current Atari nees to go back, review the mistakes of the past and take with them all the good

things that once made them a great thing. Until they do this, Atari will continue to fail and miserably.

You can't bite the hand that feeds you.

[Gorf]

Hi,

 

The two screenshots show the 160 mode and the 320 mode. The scrolling is 160pixel res as the HW scrolling on the 7800 is fixed to that res ( same as the 5200 )

 

Do you have a .bin version of this for us Cuttle Cart owners?

 

I've put one in the zip here, though you should be able to build it from the source if you want to change anything.

 

 

Really nice job Crazy Ace....I could see a BattleZone come from this.

Might be a bit simple than Moon Patrol ...then again maybe not.

Moon Patrol is pretty much straight 2D where BZ would need some

'psuedo' 3D kinda of look. Perhaps a good use for 320 mode?

 

At any rate good job!

[Gorf]

Unless the video processor is capable of looping then it can't do this, and I think for something to be Turing complete it must at least be able to operate on its own indefinitely after being bootstrapped. I don't know if Jaguar's video processors can loop but they'd have to be able to to even have the power of finite state machines.

 

Once you start the OPL it can run continuously. It has branch objects and such,

that if you time everything just right, it could run on its own and actually make

a stable display. It would hardly be of much use for any serious gaming app I'll

grant you. The OPL has an interrupt system, although buggy that can be used

to make it act just like a 7800 Maria. For this you would need help from the other

gen purp cpu's.

 

Again, this argument is one of CPU bitness versus system bitness. I have only ever

said that the Jaguar as a system is a 64 bit system. Going by any of the gen purp

cpu's is another story. Its does not have a 64 bit gen purp

 

Take away the Blitter and the OPL and you have essentially ripped the balls off of

the little black cat. The 64 bit main bus is indeed the heart of that system. The three

gen purp CPU's are more like assitants to the blitter and the OPL(which do all the real

work) and AI and game logic units....neither of which need to be 64 bit.

 

There is no MAIN CPU in the Jaguar. The OPL in fact has higher priority over the bus

than even the blitter or the riscs at default. You could change this via the control registers

but normal operation is usually the 68k since it hosts the systems, then the OPL, and

the J-RISC's and the blitter are usually under those. You could throw the blitter into

HOG mode where is HOGs the bus but this can be very dangerous as you must give

enough time to the OPL to transfer the image buffer to the line buffer.

 

The Jaguar system is quite flexible in what parts of the hardware you can use.

Tursi, the guy who just released the Skunk Board wrote a neat little demo that uses

blitter to write directly to the line buffers to draw the display image. JagRotate, I

beleive it is called. To say any processor in the Jaguar is the main processor is

just not reasonable. There are so many ways each piece can control the other.

 

The BUS is what makes the Jaguar 64 bits and not the on board processsors.

 

Anyway....since this is a 7800 topic.....has anyone ever tried to write directly to

the line buffers in the Maria chip? Can the line buffers even be accesses by the

user?

[Crazyace]

No, the line buffers aren't available on Maria.

 

- Can OPL make a stable display, I thought the height/address fields had to be reprogrammed every frame?

[Gorf]

No, the line buffers aren't available on Maria.

 

- Can OPL make a stable display, I thought the height/address fields had to be reprogrammed every frame?

 

That could cause an issue but I think the Scatologic guys said there is a way around it.

[opcode]

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

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

 

Not fair. You cannot compare modern homebrews with legacy commercial games. Today's programmers have more cartridge memory, almost unlimited time, more resources, etc.

Did the 7800 get a version of Frogger or Q*Bert back in the 80s? No, so you cannot compare those games. Of course much better versions of Frogger and Q*Bert would be produced on the CV today.

About the 100 objects on screen thing, I believe (and I can be wrong here) that part of that is used for background graphics too, right? So you don't have 100 objects to move around, unless we are talking about games with no background at all, like Galaga (ok, even Galaga has a starfield).

Another thing is how difficult it’s to program for each console. I can tell you just from reading the 7800 docs, that the 7800 is far more difficult to program because of the "funny" (to not say outdated, even for the 80s standards) video scheme it uses. Then Maria steals cycles from the 6502, as does any access to the controllers and sound chip. And I would say that even the display list steals cycles, because the program need to keep the list ordered all the time (extra processing that the TMS9918 sprite system doesn't require). Finally the CV has better horizontal resolution (256 pixels versus 160 pixels on the 7800).

Then the 7800 has just 2 audio channels, while the CV has 3 (or 4, if you count the noise channel).

Finally the CV uses a Z80, which was used by more than 80% of all arcade games during the 1979-1984 period. Aside Atari, how many companies consistently used the 6502 for arcade games? Don't you think that means something?

So generally speaking I could say that the 7800 can produce slightly better graphics, it has hardware scroll, more colors, but lower resolution. However it isn't as good as the CV in the sound department and the CV could offer more processing power for game logic since it uses a Z80 and there is nothing stealing cycles from it.

[xZanU]

So generally speaking I could say that the 7800 can produce slightly better graphics, it has hardware scroll, more colors, but lower resolution. However it isn't as good as the CV in the sound department and the CV could offer more processing power for game logic since it uses a Z80 and there is nothing stealing cycles from it.

Could Offer? A friend of mine had a CV, it was fun to play, but comparing what a system could have done to what another did do? Seems a bit offtrack. But then again, I may have missed your point all together

[opcode]

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 )

 

The V9938 can only do vertical fine scroll. However the V9958 can do both vertical and horizontal. The V9958 also offers 19K colors on screen at the same time.

[Artlover]

Not fair. You cannot compare modern homebrews with legacy commercial games. Today's programmers have more cartridge memory, almost unlimited time, more resources, etc.

What, is cart memory something that is based on new hardware technology that was only developed recently?

 

Nothing is being done now that couldn't have been done then had anyone bothered to think of it.

[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 )

 

The V9938 can only do vertical fine scroll. However the V9958 can do both vertical and horizontal. The V9958 also offers 19K colors on screen at the same time.

 

That was in the MSX2+ wasn't it .... How popular was it ( I'd guess it's a bit like the STe - where the extra features were just too late )

19k, Couldn't you get that amount of colours on a SNES at that time?

[Crazyace]

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

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

 

Not fair. You cannot compare modern homebrews with legacy commercial games. Today's programmers have more cartridge memory, almost unlimited time, more resources, etc.

Did the 7800 get a version of Frogger or Q*Bert back in the 80s? No, so you cannot compare those games. Of course much better versions of Frogger and Q*Bert would be produced on the CV today.

About the 100 objects on screen thing, I believe (and I can be wrong here) that part of that is used for background graphics too, right? So you don't have 100 objects to move around, unless we are talking about games with no background at all, like Galaga (ok, even Galaga has a starfield).

Another thing is how difficult it’s to program for each console. I can tell you just from reading the 7800 docs, that the 7800 is far more difficult to program because of the "funny" (to not say outdated, even for the 80s standards) video scheme it uses. Then Maria steals cycles from the 6502, as does any access to the controllers and sound chip. And I would say that even the display list steals cycles, because the program need to keep the list ordered all the time (extra processing that the TMS9918 sprite system doesn't require). Finally the CV has better horizontal resolution (256 pixels versus 160 pixels on the 7800).

Then the 7800 has just 2 audio channels, while the CV has 3 (or 4, if you count the noise channel).

Finally the CV uses a Z80, which was used by more than 80% of all arcade games during the 1979-1984 period. Aside Atari, how many companies consistently used the 6502 for arcade games? Don't you think that means something?

So generally speaking I could say that the 7800 can produce slightly better graphics, it has hardware scroll, more colors, but lower resolution. However it isn't as good as the CV in the sound department and the CV could offer more processing power for game logic since it uses a Z80 and there is nothing stealing cycles from it.

 

Part of the fun in old systems is trying to get more out of them...

I think it's not the 100's of sprites, more the lack of flicker - but the coleco does have an edge having 256 only vs 160/(320 cut down) and the standard sound is no comparision.

Some things are hard on the 7800, but there are also some hard things to do on the CV.

6502 v Z80 - to me they're pretty much the same.

[opcode]

So generally speaking I could say that the 7800 can produce slightly better graphics, it has hardware scroll, more colors, but lower resolution. However it isn't as good as the CV in the sound department and the CV could offer more processing power for game logic since it uses a Z80 and there is nothing stealing cycles from it.

Could Offer? A friend of mine had a CV, it was fun to play, but comparing what a system could have done to what another did do? Seems a bit offtrack. But then again, I may have missed your point all together

 

I was trying to mean that it's hard to compare a system that stopped in 84 (because of the crash) against another system that lasted till the 90s. By then memory was a lot cheaper, games were bigger and more complex.

However the MSX1 lasted till 1988, and since it used the same CPU and VDP, we could use it as an example of what the CV could have done had it stayed around a little longer.

 

First, Gradius, a MSX game from 1986:

 

Gradius

 

 

Then Penguin Adventure, another MSX1 game from 1986:

Penguin Adventure

A great "3D" game, much better than anything we saw in the CV. I suggest checking the boss battle, in the end of stage 3. And the video shows only 4 of the many different stages in the game.

 

Here is another good game, Gofer no Yabou Episode II (aka Gradius II part II) from 1988:

 

Stage 3

Stage 4 (or boss on parade)

Stage 5

Stage 6

Stage 7

Stage 8

Stage 9

Stage 10

Final stage and Ending

 

Even though the video quality here is poor, the videos give a good idea of how much stuff the CV could handle on screen. Some of the later stages could be a real challenge for a NES...

[opcode]

Not fair. You cannot compare modern homebrews with legacy commercial games. Today's programmers have more cartridge memory, almost unlimited time, more resources, etc.

What, is cart memory something that is based on new hardware technology that was only developed recently?

 

Nothing is being done now that couldn't have been done then had anyone bothered to think of it.

 

Mbit cartridges (cartridges with 128KB or more) didn't exit till 1986. The biggest CV game you got during its commercial lifecycle was 32KB. The NES got dozens of Mbit games. I am sure the 7800 also lots of them.

[opcode]

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 )

 

The V9938 can only do vertical fine scroll. However the V9958 can do both vertical and horizontal. The V9958 also offers 19K colors on screen at the same time.

 

That was in the MSX2+ wasn't it .... How popular was it ( I'd guess it's a bit like the STe - where the extra features were just too late )

19k, Couldn't you get that amount of colours on a SNES at that time?

 

Yep, the MSX2+ and TurboR. And I don't think the SNES could display that many colors at the same time. However the 19K colors mode used a kind of compression similar to JPEG that limited the use of colors somewhat (it was called YJK mode). Yo can check screenshots here: http://www.faq.msxnet.org/hbivi.html

[Crazyace]

Even though the video quality here is poor, the videos give a good idea of how much stuff the CV could handle on screen. Some of the later stages could be a real challenge for a NES...

 

Although it's pretty impressive, it's mainly character graphics - and the scrolling hurts the eyes. It would have been cool to see it on CV though - has anyone tried porting it?

[opcode]

Even though the video quality here is poor, the videos give a good idea of how much stuff the CV could handle on screen. Some of the later stages could be a real challenge for a NES...

 

Although it's pretty impressive, it's mainly character graphics - and the scrolling hurts the eyes. It would have been cool to see it on CV though - has anyone tried porting it?

 

Gradius, yes.

[Artlover]

Mbit cartridges (cartridges with 128KB or more) didn't exit till 1986. The biggest CV game you got during its commercial lifecycle was 32KB.

Which doesn't mean they couldn't have done before then. It is afterall nothing more in the end then an issue of just sticking more rom memory on the cart, which was available at the time. The reason 8k & 16k bankswitching on the 2600 exists is because of the developers wanting to make games that just couldn't fit in 4k, and doing what was neccessary to accomplish what they wanted - more rom memory and modified programming techniques to take advantage of it. It's not like there were seperate cartridges makers dictating the size of them that the console companies had to conform to.

 

Which brings us back to my point; It is simply an issue where no one at the time thought to do it, or thought it was neccessary to do so. Lack of vision and foresight on the part of the old developers. "Bah, who needs more then 32k for a colecovision game." Had they, it could have been. Given the era, I suspect cost is the primary factor cartridges were generaly as small as they were. Hell, IIRC, cost was one of the factors why 2600 pac-man ended up being 4k instead of 8k.

[Crazyace]

Yep, the MSX2+ and TurboR. And I don't think the SNES could display that many colors at the same time. However the 19K colors mode used a kind of compression similar to JPEG that limited the use of colors somewhat (it was called YJK mode). Yo can check screenshots here: http://www.faq.msxnet.org/hbivi.html

 

It's been a long time since I looked at the SNES - but I think mode 3 with 256colour main screen and 16 colour sub screen blended on would give 256*16 basic - more with extra pallettes switching per line maybe..

Not as good as the YJK mode though - that's pretty cool

[DracIsBack]

Mbit cartridges (cartridges with 128KB or more) didn't exit till 1986. The biggest CV game you got during its commercial lifecycle was 32KB. The NES got dozens of Mbit games. I am sure the 7800 also lots of them.

 

It got them, but not until later in its life. I think the Epyx titles were the first, with a lot more happening in 1989 and 1990. Initially, Tramiel didn't want to pay for bankswitched cartridges, which is why 7800 games from 1986 and 1987 are 16K, 32K or 48K. He did loosen the purse strings later, but the largest released 7800 title is 144K. There was a board found for 512K (4-megabit) games and some proposals done, but Jack would neither shell out for the development or the production of the cartridges to host the games.

 

There was a proposal to do a Zelda-like game called "Time Lords of Zantac" that was 4-megabit and had battery save. Was killed off quickly.

Edited September 24, 2008 by DracIsBack

[opcode]

Mbit cartridges (cartridges with 128KB or more) didn't exit till 1986. The biggest CV game you got during its commercial lifecycle was 32KB.

Which doesn't mean they couldn't have done before then. It is afterall nothing more in the end then an issue of just sticking more rom memory on the cart, which was available at the time. The reason 8k & 16k bankswitching on the 2600 exists is because of the developers wanting to make games that just couldn't fit in 4k, and doing what was neccessary to accomplish what they wanted - more rom memory and modified programming techniques to take advantage of it. It's not like there were seperate cartridges makers dictating the size of them that the console companies had to conform to.

 

Which brings us back to my point; It is simply an issue where no one at the time thought to do it, or thought it was neccessary to do so. Lack of vision and foresight on the part of the old developers. "Bah, who needs more then 32k for a colecovision game." Had they, it could have been. Given the era, I suspect cost is the primary factor cartridges were generaly as small as they were. Hell, IIRC, cost was one of the factors why 2600 pac-man ended up being 4k instead of 8k.

 

We are talking about consumer electronics here, not expensive arcade games. Of course someone had thought about putting 1MBit of memory inside a cartridge long before that, however how much could it had costed back in 84? Mbit cartridges started to show up in 1986 (probably later in the US), because ROM started to get cheaper. Need proof? The Super Game Module. Why would Coleco want that if they really thought 32KB was good enough? And why would Coleco want to deal with an expensive add-on if they could simply produce bigger cartridges? Having the technology available doesn't mean that you can use that for consumer electronics. Price will dictate what you can and what you cannot use.