Author Topic: DSP in a HuCard & Max Storage Size of a HuCard  (Read 3798 times)

SeymorOnion

  • Full Member
  • ***
  • Posts: 182
DSP in a HuCard & Max Storage Size of a HuCard
« on: May 14, 2012, 03:43:18 PM »
This is somewhat related to my thread about making the HuCard Shells:
http://www.pcenginefx.com/forums/index.php?topic=11807.0

I need to know if the following is feasible, because if it is,
allowances need to be made in my HuCard Shell Designs,
for those of you who wish to design the PCBs.

Ignoring cost, is it possible to include some kind of sound hardware in a HuCard, so that HuCard Games are no longer limited by the PCE/TG/TE synth?
Are there any hardware, or interface, limitations that would prevent this from working on all versions of TG/PCE/TE (and so on) hardware?
For it to be worthwhile for a developer to bother using said chip on their HuCards, no modification to the Consoles or Handhelds should have to be made, so that the market for games including this feature won't be limited to only people who can mod their console.

Ok, for the second half, also ignoring cost, what is the max size of storage space that can be somewhat easily addressed by the TG/PCE/TE?
700 MB (same as a CDR) would probably be ideal, but I'm not sure.
I'm hoping Turbo Express owners can have their cake, and eat it too; ACD Quality Games, on a single HuCard.
This should also make it easier for Game Developers to get a game out, because they won't have to deal with Data Alignment Issues on the CD-R's they send off to Publishing Houses.

And then there's the greatest benefit of all: no load times.  8)

TheOldMan

  • Hero Member
  • *****
  • Posts: 958
Re: DSP in a HuCard & Max Storage Size of a HuCard
« Reply #1 on: May 14, 2012, 03:54:26 PM »
Quote
Ignoring cost.....

If you ignore cost, most anything is possible. But who could afford a $100,000 HuCard?
The dsp idea is nice, but hucards only have a single sound output, so whatever the sound started out, it would end up being mono when sent to the pce. And then you would have to deal with clocking the chip, etc.
Possible, yes. Easy, no. Cheap....Probably not.

Quote
max size of storage space that can be somewhat easily addressed by the TG/PCE/TE?
From a Hucard, without any special hardware...2M byte, I think. Maybe 8M. Nowhere near cd size.
Now, if cost is no object, and you want to design a completely new mapping system, you could stuff however much memory you wanted on a card. Would be a big card, and require an external power source, but it could (in theory) be done.

Keep in mind, only a small part of the cd is actually loaded in memory at one time.

SeymorOnion

  • Full Member
  • ***
  • Posts: 182
Re: DSP in a HuCard & Max Storage Size of a HuCard
« Reply #2 on: May 14, 2012, 04:24:50 PM »
While the outcome saddens me, I am grateful for the reply.

The single sound output is a deal-breaker for the DSP, as is the cost to the end-user. @_@

The "Design a Completely New Mapping System" part shouldn't be too much of a problem, and I might be able to get around the external power source issue by designing proprietary chips that can make due with what the Card Slot makes available. Cost-per-pcb should remain now, if I make a ton of them...
I'm not sure how far I can stretch/increase available memory with this method; R&D will have to be done first.
However...
The startup costs would be too big, for me to be able to tackle this, in the near future.
When the time comes, I can just make a new mold for the new extra-large-capacity PCB, if needed.
I'm gonna buy a lotto ticket tomorrow... XD

On the bright side, this simplifies matters when it comes to the design of the a/b HuCard Shell.
It just needs enough plastic hollowed out to support up to 8Mb (1MB) of chips, and have connectors on both sides.

nodtveidt

  • Guest
Re: DSP in a HuCard & Max Storage Size of a HuCard
« Reply #3 on: May 14, 2012, 05:13:09 PM »
Technically, there are 21 address lines, but only 20 of them are ever used because the internal hardware uses addresses above the 1MB mark. The last one is generally used as a CE line. So yeah... 1MB or 8mbit, is the "standard" addressable range. SFII got around that by using a memory mapper... it uses the first 512KB as static ROM but then is able to remap the latter 512KB to one of four 512KB banks... or so I understand, anyway.

spenoza

  • Hero Member
  • *****
  • Posts: 2751
Re: DSP in a HuCard & Max Storage Size of a HuCard
« Reply #4 on: May 14, 2012, 06:12:56 PM »
Well, and Tailchao has a proto with a mapper for larger HuCards which also includes save memory access. You should communicate with him. I don't think a cheap DSP would be a bad idea just because there's a single audio line. It could still be used quite easily for audio that doesn't have to be well-coordinated, like background music, where you fire off a single command to tell it to play X on repeat. Might actually be easy to integrate something like that with Tailchao's work.
<a href="http://www.pcedaisakusen.net/2/34/103/show-collection.htm" class="bbc_link" target="_blank">My meager PC Engine Collection so far.</a><br><a href="https://www.pcenginefx.com/forums/" class="bbc_link" target="_blank">PC Engine Software Bible</a><br><a href="http://www.racketboy.com/forum/" c

SignOfZeta

  • Hero Member
  • *****
  • Posts: 8497
