Jump to content
etschuetz

What is the 7800 really capable of?

Recommended Posts

 

 

Your "7800" comparison above, but with four colors, providing (golden) blond hair, seems like a very likely candidate (Although red hair was the NES/SMS choice for some reason). May need to change the flesh tones to make it appear better with the (different color) hair - not sure.

:ponder:

 

:)

 

ff79R8.png

  • Like 1

Share this post


Link to post
Share on other sites

 

:)

 

ff79R8.png

 

Now that is more like it and a should have been (And a very realistic could have been) for the 7800. Awesome sir, thank you! :)

 

Combine that kind of quality character sprite with 2 Player Cooperative play and (slightly) tweaked gameplay (Something as simple as slowing down the speed in which enemies strike and/or their amount of hit damage to the player), give it POKEY sound, and we would of had an amazing port on the 7800.

 

That original 7800 sprite looks like the "flesh eating" disease combined with the "elephant man" disease creating some sort of fighting character.

 

Understanding the 7800 sprite mode capabilities, but making a concession/trade-off of only utilizing 3 or 4 colors total, if feeling up to it, I'm curious how your original large character/160B mode creation would appear.

:ponder:

  • Like 1

Share this post


Link to post
Share on other sites

The things that stand out to me is the lack of games with vertical and horizontal scrolling, numbers of sprites, over all game complexity, and especially sound, the 7800 simply didn't have it.

 

 

I am Mostly just listening and learning in this conversation, and not disagreeing with most of what's going on here, but I'd like to point out that the 7800 could (and sometimes did) handle tons of sprites, Robotron comes to mind.

  • Like 1

Share this post


Link to post
Share on other sites

 

Understanding the 7800 sprite mode capabilities, but making a concession/trade-off of only utilizing 3 or 4 colors total, if feeling up to it, I'm curious how your original large character/160B mode creation would appear.

:ponder:

 

I'm glad you like the sprites, Robert. :)

 

Here is an alternative in 160A mode 6 colors.

 

 

 

 

 

 

m9VYJR.png

xr04tN.png

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Very cool...I was thinking along the lines of overlapping sprites to achieve the higher colors after making my previous post. You must have read my mind. :-D

 

Not sure how that translates to programming though, and how much (additional) overhead (cycles eating) would be added to a game having a second set of sprites overlap with the first to achieve the 'unified' character.

 

Regardless, not surprising but amazing work as always, Marco. Thanks for sharing it!

 

-Rob

  • Like 1

Share this post


Link to post
Share on other sites

 

Not sure how that translates to programming though, and how much (additional) overhead (cycles eating) would be added to a game having a second set of sprites overlap with the first to achieve the 'unified' character.

 

...or background in 160A and sprites in 160B (as in Bentley Bear Crystal Quest). :ponder:

 

Just to add that watching the 7800 rom it seems there is the space to make the sprites higher, code changes are needed however.

I inserted the new sprite for test, there are issues but it is just to have an idea (works with MESS).

 

 

 

 

 

53qtvy.png

Double Dragon_sprite test_.a78

  • Like 2

Share this post


Link to post
Share on other sites

Awesome and thank you!

Is the space to make the sprites higher utilized for larger Double Dragon characters?

Just thinking about Abobo for instance.

It's probably utilized for his character for the the space that is there.

Share this post


Link to post
Share on other sites

I'd like to see someone incorporate the NES Mappers into a 7800 cartridge and get it to work. Based upon the 7800 schematics Dan Kramer posted to the 7800 group over at Facebook, it is entirely possible to use a graphics chip or "CPU" in the cartridge and have it work, not just limited to add-on audio chips like the POKEY or the never-completed GUMBY.

 

With that being said, I'm surprised Atari Corp and Atari Games/Tengen didn't decide to try to incorporate the RAMBO Mapper for use with 7800 Klax or Pit Fighter.

Share this post


Link to post
Share on other sites

First of all I have not read this entire thread, so please excuse any redundancies that I might raise. It's late on the east coast and I can't sleep. Now, addressing the original question from a layman's perspective. I think it would be best to look at what the 7800 is good at. Is it better at putting something or moving something on the screen than similar systems? A good part of that would be comparing it with it's contemporaries (and I'm not a tech guy but I'm going to guess the CV and NES). Sound is a no brainer, but in what areas does it truly excel? Maybe the best type of people to give those answers, especially with comparisons to other consoles, are the modern homebrewer who crank out as much juice as the can from our beloved, obsolete beasts.

 

Does that make any sense?

Edited by toptenmaterial

Share this post


Link to post
Share on other sites

If an on-cart CPU is supported why not let the Harmony 7800s ARM take over? Has batari said anything about such a capability?

I love that idea, but batari has stated there won't be a Melody 7800 due to cost, so a game using this approach would be Harmony-only.

 

Looking at the prospects, just for fun...

 

The natural fit for acceleration on the 7800 would be to have our mapper manage the display memory (DLL+DL), rather than the 6502. This would free up a tremendous amount of 6502 time for games with a lot of sprites and background.

 

It would also be cool if the DL+DLL memory was automatically bankswitched, depending on the status of the HALT cart line, so those addresses could also be available for general use by the game. (thinking of on-cart type RAM here, rather than the usual 7800 RAM)

 

Being able to program triggers for the IRQ line (frame-relative timer, free-running, or one-shot) would be the cherry on top.

 

No idea how feasible any of this is with the Harmony 7800 design. :ponder:

  • Like 4

Share this post


