Mad Stalker - Arcade or Super System game?

[lkermel]

Hi everyone,

While updating the review of Mad Stalker on my site, I bumped into something very interesting I would like to discuss here. I've always found weird that Mad Stalker was an Arcade Card game - I feel that it could have totally worked with a Super System Card (and many people seem to share that idea). Anyway, I noticed that there are two hidden screens in the game, and one of them looks like a Super System Card v.3.0 warning screen - was Mad Stalker originally designed as a Super System Card game? And was maybe changed at the last minute for technical or marketing reasons? The current system warning screen in the game feels really cheap and that hidden one would have been much better - could it be because the Arcade Card move was a last minute decision? What do you think?

Here's the review page with images of what I think is the Super System Card v.3.0 warning screen:

Mad Stalker - PC Engine

[CrackTiger]

It feels like a second-rate CD2 game.

[esteban]

Ha! That warning screen is a great find.

I wonder if the game uses the Arcade capacity  simply for the cinemas...to reduce the frequency of loading sessions.

Pure speculation, of course.

[deubeul]

Despite the lack of parallax, I always found the game great to watch. Robots are big and well animated.

[Digi.k]

Despite the lack of parallax, I always found the game great to watch. Robots are big and well animated.

The thing that strikes me about this game is just how meaty the sound fx are.  I wish it had parallax that would have been the icing..

[Koa Zo]

It wouldn't be surprising if Mad Stalker was bumped to Arcade Card so that there would be more product supporting that late format.

[Artabasdos]

Hi everyone,

While updating the review of Mad Stalker on my site, I bumped into something very interesting I would like to discuss here. I've always found weird that Mad Stalker was an Arcade Card game - I feel that it could have totally worked with a Super System Card (and many people seem to share that idea). Anyway, I noticed that there are two hidden screens in the game, and one of them looks like a Super System Card v.3.0 warning screen - was Mad Stalker originally designed as a Super System Card game? And was maybe changed at the last minute for technical or marketing reasons? The current system warning screen in the game feels really cheap and that hidden one would have been much better - could it be because the Arcade Card move was a last minute decision? What do you think?

Here's the review page with images of what I think is the Super System Card v.3.0 warning screen:

Mad Stalker - PC Engine

Those graphics look like they could run from a HuCard if SFII is any comparison

[CrackTiger]

Those graphics look like they could run from a HuCard if SFII is any comparison

CD games are the same as HuCard games, only they're bottlenecked by only being able to run a small segment at any given time.

That's why SFII' wasn't also released for Super CD, because a match wouldn't fit within the tiny space that CD games have to run out of.

[Artabasdos]

Those graphics look like they could run from a HuCard if SFII is any comparison

CD games are the same as HuCard games, only they're bottlenecked by only being able to run a small segment at any given time.

That's why SFII' wasn't also released for Super CD, because a match wouldn't fit within the tiny space that CD games have to run out of.

Er, have you seen Art of Fighting or Fatal Fury Special on PCE CD? Both are considerably more advanced than SFII!

[NecroPhile]

Er, have you seen Art of Fighting or Fatal Fury Special on PCE CD? Both are considerably more advanced than SFII!

They're also not Super CDs.  If they were, they'd be far less impressive, as an awful lot of sprite frames and background tiles would have to be cut to fit in 1/9th as much ram.

[Artabasdos]

Er, have you seen Art of Fighting or Fatal Fury Special on PCE CD? Both are considerably more advanced than SFII!

They're also not Super CDs.  If they were, they'd be far less impressive, as an awful lot of sprite frames and background tiles would have to be cut to fit in 1/9th as much ram.

He said CD games. He mentioned nothing of system card type.

[CrackTiger]

Those graphics look like they could run from a HuCard if SFII is any comparison

CD games are the same as HuCard games, only they're bottlenecked by only being able to run a small segment at any given time.

That's why SFII' wasn't also released for Super CD, because a match wouldn't fit within the tiny space that CD games have to run out of.

Er, have you seen Art of Fighting or Fatal Fury Special on PCE CD? Both are considerably more advanced than SFII!

It's still just sprites and tiles and no kind of "hardware parallax" or anything else. Instead of a gameplay segment being stuck with half a meg or 2 megs, the Arcade Card expands upon the Super CD's space to allow up to 18 megs used at once.

All three CD formats use identical hardware, which only adds parallel adpcm and redbook audio channels. Otherwise CD games are pretty restricted for what can be done compared to HuCards and cart games in general.

That's why many CD versions of HuCard games have neutered assets.

[Artabasdos]

Those graphics look like they could run from a HuCard if SFII is any comparison

CD games are the same as HuCard games, only they're bottlenecked by only being able to run a small segment at any given time.

That's why SFII' wasn't also released for Super CD, because a match wouldn't fit within the tiny space that CD games have to run out of.

Er, have you seen Art of Fighting or Fatal Fury Special on PCE CD? Both are considerably more advanced than SFII!

It's still just sprites and tiles and no kind of "hardware parallax" or anything else. Instead of a gameplay segment being stuck with half a meg or 2 megs, the Arcade Card expands upon the Super CD's space to allow up to 18 megs used at once.

