CD Stupid Card 4.0

[TailChao]

As discussed here, there seems to be a desire to create a new CD System Card with extended memory to simplify translation work and generally improve the PCE's capabilities.

Based upon these, I'd like to propose the CD Stupid Card 4.0:
*512KB ROM + 2MB RAM + MCGenjin-CD Mapper.
*Linear 1MB RAM mode for loading all your (legally obtained) HuCard images from CD, or rolling your own CD BIOS, or whatever.
*Works in both the PCE and TG16 without modification.
*Compatible with most CD System Card 3.0 software using a patched version of said card's BIOS.
*Can already be emulated by Mednafen excluding the linear 1MB mode (see "BIOS" section below).
*Two LEDs indicating region locking and mode (512KB ROM + Banked RAM or Linear 1MB RAM).


MCGenjin-CD Mapper:

Code ("MCGenjin-CD Documentation") Select Expand

;*************************************************************
; !!!!----              MCGenjin-CD                ----!!!!
;*************************************************************
  MCGenjin-CD is a modified version of the MCGenjin memory
  mapper for use in CD System Cards. It includes the standard
  dual-region capability present on the original MCGenjin as
  well as facilities for controlling 512KB of cartridge ROM
  and 2MB of cartridge RAM.


;*************************************************************
; !!!!----            MEMORY MAPPING              ----!!!!
;*************************************************************
  In Normal / Startup mode, the 1MB cartridge region is
  arranged as follows:
    $00000 - $3FFFF Lower 256KB of ROM
    $40000 - $7FFFF Upper 256KB of ROM or Secondary 256KB RAM Bank
    $80000 - $BFFFF Selected 256KB RAM Bank
    $C0000 - $FFFFF Highest 256KB RAM Bank
 
  Once RAM mode is enabled, the cartridge region will just
  contain a linear map of the lower 1MB of RAM, and will remain
  in this mode until the console is reset.
    $00000-$FFFFF 1MB RAM


;*************************************************************
; !!!!----            MCGENJIN HEADER            ----!!!!
;*************************************************************
  As the MCGenjin-CD is an MCGenjin derivative mapper, an
  MCGenjin header should be included from $1FD0 to $1FDF in the
  ROM residing on the card. The following contents should be used,
  appearing as follows after being mapped into MPR7/$FFD0:

    $FFD0-$FFD7 : ASCII String containing "MCGENJIN"
    $FFD8 : MCGenjin Chip Revision.
        $CD- "CD" Version
    $FFD9 : Number of 256KB pages in ROM
        $2- 512KB of ROM
    $FFDA : Native ROM Region
        $0- US/EU
        $1- JP
    $FFDB : User Chipselect 0 Device Type
        $15- 256KB SRAM
    $FFDC : User Chipselect 1 Device Type
        $15- 256KB SRAM
    $FFDD-$FFDF : Unused/Future Expansion
        -Set to $0


