DSP in a HuCard & Max Storage Size of a HuCard

[SeymorOnion]

This is somewhat related to my thread about making the HuCard Shells:
https://www.pcengine-fx.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.  

[OldMan]

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.

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]

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.

[OldRover]

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]

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.

[SignOfZeta]

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]

It's ambitious to say the least, but I'm half interested.  The idea of playing Sapphire on a GT is certainly compelling.

[ooPo]

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 Asylum]

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.

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.

[TailChao]

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: https://www.pcengine-fx.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 

[Arkhan Asylum]

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.

[CrackTiger]

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.

[Nazi NecroPhile]

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?

[OldRover]

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, Aetherbutt 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 Asylum]

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.  

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.  

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.

[OldRover]

MSR took a long time to complete mainly because it was a learning experience... and real life got in the way a LOT. If we were to actually lay out how much time was really spent putting it together... and I'm referring to all the work that went into the finished product... it might not have exceeded a year, maybe 15 months, of "commercial time". Also, I started it in early 2005, so it's not even close to 10+ years. It was started not long before my first child was born, and she's only 6.

[SignOfZeta]

I can certainly understand that programmers of today aren't as great at dealing with the minuscule amounts of memory and storage that the guys in the 80s/90s were, and therefore would in theory benefit greatly from something other than Super CD format. Something like how NG: Dev is making Neo carts as huge as GBA carts, and it shows. After all, SuperCD is like trying to drink a fish tank full of booze one shot glass at a time. WHY IS THE FISHTANK SO BIG IF ALL I HAVE IS THIS SHOT GLASS!?

But in the end those aren't the only limits they are going to hit, and it makes me wonder if nearly limitless HuCard storage is really, in the end, going to make that much of a difference. Don't you kind of have to be "in the zone", fully mentally, strategically, committed to a 8 bit way of doing things to really kick ass on the PCE? I suppose it would help, but you still aren't going to be able to make Garou: Mark of the Wolves or Dondanpachi without some serious fucking skill, no matter what the storage method is. The Arcade Card is out there, with a fucking ridiculous amount of storage, but I still haven't seen anyone port KOF 94 to it.

That would be a great project, btw. KOF 94 AC.

[Arkhan Asylum]

MSR took a long time to complete mainly because it was a learning experience...

in that learning experience, you probably realized "shit, maybe next time these cutscenes/art should be planned out a bit better".

I wonder how many times a game like CF had the art sized down, or if the art team was told "this is your size limit.  Fuck you if you don't like it!"

lol

[OldRover]

That's why I was very selective in which frames to cut... the scenes still had to be portrayed correctly, but I could only cut so much before the effect was lost. Cutscene 2 is the most packed cutscene in the game, and it really shows... I had to letterbox quite a few frames just to get enough frames in.

SoZ, my initial background is in the Commodore 64. I'm very experienced in working with severely limited resources. You simply switch mindsets when you work with a much larger platform, such as the PC or the 360... you go from "how much can we stuff into this" to "how many polys can we push per frame".

[Arkhan Asylum]

Fuck the C64!  That things retarded for programming, lol.

Ever notice how most of the hardcore C64 coders still kickin today are wacko?

[OldRover]

Dude, most retro programmers in general still kickin today are wacko, present company included.

[Arkhan Asylum]

Theres wacko, and then theres C64 wacko.

[spenoza]

Wait, I don't see how SuperCD was a limited medium for Mysterious Song. Cutscenes, yeah, but good map design which promotes reasonable loading breaks should free you from most RPG limitations. Just avoid huge sections that need a single load.

Back to the HuCard issue... I'd much rather see some scratch RAM on a HuCard than a DSP. Even a little 128 kibit blorp of read/write RAM that the CPU could use to decompress data into or use for storing extra variable and data would be fantastic. The question is, how much additional complexity would a RAM/ROM mapper and a small RAM chip add? This would, effectively, be the SuperCD Card of HuCards.

[Nazi NecroPhile]