All three CD formats use identical hardware, which only adds parallel adpcm and redbook audio channels. Otherwise CD games are pretty restricted for what can be done compared to HuCards and cart games in general.

That's why many CD versions of HuCard games have neutered assets.

I assume you're talking about non-arcade system cards right? Otherwise your SFII statement makes no sense.

[NecroPhile]

He said CD games. He mentioned nothing of system card type.

He specifically called out Super CD: "That's why SFII' wasn't also released for Super CD, because a match wouldn't fit within the tiny space that CD games have to run out of."

Try harder next time. 

I assume you're talking about non-arcade system cards right? Otherwise your SFII statement makes no sense.

No matter the system card, there's no special graphical capabilities afforded by the CD hardware; other than redbook and adpcm stuff, if it could be done on CD it could be done on huey and visa versa.

[Artabasdos]

He said CD games. He mentioned nothing of system card type.

He specifically called out Super CD: "That's why SFII' wasn't also released for Super CD, because a match wouldn't fit within the tiny space that CD games have to run out of."

Try harder next time. 

I assume you're talking about non-arcade system cards right? Otherwise your SFII statement makes no sense.

No matter the system card, there's no special graphical capabilities afforded by the CD hardware; other than redbook and adpcm stuff, if it could be done on CD it could be done on huey and visa versa.

Yup, I'm an idiot and missed that. My bad.

I'm aware of that, but it does allow for storage of graphics data.

[CrackTiger]

Those graphics look like they could run from a HuCard if SFII is any comparison

CD games are the same as HuCard games, only they're bottlenecked by only being able to run a small segment at any given time.

That's why SFII' wasn't also released for Super CD, because a match wouldn't fit within the tiny space that CD games have to run out of.

Er, have you seen Art of Fighting or Fatal Fury Special on PCE CD? Both are considerably more advanced than SFII!

It's still just sprites and tiles and no kind of "hardware parallax" or anything else. Instead of a gameplay segment being stuck with half a meg or 2 megs, the Arcade Card expands upon the Super CD's space to allow up to 18 megs used at once.

All three CD formats use identical hardware, which only adds parallel adpcm and redbook audio channels. Otherwise CD games are pretty restricted for what can be done compared to HuCards and cart games in general.

That's why many CD versions of HuCard games have neutered assets.

I assume you're talking about non-arcade system cards right? Otherwise your SFII statement makes no sense.

The Arcade Card format wasn't released until over a year after SFII' came out.

[Artabasdos]

Those graphics look like they could run from a HuCard if SFII is any comparison

CD games are the same as HuCard games, only they're bottlenecked by only being able to run a small segment at any given time.

Fair enough. I also thought the Super system card had more RAM than it actually has. It has 3x less than the MegaCD lol.

That's why SFII' wasn't also released for Super CD, because a match wouldn't fit within the tiny space that CD games have to run out of.

Er, have you seen Art of Fighting or Fatal Fury Special on PCE CD? Both are considerably more advanced than SFII!

It's still just sprites and tiles and no kind of "hardware parallax" or anything else. Instead of a gameplay segment being stuck with half a meg or 2 megs, the Arcade Card expands upon the Super CD's space to allow up to 18 megs used at once.

All three CD formats use identical hardware, which only adds parallel adpcm and redbook audio channels. Otherwise CD games are pretty restricted for what can be done compared to HuCards and cart games in general.

That's why many CD versions of HuCard games have neutered assets.

I assume you're talking about non-arcade system cards right? Otherwise your SFII statement makes no sense.

The Arcade Card format wasn't released until over a year after SFII' came out.

[NecroPhile]

I'm aware of that, but it does allow for storage of graphics data.

Of course it does, but that's no different than the rom of a huey.

[Artabasdos]

I'm aware of that, but it does allow for storage of graphics data.

Of course it does, but that's no different than the rom of a huey.

Of course it's different. The CD can hold 500MB+ of data, and load it into RAM when required. A HuCard/cart can only hold a few megs in total. IIRC SFII on PCE is 20 megabits, or 2 1/2MB!

[NecroPhile]

Of course it's different. The CD can hold 500MB+ of data, and load it into RAM when required. A HuCard/cart can only hold a few megs in total. IIRC SFII on PCE is 20 megabits, or 2 1/2MB!

The only appreciable difference there is cost.  20 megabits isn't the max allowable rom size; with the right mapper, a huey could be made to hold just as much as any cd game made, none of which are even close to 500 megabytes in game size (most disc space is filled with adpcm samples and redbook).

[Artabasdos]

Of course it's different. The CD can hold 500MB+ of data, and load it into RAM when required. A HuCard/cart can only hold a few megs in total. IIRC SFII on PCE is 20 megabits, or 2 1/2MB!

The only appreciable difference there is cost.  20 megabits isn't the max allowable rom size; with the right mapper, a huey could be made to hold just as much as any cd game made, none of which are even close to 500 megabytes in game size (most disc space is filled with adpcm samples and redbook).

Are you sure about that?