;*************************************************************
; !!!!----            REGISTER LIST              ----!!!!
;*************************************************************
  All registers are write-only and accessed by writing
  anywhere in the $00000 - $3FFFF region. Register access
  is completely disabled upon a switch into linear RAM mode.
 
  Note that unlike a normal MCGenjin, _only_ the Region Control
  register does not account for the current operating region
  (dataline transposition). All other registers such as the
  RAM Bank Select and Linear Mode Unlock will properly reverse
  written data bits. Therefore, when setting the system region
  at startup it is best just to write $00 for native / unswapped
  or $FF for foriegn / swapping enabled.
 
 
 +Writes to %00 addresses control UPPER ROM ENABLING
                      76543210
    High ROM Enable: xxxxxxxR, Reset = xxxxxxx0
    R = When set, the upper 256KB of ROM from $40000 - $7FFFF
    will be replaced with the LOWER RAM BANK (selected using
    register %01).
    Note that any writes to this register will also reset
    the linear mode unlock sequence.
 
 -Writes to %01 addresses select the LOWER RAM BANK
                      76543210
    RAM Bank Select: xxxxxBBB, Reset = xxxxx000
    BB = A20-A18 of the lower 256KB RAM Bank ($40000 - $7FFFF)
    Note that any writes to this register will also reset
    the linear mode unlock sequence.
 
 +Writes to %10 addresses control REGION and LINEAR MODE
                      76543210
    Region Control:  xxxxxxxS, Reset = xxxxxxx0
    Upon reset, this register controls the system region
    (dataline reversal enable). Once a region has been
    selected (writing '0' for no reversal or '1' to
    request dataline reversal), this register's purpose
    will change to control LINEAR RAM MODE UNLOCKING.
 
                      76543210
    Linear Unlock:  KKKKKKKK
    To request a switch into linear RAM mode, the two ASCII
    characters "HU" must be written to this register in order.
    Once in linear RAM mode, all register access will be
    disabled until the system is reset.
 
 -Writes to %11 addresses select the UPPER RAM BANK
                      76543210
    RAM Bank Select: xxxxxBBB, Reset = xxxxx000
    BB = A20-A18 of the upper 256KB RAM Bank ($80000 - $BFFFF)
    Note that any writes to this register will also reset
    the linear mode unlock sequence.


BIOS:
I have two UPS patches available for the Japanese System Card 3.0 (Original MD5 should be 38179df8f4ac870017db21ebcbf53114). A summary of the patch changes is available here.

* Super CD-ROM DERP v3.6 - Can be used with Mednafen as a System Card 3.0 with 512KB RAM (basically no RAM banking or linear 1MB mode), if you test your game or translation using this it will work 100% fine on the CD Stupid Card.

* Stupid CD-ROM DERP v4.1 - Version for the CD Stupid Card. Not 100% compatible with Mednafen.


Resources to make your OWN CD Stupid Cards:
Are all available here.
These include the board gerbers, mapper source (in Verilog) and precompiled POF, along with documentation and a test program.
If you're planning on mass-producing a variation of this card, I highly recommend laying out a new board. Smaller packages of the components used are available and could easily be arranged such that everything fits in the same area as an original System Card. I also screwed up the SRAM pads which makes manufacturing difficult.


Components and Cost:
1x EPM7032LC44 / CPLD : $2.40 ea
1x 39SF040 / 512KB Flash : $2.07 ea
2x AS6C8008 / 1MB SRAM : $7.24 ea

1x DIP32 Socket : $0.73 ea
2x Amber LED : $0.25 ea
2x 1KOhm Resistor (0402) : $0.07 ea
1x 10uF, 25V Tantalum Capacitor (1206) : $0.21 ea
4x 0.1uF, 50V Ceramic Capacitor (0402) : $0.06 ea

1x PCB : $1.49 ea

Total: $22.26 per card
Please note that it this is raw component cost in low quantities and excludes shipping and manufacturing. However, the point still stands that this card is cheap to make. The developer cards will be available for $35/ea plus shipping.


Yeah great, but where are you going with all this?:
This is the System Card I've wanted since I first bought my TurboGrafx: something affordable which works in both console regions. It also has some neato extra stuff for translations and new games.
That said, I do not have time to manufacture hundreds of these. I'm currently developing two games and working on a book, which have to take priority over weird niche card designs. However, I'd like to do a small "developer's" run of cards and then release all the materials I used to create the cards. This means both the gerber files for the PCB and Verilog + POF for MCGenjin-CD (update, these are available). That way the community can take the card wherever it needs to go.
This developer run of cards will only be 25 cards maximum. If you're interested in a card, please post in this topic saying so. These are first-come first-serve (update, with the current developer sign-up I'll be manufacturing 16 cards total).


What I'd like from you guys:
Nothing! Enjoy your cards!


Status Tracker:
*Card and Mapper Specification, DONE!
*Mapper Verilog, DONE!
*Board Layout, DONE!
*Developer Sign-Up, DONE!
*Developer Card Fab, DONE!
*Card Verification, DONE!
*Card Manufacturing, DONE!
*Developer Distribution, DONE!