Re: DSP in a HuCard & Max Storage Size of a HuCard
« Reply #5 on: May 14, 2012, 10:05:11 PM »
I don't get it. Are home brew developers so prolific with code and assets to the extent that they've maxed out the SuperCD format? From what I've seen it's hard enough just making something that resembles a low end retail game from 20 years ago. They aren't exactly maxing out the limits of normal sized HuCard/CDROM2 formats, not from what I've seen anyway.

And the plastic shell the HuCard comes in...that's the last of anyone's worries.

Sorry to be a negative Nellie here...

soop

  • Hero Member
  • *****
  • Posts: 2828
Re: DSP in a HuCard & Max Storage Size of a HuCard
« Reply #6 on: May 14, 2012, 10:52:21 PM »
It's ambitious to say the least, but I'm half interested.  The idea of playing Sapphire on a GT is certainly compelling.

ooPo

  • Jr. Member
  • **
  • Posts: 62
Re: DSP in a HuCard & Max Storage Size of a HuCard
« Reply #7 on: May 15, 2012, 01:08:43 AM »
Memory is accessed in 8KB pages and the first 247 (0-F6) are available for hucard data. Accessing more than that would require a mapper of some sort.

SF2 is a 2.5MB game that uses a 1MB map split into two halves. The lower 512KB is static and writes to specific addresses on that page will swap one of four other 512KB pages into the upper half.

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: DSP in a HuCard & Max Storage Size of a HuCard
« Reply #8 on: May 15, 2012, 02:25:01 AM »
I don't get it. Are home brew developers so prolific with code and assets to the extent that they've maxed out the SuperCD format? From what I've seen it's hard enough just making something that resembles a low end retail game from 20 years ago. They aren't exactly maxing out the limits of normal sized HuCard/CDROM2 formats, not from what I've seen anyway.
I agree here.  Unless some superforce comes in and makes Hudson's games look like balls, a standard CD/SCD game, and the shit we're pulling with cards, should be adequate.   Exploring obnoxious mapper expansions is neat, sure.  But, to me it is an edge case.  I'd prefer anything HuCard oriented be targetted at the middle ground here.  The end result is far better this way.   Cost/Complexity goes down.

Quote
And the plastic shell the HuCard comes in...that's the last of anyone's worries.