Even if that is true, the price of such a HuCard would be brutal. Approaching higher end AES cart prices back in the day. That's to say nothing of the reduced performance from the phenomenal amount of bank switching that would be required. CDs were far cheaper and more simple to deal with.

[CrackTiger]

Of course it's different. The CD can hold 500MB+ of data, and load it into RAM when required. A HuCard/cart can only hold a few megs in total. IIRC SFII on PCE is 20 megabits, or 2 1/2MB!

The only appreciable difference there is cost.  20 megabits isn't the max allowable rom size; with the right mapper, a huey could be made to hold just as much as any cd game made, none of which are even close to 500 megabytes in game size (most disc space is filled with adpcm samples and redbook).

Are you sure about that?

Even if that is true, the price of such a HuCard would be brutal. Approaching higher end AES cart prices back in the day. That's to say nothing of the reduced performance from the phenomenal amount of bank switching that would be required. CDs were far cheaper and more simple to deal with.

That's why disc-based consoles became standard. Large SNES carts were very expensive bitd, but CD games typically never used more than <1% of the space on a CD for anything other than redbook and adpcm audio. A game like Dracula X wouldn't have been any bigger than larger non-RPG SNES and Genesis games from around the same time.


Here's how CD games work compared to normal HuCards:

[OldMan]

That's to say nothing of the reduced performance from the phenomenal amount of bank switching that would be required.

As opposed to the time to load things from CD?

[esteban]

Of course it's different. The CD can hold 500MB+ of data, and load it into RAM when required. A HuCard/cart can only hold a few megs in total. IIRC SFII on PCE is 20 megabits, or 2 1/2MB!

The only appreciable difference there is cost.  20 megabits isn't the max allowable rom size; with the right mapper, a huey could be made to hold just as much as any cd game made, none of which are even close to 500 megabytes in game size (most disc space is filled with adpcm samples and redbook).

Are you sure about that?

Even if that is true, the price of such a HuCard would be brutal. Approaching higher end AES cart prices back in the day. That's to say nothing of the reduced performance from the phenomenal amount of bank switching that would be required. CDs were far cheaper and more simple to deal with.

Comrade, I know what you are thinking... I, too, was confused about the "bottleneck" that is created for CD-ROM games based on the fact that only ____________ of data (depends on the system card) can be loaded and therefore available at any given moment.

If you want LOTS OF ANIMATION in large sprites... you can quickly run out of room.

Therefore, once it was evident that the install base of CD-ROM hardware was healthy,  developers/publishers *still* had a decision to make: did the technical requirements/challenges of the game lend itself to HuCARD or CD-ROM.

CD-ROM was not automatically the best fit for every project.

[Artabasdos]

Of course it's different. The CD can hold 500MB+ of data, and load it into RAM when required. A HuCard/cart can only hold a few megs in total. IIRC SFII on PCE is 20 megabits, or 2 1/2MB!

The only appreciable difference there is cost.  20 megabits isn't the max allowable rom size; with the right mapper, a huey could be made to hold just as much as any cd game made, none of which are even close to 500 megabytes in game size (most disc space is filled with adpcm samples and redbook).

Are you sure about that?

Even if that is true, the price of such a HuCard would be brutal. Approaching higher end AES cart prices back in the day. That's to say nothing of the reduced performance from the phenomenal amount of bank switching that would be required. CDs were far cheaper and more simple to deal with.

Comrade, I know what you are thinking... I, too, was confused about the "bottleneck" that is created for CD-ROM games based on the fact that only ____________ of data (depends on the system card) can be loaded and therefore available at any given moment.

If you want LOTS OF ANIMATION in large sprites... you can quickly run out of room.

Therefore, once it was evident that the install base of CD-ROM hardware was healthy,  developers/publishers *still* had a decision to make: did the technical requirements/challenges of the game lend itself to HuCARD or CD-ROM.

CD-ROM was not automatically the best fit for every project.

I can understand that. I thought the system 3.0 card had 512KB of RAM, not 192KB. Given the fact that its main rival the MegaCD had 768KB of RAM (outside of sound), I would of thought the general purpose amount of the PCE CD would have a competitive amount!

[esteban]

I would of thought the general purpose amount of the PCE CD would have a competitive amount!

That's actually a good question: both PCE Super CD and Mega Drive CD were released in December of 1991...

...technical specs had been released to the public, I am assuming, but at what point were NEC and Sega aware of *exactly* what the other company was doing?

Had the technical specs been nailed down by the engineers long before knowledge of competitor's hardware?

[Artabasdos]

I would of thought the general purpose amount of the PCE CD would have a competitive amount!

That's actually a good question: both PCE Super CD and Mega Drive CD were released in December of 1991...

...technical specs had been released to the public, I am assuming, but at what point were NEC and Sega aware of *exactly* what the other company was doing?

Had the technical specs been nailed down by the engineers long before knowledge of competitor's hardware?

Hard to say without some pretty hardcore research most likely. One thing to mention that the cost of RAM in the 100s of KB amount was pretty low by 1991. Also, they are only selling the HuCard with RAM built-in, unlike the MegaCD, which had a whole ton of crap. I'd of thought 512KB would have been the best idea.