Developer Sign-Up:
- MotherGunner
- elmer
- Black Tiger
- Lochlan
- wyndcrosser
- The Old Rover
- VenomMacbeth
- SamIAm
- Bonknuts / Tomaitheous
- cjameslv
- akamichi
...and one for me makes 12 cards! I'll be manufacturing 16 in case of defects.

UPDATE - All cards have been shipped out. If you encounter any issues with your card or have questions, please PM me or post in this topic.


Manufacturing Tracker Archive:
Since I am manufacturing the cards in "components passes" (i.e. solder the RAM on a group of cards, then the CPLDs), progress will be listed by how many cards have passed a given step in production. I cannot give solid estimates as to when all the cards will be done, but you can watch the list below:
- RAM: 16
- CPLD : 16
- Discrete Components : 16
- Flash : 16

- Verified OK : 13
- Defective / Bad Merchandise : 3


This post will be updated as needed.

[deubeul]

As I'm not aware of the tech things, i'll just say: What you do is great.

[poponon]

HYYYYYYPE

[Dicer]

Whatever it is make sure it has enough bells and whistles so it's the be all end all card, no need for further expansion...

[elmer]

I'd be happy if you'd put me down for one when they're ready!

Actually, I'm interested in both HuCard and SCD development ... HuCard for one smaller project, and SCD/ACD for a bigger one.

From my personal POV, I'd love to see 3MB (however mapped, it doesn't really need to be ACD-compatible).

That would let you simulate the space on an 2MB ACD and still have 1MB to give extra development space. But realistically ... that environment can just be simulated on Mednafen and then run on a real Arcade Card ... so it's a distraction that you would be better to ignore.

The 1MB sounds like it will do absolutely everything that both new SCD development and SCD translations need ... and I think that it's more important to fulfill those 98% of wishes rather than over-specify and never get it done.

Whatever it is make sure it has enough bells and whistles so it's the be all end all card, no need for further expansion...

The way that it's looking, the things that it wouldn't do are Arcade Card and Street Fighter ... and putting in either of those would likely stall the project to the point where it never gets done.

I'd personally rather have what's been talked about and then pay for an upgraded version at some time in the future, if there's enough demand to ever produce one.

[seieienbu]

Ideally I'd like for a new system card to support Arcade Card titles as well.

[Psycho Punch]

The name is misleading, this isn't stupid at all.

People that are planning homebrews for that card, will they come with the systemcard bundled with it just like Games Express' software? I know this is primarily for PCE translations but it doesn't hurt to ask.

[Dicer]

The way that it's looking, the things that it wouldn't do are Arcade Card and Street Fighter ... and putting in either of those would likely stall the project to the point where it never gets done.

I'd personally rather have what's been talked about and then pay for an upgraded version at some time in the future, if there's enough demand to ever produce one.

Why are these sticking points exactly?!?!

[TailChao]

From my personal POV, I'd love to see 3MB (however mapped, it doesn't really need to be ACD-compatible).

That would let you simulate the space on an 2MB ACD and still have 1MB to give extra development space. But realistically ... that environment can just be simulated on Mednafen and then run on a real Arcade Card ... so it's a distraction that you would be better to ignore.

The 1MB sounds like it will do absolutely everything that both new SCD development and SCD translations need ... and I think that it's more important to fulfill those 98% of wishes rather than over-specify and never get it done.

Ideally I'd like for a new system card to support Arcade Card titles as well. 

I left out Arcade Card support for the following reasons:
*It needs a larger CPLD
*The majority of the library is Super CD / 3.0 games.
*I am not fond of its "enhancements" (extra memory is accessed through a window rather than directly).

However, I can change the amount of RAM on the CD Stupid Card to 2MB (just adding a second SRAM chip and extra banking bit), if it's actually useful to people. But this will obviously raise the card cost.

