Mad Stalker - Arcade or Super System game?

[Necromancer]

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.

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

[Necromancer]

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...

[Necromancer]

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.

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

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

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