[Psycho Punch]

That's to say nothing of the reduced performance from the phenomenal amount of bank switching that would be required.

Yes, phenomenal microseconds lost to order an instantaneous bank change as opposed to the seconds long optical + mechanical maneuvers every time you want data outside the tiny window already loaded into the syscard ram. Truly phenomenal

Your posts make you sound like you're the kind of random Internet expert that says stuff like "the PCE is 8 bit but has two 16 bit video chips"

[Artabasdos]

That's to say nothing of the reduced performance from the phenomenal amount of bank switching that would be required.

Yes, phenomenal microseconds lost to order an instantaneous bank change as opposed to the seconds long optical + mechanical maneuvers every time you want data outside the tiny window already loaded into the syscard ram. Truly phenomenal

Your posts make you sound like you're the kind of random Internet expert that says stuff like "the PCE is 8 bit but has two 16 bit video chips"

I suggest you look up how bus bandwidth affects data transfer, especially when it's constantly jumping back and forth between the CPU, memory mapper, RAM, and game data. The same kind of thing happens on modern handhelds using the largest supported flash memory. The 64GB Vita memory card is considerably slower than the 32GB and lower. Same for the 3DS & DS. Game carts of 512MB on the DS were noticeably slower. Same for SD cards or any kind of Flash data.

So kindly take your sarcasm and stuff it where the sun doesn't shine.

[CrackTiger]

I guess that Paprium is going to crawl along, since it's 2.5 times as big as the hardware can accept without bank switching and larger than many/most PCE CD games.

Of course SFII' PCE is also 2.5 times the hardware's max rom size and we saw how crippled that game was.

[NecroPhile]

Right, BT.  Also, look at all the NES games that used mappers or the few SNES and Genny games that needed 'em, and try to name one that had "performance issues".  Street Fighter Alpha 2 maybe, but its issues were from running a decompression algorithm and would've been eliminated with a mapper and larger rom.

[Artabasdos]

I guess that Paprium is going to crawl along, since it's 2.5 times as big as the hardware can accept without bank switching and larger than many/most PCE CD games.

Of course SFII' PCE is also 2.5 times the hardware's max rom size and we saw how crippled that game was.

That's 2.5MB, not 500+. That's 200x or more data it has to sift through, pull back to the bus, check the MMU values, dump into the appropriate RAM pool, and repeat. This of course is not accounting for sound data also doing the same, except it has to hit the CPU too, as the PCE has no dedicated sound CPU.

Not only that, but can you imagine the freaking size of such a HuCard? Especially with '91 technology. I mean Christ, the NEOGEO carts of the period where like what, 20-50MB? Yet they're bigger than the PCE itself.

[Artabasdos]

Right, BT.  Also, look at all the NES games that used mappers or the few SNES and Genny games that needed 'em, and try to name one that had "performance issues".  Street Fighter Alpha 2 maybe, but its issues were from running a decompression algorithm and would've been eliminated with a mapper and larger rom.

Lol, irrelevant. We're talking economy of scale in terms of what is acceptable performance. 2-8MB is nothing compared to CD size.

[Psycho Punch]

That's to say nothing of the reduced performance from the phenomenal amount of bank switching that would be required.

Yes, phenomenal microseconds lost to order an instantaneous bank change as opposed to the seconds long optical + mechanical maneuvers every time you want data outside the tiny window already loaded into the syscard ram. Truly phenomenal

Your posts make you sound like you're the kind of random Internet expert that says stuff like "the PCE is 8 bit but has two 16 bit video chips"

Super Mario Bros. 2 was actually a game called Doki Doki Panic in Japan.

Cartridge mask ROM != Flash DRAM memory. Flash is significantly slower.
I'm not an expert but I'm pretty sure that the HuC6280 doesn't work at all like you probably imagine it to. It doesn't have an internal RAM cache. The CPU fetches data as fast in ROM as in RAM, and only slows down when its doing something weird like running one of its block transfer instructions. This isn't a modern computer, dude.
There's no reading data all over the full physical space with long jumps too because games which rely on bankswitching (like, all hucards ever and 90% of the NES library) usually organize code to require the least amount of "far jumps" possible, and most of the time the most mobile portion of the ROM is DATA which is usually copied elsewhere (VRAM, or just plain RAM sometimes). SFII is the perfect example (top half of rom is FIXED, bottom half of rom is bankswitchable... and most of the extra space is used for bg/sprite data which is uploaded to VRAM when needed).

Comparing a PCE HuCard to SD cards... lmao. Nice job. Btw my point was that no mapper cart could be possibly slower than CDROM -- please show me how a PCE cartridge could be slower than something relying on a 1x mechanical CDROM controller. Or own me by schooling me on the PCE CPU's ROM access speeds or something, with all the pretty bus timing diagrams and shit. Again I'm no expert, but you'll have to be more substantial than that, I'd shut up if it was someone who knows his shit like tomaitheous or elmer, not you though, sorry.

[NecroPhile]

Lol, irrelevant. We're talking economy of scale in terms of what is acceptable performance. 2-8MB is nothing compared to CD size.