[NecroPhile]

The name is misleading, this isn't stupid at all.

I assumed it was named after me.  Tres flattering.   

[Opethian]

Ideally I'd like for a new system card to support Arcade Card titles as well. 

there is no shortage of arcade cards there is no reason to implement this or SFII' support

[esteban]

I hope the tech gurus share their thoughts soon...

As a mere layperson, I am hopeful...

[poponon]

Ideally I'd like for a new system card to support Arcade Card titles as well.

Agreed!! This'll save some of us from having to shell out for the new v2 turbo everdrive as well.But I'll be ecstatic regardless of what you guy's release!!!

 Would you guys consider also posting about this on other forums ? I'm sure there are a lot more people out there that'd be interested in this thing.

[seieienbu]

I left out Arcade Card support for the following reasons:
*It needs a larger CPLD
*The majority of the library is Super CD / 3.0 games.
*I am not fond of its "enhancements" (extra memory is accessed through a window rather than directly).

However, I can change the amount of RAM on the CD Stupid Card to 2MB (just adding a second SRAM chip and extra banking bit), if it's actually useful to people. But this will obviously raise the card cost.

If it's too much of a hassle then by all means leave it out.  There aren't that many games that use it and I figure at this point most people who want one have one.

I just think it'd be cool to have a single system card that would play all (not counting the pr0n-o cd games, I guess) CD games, translations, etc.  Between this new system card and an everdrive It would be easier to start Obeying with reckless abandon as you'd have (almost) the entire library available without even having to worry about region compatibility.

[ccovell]

A cheat menu that works off of the top IRQ vectors would be what I'd want... perhaps this could have a flash ROM region for customization.  If the IRQ vectors aren't enough for games, then some hardware monitoring of the pins on the HuCard might work.

That's my blue-sky "enhancement".

[elmer]

A cheat menu that works off of the top IRQ vectors would be what I'd want... perhaps this could have a flash ROM region for customization.  If the IRQ vectors aren't enough for games, then some hardware monitoring of the pins on the HuCard might work.

That's my blue-sky "enhancement".

You may have missed the other thread, but I think that you're already getting what you want.

My understanding from that thread is ...

There will be flash, but it won't be in-system-programmable.
The bottom 512KB will be switchable from flash to RAM ... so just load up whatever modified BIOS with whatever vectors you like into that RAM.

There's your cheat menu.

Would you guys consider also posting about this on other forums ? I'm sure there are a lot more people out there that'd be interested in this thing.

Did you miss the bit about TailChao kindly offering to maybe make 25 or so of these for developers?

He's not proposing a mass-manufacturing run ... it's a bit too early to want more interest.

[TailChao]

If it's too much of a hassle then by all means leave it out.  There aren't that many games that use it and I figure at this point most people who want one have one.

I just think it'd be cool to have a single system card that would play all (not counting the pr0n-o cd games, I guess) CD games, translations, etc.  Between this new system card and an everdrive It would be easier to start Obeying with reckless abandon as you'd have (almost) the entire library available without even having to worry about region compatibility.

I can totally understand the desire to have everything on one card, but the arcade card features exponentially increase the complexity of this project. I think you'll agree that it's easier just to try and keep the cost of the CD Stupid Card under $40.

A cheat menu that works off of the top IRQ vectors would be what I'd want... perhaps this could have a flash ROM region for customization.  If the IRQ vectors aren't enough for games, then some hardware monitoring of the pins on the HuCard might work.

That's my blue-sky "enhancement".

It depends upon how you want the cheat feature to work.
To be clear, the 512KB of flash on the card only has the lower 256KB used for the patched Super System Card BIOS. The upper 256KB is completely empty and you are free to make your own "Cheat BIOS" or whatever BIOS you want. However, this requires a chip programmer (I am happy to supply the 39F040 as a socketed DIP, but I cannot make it easily programmable through the cartridge slot without dropping dual region support).