Back to the HuCard issue... I'd much rather see some scratch RAM on a HuCard than a DSP. Even a little 128 kibit blorp of read/write RAM that the CPU could use to decompress data into or use for storing extra variable and data would be fantastic. The question is, how much additional complexity would a RAM/ROM mapper and a small RAM chip add? This would, effectively, be the SuperCD Card of HuCards.

Wouldn't access to ram on the huey be just as slow as accessing anything else on the rom?

[spenoza]

I don't know that that would be a problem. And ROM is pretty fast, at least fast enough. The Super System card adds flexibility because it is writeable, not just a ROM store, and the limited memory of the PCE is often a bottleneck, so be expanding the RAM area via a HuCard you allow HuCard games to do some of what SuperCD games have been able to do for a while.

[Mednafen]

If I were to design a special mapping chip for a HuCard, it would have a 64x8-bit FIFO(writeable via HuC6280), with its output clocked at a semi-programmable rate(say 32KHz / (2**n), where n is 0-2) connected to an adder that adds(at a fixed rate of 32KHz) the 8-bit value(sign-extended, and shifted left by "2 - n") to a 10 bit latched value, and latches the 10-bit result, and the upper 8-bits of the 10-bit result latch are fed to an 8-bit DAC, which is routed to the audio pin of the HuCard.

Additionally, it would have a feature that allows for ROM data to only appear at odd addresses, and a value alternating between 0x13 and 0x23 to appear at even addresses, such
that a data block like: 0xDE 0xAD 0xBE 0xEF
would become: 0x13 0xDE 0x23 0xAD 0x13 0xBE 0x23 0xEF

Oh, and of course it would have ROM bankswitching abilities, too. ;)


I think this is all reasonably simple functionality, and something that would have been technically feasible and cost effective during the PC Engine/TG16's heyday.


Edit: Fixing issues with my description of the audio playback functionality, I shouldn't post technical descriptions while still half-asleep.

[thesteve]

true

i figured use a ram chip in the card and have 1 address set 8 bit address extending the addressing to 28 bits.
could be just an 8 bit register.
set an audio player to use its own rom for the aud pin with fixed sample sizes that can be called as single addresses

[BigusSchmuck]

Theres wacko, and then theres C64 wacko.

Hey thats how I learned how to program back in the day. So I guess my question is this: whats stopping us from creating our own arcade cards if RAM is so cheap these days? Just a thought considering people are saying how limited the Super CD is..

[TailChao]

If I were to design a special mapping chip for a HuCard, it would have a 64x8-bit FIFO(writeable via HuC6280), with its output clocked at a semi-programmable rate(say 32KHz / (2**n), where n is 0-2) connected to an adder that adds(at a fixed rate of 32KHz) the 8-bit value(sign-extended, and shifted left by "2 - n") to a 10 bit latched value, and latches the 10-bit result, and the upper 8-bits of the 10-bit result latch are fed to an 8-bit DAC, which is routed to the audio pin of the HuCard.

I was actually thinking of something like this for another platform, and if you have the mapper already passing the datalines from the ROM to the PCE's databus, you could just have the mapper fetch the bytes for you when the CPU isn't doing a read cycle

Additionally, it would have a feature that allows for ROM data to only appear at odd addresses, and a value alternating between 0x13 and 0x23 to appear at even addresses, such
that a data block like: 0xDE 0xAD 0xBE 0xEF
would become: 0x13 0xDE 0x23 0xAD 0x13 0xBE 0x23 0xEF

This is really clever, haha.

I think this is all reasonably simple functionality, and something that would have been technically feasible and cost effective during the PC Engine/TG16's heyday.

It's very strange that NEC/Hudson didn't do more with mappers, especially since both had so much background in chip design. I guess CD was their thing. Something like you describe in an ASIC would be pennies for them.

[OldRover]

Wait, I don't see how SuperCD was a limited medium for Mysterious Song. Cutscenes, yeah, but good map design which promotes reasonable loading breaks should free you from most RPG limitations. Just avoid huge sections that need a single load.

You also don't have an idea of how complex MSR is under the hood. Don't be deceived by what appears to you to be "simple"... RPGs require a ridiculous amount of code. Couple that with the blatantly obvious design shortcuts and limitations of HuC itself... and maps are the least of your worries.