And as was said before, the game itself is nowhere near the 650MB capacity of a CD.  If a CD game were made as a huey instead, it'd lose the hundreds of megs of redbook and adpcm.  Duh.

[Artabasdos]

That's to say nothing of the reduced performance from the phenomenal amount of bank switching that would be required.

Yes, phenomenal microseconds lost to order an instantaneous bank change as opposed to the seconds long optical + mechanical maneuvers every time you want data outside the tiny window already loaded into the syscard ram. Truly phenomenal

Your posts make you sound like you're the kind of random Internet expert that says stuff like "the PCE is 8 bit but has two 16 bit video chips"

Super Mario Bros. 2 was actually a game called Doki Doki Panic in Japan.

Cartridge mask ROM != Flash DRAM memory. Flash is significantly slower.
I'm not an expert but I'm pretty sure that the HuC6280 doesn't work at all like you probably imagine it to. It doesn't have an internal RAM cache. The CPU fetches data as fast in ROM as in RAM, and only slows down when its doing something weird like running one of its block transfer instructions. This isn't a modern computer, dude.
There's no reading data all over the full physical space with long jumps too because games which rely on bankswitching (like, all hucards ever and 90% of the NES library) usually organize code to require the least amount of "far jumps" possible, and most of the time the most mobile portion of the ROM is DATA which is usually copied elsewhere (VRAM, or just plain RAM sometimes). SFII is the perfect example (top half of rom is FIXED, bottom half of rom is bankswitchable... and most of the extra space is used for bg/sprite data which is uploaded to VRAM when needed).

Comparing a PCE HuCard to SD cards... lmao. Nice job. Btw my point was that no mapper cart could be possibly slower than CDROM -- please show me how a PCE cartridge could be slower than something relying on a 1x mechanical CDROM controller. Or own me by schooling me on the PCE CPU's ROM access speeds or something, with all the pretty bus timing diagrams and shit. Again I'm no expert, but you'll have to be more substantial than that, I'd shut up if it was someone who knows his shit like tomaitheous or elmer, not you though, sorry.

It's still Flash memory. It's only faster because it's one way, unlike SDs etc.

Bank switching is still bank switching. You're suggesting that 500-600MB worth of data being bank switched will have the same seek/fetch time as 2MB or so. That's utter bullshit.

The MMU is going to be bit with so much freaking data it's unreal, and unlike CD-ROM, it has no buffer. I doubt if the slot would even provide sufficient power to so many ROM chips of '91 vintage.

The CD-ROM will have a logic control chip, and buffer.

[Artabasdos]

Lol, irrelevant. We're talking economy of scale in terms of what is acceptable performance. 2-8MB is nothing compared to CD size.

And as was said before, the game itself is nowhere near the 650MB capacity of a CD.  If a CD game were made as a huey instead, it'd lose the hundreds of megs of redbook and adpcm.  Duh.

Lol, that is still data being stored on ROMs. Not only that, but all sound data is run off the CPU, with no additional sound chip as found in the CD-ROM unit. That is even worse...

[NecroPhile]

Lol, that is still data being stored on ROMs. Not only that, but all sound data is run off the CPU, with no additional sound chip as found in the CD-ROM unit. That is even worse...

Are you a troll or are you really this dense?

The adpcm stuff would be scrapped (it requires cd hardware) and the redbook would be exchanged for exponentially smaller chip tune data.  You trying to argue that a graphically identical game (but with different sounds) would still be hundreds of megabytes on a huey is simply laughable.  You obviously have no idea what you're talking about.

[Psycho Punch]

That's to say nothing of the reduced performance from the phenomenal amount of bank switching that would be required.

Yes, phenomenal microseconds lost to order an instantaneous bank change as opposed to the seconds long optical + mechanical maneuvers every time you want data outside the tiny window already loaded into the syscard ram. Truly phenomenal

Your posts make you sound like you're the kind of random Internet expert that says stuff like "the PCE is 8 bit but has two 16 bit video chips"

Super Mario Bros. 2 was actually a game called Doki Doki Panic in Japan.

Cartridge mask ROM != Flash DRAM memory. Flash is significantly slower.
I'm not an expert but I'm pretty sure that the HuC6280 doesn't work at all like you probably imagine it to. It doesn't have an internal RAM cache. The CPU fetches data as fast in ROM as in RAM, and only slows down when its doing something weird like running one of its block transfer instructions. This isn't a modern computer, dude.
There's no reading data all over the full physical space with long jumps too because games which rely on bankswitching (like, all hucards ever and 90% of the NES library) usually organize code to require the least amount of "far jumps" possible, and most of the time the most mobile portion of the ROM is DATA which is usually copied elsewhere (VRAM, or just plain RAM sometimes). SFII is the perfect example (top half of rom is FIXED, bottom half of rom is bankswitchable... and most of the extra space is used for bg/sprite data which is uploaded to VRAM when needed).