You can also load your own patched cheat BIOS via CD into the lower 512KB of RAM, then switch into 1MB Linear RAM mode, which does not require a chip programmer. This is pretty much the cool mode, since you could literally load a HuCard from the CD, then layer cheats / patches on top of it.

Edit: Elmer basically got it.

[poponon]

Did you miss the bit about TailChao kindly offing to maybe make 25 or so of these for developers?

He's not proposing a mass-manufacturing run ... it's a bit too early to want more interest.

Ah yeah I'm jumping the gun. Too excited to see how the project turns out.

[elmer]

However, I can change the amount of RAM on the CD Stupid Card to 2MB (just adding a second SRAM chip and extra banking bit), if it's actually useful to people. But this will obviously raise the card cost.

From what I can see, you've got 2 different groups of developers that this card will apply to ...

1) The translation guys.
2) The new development guys.

From what I've seen in the translation discussions, they're not going to need more than 1MB. They're targeting SCD, and 512KB-more-than-an-SCD is plenty for them to solve their space problems.

2MB that isn't compatible with an Arcade Card is unlikely to help them with any ACD games or ACD-enhanced games.

From my POV when looking at new development ... I have 4 specific games in mind, of which I'll try to pick 2, or maybe 3 to actually do (1 starter project, and 1 how-good-can-I-make-it project).

The 2 smaller games should run with either 1MB HuCard or your 1MB enhanced SCD card.

The 2 larger games are only going to be possible (at the moment) with the extra memory of an Arcade Card.

If you can put 2MB RAM on board, then 2MB+64KB (your card) is so close to 2MB+256KB (Arcade Card), that I'd definitely make the game(s) run with your card as an alternative to the Arcade Card.

For new development, I'd think that putting 2MB on your card should make it a viable target for anyone wanting to make Arcade Card games.

In my very personal opinion, I think that the cost of the extra 1MB would be worth it as an investment into encouraging future development ... but I can easily see others disagreeing and just wanting the cheapest card possible for encouraging future translations.

Now, when it comes to the technical details of actually accessing the memory, my 'druthers as a programmer would be ...

• The bottom 256KB or 512KB region is write-protected so that existing games won't screw up the BIOS-in-RAM with writes.
• Have a bit to flip somewhere to switch the bottom 512KB between either flash or the bottom 512KB bank of RAM
• Have another 1 bit (if 1MB) or 2 bits (if 2MB) to select which of the 2-or-4 512KB banks of RAM is seen in the top 512KB region of the cart ... that would specifically include the 512KB bank that is used to replace the flash.
• Optional, but not-at-all-necessary, would actually be 1-or-2 bits to select which bank of RAM appears in the low 512KB region to replace the flash.

There you go ... that's my unasked-for wish-list specification! 

[TailChao]

For new development, I'd think that putting 2MB on your card should make it a viable target for anyone wanting to make Arcade Card games.

In my very personal opinion, I think that the cost of the extra 1MB would be worth it as an investment into encouraging future development ... but I can easily see others disagreeing and just wanting the cheapest card possible for encouraging future translations.

I'm totally cool with putting 2MB instead of 1MB, it's only an extra $7 and there should be room on the PCB. However to address your list:

• The bottom 256KB or 512KB region is write-protected so that existing games won't screw up the BIOS-in-RAM with writes.

I think this is kind of moot, since we should be able to get decent compatibility with whatever patched System Card 3.0 is included on Flash, and that is write protected anyway. Either the simple one I released or whatever you guys come up with later.

• Have another 1 bit (if 1MB) or 2 bits (if 2MB) to select which of the 2-or-4 512KB banks of RAM is seen in the top 512KB region of the cart ... that would specifically include the 512KB bank that is used to replace the flash.

The current card should already do what you want. The upper 512KB (RAM) is split into a selectable bank (lower 256KB) and fixed bank (upper 256KB). It's just in 256KB chunks instead of 512KB (which would be cumbersome).

