CD Stupid Card 4.0

[Bonknuts]

I'm still ignorant enough to not quite understand the circumstances that you're targeting.

Do you want this to make sample playback on HuCards less CPU-intensive, or more for adding extra sample channels to CD games?

Either way is cool ... just curious 

 Both.

 Currently, at a minimum, you have to write to the LSB of the scanline counter (update) for everyline. The PCE can generate an hsync interrupt for all 262/263 lines, perfect for driving higher sample rates, but the even with optimized routine (which writes only to the LSB of the VDC reg 99% of the time) - the overhead is still ~5.2% cpu resource per frame. More if you write a less optimized routine. But for games that don't use full cpu resource, having 32khz vs 16khz sample rate would be even nicer; you only need a single interrupt routine to drive both the audio and VDC (handling a dual interrupt system kinda sucks and is a waste of cpu resource). That, and doing stuff like channel hard-sync and other none sample type audio effects would sound less gritty with a higher input clock for the phase-accumulator. 

 Though, not just for samples, but if you're doing something every scanline or such on the VDC. It can help (which is ~3.8%). But yeah, mostly sample  playback. It might not sound like much, but that could be enough for a game to overload its cpu resource for a frame (slowdown).

[elmer]

Though, not just for samples, but if you're doing something every scanline or such on the VDC. It can help (which is ~3.8%). But yeah, mostly sample  playback. It might not sound like much, but that could be enough for a game to overload its cpu resource for a frame (slowdown).

Thanks for the explanation. 

Yep, been there, done that, spent long hours searching for those cycles!

Luckily, these days it's often just a case of "get that bloody artist to halfsize some of those damned 2048x2048 textures!". 

But seriously, from my POV, I wouldn't want to rely on that feature in order to hit framerate and thus require this new card in order to ship a game.

Enhanced audio rate? ... sure, if there's enough spare memory for the samples, but we're already 9% down on an Arcade Card.

[TailChao]

So regarding that timer-
I can fit in a 32.768KHz oscillator with an option of no division or division by 2 if I drop both mode indicator LEDs. However, you'll get no sync capability. Just interrupts @32KHz or @16KHz.
Interface will just be an enable bit in one register and "write to ack" in another. Does that work for you?

Edit:

Roughly how much would this card cost, if the Arcade card features were included?  One reason I ask this, is because we did have plans for at least 1 Arcade CD game(Golden Axe), however, I wonder if it'd be more doable with this cards current features compared to the Arcade CD, or if we'd still need the ACD & combine it with the Stupid Cards features.  Ultimately, I know nothing, Old Rover/Nod would have to chime in about this, but you can read about the project here:
http://www.pcenginefx.com/forums/index.php?topic=15488.15

It would increase the cost of the CPLD by a couple dollars, but the cost of the PCB would go up significantly.
The difficulty in implementing the arcade card features is that they require manipulation of the extended RAM's address lines... all of them. This requires a very large CPLD but also more board layers in order to break out of the QFP or BGA or whatever form factor said CPLD would be.

As for which card to use for your game, the difference between the CD Stupid Card versus the Arcade Card is that you get slightly less RAM (192K less) on the CD Stupid Card, but all of it is general purpose. On the Arcade Card the 2MB extended memory is accessed through a straw.
The CD Stupid Card setup may be better for you depending upon how your game works. In any case I think it is easier.

[ParanoiaDragon]

So regarding that timer-
I can fit in a 32.768KHz oscillator with an option of no division or division by 2 if I drop both mode indicator LEDs. However, you'll get no sync capability. Just interrupts @32KHz or @16KHz.
Interface will just be an enable bit in one register and "write to ack" in another. Does that work for you?

Edit:

Roughly how much would this card cost, if the Arcade card features were included?  One reason I ask this, is because we did have plans for at least 1 Arcade CD game(Golden Axe), however, I wonder if it'd be more doable with this cards current features compared to the Arcade CD, or if we'd still need the ACD & combine it with the Stupid Cards features.  Ultimately, I know nothing, Old Rover/Nod would have to chime in about this, but you can read about the project here:
http://www.pcenginefx.com/forums/index.php?topic=15488.15