Comparing a PCE HuCard to SD cards... lmao. Nice job. Btw my point was that no mapper cart could be possibly slower than CDROM -- please show me how a PCE cartridge could be slower than something relying on a 1x mechanical CDROM controller. Or own me by schooling me on the PCE CPU's ROM access speeds or something, with all the pretty bus timing diagrams and shit. Again I'm no expert, but you'll have to be more substantial than that, I'd shut up if it was someone who knows his shit like tomaitheous or elmer, not you though, sorry.

It's still Flash memory. It's only faster because it's one way, unlike SDs etc.

Bank switching is still bank switching. You're suggesting that 500-600MB worth of data being bank switched will have the same seek/fetch time as 2MB or so. That's utter bullshit.

The MMU is going to be bit with so much freaking data it's unreal, and unlike CD-ROM, it has no buffer. I doubt if the slot would even provide sufficient power to so many ROM chips of '91 vintage.

The CD-ROM will have a logic control chip, and buffer.

Your last two paragraphs don't make any sense and no game ever used 1/8 of a disc, let alone 650MB.

By the way, do you think that it's possible to do a conversion of a, say, roughly 20 to 30 Megabit arcade game to an 8 bit console that can only have 64 KB of ROM without bankswitching or do you think that it's impossible to do so because of the limitations of bankswitching you're claiming? Just a curiosity.

[Artabasdos]

Lol, that is still data being stored on ROMs. Not only that, but all sound data is run off the CPU, with no additional sound chip as found in the CD-ROM unit. That is even worse...

Are you a troll or are you really this dense?

The adpcm stuff would be scrapped (it requires cd hardware) and the redbook would be exchanged for exponentially smaller chip tune data.  You trying to argue that a graphically identical game (but with different sounds) would still be hundreds of megabytes on a huey is simply laughable.  You obviously have no idea what you're talking about.

The PCE's sound chip can combine channels to play better quality sound. Therefore the redbook could theoretically run to some extent when converted to whatever container.
I'm arguing that your point about a "Huey" of several hundred MBs wouldn't work very well. Even with an onboard MMU. That amount of data would bottleneck.

You also didn't mention about converting the redbook to chiptune. Your argument was purely on MB size.

[Artabasdos]

That's to say nothing of the reduced performance from the phenomenal amount of bank switching that would be required.

Yes, phenomenal microseconds lost to order an instantaneous bank change as opposed to the seconds long optical + mechanical maneuvers every time you want data outside the tiny window already loaded into the syscard ram. Truly phenomenal

Your posts make you sound like you're the kind of random Internet expert that says stuff like "the PCE is 8 bit but has two 16 bit video chips"

Super Mario Bros. 2 was actually a game called Doki Doki Panic in Japan.

Cartridge mask ROM != Flash DRAM memory. Flash is significantly slower.
I'm not an expert but I'm pretty sure that the HuC6280 doesn't work at all like you probably imagine it to. It doesn't have an internal RAM cache. The CPU fetches data as fast in ROM as in RAM, and only slows down when its doing something weird like running one of its block transfer instructions. This isn't a modern computer, dude.
There's no reading data all over the full physical space with long jumps too because games which rely on bankswitching (like, all hucards ever and 90% of the NES library) usually organize code to require the least amount of "far jumps" possible, and most of the time the most mobile portion of the ROM is DATA which is usually copied elsewhere (VRAM, or just plain RAM sometimes). SFII is the perfect example (top half of rom is FIXED, bottom half of rom is bankswitchable... and most of the extra space is used for bg/sprite data which is uploaded to VRAM when needed).

Comparing a PCE HuCard to SD cards... lmao. Nice job. Btw my point was that no mapper cart could be possibly slower than CDROM -- please show me how a PCE cartridge could be slower than something relying on a 1x mechanical CDROM controller. Or own me by schooling me on the PCE CPU's ROM access speeds or something, with all the pretty bus timing diagrams and shit. Again I'm no expert, but you'll have to be more substantial than that, I'd shut up if it was someone who knows his shit like tomaitheous or elmer, not you though, sorry.

It's still Flash memory. It's only faster because it's one way, unlike SDs etc.

Bank switching is still bank switching. You're suggesting that 500-600MB worth of data being bank switched will have the same seek/fetch time as 2MB or so. That's utter bullshit.

The MMU is going to be bit with so much freaking data it's unreal, and unlike CD-ROM, it has no buffer. I doubt if the slot would even provide sufficient power to so many ROM chips of '91 vintage.

The CD-ROM will have a logic control chip, and buffer.

Your last two paragraphs don't make any sense and no game ever used 1/8 of a disc, let alone 650MB.

By the way, do you think that it's possible to do a conversion of a, say, roughly 20 to 30 Megabit arcade game to an 8 bit console that can only have 64 KB of ROM without bankswitching or do you think that it's impossible to do so because of the limitations of bankswitching you're claiming? Just a curiosity.

Depends on the hardware, and if the port has been watered down. Is the data on the cart 20-30 megabits, or cut down?

When you say without bank switching, do you mean the hardware can't do that?

[Psycho Punch]

By the way, do you think that it's possible to do a conversion of a, say, roughly 20 to 30 Megabit arcade game to an 8 bit console that can only have 64 KB of ROM without bankswitching or do you think that it's impossible to do so because of the limitations of bankswitching you're claiming? Just a curiosity.