Link to post
Share on other sites

If an on-cart CPU is supported why not let the Harmony 7800s ARM take over? Has batari said anything about such a capability?

 

Isn't that "cheating" unless the ARM is emulating another CPU of that era, such as say a 65816?

 

Who knows what Atari Inc ultimately would've done. Maybe they could've incorporated the Amiga Lorraine chipset into their computer add/on case design [that the XM case is based upon] in a proto-32x style means of extending the life of the 7800. But in terms of a cartridge, I'm sure they would've went for POKEY, GUMBY, and AMY for audio, and probably used some other custom silicon for graphics. Maybe even the TI graphics chip that's used by the Colecovision and MSX for porting of certain games.

 

I just don't understand the post-crash sensibilities of both Atari Corp and Activision and how neither of them took advantage of David Crane's DPC chip that was used in 2600 Pitfall II. Sure, it doesn't work in the 2nd and 3rd revisions of the 7800 but that could've been fixed. Crane mentions nobody wanted to use the DPC after 1983 due to the crash but 1985-1986 and up until 1992, Atari Corp and Activision continued releasing new 2600 games. To my ears, DPC audio in 2600 Pitfall II sounds just as good as POKEY audio Pitfall II on the 5200. Then again, maybe Activision just didn't put a lot of effort into the POKEY audio version [the SID audio doesn't sound that great on the port to the C64 either] compared to DPC just as the contract companies porting Desert Falcon and Dark Chambers over to the XEGS/A8 didn't make it sound any better than the TIA audio from the 7800 originals.

 

I mentioned the RAMBO mapper since that was fully Tengen's [Atari Games Corp] intellectual property as opposed to the more commonly used MMC3 - MMC5 mappers used on the NES which of course were Nintendo's IP. It would seem like a no-brainer to use that on Atari Games/Tengen IP ported to the 7800 since it probably shouldn't require much code revision to port the NES version over assuming the RAMBO handled the majority of the NES port's processing duties.

 

If that's the case, then maybe an FPGA version of RAMBO would be in order. You couldn't get more "Atari" than that unless you pulled the RAMBO mappers out of old Tengen NES carts or ordered a new batch to be produced by a chip fab.

 

I don't think Tengen used any "mappers" for their Genesis titles. I'm still in awe over their Genesis version of Gauntlet using a lot of the original arcade source code and getting excellent playability and speed out of it considering the Genesis' 68000 was sub-8 Mhz and the arcade had the benefit of a faster 68010 CPU, not to mention a 6502, a POKEY, a TI speech chip, and a YM2151. The Atari ST version was damn near close without using any original arcade source code, having a much weaker Yamaha sound chip than what was in the Genesis, and taxing the 68000 for practically everything else [granted, using a 16Mhz 68000 for the ST port gives it arcade equivalent speed].

Share this post


Link to post
Share on other sites

 

I just don't understand the post-crash sensibilities of both Atari Corp and Activision and how neither of them took advantage of David Crane's DPC chip that was used in 2600 Pitfall II. Sure, it doesn't work in the 2nd and 3rd revisions of the 7800 but that could've been fixed.

 

The DPC chip should work fine in all revisions of 7800.

 

Mitch

Share this post


Link to post
Share on other sites

Isn't that "cheating" unless the ARM is emulating another CPU of that era, such as say a 65816?

"Cheating" implies that all of us coders are bound by the same rules. We're only bound by the ones we set for ourselves.

 

My own rules would include using the ARM, but I'd only use it to emulate a custom ASIC, like those used in NES mappers. The stuff I described would be doable under those rules.

 

If someone wants to go whole hog and drive it all from ARM, more power to them. If someone else wants to go purist and use the ST to develop, same thing. Whatever makes the hobby fun and interesting.

  • Like 2

Share this post


Link to post
Share on other sites

Who knows what Atari Inc ultimately would've done. Maybe they could've incorporated the Amiga Lorraine chipset into their computer add/on case design [that the XM case is based upon] in a proto-32x style means of extending the life of the 7800. But in terms of a cartridge, I'm sure they would've went for POKEY, GUMBY, and AMY for audio, and probably used some other custom silicon for graphics. Maybe even the TI graphics chip that's used by the Colecovision and MSX for porting of certain games.

 

I just don't understand the post-crash sensibilities of both Atari Corp and Activision and how neither of them took advantage of David Crane's DPC chip that was used in 2600 Pitfall II. Sure, it doesn't work in the 2nd and 3rd revisions of the 7800 but that could've been fixed. Crane mentions nobody wanted to use the DPC after 1983 due to the crash but 1985-1986 and up until 1992, Atari Corp and Activision continued releasing new 2600 games. To my ears, DPC audio in 2600 Pitfall II sounds just as good as POKEY audio Pitfall II on the 5200. Then again, maybe Activision just didn't put a lot of effort into the POKEY audio version [the SID audio doesn't sound that great on the port to the C64 either] compared to DPC just as the contract companies porting Desert Falcon and Dark Chambers over to the XEGS/A8 didn't make it sound any better than the TIA audio from the 7800 originals.

 

Well the long running thought was that Jack Tramiel simply didn't care enough about console sales, just computers. Then more recently, thought turned to blame he and his predecessors for failing to come through on deals/promises for the 7800. I think it's some of both. Tramiel wasn't keenly interested, and his interest waned when he and his execs learned how bad the system's projects and 3rd party were. Better cart hardware required money, and Jack didn't want to spend it. Probably a wise decision.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...