I disagree here, lol.  It'd be nice if our AbCards were in nice shells. :)
[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

TailChao

  • Full Member
  • ***
  • Posts: 156
Re: DSP in a HuCard & Max Storage Size of a HuCard
« Reply #9 on: May 15, 2012, 04:43:52 AM »
Well, and Tailchao has a proto with a mapper for larger HuCards which also includes save memory access. You should communicate with him. I don't think a cheap DSP would be a bad idea just because there's a single audio line. It could still be used quite easily for audio that doesn't have to be well-coordinated, like background music, where you fire off a single command to tell it to play X on repeat. Might actually be easy to integrate something like that with Tailchao's work.

There should be useful info in the topic here: http://www.pcenginefx.com/forums/index.php?topic=10583.0
As for a DSP, I think this is a bit much. If the project you're designing has such large requirements it might be easier just to move to something like Saturn.

I agree here.  Unless some superforce comes in and makes Hudson's games look like balls, a standard CD/SCD game, and the shit we're pulling with cards, should be adequate.   Exploring obnoxious mapper expansions is neat, sure.  But, to me it is an edge case.  I'd prefer anything HuCard oriented be targetted at the middle ground here.  The end result is far better this way.   Cost/Complexity goes down.

I think this depends upon what you're doing with the mapper. The whole reason I was experimenting with MCGenjin was to make multiregion HuCard manufacturing easier for both software and hardware. CDs are great and all, but with an already limited audience on the PCE I'd rather just allow everyone with the base system to play. Now I'm assured that if I go through with a PCE project that I don't have to worry about making a card with two sets of pins, can make it fat like a System card, etc.

The memory expansion features were added since there were quite a few free pins on the CPLD, and it's better to have those things "just in case." Plus I can use my 4MB Plus card as a makeshift BRAM copier  :D

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: DSP in a HuCard & Max Storage Size of a HuCard
« Reply #10 on: May 15, 2012, 05:06:25 AM »
I think we may discover that CD/HuCard are both a limited-as-hell audience.

We will see.

I get what you're saying, but it's likely to be overkill.
[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

Black Tiger

  • Hero Member
  • *****
  • Posts: 11242
Re: DSP in a HuCard & Max Storage Size of a HuCard
« Reply #11 on: May 15, 2012, 05:37:14 AM »
I don't get it. Are home brew developers so prolific with code and assets to the extent that they've maxed out the SuperCD format? From what I've seen it's hard enough just making something that resembles a low end retail game from 20 years ago. They aren't exactly maxing out the limits of normal sized HuCard/CDROM2 formats, not from what I've seen anyway.

And the plastic shell the HuCard comes in...that's the last of anyone's worries.

Sorry to be a negative Nellie here...

It actually works backwards from what you're thinking. Although homebrew for PCE is still just getting started in the grand scheme of things, yes, the Super CD format is already a bottleneck. Homebrew developers aren't as efficient as professional development teams with official dev kits bitd, especially when working with something like HuC. So having more than enough space, like say ACD format, is already beneficial for games that don't come off as top end 16-bit console games.

Mysterious Song's cinemas already surpassed the Super CD load space and the battles with background art and no loading in and out of fights is jam packed. The final cinemas of MSR are broken into three sections and a bunch of art and animation was cut. Many high end retail RPGs from bitd lacked battle bg art. Full screen RPG battle bgs with animated sprites would benefit from the jump to ACD or a huge HuCard.

Jungle Bros is also going to be limited by what will fit in a single load, not by whatever content people could be bothered to put together.
http://www.superpcenginegrafx.net/forum

Active and drama free PC Engine forum

Necromancer

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 21419
Re: DSP in a HuCard & Max Storage Size of a HuCard
« Reply #12 on: May 15, 2012, 05:41:21 AM »
I think we may discover that CD/HuCard are both a limited-as-hell audience.

Agreed.  Besides, who is hardcore enough to buy homebrew yet denies themselves access to some of the best titles?
U.S. Collection: 98% complete    157/161 titles

nodtveidt

  • Guest
Re: DSP in a HuCard & Max Storage Size of a HuCard
« Reply #13 on: May 15, 2012, 05:55:50 AM »
Hucards become more and more attractive as time goes on... especially for action games that require access to huge amounts of data at once. We'd not have had the space problems with Jungle Bros if we had opted for hucard... frames of animation had to be cut due to the immense amount of storage the game's sprites require. On hucard, this would not be an issue whatsoever, although the same thing applies to the arcade card... more than enough storage for those sprites. Furthermore, Aetherbyte has conquered the final frontier of hucards... proper sound. The latest Squirrel is a sound monster... music and sound effects on hucards is no longer an issue. Obviously, hucards can't deliver CD quality sound, and you're utilizing CPU time and sound channels for music and sound effects (meaning music channels can get cut... on CD, you can dedicate the entire sound circuit to sound effects without interrupting the music, AND you have the ADPCM circuit too), but the lack of loading times and access to the entire ROM space at once balances it out.

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: DSP in a HuCard & Max Storage Size of a HuCard
« Reply #14 on: May 15, 2012, 05:59:21 AM »
It actually works backwards from what you're thinking. Although homebrew for PCE is still just getting started in the grand scheme of things, yes, the Super CD format is already a bottleneck. Homebrew developers aren't as efficient as professional development teams with official dev kits bitd, especially when working with something like HuC. So having more than enough space, like say ACD format, is already beneficial for games that don't come off as top end 16-bit console games.
I beg to differ.  The official devkit isn't the real crutch here.  It's the part where they were paid to sit for 40+hrs a week and work on this stuff.  


Quote
Mysterious Song's cinemas already surpassed the Super CD load space and the battles with background art and no loading in and out of fights is jam packed. The final cinemas of MSR are broken into three sections and a bunch of art and animation was cut. Many high end retail RPGs from bitd lacked battle bg art. Full screen RPG battle bgs with animated sprites would benefit from the jump to ACD or a huge HuCard.
This is not by any means a jab.  I just don't think it's really sensible to hold MSR as the standard for CD use with homebrew projects...

The cinematics are cool.  Definitely.  However, like you've mentioned, they're a bit over the top as far as space.  In hindsight, maybe they should have been dialed down some, especially since commercial RPGs succeeded with less.  Maybe there was a reason they went with less commercially.  It just works better in the end.

Also, at it's core, Mysterious Song is pretty much still that same simple RPG it was on DOS.  Yes it has colorful, variety filled backgrounds not normal for RPGs on the platform, but again, look what commercial games did with less as far as battles go.  Cosmic Fantasy rocks the black menu style combat no problem!

So yes, you pushed the storage capacities of the CD, and it's a job well done in that regard...but look how long it took to get all of it wrapped up.

Is it really a great idea to hold a 10+ year project with better than commercial cutscenes/backgrounds in battle as the standard?

Again, not jabbing in the slightest, I bet that if the game were done with less over-the-topness on the cutscenes, and simpler battle backgrounds all in the interest of space conservation...

the game would still be just as good, and may not have run into so many issues throughout the years.

This is just my 2 cents.  I am one of those "know your limits" kind of people.  I don't often go for over-the-top.  I just go for neat/sorta flashy/works good/has nice tunes.  

Quote
Jungle Bros is also going to be limited by what will fit in a single load, not by whatever content people could be bothered to put together.

This is again one of those know your limits kind of things.   On paper everything seems great, but it all adds up.  It sucks, but it's true.

Aetherbyte and Frozen Utopia/Eponasoft take a bit of a different approach to getting things done.   Neither is bad.

I just don't think the standard should be a 10+ year long project, because no one in their right mind is going to try doing shit like that again.  



as far as HuCards go, they offer great possibilities, but also aren't as quick and easy to manufacture/get going...

and I am sure down the line all kinds of neat little "son of a bitch" problems will arise from a Hu project.
[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.