PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: TailChao on March 03, 2015, 05:03:14 AM
-
As discussed here (http://www.pcenginefx.com/forums/index.php?topic=18629.0), 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:
;*************************************************************
; !!!!---- 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 (http://karnovssecretclub.com/Zip/HuPatch/Readme.txt).
* Super CD-ROM DERP v3.6 (http://www.tailchao.com/TurboGrafx/CDERP-SYS/Super CD-ROM System (J, v3.6).ups) - 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 (http://www.tailchao.com/TurboGrafx/CDERP-SYS/Stupid CD-ROM System (J, v4.1).ups) - Version for the CD Stupid Card. Not 100% compatible with Mednafen.
Resources to make your OWN CD Stupid Cards:
Are all available here (http://www.tailchao.com/TurboGrafx/index.php#CD_Stupid).
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 (http://tailchao.com/TurboGrafx/index.php#TurboGrafx_CD_Stupid)). 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.
-
As I'm not aware of the tech things, i'll just say: What you do is great.
-
HYYYYYYPE
(http://1.bp.blogspot.com/-vpE6uMJ37dk/UOScrne47aI/AAAAAAAAEL4/Ki-4IWO-SoY/s1600/ron-paul.gif)
-
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...
-
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.
-
Ideally I'd like for a new system card to support Arcade Card titles as well.
-
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.
-
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?!?!
-
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.
-
The name is misleading, this isn't stupid at all.
I assumed it was named after me. Tres flattering. (http://pcengine.freeforums.org/images/smilies/Hany-Walking.gif)
-
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
-
I hope the tech gurus share their thoughts soon...
As a mere layperson, I am hopeful...
-
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.
-
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.
-
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".
-
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.
-
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.
-
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.
-
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 ...
[ul][li]The bottom 256KB or 512KB region is write-protected so that existing games won't screw up the BIOS-in-RAM with writes.[/li][li]Have a bit to flip somewhere to switch the bottom 512KB between either flash or the bottom 512KB bank of RAM[/li][li]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.[/li][li]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.[/li][/ul]There you go ... that's my unasked-for wish-list specification! :wink:
-
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:
[ul][li]The bottom 256KB or 512KB region is write-protected so that existing games won't screw up the BIOS-in-RAM with writes.[/li][/ul]
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.
[ul][li]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.[/li][/ul]
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).
[ul][li]Have a bit to flip somewhere to switch the bottom 512KB between either flash or the bottom 512KB bank of RAM[/li][li]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.[/li][/ul]
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:
[ul][li]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.[/li][li]1MB linear RAM mode uses the lower 1MB.[/li][/ul]
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.
-
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. :-k
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?
-
I love you guys. Especially TailChao. Thank you so much!
-
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. :wink:
-
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. :-k
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. :wink:
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!*
[ul][li]2MB RAM is a go.[/li][li]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.[/li][li]The 1MB linear mode unlock string is now "HU".[/li][/ul]
The first post and MCGenjin-CD documentation have been updated appropriately.
-
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?
-
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.
-
Put me down for an order as well.
-
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.
-
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! :D
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 :-k
-
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
-
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 :-k
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).
-
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!". :wink:
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.
-
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.
-
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.
-
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!
-
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).
-
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! :wink:
"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".
-
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.
-
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! :D
-
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...
-
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.
-
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
-
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! :wink:
-
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".
-
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.
-
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
-
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.
-
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? :wink:
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.
-
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.
-
Whatever comes out of this will be good. I can't wait to see it happen and then being used for homebrew.
-
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.
I've just posted there to see if he'll tell us his design goals ... but it doesn't mean that he'll respond.
FYI ... he posted pictures of the prototype TED2 cards a while back ...
Version 2.0, dated 2nd Oct 2014.
Version 2.1, dated 22nd Dec 2014.
It looks, to me, like they contain ...
2 x ALVC16424S 16bit 3.3V-5V transceiver
1 x 50MHz oscillator
1 x Lattice/SiliconBlue iCE40HX1K FPGA (1280 logic cells, 64Kbit embedded RAM).
1 x FTDI FT245RL USB2 to parallel FIFO (up to 1MB/sec).
1 x Micron CellularRAM PSRAM MT45W?MW16
either ... MT45W4MW16BGX 4MBx16 (8MB)
or ....... MT45W2MW16BGX 2MBx16 (4MB)
or ....... MT45W1MW16BGX 1MBx16 (2MB)
That's a powerful piece of hardware!
-
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.
My assumption is that the DRAM they used was actually very (s)low grade. Having access limited only to ports means that the DRAM controller has all the cycles in between the actual reads to prefetch or store data.
From what TailChao has said it's already working in Mednafen ... so "yes"
The entire feature set isn't supported (obviously, since we're still designing the card in this thread). Right now you only get 512KB ROM + 512KB RAM using the patch I supplied in the first post since there's enough overlap between the (new) MCGenjin-CD and original MCGenjin mappers.
Luckily it shouldn't be too much work to add MGCenjin-CD emulation once we're finished with the card design and verification. But I will leave that to you guys and the Mednafen author if she wishes to do so.
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.
Exactly, and I'm glad someone picked up on this. While the CD Stupid Card does allow you to use it as an enhanced Super System Card 3.0, it's really just another option for developers.
No one says you have to use it as a system card, you could pull off the BIOS and replace it with something that does bitbanged comms with a PC over the controller port. Then download your test programs to the 2MB of RAM.
FYI ... he posted pictures of the prototype TED2 cards a while back ...
...
That's a powerful piece of hardware!
Yeah, once you start using lower voltage (i.e. modern) components and doing large production runs some really cool stuff can be shoved on that little HuCard form factor.
The FPGA on there is huge though. Maybe the interface will be as nice as the Everdrive N8 where there's literally a bunch of RBFs in a directory which store mapper setups. In that case Stupid Card support will be trivial.
-
Alright everyone, we've hit our feature lock date. Now it's time for me to move on to board layout.
I'll be allocating two weeks for this, and will report progress on Mar 20, then hopefully complete the design by Mar 27.
Thanks everyone for participating in the design phase!
-
FYI ... I just got a reply from KRIKzz on his forums ...
Re: Turbo ED V2 - Questions for fan translations and homebrew.
« Reply #1 on: Today at 05:36:35 PM »
turbo-ed v2 allow to dissable write protection, so, whole onboard ram (4Mbyte) avaialble for developers.
No info on the access method ... but I'd still put money on the Street Fighter method, which is 512KB fixed and 512KB banked. Pretty much perfect for the translators wanting a System Card 3.0 + 512KB RAM.
-
Splendid! The user base for RAM-expansion translations increases!
-
Good, as I sold mine off in hopes of significant enhancements. Redesigning the thing just for load time improvement alone wasn't worth it, so you had to figure he'd add other feature(s) at the very least to help better distinguish it from the previous model.
-
Re: Turbo ED V2 - Questions for fan translations and homebrew.
« Reply #1 on: Today at 05:36:35 PM »
turbo-ed v2 allow to dissable write protection, so, whole onboard ram (4Mbyte) avaialble for developers.
No info on the access method ... but I'd still put money on the Street Fighter method, which is 512KB fixed and 512KB banked. Pretty much perfect for the translators wanting a System Card 3.0 + 512KB RAM.
At least we know the amount of RAM on the card, now.
Personally I'm hoping for some method to reconfigure the FPGA on his cartridge. This is provided on things like the Everdrive N8 where the SD card literally has a folder with different RBFs for different mappers. It's pretty nice for new development (not to mention improving emulation accuracy).
-
Alright, end of the week update-
Attached is the layout status, shouldn't have any issues finishing the routing and dropping on a few more caps by the end of next week.
Edit:
-The large 39F040 is where the BIOS / Whatever ROM'd code you like will be stored. This will be socketed.
-The two LEDs on the top right of the card indicate whether the SWAP and LINEAR modes have been set to simplify debugging.
-
-The large 39F040 is where the BIOS / Whatever ROM'd code you like will be stored. This will be socketed.
Cool!
It's just crazy how the flash chip is so much larger than 2MB ram and the CPLD ... I guess that's why everyone moved to surface-mount.
Is there any chance of a ZIF socket fitting on there for the flash?
Attached is the layout status, shouldn't have any issues finishing the routing and dropping on a few more caps by the end of next week.
It's all that signal strength/coupling and power supply smoothing stuff where you totally lose me.
I'm glad that you're here to do this! :)
-
It's just crazy how the flash chip is so much larger than 2MB ram and the CPLD ... I guess that's why everyone moved to surface-mount.
Is there any chance of a ZIF socket fitting on there for the flash?
Yeah, it's pretty astonishing how much IC sizes have shrunk in the last few decades. There aren't any BGA parts on this board, either. The RAMs are only TSOPII's.
Funny thing is that if I used a smaller package for the flash it would have been way easier to route.
I'm actually not sure if there is enough clearance on the left side of the card to fit a ZIF socket which won't bonk against the card guide in every single PC-Engine variation. What I'd actually recommend is just taking a ZIF socket and then placing it in a wire-wrap socket (which have very long legs). This can then be placed in the board's normal socket and allows you to reuse the ZIF socket in other cards / projects (they're expensive, so I stopped soldering them down years ago).
It's all that signal strength/coupling and power supply smoothing stuff where you totally lose me.
Thing is that for these old machines you rarely have to worry about such things. The data speeds are too low to be super-vulnerable to interference. So what I am doing is really just a glorified connect the dots.
On some of my earlier cards, I had no proper decoupling caps at all. But they still worked.
A good rule of thumb is one small (.1uF-ish) cap per VCC pin on each IC and one larger cap (maybe 10uF) for the whole card. But I'm not going to fret over leaving out one decoupling cap if I can't fit it anywhere.
-
What I'd actually recommend is just taking a ZIF socket and then placing it in a wire-wrap socket (which have very long legs). This can then be placed in the board's normal socket and allows you to reuse the ZIF socket in other cards / projects (they're expensive, so I stopped soldering them down years ago).
That sounds like a great idea ... if a bit ugly.
I guess that in practical reality, there's not a lot of reason to flash anything other than the regular system card bios onto the Stupid Card. The would give maximum compatibility for unmodified games ... and the modified ones just load up whatever changes they want.
I guess that a question that really should be asked is ... does it even make sense to take up your valuable time and energy in actually going ahead and manufacturing these cards at this time?
I'd hate to see you get stuck with a lot of boards and parts.
There doesn't seem to have been a lot of interest from translators/developers looking to use/buy a Stupid Card so far.
The translation guys have already got a Mednafen-capable version of your MCGenjin that they can develop with in preparation for the volume-produced TurboED2 ... and developers like myself are going to find the TurboED2's 4MB RAM and its built-in USB port and SD card to be irresistible draws.
Yeah, it's pretty astonishing how much IC sizes have shrunk in the last few decades. There aren't any BGA parts on this board, either. The RAMs are only TSOPII's.
Funny thing is that if I used a smaller package for the flash it would have been way easier to route.
I've just found out how far the FPGA scene has come ... it looks like it's now possible (and afforable) to emulate complete old computers/consoles in hardware on an FPGA. It looks like there's at least one PCE-on-an-FPGA in development.
There are even people selling things like the MIST board, specifically for retro computing/gaming ...
https://code.google.com/p/mist-board/
There may be a Terasic DE1-SoC in my future sometime soon. The idea of being able to put together a complete computer without having to do any surface-mount soldering is pretty appealing. ...
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=836
-
I guess that in practical reality, there's not a lot of reason to flash anything other than the regular system card bios onto the Stupid Card. The would give maximum compatibility for unmodified games ... and the modified ones just load up whatever changes they want.
For most users, yes.
Personally this is a future investment so I can have a HuSound "loader" to receive SFX, MUS, and PCM packs over the controller port from a PC. My Lynx sound tools allow downloading like this and having the Compile -> Send -> Listen, repeat workflow with real hardware in the loop is pretty nice.
I guess that a question that really should be asked is ... does it even make sense to take up your valuable time and energy in actually going ahead and manufacturing these cards at this time?
I'd hate to see you get stuck with a lot of boards and parts.
I've been thinking the same thing. However, I'm going to make at least a few cards since I want to use them.
Once layout is done for next Friday's deadline, I'll figure out the final cost of the boards and parts and leave this topic open for a "formal" developer sign-up to get a final count. Again, even if this number is zero, I'll still fab a few cards and release all my pertinent work.
I've just found out how far the FPGA scene has come ... it looks like it's now possible (and afforable) to emulate complete old computers/consoles in hardware on an FPGA. It looks like there's at least one PCE-on-an-FPGA in development.
There are even people selling things like the MIST board, specifically for retro computing/gaming ...
https://code.google.com/p/mist-board/
There may be a Terasic DE1-SoC in my future sometime soon. The idea of being able to put together a complete computer without having to do any surface-mount soldering is pretty appealing. ...
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=836
It's really fantastic stuff, isn't it?
I invested in an old Altera DE2 years ago for my own prototyping work, and it's astonishing how much cheaper and more capable FPGAs have gotten. The DE0 Nano and friends are nuts in both price and gate count.
-
Alright, everyone. Layout is completed and it's time for Developer sign-up.
Cards will cost $35/each + shipping and I have listed a component cost breakdown in the first post for those who'd like to manufacture their own cards in the future.
If you're interested in getting a card, please state so AFTER this post (all prior "give me one" posts are ignored). A total of 25 cards are available as first-come first-serve. You may sign up for more than one card.
This sign-up period will be open until April 10th. I will not collect anyone's payment until all cards have been built and tested. Please hold on to your money.
-
Please put me down for one, thanks!
-
Alright, everyone. Layout is completed and it's time for Developer sign-up.
Yay! Thanks for doing this ... one for me, please. :)
-
I would like to get one please. :)
-
I'm tempted to get one. I haven't read every last post on the the features. Is there any advantage to getting this to play currently released games, or completely for upcoming homebrew/translations?
-
I kind of have the same question as ParanoiaDragon. I'm not a PCE developer, or a PCE Romhacker, but if I did decide to work on a project one day with a group here, would it benefit me to have this and would it generally have a benefit for the non-developer at this stage in the development process?
Also, would you plan to produce more batches in the future if it made more sense for non-developers to take a pass on it currently so that it can be used by developers as a priority?
-Thomas
-
I'm tempted to get one. I haven't read every last post on the the features. Is there any advantage to getting this to play currently released games, or completely for upcoming homebrew/translations?
Since this uses the MC Genjin mapper, I'm assuming that you could play the sound roms that TailChao has made for it, if he makes them public, as well as anything else made in the future that uses the mapper to make development easier.
-
I'm tempted to get one. I haven't read every last post on the the features. Is there any advantage to getting this to play currently released games, or completely for upcoming homebrew/translations?
I kind of have the same question as ParanoiaDragon. I'm not a PCE developer, or a PCE Romhacker, but if I did decide to work on a project one day with a group here, would it benefit me to have this and would it generally have a benefit for the non-developer at this stage in the development process?
There is no advantage that I can think of to using this on currently-released games ... they won't even know that it exists.
As for the future ... who really knows?
I honestly can't see any translators making this card a requirement when there are going to be 25 or less of them in existence.
If translators or homebrew-developers decide that they need extra RAM on a PCE, then they can develop for either this card, or for krikzz's mass-produced (but more expensive) Turbo EverDrive 2 ... or both.
That will be entirely up to them.
Also, would you plan to produce more batches in the future if it made more sense for non-developers to take a pass on it currently so that it can be used by developers as a priority?
My understanding is that TailChao has already said that he's not interested in mass-producing these cards in the future ... but that all the plans and schematics necessary to do so will be freely available for anyone that does want to do so.
That's incredibly generous of him ... as is his offer to actually make some of these cards for the people that want them, at what is basically his cost price.
But think about that mass-production run in the future ... who is going to do it?
Do you want to gamble that the community here will get together and commit to an order of 100 cards at say $60-each (if you get someone in China to manufacture them)?
IMHO, unless you're a developer that knows exactly why this card will benefit you ... and what you can use it for right now ... then I suspect that you'd just be taking up TailChao's valuable time and your money in buying a beautiful development card that you'll never use and possibly regret.
Then again ... perhaps in 5 years this will be a must-have "collectable" in it's own right! :wink:
-
IMHO, unless you're a developer that knows exactly why this card will benefit you ... and what you can use it for right now ... then I suspect that you'd just be taking up TailChao's valuable time and your money in buying a beautiful development card that you'll never use and possibly regret.
That is my thought. However, I don't want TailChao sitting on 5-10 cards for a year+ and regretting making 25. I'm holding off showing my support (buying one) for TailChao's efforts until I see his target audience has had their opportunity. Even then I'd just be a caretaker until a developer came along who missed out.
-
TailChao, please sign me up for purchasing one card. Thank you!
-
Ok, I'll hold off for now. I'm hoping these will be helpful & mass produced for the future, depending on who takes up the task.
-
IMHO, unless you're a developer that knows exactly why this card will benefit you ... and what you can use it for right now ... then I suspect that you'd just be taking up TailChao's valuable time and your money in buying a beautiful development card that you'll never use and possibly regret.
This is fairly good advice.
I do not mind manufacturing 25 of these cards for the developer run, nor ending up with leftovers (things break, extras are good to have). But unless you have a specific development paradigm where this card would help, I'd hold off.
Since this uses the MC Genjin mapper, I'm assuming that you could play the sound roms that TailChao has made for it, if he makes them public, as well as anything else made in the future that uses the mapper to make development easier.
Actually, this card uses a new mapper (MCGenjin-CD) which is not 100% compatible with the original MCGenjin (which makes sense, since they're designed for different things). So my sound driver is not compatible (yet).
-
I'm interested. PM me when you want $$. Thanks
-
I'm in... let me know what goes on.
-
I wasn't interested in this initially, but then I read about loading hucard images from CD...and that sounds spectacular. :3 Methinks I will get one when they become available!
-
I wasn't interested in this initially, but then I read about loading hucard images from CD...and that sounds spectacular. :3
They're only going to do that if/when someone writes a small homebrew app to do that (which shouldn't be difficult).
AFAIK, it's not going to be a built-in function ... unless I've missed something, and TailChao or someone else has decided to modify the System Card to do that.
Methinks I will get one when they become available!
Err ... TailChao isn't a shop keeper. He's building a small made-to-order run of these as a favor to the community, and you've got until April 10th to place that order and commit to buying it when TailChao builds it.
Do you want to do that?
-
AFAIK, it's not going to be a built-in function ... unless I've missed something, and TailChao or someone else has decided to modify the System Card to do that.
You're correct, the functionality is not built in aside from the mapper's support for linear mode.
An application to actually load the games would have to be written. I have no plans to do this as of writing.
-
I'm in Japan, so it's going to be slightly trickier to get one of these to me. I might work out a trade with someone. Anyway, please put me down for one. If Bonknuts hasn't ordered one, then put me down for two so I can get one to him.
-
Put me down, i'm in.
-
I would like to join in on this as well.
Thanks.
- akamichi
-
Just bumping this thread up to remind everyone of TailChao's deadline tomorrow.
Last call! Time, gentlemen, please!
-
Alright, update time.
I submitted the PCB gerbers for the fabrication of 30 cards on Wednesday, April 8th. This does not mean that I'll be populating and distributing all 30 of them, just that the PCBs are ordered in batches of 10 and I'd rather have extras than not.
This is my first time ordering PCBs from China rather than doing prototyping here in the USA, so I can't give 100% accurate time estimates. But the factory said the cards would be fabbed in about a week so the rest should be just shipping delays.
The components for 6 cards are already at my home, I'll order the rest once I get the first card working.
Prior to ordering, I reassigned a few pins on the MCGenjin-CD CPLD to ensure the cards will still be fine if my assumptions about write timing are incorrect. (WRn is promoted to a global clock). I've updated the card image on the first post for those who are interested.
During the fabrication gap, I'll be writing a test ROM which will exercise the various features of the card. Once I've gotten the cards working and all that is left is populating the boards for you guys, I'll release all the pertinent development materials: PCB Gerbers, MCGenjin-CD Verilog source + POF, and the card test ROM. I want you all to know exactly what you're getting.
Since I'm not likely to be in front of a computer tonight to "officially close" the developer sign-up, here's our current list:
- MotherGunner
- elmer
- Black Tiger
- Lochlan
- wyndcrosser
- The Old Rover
- VenomMacbeth
- SamIAm
- Bonknuts / Tomaitheous
- cjameslv
- akamichi
-
Thanks for the update! :D
I look forward to hearing how everything works out with the new PCB manufacturer.
-
I think it's too late for asking for one? =;
-
I think it's too late for asking for one? =;
who's alt account is this?
-
My own account, cjameslv. Lost the access from the version without the final '_' so I had to register again :(
-
I think it's too late for asking for one? =;
I won't be able to make a decision to manufacture extras or not until the PCBs arrive from the fab and I've made sure the mapper logic is correct.
I'll PM you if there is a card available.
-
Thank you! :-) I will keep my fingers crossed, feet included.
-
Picked these up at the post office yesterday.
Looks like everything was fabbed properly. The only immediate mistake is actually my fault (I made the pad rows on the RAM footprint a little too close together, but this isn't anything that will break the cards, just complicate soldering).
Luckily the wait gave me enough time to get my test program finished and fix my Turbo CD (the seek gear finally shredded itself, quite lucky that we're able to order new ones). I'll try and get the first card up and running, passing the test program, and playing Gradius II by May 8th. Then it's time to manufacture everything for you guys.
-
Picked these up at the post office yesterday.
Thanks for the update, they look really cool! I can't wait to get one in my hands. :)
-
OMG, WANT! :O
-
How is it going TailChao? :-)
-
How is it going TailChao? :-)
Very well! Around 11pm last night I finally got to see the two screens attached below.
Quite a relief, as the first card I assembled did not work properly (there is likely a bad solder joint somewhere, the TSOP-IIs SRAMs with curled under pins are a little tricky).
This means that it's resource release time (http://tailchao.com/TurboGrafx/index.php#CD_Stupid), and now I'll be moving forward to manufacturing. Since this will take awhile, and I cannot give a good estimate as to exactly how much, I'll be continuously updating the first post's new "manufacturing tracker" so you can get an idea how things are going.
Before that, though- I'm going to perform a few tests with different speed grade CPLDs and region mods. One concern I have is that the region mod most people use (the one with the analog switches) adds a very large propagation delay, which could cause the card to not work properly. I'll keep you all posted.
-
Very well! Around 11pm last night I finally got to see the two screens attached below.
Quite a relief, as the first card I assembled did not work properly (there is likely a bad solder joint somewhere, the TSOP-IIs SRAMs with curled under pins are a little tricky).
Excellent news! :D
Did you always intend to curl the pins under the chip, or was that a cunning solution to ...
The only immediate mistake is actually my fault (I made the pad rows on the RAM footprint a little too close together, but this isn't anything that will break the cards, just complicate soldering).
-
Did you always intend to curl the pins under the chip, or was that a cunning solution to ...
The only immediate mistake is actually my fault (I made the pad rows on the RAM footprint a little too close together, but this isn't anything that will break the cards, just complicate soldering).
It was the latter. But I always intended to have the NC pins removed during assembly since it greatly simplifies layout.
As an aside, I've finally *removed* the region mod in my TG16 since this card now takes care of the only reason I installed it in the first place. However, during that process I did a few quick checks as to how the CD Stupid Card and a real System Card 3.0 react to different propagation delays (either due to wire length or the MC14551s). They both start to fail around the same time (especially with the MC14551s driven with a 5V supply), so I'm not too worried. But I'll still order the 6ns CPLDs and see if things improve (we're using 15ns right now).
The TG16 has verrry long dataline traces on its mainboard and can be a real jerk in regards to signal integrity. The unmodded white PCE I have seems to run nearly anything. I imagine you Duo owners never have to think about any of this as everything is condensed on one board.
-
Just signed just because of this. I am in. *happy*
Gesendet von iPhone mit Tapatalk
-
Alright, I just found something seriously messed up:
The reset timing on the PCE and TG16 is different, in that the TG16 will occasionally have the CPU released from reset long before the signal rises on the HuCard slot.
This was causing the mapper to occasionally miss its first write (which sets the operating region) on the TG16. Putting a delay there will solve the problem, and I'll be flashing the patched System Card BIOS with the predelay added for the developer cards.
I guess this explains why some owners see different behavior among different consoles.
If any of you want to make your own mappers, this definitely needs to be kept in mind.
-
Just signed just because of this. I am in. *happy*
Well done ;-)
Tailchao: Very good news indeed, and an interesting find.
-
Hi TailChao ... any news?
I've been way distracted with the PC-FX, but I'm really looking forward to getting to use with the Stupid Card when it's released!
-
Hi TailChao ... any news?
I've been way distracted with the PC-FX, but I'm really looking forward to getting to use with the Stupid Card when it's released!
I've been on vacation for the past week and haven't had access to my soldering equipment, so things are Frozen until next Monday.
However, the batch of six cards I have been working on (see the status tracker in the first post) are nearly done. They just need their Flash sockets soldered on and I can test them out. The parts have already arrived for the second batch of eight cards, so I should be able to start those immediately after.
Assuming at least 12 of the 16 cards I'll be assembling work 100%, they'll likely be shipped out around July.
Edit: I've also decided to socket the CPLD on every cartridge, not just the flash chip. This simplifies repairs if needed and also will let you reprogram the mapper.
By the by, nice work on Zeroigar.
-
Edit: I've also decided to socket the CPLD on every cartridge, not just the flash chip. This simplifies repairs if needed and also will let you reprogram the mapper.
Excellent news ... I hadn't seen the progress updates in the first post, and now I know to look for them.
I like the idea that it's going to be socketed ... that might allow for some interesting tricks down the line.
You've come up with a really cute way of doing a multi-region card ... but I'd happily give up the multi-region aspect if I could think of something else cool to do with all of those gates inside the CPLD! :wink:
By the by, nice work on Zeroigar.
Thanks. :D
-
i found when working with the gameofyou flash cart that some configurations were so late on the reset pin going high that it wouldnt work
easy solution was simply to ignore the system reset pin (dont know how that would effect your project)
-
You've come up with a really cute way of doing a multi-region card ... but I'd happily give up the multi-region aspect if I could think of something else cool to do with all of those gates inside the CPLD! :wink:
Haha ... my little head is spinning ... apparently the larger EPM7064 CPLD is pin-compatible with EPM7032 CPLD that TailChao is using ... so perhaps a fast multiply could be added, or maybe fast pixel packing/unpacking.
Both of those would be nice for software-3D.
I'm definitely going to have to do some research on this! :D
-
i found when working with the gameofyou flash cart that some configurations were so late on the reset pin going high that it wouldnt work
easy solution was simply to ignore the system reset pin (dont know how that would effect your project)
Since the MCGenjin-CD can change the card memory map drastically, I need to clear the registers associated with this at reset and I'd rather not do this with an additional RC circuit on the card. The lucky thing is that ROM reads are allowed while RESETn is low, so I just added a stall loop before the first write to the mapper (system region) is performed.
Interestingly enough, the original MCGenjin mapper wouldn't permit ROM reads until RESETn had risen. But its complexity (and gate pushback) was much lower and hid this behavior. Or maybe the CPU was just wandering around the open bus until RESETn rose. Whatever, at least now the behavior is known.
Haha ... my little head is spinning ... apparently the larger EPM7064 CPLD is pin-compatible with EPM7032 CPLD that TailChao is using ... so perhaps a fast multiply could be added, or maybe fast pixel packing/unpacking.
Both of those would be nice for software-3D.
I'm definitely going to have to do some research on this! :D
I actually just logged in to post about that chip. However, I don't think you'll be able to fit a multiplier in it, 64 macrocells isn't that big. The EPM7096 for my Atari 7800 project's mapper is quite full, and the most elaborate thing it is doing is graphic fetch trapping.
But there are many other CPLDs to use if you're willing to wire up your own prototypes. The point is that it's very easy (and affordable) to hardware our way out of problems.
It should also be kept in mind that the MAX 7000 series is now obsolete. I continue to use them since I found several tubes in the garbage in the early 2000s. So it may be good to investigate other options.
-
I actually just logged in to post about that chip. However, I don't think you'll be able to fit a multiplier in it, 64 macrocells isn't that big. The EPM7096 for my Atari 7800 project's mapper is quite full, and the most elaborate thing it is doing is graphic fetch trapping.
But there are many other CPLDs to use if you're willing to wire up your own prototypes. The point is that it's very easy (and affordable) to hardware our way out of problems.
Awwww ... damn!
I've been too busy with other stuff to play with the Altera DE2 devkit that I bought, and so still have little idea of just how powerful a typical "macrocell" is.
Unfortunately, I'm a software guy, not a hardware guy ... the idea of soldering all those little wires makes me run away and hide behind the couch!
-
Update time, I'm about a third of the way through manufacturing.
8/16 Cards have been built, and 5/8 of those cards are working properly. The remaining three are having issues, but at least two will likely be salvageable (one doesn't boot, one's upper 1MB RAM is bad, and ones's lower 1MB is bad).
I'll start the second run of 8 cards next week, after that I'll go back and rework any cards that didn't work on the first try.
-
Am I already on the list? I can pay in advance if needed!
Gesendet von iPhone mit Tapatalk
-
Am I already on the list? I can pay in advance if needed!
Gesendet von iPhone mit Tapatalk
Unfortunately, you didn't make the list before the deadline closed.
However, I'm keeping track of everyone who has posted that they're interested in buying a card after said deadline ended. If I have extra cards after taking care of the twelve on the list (including a card for me), I'll PM you.
There is a good chance you may get a card since I'm manufacturing 16 cards and we'd have to have four completely defective ones to not have extras. But again, no guarantees.
-
Update time, I'm about a third of the way through manufacturing.
8/16 Cards have been built, and 5/8 of those cards are working properly. The remaining three are having issues, but at least two will likely be salvageable (one doesn't boot, one's upper 1MB RAM is bad, and ones's lower 1MB is bad).
Arrrggghh ... that's what scares me about trying to put together today's tiny little electronic components.
Thank you again for going through all this hard work to put these together! :D
But there are many other CPLDs to use if you're willing to wire up your own prototypes. The point is that it's very easy (and affordable) to hardware our way out of problems.
For some reason, I keep on looking at this ... and found the 5-volt Atmel AT40K FPGA. :wink:
-
There is a good chance you may get a card since I'm manufacturing 16 cards and we'd have to have four completely defective ones to not have extras. But again, no guarantees.
Oooooh ... did I just see the number of manufactured cards go up today? :-k
Really looking forward to this!
-
Oooooh ... did I just see the number of manufactured cards go up today? :-k
Yes, only four to go.
Luckily as long as three out of those four work, we're all set and I can get the cards ready for distribution soon.
-
Sorry for the double post, but it's for a good reason.
All 16 cards have been manufactured, of which 13 are working properly. I'll see if I can repair the three defective cards at a later time, but either way enough of the batch works to handle everyone on the list.
I'm going to spend the next week getting these guys ready for shipping and will PM everyone to confirm address and payment method once the cards are packed. (Paypal is preferred, but not required. If you want to trade for hardware, that's cool too).
The modified CD System 3.0 firmware on the card now includes a large delay to account for the varying RESETn rise times in NEC's hardware. All cards were tested in my TurboGrafx+CD, Turbo Express, and White PCE. Duo owners should be fine, but if anyone encounters issues on their system I'd like to figure out why.
The only thing I cannot guarantee compatibility with is systems which have the electronic region mod (using the MC14551s), as this adds a large amount of propagation delay to the system bus.
Anyway, the cards are very simple to use and aside from the "CD SYSTEM CARD DERP 4.0" present on the startup screen will operate just like a Super System Card, so you may enjoy a session of Star Parodier among whatever development you're doing.
When developing your own software, the two LEDs will become quite helpful. D1, the top LED, indicates whether or not the system region register has been written to. This is done automatically at startup by the card firmware, but should be kept in mind if you plan on writing your own bootloader or whatever. D2, the lower LED, indicates when the card has switched into linear mode.
Other than that, it's a fairly normal development PCB. Practice care when handling.
-
Excellent!!!! :D
-
One left for me?
Gesendet von iPhone mit Tapatalk
-
One left for me?
I'll PM you if there are any left after distributing the cards to everyone who made it on the list :).
There's always a chance (albeit slim) that someone's card could get smashed in the mail, and I need to keep the few extras I have put aside in case that happens.
-
My Stupid Card arrived today and it came in a package with some very nice artwork on the back.
(http://superpcenginegrafx.net/misc/derp1.jpg)
Here is the card itself:
(http://superpcenginegrafx.net/misc/derp2.jpg)
It comes loaded with Derp 4.0 System:
(http://superpcenginegrafx.net/misc/derp3.jpg)
-
(http://superpcenginegrafx.net/misc/derp1.jpg)
Percy!
-
Here is the card itself:
(http://superpcenginegrafx.net/misc/derp2.jpg)
OK who wants to volunteer to port Osman to the Stupid Card? The game's name is even printed on the board :lol:
(http://2.bp.blogspot.com/-mQ6XR87x5Zc/U9smL7vtPKI/AAAAAAAAtQo/j4r4PdUCwic/s1600/Osman_(Arcade)_27.gif)
-
OK who wants to volunteer to port Osman to the Stupid Card? The game's name is even printed on the board :lol:
(http://2.bp.blogspot.com/-mQ6XR87x5Zc/U9smL7vtPKI/AAAAAAAAtQo/j4r4PdUCwic/s1600/Osman_(Arcade)_27.gif)
That's my goal! :wink:
But sorry regular PCE guys ... I'm only interested in targeting the SuperGrafx and/or PC-FX. :(
-
Glad to see the cards are making it to their new homes safely. Hopefully no one runs into any weird compatibility issues.
Also, everyone who got on the pre-order list please check your PMs. I sent out a mass mail about two weeks ago and have only heard back from about half of you.
OK who wants to volunteer to port Osman to the Stupid Card? The game's name is even printed on the board :lol:
The sad thing is that I am absolutely rubbish at that quarter game.
-
GODDAMN BEAUTIFUL:
Package
PCB
Tracings
Future Possibilities...
-
Sorry for the bump, but I need to get the six remaining cards out of my apartment. If the following members could contact me it would be appreciated :
- Debvgger_
- Lochlan
- wyndcrosser
- The Old Rover
- VenomMacbeth
- cjameslv
I've sent two PMs to all of you on this list and an email to the address registered to your accounts (if any). These things can get lost, but if you're still interested in completing your purchase of the Stupid Card, please contact me with your address and I'll respond with shipping and payment details.
You're free to cancel the order if you no longer want the card. No hard feelings, I just need an answer.
-
if anybody cancled or you have one spare, i am all in :-)
Gesendet von iPhone mit Tapatalk
-
Same here, I'd get one of those if you get no answer from the other guies ;)
-
Update time.
I'm moving back to the East Coast in November, which involves more packing than I'd like to deal with. There are currently four CD Stupid Cards which have still not been claimed and are sitting on top of my television.
I apologize to the developers who reserved them earlier, but I have waited several months.
They're now up for grabs. If you already bought a card and want to buy another, or all four, that's cool. I just want to see them used.
If you're interested, post below. Again, there are only four cards left and the price is still $35 each plus shipping.
-
I am interested.
-
I am interested. Will pay immediately on confirmation and not leave you hanging...
-
I am interested.
PM Sent, three cards left.
Edit : Two left, now.
-
Pm sent
-
Pm sent
One card left!
-
OK who wants to volunteer to port Osman to the Stupid Card? The game's name is even printed on the board :lol:
(http://2.bp.blogspot.com/-mQ6XR87x5Zc/U9smL7vtPKI/AAAAAAAAtQo/j4r4PdUCwic/s1600/Osman_(Arcade)_27.gif)
That's my goal! :wink:
But sorry regular PCE guys ... I'm only interested in targeting the SuperGrafx and/or PC-FX. :(
I dont think the SGX would be up to it, but the PC FX should be capable of a pretty nice port Osman...would be AWESOME!!!!!
-
If yout can ship to Mexico, I'm interested and ready to pay for shipping with tracking
-
If yout can ship to Mexico, I'm interested and ready to pay for shipping with tracking
PM Sent, and that's all the cards accounted for. :D
I still have the nonworking cards put aside and a few extras just in case. If any of those become available, I'll update this topic.
Thank you everyone for participating in the development of this new accessory :)
-
I have my card. Haven't had a chance to try it out yet though.
-
Received my card today. The envelope was awesome! I will post a picture later.
Tested and working, Thanks again!
-
Just got mine!
Works perfectly on all my systems (Supergrafx, CP Engine, Duo and TG-16). Thanks a lot for your great work.
(http://b0.img.mobypicture.com/983478042d8266a250ea2f0eff8dfb6e_view.jpg)
-
Got my card and artful envelope late last week. Haven't had a chance to test it out yet...
-
I was trying out the card today, and it's too thin to work on my system (too loose). What can I use to put underneath it get a better fit?
-
Maybe a small piece of oak tag might give it enough thickness?
-
Are any of these still available?.. Or did I miss the boat...
-
I was trying out the card today, and it's too thin to work on my system (too loose). What can I use to put underneath it get a better fit?
Ah, my apologies. I guess the card slots have some variation in them.
Anyway, the proper solution is to thicken the layer of hot melt on the bottom of the card. You can use the glue gun's heated nozzle to create a nice angled edge.
A quick workaround is just to fold a piece of paper and insert it in the slot underneath the card. It's easier if you put the paper in first or use sturdy cardstock.
Worst case I can mail you another card.
Are any of these still available?.. Or did I miss the boat...
There were several boats and they've all set sail. However, I am still holding a couple extra cards in case anyone who bought one previously runs into defects. If none of those are required, I'll PM you.
-
Are any of these still available?.. Or did I miss the boat...
There were several boats and they've all set sail. However, I am still holding a couple extra cards in case anyone who bought one previously runs into defects. If none of those are required, I'll PM you.
I'm definitely interested, thank you.
-
Whoops, I forgot to distribute the final version of the CD System DERP 4.0 which was included on everyone's cards.
(By which I mean the the flash somehow arranged itself to resemble this pattern of bits. I had nothing to do with it).
The first post has been updated appropriately, the only difference from the previously available patch was the addition of the predelay in order to work around the TurboGrafx's slow RESETn rise time.
-
Alright, after the inconvenient discovery in this topic. I've prepped two new patched system cards and updated the first post (http://www.pcenginefx.com/forums/index.php?topic=18681.msg396621#msg396621) appropriately.
To summarize - it is possible to enable the internal Super CD RAM in a Duo or SuperCD while a HuCard is inserted. This causes a bus fight, and the internal Super CD RAM will usually win. While this is usually not a huge issue for the Turbo Everdrive or Stupid Card when they're running a normal Super CD game, if the Stupid Card switches into linear mode its RAM contents may differ with the Super CD RAM.
Either way, two devices driving the bus simultaneously is not cool.
I'd like to wait a few weeks to ensure there are no other things which need to be altered. But suggest everyone update if you have a chip programmer handy. Once we've locked down any other changes needed (hopefully none), I'll mail a free replacement flash chip to anyone who doesn't have a chip programmer.
-
as a side note, placing resistors in the data bus can prevent issues caused by a bus fight while determining the winner
-
as a side note, placing resistors in the data bus can prevent issues caused by a bus fight while determining the winner
Yes, but this also distorts the signal. In the case of the TurboGrafx, the bus is already a mess.
The proper solution is to remove the bus fight entirely.
-
i wouldnt say distorts so much as reduces bandwith and eliminates echo
case in point i was recently working on a CDR2 drive and added a resistor in line with the eye pattern signal (digital)
the result was a signal that looked nice on the scope, while no functional difference was found (it got rid of all the ringing in the signal)
-
i wouldnt say distorts so much as reduces bandwith and eliminates echo
That's a better way to put it, yes.
-
Hey everyone,
Sorry to bump this topic - but I've been getting PM requests to sell off the extra CD Stupid Cards I have. This is fine, but before I sell any of these I want to make sure everyone's purchased cards are still working fine (since these extras are effectively the "warranty replacements").
If anything has gone awry with your cards, get in touch with me within the next month.
-
Sorry if it was already mentioned, but I assume this card will not support arcade card pro games? I mean, physically impossible to support?
-
Sorry if it was already mentioned, but I assume this card will not support arcade card pro games? I mean, physically impossible to support?
No worries.
But yeah, this card can't support the mapper used in the Arcade Card (Pro). You'd need a larger CPLD (especially in terms of pin count) in order to handle the paging scheme and extra features it has.
If I design another card maybe that will go in. I'd need to actually buy an Arcade Card and confirm it does what the publicly available documentation says first.
-
What do you recommend to do for a full function test?
Gesendet von iPad mit Tapatalk
-
What do you recommend to do for a full function test?
At minimum, the card should be able to start up and run software. The patched BIOS has to go through enough during initialization that it will hit most features.
If you'd like to be thorough (and have a chip programmer), you can reprogram the flash with the hardware test program (http://tailchao.com/TurboGrafx/CD_Stupid_Test.zip). This is what I used to verify cards before sending them out to everyone. Note that it doesn't have the predelay for the TurboGrafx reset line issue (but the patched system card does), so it may erroneously fail on some TurboGrafx's - but not on a PCE or Duo.
-
Sorry if it was already mentioned, but I assume this card will not support arcade card pro games? I mean, physically impossible to support?
No worries.
But yeah, this card can't support the mapper used in the Arcade Card (Pro). You'd need a larger CPLD (especially in terms of pin count) in order to handle the paging scheme and extra features it has.
If I design another card maybe that will go in. I'd need to actually buy an Arcade Card and confirm it does what the publicly available documentation says first.
Ah, thanks for the info. The reason I ask is because even if arcade card pro support costs more to implement, it would be a better alternative than buying a real one. Mostly because for the money, your card would literally be the last one you will ever need. I really don't relish the idea of paying $100 something for a card that only works for a few games (even if they are good). In addition to the fact that IFU-30 owners have no choice except to get a pro card.
-
Ah, thanks for the info. The reason I ask is because even if arcade card pro support costs more to implement, it would be a better alternative than buying a real one. Mostly because for the money, your card would literally be the last one you will ever need. I really don't relish the idea of paying $100 something for a card that only works for a few games (even if they are good). In addition to the fact that IFU-30 owners have no choice except to get a pro card.
I totally understand.
After having some time to think about it - getting an Arcade Card compatible piece of hardware below the $100 range is absolutely feasible. It really shouldn't cost much more than the CD Stupid Card (for the components anyway). But in order to have everything fit in a HuCard sized space and get a reasonably featured CPLD, we need to drop down to 3.3V components with some level shifters. Then use BGA or other small footprints for everything else. The former (level shifters) aren't a huge issue, but I'm not experienced enough with BGA layout and assembly right now to tackle this.
-
Ah, thanks for the info. The reason I ask is because even if arcade card pro support costs more to implement, it would be a better alternative than buying a real one. Mostly because for the money, your card would literally be the last one you will ever need. I really don't relish the idea of paying $100 something for a card that only works for a few games (even if they are good). In addition to the fact that IFU-30 owners have no choice except to get a pro card.
I totally understand.
After having some time to think about it - getting an Arcade Card compatible piece of hardware below the $100 range is absolutely feasible. It really shouldn't cost much more than the CD Stupid Card (for the components anyway). But in order to have everything fit in a HuCard sized space and get a reasonably featured CPLD, we need to drop down to 3.3V components with some level shifters. Then use BGA or other small footprints for everything else. The former (level shifters) aren't a huge issue, but I'm not experienced enough with BGA layout and assembly right now to tackle this.
Ah, a card under $100 sounds awesome. To be honest, even if it costs more than that I'd still buy one in a heartbeat. Considering how much extra stuff it can do over a real Arcade Card Pro, it's still a swell deal!
It's too bad the Everdrive wasn't designed with this kind of afterthought. If it was extended with a little more features to cover what the Stupid Card does (with support Arcade Card Pro functionality), we wouldn't really be here. Instead of buying three cards (Everdrive, Arcade Card Pro, Stupid Card), we would just need to buy one.
At least if we can get Arcade Card Pro support eventually added to the Stupid Card, it will be clear winner in terms of a cost effective purchase. I don't know about other people, but even if the card ends up being larger than normal Stupid Card version, I'd still be totally cool with getting one. There just isn't anything on the market that addresses this problem, so any solution would be awesome!
-
lets consider for a sec that 3.3v inputs are never an issue and dont require more then a resistor for compatibility on most chips (worst case resistor and diode)
so for arcade pro we would need to read/decode the whole bus, and produce from it chip select lines for ram
we would also need a few registers to respond back to the system
if we use 5V ram, the registers will need level conversion
if 3.3v ram the data lines will need level conversion
a 3.3V regulator can be used, or 2 diodes will suffice to convert 5V to 3.6V
as for a pro card to test, im sure we can come up with a loaner if you are willing
-
I'm definitely interested if one of these is still available.
Thanks for the extra info, steve. I would volunteer my card up for testing if it wasnt buried in storage :D
-
I'm definitely interested if one of these is still available.
Thanks for the extra info, steve. I would volunteer my card up for testing if it wasnt buried in storage :D
Unfortunately, I think all the cards are accounted for unless I can get a few of the botched ones reworked (which won't be soon).
While I'd love to get started on designing a CD-Stupid 5.0 with arcade card compatibility, the biggest obstacle isn't ordering an arcade card but rather engineering time. I've made obligations to ship a game next year and that's already tight. Although afterwards I'd like to take a break or a month or two and maybe then there will be a few opportunities for hardware mischief.
In any case, my notes are available if anyone else would like to try :)