[spenoza]

I would certainly believe that HuC could be implicated.

[OldMan]

Wait, I don't see how SuperCD was a limited medium for Mysterious Song.

You also don't have an idea of how complex MSR is under the hood.

Rover's right. Let's take a simple example, and show you that it's not the graphics, nor the maps that become a problem...

Every RPG has a menu system. Yet there is no support in HuC for that. You have to build it yourself.
So, think about these questions:

How do you actually draw the menus?
    Do you use sprites or do you use background tiles?
    if You use sprites, how do you get the text in them?
      How much time will it take to set them up?
    if You use background tiles, how do you restore it when it goes away?
       How much space will that take?

    How do you handle high-lighting the current selection?
      How do you know what the curent selection is?
      How do you indicate to the main program that something has been selected?
   
   How do you store the menu text?
     How much space does that take up?

   Since the menus can be various sizes...
      Do you use a large, parameter driven routine for all text output?
      Or, do you use multiple versions of a routine for different sizes?
      How much space is it going to use?
      How fast is it going to be?

There are lots of other questions there, but I think you get the basic idea: There's a lot of code there to do
something basic to most games. HuC doesn't generate very efficient code, either. So for just the menu system
you probably have 1 bank of text (at least) and another 3-4K of code. You still have to have room for the parameters and things needed to run the menu. Don't fool yourself - the CD-Bios uses about 1/4 of the system RAM for it's own operations. HuC uses another generous portion for just the program stack. So, if you are lucky, you have maybe 2K for -all- your variables. Sad, but true.

Then, look at the bigger picture: Huc uses at least 3 banks for it's own libraries/code. Another bank is system ROM. Still another is the CD-bios. That's 5 of 8 that the cpu can reach. Now you have the graphics and the sprites - figure another 3-4 banks, for about 1/2 of the total banks available. And you still have to have room for the code...

Bottom line: Even if he uses a different overlay for each level, and comes up with a great way to load graphics and sound directly from cd, it's still going to be a tight fit.

[spenoza]

Well, every RPG has to construct a menu system and track variables. Variables are a pain on the PCE due to limited memory, but the challenges of a menu system are universal. All this points to HuC being not at all ideal for RPG coding. Sounds like HuC is the primary problem, here.

[OldRover]

Amazingly enough, HuC takes some of the headache out of making RPGs. I can't even begin to imagine the level of difficulty an RPG must be in assembly language... and I never want to find out either.

I don't quite get what you're saying about "track variables" though... all games require variables. All of them. There is not a single exception.

[OldRover]

As for menus... rarely do non-RPGs feature complex menu systems. Most other games just have basic stuff, like title screen menus or maybe some kind of basic pause menu with a few option. These are rarely complex undertakings, and you often get to skip worrying about some of the details. RPG menus, on the other hand, are quite often nested, which introduces a whole new level of complexity. And that's just one of the details that makes RPGs such a pain in the ass... nevermind a scripting system for dialogue, a sprite entity handler for things like NPCs, and let's not forget about the battle system... which can end up being a project all its own. I've actually never seen an RPG that didn't use a menu system. Zelda and its ilk are not RPGs.

[spenoza]

Yeah, menus can be a pain. When I talk about tracking variables, what I mean is that RPGs typically feature quite a bit of bookkeeping of variables, not just of the various characters stats, but when there are side quests and inventory to track and such, there's just a good bit of data to shepherd.

[OldMan]

I don't quite get what you're saying about "track variables" though

Not "Track Variables": Track where in memory variables are. Ie, keep "track" of where variables are.

the challenges of a menu system are universal.

Exactly. But when you only have 8K of ROM and 64K of cpu space, it's a bigger portion of the code.
Under those conditions, every byte counts.
I'm pretty impressed that all the code fits at all. RPGS tend to have a lot of special purpose code to run, and it has to be in memory most of the time because things can happen in an RPG at -any- time.

As for HuC not being ideal...You work with what you have. HuC may not be the best choice for an RPG, but it sure
beats assembly (which is the only other choice).