• Have a bit to flip somewhere to switch the bottom 512KB between either flash or the bottom 512KB bank of RAM
• Optional, but not-at-all-necessary, would actually be 1-or-2 bits to select which bank of RAM appears in the low 512KB region to replace the flash.

This would require mapping some controls into the upper region of the address space, which I would rather leave alone. Having all mapper operations work by trapping ROM writes is very safe, and uses less pins. Unfortunately this limits linear 1MB mode to just 1MB.
What I can do is change the modes to operate as follows:

• Startup Mode (512KB ROM + Banked RAM) keeps the ROM as-is in the lower 512KB of the cartspace. The 256KB selectable RAM bank can be set to anywhere in the 2MB range, and the 256KB fixed RAM bank is set to the highest 256KB page.
• 1MB linear RAM mode uses the lower 1MB.

Does that work for you? Or do you need more than one 256KB selectable page of RAM at once?
I can see if we have enough register space left to map out the upper 256KB of Flash and replace it with a second selectable RAM bank if it's absolutely needed.

[elmer]

Does that work for you? Or do you need more than one 256KB selectable page of RAM at once?
I can see if we have enough register space left to map out the upper 256KB of Flash and replace it with a second selectable RAM bank if it's absolutely needed.

Cool, I have a bit better understanding of where you're coming from.   

So the 1MB linear mode is targeted at running HuCard images, and is also potentially useful for the translation guys who want to load a totally custom CD BIOS.

The Startup mode can be used by the translation guys if they don't want to change the BIOS, and can also be used for new development.

The top 512K being split into fixed and bankable 256KB regions is absolutely perfect to me the way that you've described it.

Part of me is saying that I'd really like to have that 256KB-above-the-BIOS area be mapped into RAM if it's not going to cause too much trouble. Having it switchable would certainly be nice, but fixed would also be fine.

I can't say why I'm pushing for that ... I really can't see how it could possibly be an insurmountable problem if it wasn't ... but something somewhere in my head is not letting me just delete the request. 

Will it be possible to switch back-and-forth between "startup" and "linear" modes, or is to going to require a reset once "linear" mode is engaged?

[SamIAm]

I love you guys. Especially TailChao. Thank you so much!

[elmer]

I'm totally cool with putting 2MB instead of 1MB, it's only an extra $7 and there should be room on the PCB.

I don't know what on earth is going on with SRAM pricing, but I was going to point out that there is at least one 2MBx8 SRAM manufacturer out there ... and then I checked Newark's prices and ... ouch!

So 1MBx8 is available for $7 each from the cheap manufacturer, but 2MBx8 is only available from one expensive manufacturer for $21 each.

I'm so glad that there's room on TailChao's board for 2 chips. 

[TailChao]

Part of me is saying that I'd really like to have that 256KB-above-the-BIOS area be mapped into RAM if it's not going to cause too much trouble. Having it switchable would certainly be nice, but fixed would also be fine.

I can't say why I'm pushing for that ... I really can't see how it could possibly be an insurmountable problem if it wasn't ... but something somewhere in my head is not letting me just delete the request. 

Will it be possible to switch back-and-forth between "startup" and "linear" modes, or is to going to require a reset once "linear" mode is engaged?

It is understandable, more banks are nice.
I'll try to implement it, but we are tight on gates because of a few new features...

As for linear mode, once you switch in you're stuck in it until the system is powered down. I do not think this is a big loss though.

I don't know what on earth is going on with SRAM pricing, but I was going to point out that there is at least one 2MBx8 SRAM manufacturer out there ... and then I checked Newark's prices and ... ouch!

So 1MBx8 is available for $7 each from the cheap manufacturer, but 2MBx8 is only available from one expensive manufacturer for $21 each.

I'm so glad that there's room on TailChao's board for 2 chips. 

Component pricing is funny, but yes it's lucky we have room and enough pins.
The chip count is the same as the MCGenjin 4MB Plus board I did a long time ago, so everything should fit fine.

Anyway, *UPDATE!*