It would increase the cost of the CPLD by a couple dollars, but the cost of the PCB would go up significantly.
The difficulty in implementing the arcade card features is that they require manipulation of the extended RAM's address lines... all of them. This requires a very large CPLD but also more board layers in order to break out of the QFP or BGA or whatever form factor said CPLD would be.

As for which card to use for your game, the difference between the CD Stupid Card versus the Arcade Card is that you get slightly less RAM (192K less) on the CD Stupid Card, but all of it is general purpose. On the Arcade Card the 2MB extended memory is accessed through a straw.
The CD Stupid Card setup may be better for you depending upon how your game works. In any case I think it is easier.

Ok, hopefully Old Rover will see this thread, & maybe this will change the route he decides to take on the project in regards to which card to use.

[elmer]

Ok, hopefully Old Rover will see this thread, & maybe this will change the route he decides to take on the project in regards to which card to use.

As a programmer, I'd opine that this card should be able to do 90%+ of what an Arcade Card can do ... but in a way that's a bit more programmer-friendly, and a lot more elegant.

Ultimately ... if you really need the extra 192KB that an Arcade Card provides, or Old Rover actually needs the Arcade Card's bit-shifter ... then the Arcade Card will be your only choice.

If you can trim down the memory requirements a tiny bit, and don't need the bit-shifter, then this card will likely be an alternative that you can support with Golden Axe.

But, as developers of a new game, AFAIK there's relatively little that you can do with this card, in it's current form, that you can't do with an Arcade Card.

That's not the case for game-translation teams, where this card could be an absolute godsend.

You may just end up supporting both this card and the Arcade Card, but I'd be a little surprised if you end up supporting it instead of the Arcade Card ... that will be entirely up to you guys.

http://www.pcenginefx.com/forums/index.php?topic=15488.15

I've been drooling at it ever since I saw it ... absolutely gorgeous!

[Bonknuts]

So regarding that timer-
I can fit in a 32.768KHz oscillator with an option of no division or division by 2 if I drop both mode indicator LEDs. However, you'll get no sync capability. Just interrupts @32KHz or @16KHz.
Interface will just be an enable bit in one register and "write to ack" in another. Does that work for you?

 Hmm, that won't work. The phase difference to the line frequency is too much. 32.768khz / 2 = 436 cpu cycles vs the display which is 455 cpu cycles. Even if it was just +1 cpu cycle off, it's going to accumulate to quite a bit across the frame. I was thinking something of a higher clock, that divides down internally and you could reset that counter. It'd have to be almost exactly 31.470khz on the interrupt side (double the horizontal scan rate). I was thinking of a higher clock. Something like a ~4mhz clock with a writable 12bit value (the value is copied to a reg, is decremented on every external clock cycle, overflow generates interrupt and the reg is reloaded with user value, etc) and the ability to clear (i.e. force a reload) the internal counter to resync it. I do this with the 7khz to keep it in sync with VDC every frame, when I run both interrupts. Might be best to scrap this idea. 


 Edit: The arcade card indirect regs are nice, but hardly a huge benefit. I can think of a few optimization you can do with it, but it's hardly a "make or break" issue. This card also offers something the Arcade Card does not [!]... embedded VDC data as opcodes (ST1/ST2 opcodes) for thee fastest transfer method to vram and none of that silly stalling of interrupts that the Txx instructions do. That right there, is worth gold to me. So yeah, it's already a better option than the arcade card (touko wanted to do this on the AC but realized it can't be done). Following similar suit, this card also allows for "code list" optimizations (you pre-generate all possible code logic routes and use a jump table to execute this fast code branches).

[elmer]

This card also offers something the Arcade Card does not [!]... embedded VDC data as opcodes (ST1/ST2 opcodes) for the fastest transfer method to vram and none of that silly stalling of interrupts that the Txx instructions do. That right there, is worth gold to me. So yeah, it's already a better option than the arcade card (touko wanted to do this on the AC but realized it can't be done). Following similar suit, this card also allows for "code list" optimizations (you pre-generate all possible code logic routes and use a jump table to execute this fast code branches).