Depends on the hardware, and if the port has been watered down. Is the data on the cart 20-30 megabits, or cut down?

When you say without bank switching, do you mean the hardware can't do that? [/quote]
Port is of a game that might theoretically hit 30 MiB of data, original might be double the size of the port. Hardware can only see 64 KB of data without resorting to bankswitching circuitry. Seems to be an interesting proportion, not as huge as a CD to HuCard but still an interesting question. In the data size aspect alone, considering all data might be accessed at any given time, is it possible to have this theoretical port?

[Artabasdos]

By the way, do you think that it's possible to do a conversion of a, say, roughly 20 to 30 Megabit arcade game to an 8 bit console that can only have 64 KB of ROM without bankswitching or do you think that it's impossible to do so because of the limitations of bankswitching you're claiming? Just a curiosity.

Depends on the hardware, and if the port has been watered down. Is the data on the cart 20-30 megabits, or cut down?

When you say without bank switching, do you mean the hardware can't do that?

Port is of a game that might theoretically hit 30 MiB of data, original might be double the size of the port. Hardware can only see 64 KB of data without resorting to bankswitching circuitry. Seems to be an interesting proportion, not as huge as a CD to HuCard but still an interesting question. In the data size aspect alone, considering all data might be accessed at any given time, is it possible to have this theoretical port?[/quote]
Again, it depends on the hardware. 20-30MB shouldn't be too much of a challenge. Does the cart have an MMU?
When you say "only see 64KB", are you referring to the ROM chip sizes in the cart? Or the data in the VRAM? The PCE has 64KB of VRAM. Is that what you mean?

[Psycho Punch]

By the way, do you think that it's possible to do a conversion of a, say, roughly 20 to 30 Megabit arcade game to an 8 bit console that can only have 64 KB of ROM without bankswitching or do you think that it's impossible to do so because of the limitations of bankswitching you're claiming? Just a curiosity.

Depends on the hardware, and if the port has been watered down. Is the data on the cart 20-30 megabits, or cut down?

When you say without bank switching, do you mean the hardware can't do that?

Port is of a game that might theoretically hit 30 MiB of data, original might be double the size of the port. Hardware can only see 64 KB of data without resorting to bankswitching circuitry. Seems to be an interesting proportion, not as huge as a CD to HuCard but still an interesting question. In the data size aspect alone, considering all data might be accessed at any given time, is it possible to have this theoretical port?

Again, it depends on the hardware. 20-30MB shouldn't be too much of a challenge. Does the cart have an MMU?
When you say "only see 64KB", are you referring to the ROM chip sizes in the cart? Or the data in the VRAM? The PCE has 64KB of VRAM. Is that what you mean?

Only see 64KB = the CPU can only map stuff to bytes 0 to 65535, including ROM. This has nothing to do with VRAM, and yes presumably it would have a MMU chip.

edit: rewording.

[Artabasdos]

By the way, do you think that it's possible to do a conversion of a, say, roughly 20 to 30 Megabit arcade game to an 8 bit console that can only have 64 KB of ROM without bankswitching or do you think that it's impossible to do so because of the limitations of bankswitching you're claiming? Just a curiosity.

Depends on the hardware, and if the port has been watered down. Is the data on the cart 20-30 megabits, or cut down?

When you say without bank switching, do you mean the hardware can't do that?

Port is of a game that might theoretically hit 30 MiB of data, original might be double the size of the port. Hardware can only see 64 KB of data without resorting to bankswitching circuitry. Seems to be an interesting proportion, not as huge as a CD to HuCard but still an interesting question. In the data size aspect alone, considering all data might be accessed at any given time, is it possible to have this theoretical port?

Again, it depends on the hardware. 20-30MB shouldn't be too much of a challenge. Does the cart have an MMU?
When you say "only see 64KB", are you referring to the ROM chip sizes in the cart? Or the data in the VRAM? The PCE has 64KB of VRAM. Is that what you mean?

Only see 64KB = the CPU can only address bytes 0 to 65535 on a ROM cart. This has nothing to do with VRAM, and yes presumably it would have a MMU chip.

Well without knowing the exact console you mean, I would imagine yes, that's pretty possible. 30MB is a lot, but broken into 64KB chunks with an MMU it shouldn't be too bad at all. With an inbuilt MMU, the data being fed out is only what is needed, and won't constantly be running calls across the bus to the CPU or system MMU.

[Psycho Punch]

By the way, do you think that it's possible to do a conversion of a, say, roughly 20 to 30 Megabit arcade game to an 8 bit console that can only have 64 KB of ROM without bankswitching or do you think that it's impossible to do so because of the limitations of bankswitching you're claiming? Just a curiosity.

Depends on the hardware, and if the port has been watered down. Is the data on the cart 20-30 megabits, or cut down?

When you say without bank switching, do you mean the hardware can't do that?