• 2MB RAM is a go.
• I've removed the requirement to reverse register writes for "swapped" regions. The only thing that requires this is the region register, and my System Card patches do this for you.
• The 1MB linear mode unlock string is now "HU".

The first post and MCGenjin-CD documentation have been updated appropriately.

[HailingTheThings]

Arcade Card support would be awesome because then I could just use this little guy instead of my Arcade Duo that secretes goopy glue whenever I feel its time to Sapphire?

[TurboXray]

Well.. since you're asking.. lol

 How much room do you have to implement features on the CPLD?

 The arcade card is a big much, yeah? What about two indirect registers? Full 2mb ram mode (only) with an 16bit signed auto incrementor against a 24bit vector address. Two regs (so you can read and write between to ports). Maybe put the ports in in open bus area of the AC region? (the hardware bank) Both having 8bit float parts would be nice too.


 But what I'd really love, but probably isn't doable with your existing setup.. a freaking finer timer interrupt. Something like up to 32khz and could be reset (the counter, so it can be resynced). There an irq on the cart port, so it should be doable. The reason for this? The stupid overhead of using the VDC interrupt to drive a 16khz sample playback. Why the hell didn't the implement a continuous mode where it's generated on every line without having to reload it? Having an external timer interrupt at 32khz should work, AFAIK because the phase drift isn't that great inside the frame and simply resetting/resyncing it ever vblank solves anything beyond that.

 But really, 2mbyte of ram is lot. I'd love access to that for new dev and whatever (I do both). The only concern is the availability. I don't care about price too much per se, but if I made something for this (this amount of memory), I'd love to be able to have people purchase this card.. somehow.

 Anyway, put me down for an order.

[SamIAm]

Put me down for an order as well.

[TailChao]

How much room do you have to implement features on the CPLD?

The EPM7032 we're using is 36 macrocells, not that big at all. But our real limit is pinning.
I'd like to keep the PLCC44 footprint for the mapper since anything larger would likely require a 4-layer board. We could move to an EPM7064 for more gates, but this basically rules out any features requiring fetch address manipulation.

Your timer might actually be doable if I can fit an oscillator on the board and sacrifice the indicator LEDs. Will let you know.

That said, I added Elmer's request for a second RAM bank at $40000 - $7FFFF this morning. You can optionally disable the flash in this region and then get this new feature. I'll hold off on updating the first post pending any other features that might be added in soon.

But really, 2mbyte of ram is lot. I'd love access to that for new dev and whatever (I do both). The only concern is the availability. I don't care about price too much per se, but if I made something for this (this amount of memory), I'd love to be able to have people purchase this card.. somehow.

Yes, now you can finally just have hugeass MUL, DIV, SQRT, and ARCTAN tables for CD games and not care about it!

As for manufacturing, I wish I could go through with a huge run of these on real plastic HuCards. But again, you guys will get all the mapper verilog and board gerbers for making more cards if they're ever needed.

Of course, once the feature set is finalized we should also add proper support to Mednafen as well.

[elmer]

That said, I added Elmer's request for a second RAM bank at $40000 - $7FFFF this morning. You can optionally disable the flash in this region and then get this new feature.

Wow ... and optional, too ... that's absolutely perfect! Thanks!

But what I'd really love, but probably isn't doable with your existing setup.. a freaking finer timer interrupt. Something like up to 32khz and could be reset (the counter, so it can be resynced). There an irq on the cart port, so it should be doable. The reason for this? The stupid overhead of using the VDC interrupt to drive a 16khz sample playback. Why the hell didn't the implement a continuous mode where it's generated on every line without having to reload it? Having an external timer interrupt at 32khz should work, AFAIK because the phase drift isn't that great inside the frame and simply resetting/resyncing it ever vblank solves anything beyond that.

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 

[ParanoiaDragon]

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:
https://www.pcengine-fx.com/forums/index.php?topic=15488.15

[TurboXray]

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