Oooooh ... Good points! 

"Yes", those are definitely things that you can do with this card that you can't do with the Arcade Card's "external" memory.

But now you've also made your game specific to the extra CPU-addressable memory that's available in a piece of add-on hardware that was never available during the console's lifetime ... everyone has to decide for themselves whether they consider that to be "fair game".

[TailChao]

Hmm, that won't work. The phase difference to the line frequency is too much. 32.768khz / 2 = 436 cpu cycles vs the display which is 455 cpu cycles. Even if it was just +1 cpu cycle off, it's going to accumulate to quite a bit across the frame. I was thinking something of a higher clock, that divides down internally and you could reset that counter. It'd have to be almost exactly 31.470khz on the interrupt side (double the horizontal scan rate). I was thinking of a higher clock. Something like a ~4mhz clock with a writable 12bit value (the value is copied to a reg, is decremented on every external clock cycle, overflow generates interrupt and the reg is reloaded with user value, etc) and the ability to clear (i.e. force a reload) the internal counter to resync it. I do this with the 7khz to keep it in sync with VDC every frame, when I run both interrupts. Might be best to scrap this idea. 

Ahh, okay. So you're looking for a really precise synchro with the VDC, not just a faster timer for PCM playback.
Yeah, let's cut it for now. This would have been trivial if NEC just put the system clock on the HuCard slot instead of the useless speed indicator. Having two separate oscillators sync as you're describing is doable, but it's still not too great precision wise. Especially as these things vary with temperature (even just a little makes a difference).

Of course... *UPDATE!*
[ul][li]Second RAM bank select has been added[/li][li]Upper 256KB of flash may be optionally swapped out to use this[/li][/ul]
I've updated the mapper documentation in the first post to reflect these new features.

[elmer]

Of course... *UPDATE!*
[ul][li]Second RAM bank select has been added[/li][li]Upper 256KB of flash may be optionally swapped out to use this[/li][/ul]
I've updated the mapper documentation in the first post to reflect these new features.

Excellent, thank you! 

[nodtveidt]

But now you've also made your game specific to the extra CPU-addressable memory that's available in a piece of add-on hardware that was never available during the console's lifetime ... everyone has to decide for themselves whether they consider that to be "fair game".

...isn't this kind of the whole point of making an improved piece of hardware to begin with? After all, GE games only work with GE cards...

[Bonknuts]

But now you've also made your game specific to the extra CPU-addressable memory that's available in a piece of add-on hardware that was never available during the console's lifetime ... everyone has to decide for themselves whether they consider that to be "fair game".

Maybe, but it's not that far out of reality with the PCE. I mean, the arcade card was developed and to be honest, it probably wouldn't have cost that much to do SRAM over DRAM. All that extra logic for could have just been a very simple mapper. I think the AC was developed to be more "C" friendly. There's a discussion as to where early mid 90's was starting to see C stuff on the snes and gameboy. Some arcade games were supposedly coded in C as well, and a number of Genesis softs too.

 But yeah, this card isn't too far fetched. No SuperFX or SVP processors, enhanced audio chips (nes), etc. This seems more inline with the PCE; brute forcing everything with minimal set of hardware at hand. 

 You wouldn't believe how many people believed the CD unit added an extra processor, and/or the arcade card as well.

[SkyeWelse]

This sounds like a great project, and it's nice to see new PCE hardware being created. If developers were to use this card to enhance PCE translations, then it would require this card to play the patched game correct?

I'm not a PCE developer... (yet), but if that is the case, then as a regular player it would benefit anyone interested who wanted to play these new enhanced translations to have this card. If that's a correct understanding of how this card would work, I'd definitely like to order one when they become available. 

Would this card also be available eventually as a system card that could be used with emulation as well?

-Thomas

[elmer]

Maybe, but it's not that far out of reality with the PCE. I mean, the arcade card was developed and to be honest, it probably wouldn't have cost that much to do SRAM over DRAM. All that extra logic for could have just been a very simple mapper.