Port is of a game that might theoretically hit 30 MiB of data, original might be double the size of the port. Hardware can only see 64 KB of data without resorting to bankswitching circuitry. Seems to be an interesting proportion, not as huge as a CD to HuCard but still an interesting question. In the data size aspect alone, considering all data might be accessed at any given time, is it possible to have this theoretical port?

Again, it depends on the hardware. 20-30MB shouldn't be too much of a challenge. Does the cart have an MMU?
When you say "only see 64KB", are you referring to the ROM chip sizes in the cart? Or the data in the VRAM? The PCE has 64KB of VRAM. Is that what you mean?

Only see 64KB = the CPU can only address bytes 0 to 65535 on a ROM cart. This has nothing to do with VRAM, and yes presumably it would have a MMU chip.

Well without knowing the exact console you mean, I would imagine yes, that's pretty possible. 30MB is a lot, but broken into 64KB chunks with an MMU it shouldn't be too bad at all. With an inbuilt MMU, the data being fed out is only what is needed, and won't constantly be running calls across the bus to the CPU or system MMU.

This is the exact same case as the PCE having a large mapper to be able to hold a 200 MB ROM, why is my example possible and what we're trying to tell you in this thread isn't?

edit: oh and by the way I'm disappointed that you didn't take the bait and claim that it would be impossible. You know which console has 64KB of logic addressing? The PCE. The thing has an internal "MMU" that maps upwards of 1 megabyte (the ceiling for "standard" hucards)... it wasn't as epic as it would be if you answered otherwise but you got the right answer out of pure luck anyway, seeing that you didn't catch that little trivia piece that is even shown in the HuC6280's wikipedia page lol.

No game uses more than 50MB on a CDROM (audio tracks obviously excluded) and this is a 1987 console with a custom mapper built in on the CPU, if there's a hugeass cart it's not going to use all data at once and it won't bankswitch on the cart side more than once per second, thus it could run all CD titles without loss (except for Redbook audio of course), it's not rocket science dude. It's possible even if you pretend that the cart would be slower than the CDROM pickup of the Duo (which it's never going to be, not even close lmao).

[CrackTiger]

Lol, irrelevant. We're talking economy of scale in terms of what is acceptable performance. 2-8MB is nothing compared to CD size.

And as was said before, the game itself is nowhere near the 650MB capacity of a CD.  If a CD game were made as a huey instead, it'd lose the hundreds of megs of redbook and adpcm.  Duh.

Lol, that is still data being stored on ROMs. Not only that, but all sound data is run off the CPU, with no additional sound chip as found in the CD-ROM unit. That is even worse...

There are more chiptunes in CD games than HuCards.

Many HuCard games run multiple samples at once while still running intensive games that would melt the SNES.

[Artabasdos]

@Punch

Oh God lol. Scale. 30MB vs 500MB. An inbuilt MMU would help, but good luck powering fuck knows' how many vintage ROM chips with whatever fragment of 4W the PCE gives the slot. The seek/fetch is still gonna be brutal.

[Artabasdos]

Lol, irrelevant. We're talking economy of scale in terms of what is acceptable performance. 2-8MB is nothing compared to CD size.

And as was said before, the game itself is nowhere near the 650MB capacity of a CD.  If a CD game were made as a huey instead, it'd lose the hundreds of megs of redbook and adpcm.  Duh.

Lol, that is still data being stored on ROMs. Not only that, but all sound data is run off the CPU, with no additional sound chip as found in the CD-ROM unit. That is even worse...

There are more chiptunes in CD games than HuCards.

Many HuCard games run multiple samples at once while still running intensive games that would melt the SNES.

What does that have to do with a bottlenecked bus and horrible data overload?

[NecroPhile]

The PCE's sound chip can combine channels to play better quality sound. Therefore the redbook could theoretically run to some extent when converted to whatever container.
I'm arguing that your point about a "Huey" of several hundred MBs wouldn't work very well. Even with an onboard MMU. That amount of data would bottleneck.

You also didn't mention about converting the redbook to chiptune. Your argument was purely on MB size.

I never said that a 500+ megabyte huey would be required; that's your foolish notion.  The entire argument is about recreating a cd game as a graphically identical huey, and I said in the very beginning that adpcm and redbook would be scrapped: "other than redbook and adpcm stuff, if it could be done on CD it could be done on huey".  Don't try to change the argument after being shown you're wrong.

Since elmer has posted such fancy details, let's use Xanadu 1 and 2 as examples: they have about 6 megabytes and 9 megabytes of game data (respectively) with the rest of their discs being filled with adpcm and redbook.  These are a couple of the largest and most graphically impressive games around, yet they'd comfortably fit in a cart similar in size to Star Ocean or Pier Solar, neither of which have any "performance issues" you claim.  These two games also rely heavily on chip tunes in game, so you'd not need to double the rom size or play in silence.


Wanna know what's really funny?  This shit isn't exactly hypothetical.

There's several titles that were released as both 500+ megabyte cds and 8 megabit or smaller hueys.... yet they were substantially identical games other than the tunes.

There's several more that were released as PCE CDs and SNES/Genny carts.... yet the latter 8 or 16 megabit carts weren't missing 90% of the graphics/sound/etc.