https://www.pcengine-fx.com/forums/index.php?topic=15488.15

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

[TurboXray]

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!*

• Second RAM bank select has been added
• Upper 256KB of flash may be optionally swapped out to use this

I've updated the mapper documentation in the first post to reflect these new features.

[elmer]

Of course... *UPDATE!*

• Second RAM bank select has been added
• Upper 256KB of flash may be optionally swapped out to use this

I've updated the mapper documentation in the first post to reflect these new features.

Excellent, thank you! 

[OldRover]

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

[TurboXray]

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

• Choose to ignore this card.
• Choose to use it only during development to make things easier.
• Make it "optional" for the translated game.
• Make it "required" for the translated game.

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.

[SkyeWelse]

Thank you for clarifying that Elmer. That makes sense to me. It would likely have to be in the hands of developers for awhile before any real decisions or processes would be made as to whether the card would be required or not.

And if that's the case, perhaps there would be enough support at that time for TailChao to make another batch. I'm definitely considering getting a Turbo EverDrive 2.0 at the very least. I'm trying to follow along with what SamIAm mentioned in the post directly after yours about the Stupid Card 4.0 and EverDrive 2.0 being compatible, but I'm a bit lost on that since you could only have one card inserted in the HuCard bay at one time right? Unless there is a slot expander hardware that I don't know about. I may be over thinking things here... but it I'm trying to get on the same page as the rest of you.

-Thomas

[SamIAm]

I mean that it would be nice if people could use a Turbo Everdrive 2.0 instead of the Stupid Card 4.0, not both of them together. In other words, if you bought an Everdrive, you wouldn't have to also buy the 4.0 card to play the translations or homebrew games that are made for it.

Both cards are hooking up a huge chunk of RAM to the system through the hucard port. However, if they are designed too differently, it might not be possible for hackers/developers to use that RAM in the same way for each card.

[elmer]

I mean that it would be nice if people could use a Turbo Everdrive 2.0 instead of the Stupid Card 4.0, not both of them together. In other words, if you bought an Everdrive, you wouldn't have to also buy the 4.0 card to play the translations or homebrew games that are made for it.

Remember ... we still don't know yet if the TED2's RAM will be CPU-writable. For me, that's the big question.

His primary audience is obviously people that are playing HuCard images.

So we can be 99.9% sure that it will be able to do 1MB "linear" mode. But we still don't know if you'll be able to write to any of that memory.

If the translation guys stick to the Stupid Card's "linear" mode, then their stuff should be compatible with the TED2 ... that's if his memory is CPU-writable. Did I mention that we don't know about that, yet?

For any of us guys contemplating using the 2MB in "Standard Mode" ... I'd be very, very surprised indeed if the TED2 is even remotely compatible.

More likely, is that it would support the Street Fighter mapping scheme ... but (let's all stand up and say it ...) we still don't know if it's going to be CPU-writable.

If it is writable, and does support the Street Fighter mapper ... then you'll probably find that developers can make any newly written game work on either the Stupid Card, or the TED2.

It would just be a bit of a programming pain to support the TED2, Stupid Card, and possibly Arcade Card.

Would this be the time to mention my old post in the original "System Card Dreams" thread that suggested that the translators just move forward with the 1MB MCGenjin that's already supported in Mednafen ... and that the rest of us cool it a little bit until the TED2 comes out? 

Having said which ... I'd still really like one of these for development, whatever happens with the TED2. Combine the Stupid Card with a USB-based Develo-board and you've got a really nice development system.

[SamIAm]

Yeah, the whole idea is to make things easier for hackers/developers, so I wouldn't want to defeat that by asking them to take extra time and make custom versions for both the TED2.0 and the Stupid Card.

Still, as soon as the time is right, somebody should really contact krikzz with details about the Stupid Card. You can be sure that he is working on finalizing the TED2.0 right now, so it's a really good time to let him know.

[shubibiman]

Whatever comes out of this will be good. I can't wait to see it happen and then being used for homebrew.