I certainly can't see why they chose to do the external mapping rather than the simple 2-level mapping that's on the Stupid Card ... nor can I see why they couldn't have chosen to do the 2-level mapping with dram.

I can say that SRAM was more expensive than DRAM at the time (and has remained so ... more gates per bit) ... but that's not really relevant to the actual point.

I think the AC was developed to be more "C" friendly. There's a discussion as to where early mid 90's was starting to see C stuff on the snes and gameboy. Some arcade games were supposedly coded in C as well, and a number of Genesis softs too.

AFAIK, C didn't really hit the console industry until the 5th generation ... when every console manufacturer shipped consoles that actually included (and required) C system libraries.

By the mid 90s, there could have been some people doing ports from C code to the SNES and GB that wanted to use a C compiler ... but I don't have any memory of them personally.

In the early 90s ... please just consider that those early compilers were pretty bad, and any reasonably competent programmer could run rings around them. I can't think of anyone that specifically had enough free cycles to burn that they'd waste it on C ... and it just didn't have the mind-share, nor, more importantly, a good debugger.

Now ... if you really believe that the Arcade Card's design was influenced by the desire for C-style auto-incrementing pointers ... then I suspect that you should look to SNK's Neo Geo and it's 68000.

It almost looks to me as though the Arcade Card was specifically designed to allow the porting of SNK's Neo Geo arcade games.

Some arcade games were supposedly coded in C as well, and a number of Genesis softs too.

The arcade guys cheated ... expensive custom hardware with new boards on a regular basis, potentially with each game! They got the fun processors and technology way before the console guys.

...isn't this kind of the whole point of making an improved piece of hardware to begin with? After all, GE games only work with GE cards...

As I said ... everyone gets to pick their own comfort zone.

For me, anything that makes the translator's job easier is "fair game", they have a tough enough time anyway ... and they're not using the card's features to change the game itself.

I started my career doing arcade game conversions onto home computers that couldn't possibly do them justice. For me, living within the restrictions of the machines as they were sold at time is part of the fun of getting back to them now.

But that's just my personal feeling ... I have absolutely no right to comment on whatever choices you choose to make while you're spending your valuable time doing the work that you're doing in bringing a wonderful new game to the PCE.

Anyway ... the idea that they could just have used the 2-level mapping scheme does make me more personally willing to take advantage of those tricks, especially since they're going to be just sitting there ... calling out ... tempting! 

[elmer]

This sounds like a great project, and it's nice to see new PCE hardware being created. If developers were to use this card to enhance PCE translations, then it would require this card to play the patched game correct?

That's entirely up to the individual translation teams. They can ...
[uldecimal][li]Choose to ignore this card.[/li][li]Choose to use it only during development to make things easier.[/li][li]Make it "optional" for the translated game.[/li][li]Make it "required" for the translated game.[/li][/ul]Until these cards have been made and given out to those teams ... and they have had time to use them ... then nobody really knows what each team will choose to do ... you'd have to ask your favorite translation developers what they think.

I'm not a PCE developer... (yet), but if that is the case, then as a regular player it would benefit anyone interested who wanted to play these new enhanced translations to have this card.

Yes ... but things are a long way from that stage, and right now there's going to be a very, very limited supply of these cards.

If they really get used by the translators, then there will be a "production" run at a later date.

Would this card also be available eventually as a system card that could be used with emulation as well?

From what TailChao has said it's already working in Mednafen ... so "yes".

[SamIAm]

Just a thought, but it would be nice if the Stupid Card 4.0 and the Turbo Everdrive 2.0 were effectively cross compatible. I'm not trying to plug for Everdrive sales or anything, I just want to maximize access for users.

When it looks like the specs for the Stupid Card 4.0 are getting fully locked in, including if that's the case now, one of you guys ought to PM krikzz on his forum and just say "hey, we're making a card with x, y and z features, and if you could tool your new TED to be compatible, it would be win-win situation."

I'd do it myself, but I'm not confident that I understand the details or what things need to be emphasized well enough.