It's really not that HuC is a problem, either. It's the scale and scope of RPGS that are the "problem". You either have lots of loads from cd, or you fight to pack things into memory.
All programming is tradeoffs like that.

[OldRover]

OK I see what you're saying. Yeah, not all RPGs have to maintain massive libraries of data, though many do. It's perfectly possible to get away with miniscule amounts of data... mainly if you're doing a linear story. Sometimes, you can't avoid it though... Cosmic Fantasy 2, for example, uses 338 bytes of data (iirc) for its save file. That's pretty hefty. MSR uses under 150... much smaller.

[spenoza]

Funny you should say that. RPGs proliferated on early PCs because early PCs were not especially good with actiony kinds of games, but even with limited RAM and CPU speed, RPGs were the perfect game for the hardware. The PCE's system design seems slightly less well-suited to RPGs than the competition, but then again, the NES did have some impressive RPGs on it.

[SeymorOnion]

If you designed MSR for the Arcade Card, would you still have had issues with not having enough room for the menus, text, items & Equipment Inventory, and other variables?

[OldRover]

Don't forget though that many of those early games did not feature code-heavy sequences... menus consisted of simple text output and pressing hotkeys, dialogue was rarely impressive in presentation, combat systems were ridiculously simplistic, graphics were terrible (if they existed at all) but used up very little space... and many of them didn't have sound, or just had your basic PC speaker bleeps and bloops. These kinds of games would be easy to convert to the PCE.

[SeymorOnion]

I mean, would it be better to put MSR on an advanced HuCard, or would the Arcade Card/CD Format good enough?

[OldRover]

If you designed MSR for the Arcade Card, would you still have had issues with not having enough room for the menus, text, items & Equipment Inventory, and other variables?

If designed for the ACD, I could put 95% of the graphics into ACD RAM, which would cut down load time tremendously, possibly even eliminating the need for independent subprograms (map and battle). System RAM would still fill up, but it now would largely be with code rather than code + graphics. It would not affect variable usage whatsoever, as that's all done in scratch RAM, which is unaffected by the ACD. Cutscenes would be complete; no dropped frames whatsoever. It'd have turned out to be a better game, but would have fewer people able to play it on real hardware.

Oh... and the game itself, without the cutscenes, would fit nicely on a standard hucard. It'd be nice to put on ACD but it's already too late for that now anyway.

[SeymorOnion]

I also have plans on mass producing Arcade Cards (it'll probably be a few years before I can do it) because (and correct me if I'm wrong) Neutoipa III is being designed for it.

However, someone posted in this thread that it would be very beneficial to add additional scratch ram to a system card,
should someone make new System Cards.
Is it safe to assume that additional scratch ram on a system card (in addition to the chips found on the Arcade Card)
would make it much easier to make RPGs for the PCE/TG16?
Or can it not be used in the same way as the scratch ram on the system's mobo?

[spenoza]

What I proposed was additional scratch RAM on a HuCard paired with ROM/flash for HuCard game development, not as a new system card.

Rover, I loved those old RPGs. They were actually just as complex, if not more, than the typical, basic JRPG. JRPGs have more going on graphically, but at their core they're not necessarily any more complex as games. Maybe in code, but not as games.

[SeymorOnion]

Wait, I don't see how SuperCD was a limited medium for Mysterious Song. Cutscenes, yeah, but good map design which promotes reasonable loading breaks should free you from most RPG limitations. Just avoid huge sections that need a single load.

Back to the HuCard issue... I'd much rather see some scratch RAM on a HuCard than a DSP. Even a little 128 kibit blorp of read/write RAM that the CPU could use to decompress data into or use for storing extra variable and data would be fantastic. The question is, how much additional complexity would a RAM/ROM mapper and a small RAM chip add? This would, effectively, be the SuperCD Card of HuCards.

Ah, my bad. I just re-read your thread (bold mine).
Now, that sounds interesting!

[OldRover]

Populous had onboard RAM because of the immense amount of data it had to process. 32KB, to be exact... which is plenty. 128KB would help for complex decompression, but if you're already going the way of mega-massive hucard designs, chances are that decompression of stuff might not even going to be required... unless you're making the mother of all hucard RPGs.

[Arkhan Asylum]

Yeah, menus can be a pain. When I talk about tracking variables, what I mean is that RPGs typically feature quite a bit of bookkeeping of variables, not just of the various characters stats, but when there are side quests and inventory to track and such, there's just a good bit of data to shepherd.

There is alot of data to keep track of in ANY game.  Even something simple, like Insanity, has a shit-load of crap to deal with at any given time.  Atlantean is actively dealing with as many sprites as the PCE can handle (and more), and tracking various bits of information for each one of them.  There are pros and cons to any type of game.   You avoid the problems in one game, and have them in another.    MSR is pretty safe in the sprite-world (from what I gather), but in the "goddamn theres alot of data" world, it's got issues. 

Especially, as OldMan said, when you are dealing with variables that need to exist in any portion of the game.  you can't stop tracking your parties stats, or the flags for their progress in the game.  You have certain portions of the game that always need to exist in memory.

Even with the best development tools ever, you are stuck with a limited game in that regard.  Look at Cosmic Fantasy, the Ys games,  and basically ANY RPG for the system.  We're talking about companies with years of experience on those platforms, with the best tools possible, and there are STILL limitations.  It's not HuC's fault with this.    You will encounter this no matter what.  HuC's real problem comes from accessing things quickly.  This isn't so much of an issue with an RPG.  The problem is just having it all fit regardless. 

I would strongly suggest you experience HuC before making statements about what HuC is or isn't doing right.

Funny you should say that. RPGs proliferated on early PCs because early PCs were not especially good with actiony kinds of games, but even with limited RAM and CPU speed, RPGs were the perfect game for the hardware. The PCE's system design seems slightly less well-suited to RPGs than the competition, but then again, the NES did have some impressive RPGs on it.

This is false.  The Apple II had plenty of good to great action titles. So did the C64 and the Atari computers.  They handled smooth action very well, even early on.

The real reason RPGs came out of the woodwork on computers is because thats the only platform you had at the time.  It had a keyboard.  This is very important, especially since the idea was to recreate D&D style gaming, which includes conversing (Ultima).  Ultima came out at a time where your only option was a computer.  A computer that could do action games too.  Horizon V for Apple II is a pretty solid action game.

Computers had technically infinite (limited by how many disks you want your game to come with) storage.

What was your other option, an Atari 2600? Fuck that.  Swordquest? lol.

Saying the PCE's system design is not well suited to RPGs does not make much sense, as it is more capable than a system like the C64, which contains many power-house RPGs like Legacy of the Ancients.

I mean, the PCE CD has Might and Magic III and five Wizardry games.  They blow away the PC counterparts, easily. 

The PCE is more capable than the NES as well.  Everything the NES did RPG wise, the PCE did, or could do far better.

[thesteve]

the need for an upper and lower (upper mapped, lower not) is over stated.
if you map all the addresses, you just need to mirror the base code to each mapped bank.
if your base code (the part that must be readable at all times) is less than 256K that offers even more flexibility.

[spenoza]

I would strongly suggest you experience HuC before making statements about what HuC is or isn't doing right.

I wasn't asserting factually what HuC is or isn't good for. I was pointing out that it sounded like the explanation put the blame on HuC. I was attempting to draw conclusions from information someone else provided, based on how they worded that information.

Saying the PCE's system design is not well suited to RPGs does not make much sense, as it is more capable than a system like the C64, which contains many power-house RPGs like Legacy of the Ancients.

...

The PCE is more capable than the NES as well.  Everything the NES did RPG wise, the PCE did, or could do far better.

See, I would naturally assume that the C64 or Apple II would be better suited to RPGs due to having more RAM and bitmap graphics modes.

I had an Apple IIc. I had lots of action games. Some of them were fun. None of them were particularly smooth except Lode Runner.

It would be hard to argue the PCE isn't more capable than the NES. You'll find I never stated otherwise.