PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: TheOldMan on February 24, 2015, 04:18:50 PM
-
I haz a dream: Someday Arkhan will tell me all of the Alantean boards are done, sold and shipped.
I haz a dream: Arkhan will total everything up, and we will have actually made a small profit...
And it's enough money to develope the new system card....
And he's willing to do that.
I haz a dream: We order prototype boards and all the pieces...
And I put them together without screwing things up...
And they work...
And the bios is reprogrammable, for future changes.
I haz a dream: Bonknuts has time off from school, and decides to work on translations....
And he finishes one using the new system card....
And expands on MegaMan-CD as well.
I haz a dream: With the extra flash space, we start adding useful routines for translations and developement....
And speed up the cd reading routines....
And fix some of the problems in the bios....
And it is still backwards-compatible.
I haz a dream: Other developers look at this, and start other fan translations....
And actually finish them...
And decide to produce pressed cds.
I haz a dream, that tobias sees everything going on, and decides to get 500 copies
of each new translation pressed. He opens up orders and starts taking money....
And then finds out he needs the new system card for them to work :)...
And has to refund everything....
And goes broke :)
Of course, I also have a dream where everyone from the turbo game shows appear at my door to use the bathroom,
piss all over the shower, and my wife says "They're your friends. *You* clean it up....."
-
That's quite a dream. :)
-
The part where Tobias gets f*cked is the best part.
-
Heh, I like your dreams. :mrgreen:
-
(http://s18.postimg.org/j4tzv906h/IHave_ADuo.png)
the dream is real
-
If you're actually serious about this, what kind of features are you looking for in a new system card?
Several years ago I made a custom order cartridge with 512KB of RAM in banks $40-$7F. Aside from the lack of firmware rewritability this was a pretty big improvement over the Super System Card. Ideally you just want enough RAM so you can soft-patch firmware issues anyway.
-
(http://s18.postimg.org/j4tzv906h/IHave_ADuo.png)
the dream is real
Slap on a pair of Air Zonk shades and that would be an amazing shirt.
-
Errr ... shouldn't this wait just a little bit to see what Krikzz comes up with in a couple of months with TED2?
He's already said that it's based on RAM instead of flash.
-
Dreams happen with action and intention. Get off your ass and make it happen ;D
-
Dreams happen with action and intention. Get off your ass and make it happen ;D
Sure ... and if you want to make that dream come true, then IMHO ...
[uldecimal][li]Make the dozen-or-less line modification to Mednafen to emulate 512KB ROM/RAM.[/li][li]Gather together your crew that's going to work on the first translation that uses it.[/li][li]Start development with the modified Mednafen and make sure that you can use the RAM effectively.[/li][li]That's all.[/li][/ul]By that time you've already used up 2-3 months, and you'll know if TED2 will do everything that you need.
If it doesn't, then you've already got a project started, and you've got real motivation to find someone like TailChao that can actually put together a simple ROM/RAM cart ... or perhaps the guys that are doing the AbCard.
It's not that much of a technical challenge ... it's a matter of will.
Jeez ... I'll make the damned mods to Mednafen if they're not already there ... I want them for my own development, and have to screw around inside Medafen anyway to enhance the PC-FX debugging.
-
Slap on a pair of Air Zonk shades and that would be an amazing shirt.
(http://s12.postimg.org/lwndg2vv1/duodreams.png)
Jah feel?
http://printallover.me/products/0000000p-i-have-a-duo?social=true
-
If you're actually serious about this, what kind of features are you looking for in a new system card?
Several years ago I made a custom order cartridge with 512KB of RAM in banks $40-$7F. Aside from the lack of firmware rewritability this was a pretty big improvement over the Super System Card. Ideally you just want enough RAM so you can soft-patch firmware issues anyway.
Your card is exactly what inspired Bonknuts (aka Tom) to want to have this for translation projects.
If you would be willing to share more details about what you did to make that card, that would be wonderful. In another thread (http://www.pcenginefx.com/forums/index.php?topic=18443.msg393603#msg393603), I was talking about putting up money to build some prototypes, and that could be arranged with you if you are interested.
I hope Bonknuts can get in touch with whomever is most interested in making a card and work out the technical details. I'll start bugging him to weight in here.
Errr ... shouldn't this wait just a little bit to see what Krikzz comes up with in a couple of months with TED2?
He's already said that it's based on RAM instead of flash.
If the TED2 does the job, that's wonderful. However, it will be $80 to ship that thing. I don't know, but I wouldn't be surprised if we could ship a custom card for less than $30. I think that would make a big difference in the number of people willing to pay to play our translations.
You're right that any hacker who really wants to can just go ahead and start planning on using extra RAM, though.
It's not that much of a technical challenge ... it's a matter of will.
Yep. We can make it happen. We will make it happen.
-
If you're actually serious about this, what kind of features are you looking for in a new system card?
I'm not looking for any particular features; someone else was talking about needing a few extra pages of RAM for modified/new routines for a translation (Xak II, iirc). I just tried to move the discussion of the modified system card out of the main topic.
shouldn't this wait just a little bit to see what Krikzz comes up with in a couple of months with TED2?
Depends on how he's planning to use the RAM. I think it would be a lot harder to code for than a simple extension to the page mechanism already in place, but I could be wrong.
Dreams happen with action and intention. Get off your ass and make it happen ;D
I'm in no hurry; this is my hobby, not my job.
But for what its worth, I have the board designed already. Just need to get parts to make sure the pad footprints / traces are right, and have the boards made. All that has to go through Arkhan - I don't shop online. And he's waiting to see if we have enough $$ from atlantean to do it.
...or perhaps the guys that are doing the AbCard.
Yep. That would be us :)
I'll make the damned mods to Mednafen if they're not already there....
Do it, and post the changes (and how to re-build everything). Maybe that will inspire people to get some of the translations done.
If you do, would you please let me know where to look in the mednafen source for the cd handling routines? If I can see how it's emulated, maybe I can figure out what is going on with the scsi bus in bios.
BTW, I'm not sure you would actually have to modify mednafen much. You can already write to ROM, and have it change. We were going to add a message based on that to atlantean :)
("Emulator in use")
...........................................................
I wouldn't be surprised if we could ship a custom card for less than $30.
Assuming just 10 cards are made: It's $220+ to make them. The chips and such are about $10.
That would make each card about $35.
But we know from experience, large quantities are the way to go. If you make 50 cards, it's only a bit more expensive - but the cost per card drops dramatically (to around $5, iirc). The majority of the card cost is setup expenses. So yeah, I could see $20 for a card.
You are right, though. We need bonknuts to get some time off school so he can work on this. I honestly think if he were to fix/re-write/extend the bios, this could be a big thing....
-
Yep. We can make it happen. We will make it happen.
damn sam your dedication is really inspiring. I'd really like to help out in some way - I know translators are a dime a dozen but I may be able to help out with spot translations.
-
If you're actually serious about this, what kind of features are you looking for in a new system card?
I'm not looking for any particular features; someone else was talking about needing a few extra pages of RAM for modified/new routines for a translation (Xak II, iirc). I just tried to move the discussion of the modified system card out of the main topic.
shouldn't this wait just a little bit to see what Krikzz comes up with in a couple of months with TED2?
Depends on how he's planning to use the RAM. I think it would be a lot harder to code for than a simple extension to the page mechanism already in place, but I could be wrong.
Dreams happen with action and intention. Get off your ass and make it happen ;D
I'm in no hurry; this is my hobby, not my job.
But for what its worth, I have the board designed already. Just need to get parts to make sure the pad footprints / traces are right, and have the boards made. All that has to go through Arkhan - I don't shop online. And he's waiting to see if we have enough $$ from atlantean to do it.
...or perhaps the guys that are doing the AbCard.
Yep. That would be us :)
I'll make the damned mods to Mednafen if they're not already there....
Do it, and post the changes (and how to re-build everything). Maybe that will inspire people to get some of the translations done.
If you do, would you please let me know where to look in the mednafen source for the cd handling routines? If I can see how it's emulated, maybe I can figure out what is going on with the scsi bus in bios.
BTW, I'm not sure you would actually have to modify mednafen much. You can already write to ROM, and have it change. We were going to add a message based on that to atlantean :)
("Emulator in use")
...........................................................
I wouldn't be surprised if we could ship a custom card for less than $30.
Assuming just 10 cards are made: It's $220+ to make them. The chips and such are about $10.
That would make each card about $35.
But we know from experience, large quantities are the way to go. If you make 50 cards, it's only a bit more expensive - but the cost per card drops dramatically (to around $5, iirc). The majority of the card cost is setup expenses. So yeah, I could see $20 for a card.
You are right, though. We need bonknuts to get some time off school so he can work on this. I honestly think if he were to fix/re-write/extend the bios, this could be a big thing....
You guys really impress me. Where do you learn to design boards? Are you guys computer engineers? Electrical engineers? I'm a software engineer in the business/mainframe world. But you guys really blow my mind.
-
I wouldn't be surprised if we could ship a custom card for less than $30.
Assuming just 10 cards are made: It's $220+ to make them. The chips and such are about $10.
That would make each card about $35.
But we know from experience, large quantities are the way to go. If you make 50 cards, it's only a bit more expensive - but the cost per card drops dramatically (to around $5, iirc). The majority of the card cost is setup expenses. So yeah, I could see $20 for a card.
You are right, though. We need bonknuts to get some time off school so he can work on this. I honestly think if he were to fix/re-write/extend the bios, this could be a big thing....
But for what its worth, I have the board designed already. Just need to get parts to make sure the pad footprints / traces are right, and have the boards made. All that has to go through Arkhan - I don't shop online. And he's waiting to see if we have enough $$ from atlantean to do it.
Thanks for the info.
Arkhan, I know you'll read this sooner or later. Hit me up. I'll pay for the parts.
I don't mind paying at a higher rate to make some prototypes before we go for a large-quantity order. Ideally, I'd like to test the proto-boards with literally a couple dozen games as well as some sort of test-program, if Bonknuts or someone else can whip one up.
-
Sure ... and if you want to make that dream come true, then IMHO ...
[uldecimal][li]Make the dozen-or-less line modification to Mednafen to emulate 512KB ROM/RAM.[/li][li]Gather together your crew that's going to work on the first translation that uses it.[/li][li]Start development with the modified Mednafen and make sure that you can use the RAM effectively.[/li][li]That's all.[/li][/ul]
This is basically why I asked what people are looking for in a System Card. If all that's desired is 512KB ROM + 512KB RAM, MCGenjin already gives you that and is fully supported in Mednafen. You just need to add an MCGenjin header (http://tailchao.com/Extras/PCE/MCGenjin_SP.txt) to a modified system card, and configure it for 2 x 256KB.
I have some crappy prototypes with 1MB of RAM and RAM paging, but those aren't emulated (and are really overkill in my opinion).
Your card is exactly what inspired Bonknuts (aka Tom) to want to have this for translation projects.
If you would be willing to share more details about what you did to make that card, that would be wonderful. In another thread (http://www.pcenginefx.com/forums/index.php?topic=18443.msg393603#msg393603), I was talking about putting up money to build some prototypes, and that could be arranged with you if you are interested.
I hope Bonknuts can get in touch with whomever is most interested in making a card and work out the technical details. I'll start bugging him to weight in here.
Gotcha,
All the MCGenjin work I did is here (http://tailchao.com/Extras/PCE/index.php).
To get 512KB of RAM you can use the supplied POFs as is and connect two 256K x 8 SRAMs to User CS0 and User CS1.
An easier way (since 512KB x 8 chips are common) is to alter the decoding to just trigger a single User CS when A20 is low and A19 is high. If you want me to post modified POFs and VHDL here which do essentially that, I'd be happy to.
-
This is basically why I asked what people are looking for in a System Card. If all that's desired is 512KB ROM + 512KB RAM, MCGenjin already gives you that and is fully supported in Mednafen. You just need to add an MCGenjin header (http://tailchao.com/Extras/PCE/MCGenjin_SP.txt) to a modified system card.
I have some crappy prototypes with 1MB of RAM and RAM paging, but those aren't emulated (and are really overkill in my opinion).
Yeah, we really shouldn't need that for translations. As little as 8kb of extra RAM would make an enormous difference.
Your experience making a real card would be very valuable if you can share it. With the basic 512KB ROM/RAM card that you built, did you encounter any compatibility problems?
-
Yeah, we really shouldn't need that for translations. As little as 8kb of extra RAM would make an enormous difference.
Your experience making a real card would be very valuable if you can share it. With the basic 512KB ROM/RAM card that you built, did you encounter any compatibility problems?
I actually never tried flashing it with the System card image, so I'm not sure. It was built upon request for someone when I first finished the MCGenjin stuff way back when, and I just tested it for functionality (i.e. does the RAM and mapping work properly).
I just looked at the system card in a hex editor and the end of the first bank is padded with $FF, so an MCGenjin header can just be slammed in there no problem. Will test with Mednafen later.
-
Depends on how he's planning to use the RAM. I think it would be a lot harder to code for than a simple extension to the page mechanism already in place, but I could be wrong.
You know that it's already going to be readable through the regular mapping mechanism ... he wants to replace the current flash memory with it.
But there is definitely the question of whether it will be CPU writable through the same mechanism, or even at all!
He's currently using 8MB of flash memory ... but I can only find 1 supplier of 2MBx8 5V SRAM, and 3 suppliers of 1MBx8 5V SRAM ... and it's not very cheap.
I guess that he could be using SDRAM ... but that would be one heck of a lot of work!
It'll be very interesting to see what he's using when it comes out.
BTW, I'm not sure you would actually have to modify mednafen much. You can already write to ROM, and have it change.
Huh??? If it's not actually masking off writes to the emulated ROM memory, then the capability is already in there and I don't need to do anything!
You should just be able to pad a system card up to 512KB or 1MB with zeros, fix up it's header for that size ... and Mednafen would then allocate you a whole bunch of spare memory for you to write into.
Is there some reason that wouldn't do everything that you need?
Do it, and post the changes (and how to re-build everything).
Sounds like you don't actually need any changes!
I'll certainly post build instructions if/when I've got the PC-FX changes done ... but unless someone tells me that expanding a system card didn't work, I'll keep on with the PC-FX stuff while I'm still on a roll.
If you do, would you please let me know where to look in the mednafen source for the cd handling routines? If I can see how it's emulated, maybe I can figure out what is going on with the scsi bus in bios.
What are you looking for? Do you already have the SCSI and SCSI3 documentation?
We need bonknuts to get some time off school so he can work on this. I honestly think if he were to fix/re-write/extend the bios, this could be a big thing....
I'm new here ... may I ask what's wrong with the existing SuperCDROM BIOS???
-
This is basically why I asked what people are looking for in a System Card. If all that's desired is 512KB ROM + 512KB RAM, MCGenjin already gives you that and is fully supported in Mednafen.
So no need to change Mednafen at all ... and the translation crew can just get to work! :wink:
All the MCGenjin work I did is here (http://tailchao.com/Extras/PCE/index.php).
Cool stuff! I hadn't seen that before ... really nice! :D
-
Now, I'm trying to remember a previous discussion some time back about how the system uses RAM. For main RAM, what is the max the system can use? Can it access main RAM through the cart slot? Can cart slot RAM only server as extended memory?
Maybe I'm mixing metaphors, here... I think what I'm remember was related to the SuperGrafx. The SGX doubles the system memory, does it not?
-
Now, I'm trying to remember a previous discussion some time back about how the system uses RAM. For main RAM, what is the max the system can use? Can it access main RAM through the cart slot? Can cart slot RAM only server as extended memory?
Maybe I'm mixing metaphors, here... I think what I'm remember was related to the SuperGrafx. The SGX doubles the system memory, does it not?
The PCE's HuC6280 CPU is a classic 8-bit CPU with a 64KB logical-address range ... but it can map any 8KB logical-segment into any 8KB memory segment in it's 2MB physical-address range.
That's actually one of the nicest memory schemes of any of the early consoles.
So ... the cartridge memory is mapped into the bottom 1MB of the physical address range (thus the 1MB limit on carts - without a second level of mapping, like Street Fighter used) ... and the top 1MB stays internal to the console.
Most of the internal space is wasted, after all, who would EVER need a cartridge more than 1MB!!!!!
The original PCE had 1 internal 8KB segment of RAM, the SGX had 4 internal 8KB segments of RAM.
The cartridge port does have the "write" signals taken out to it, so "yes" you can put RAM on a cartridge and map into into regular memory like any other segment.
-
toymachine78:
Where do you learn to design boards? Are you guys computer engineers? Electrical engineers?
Actually, I'm a software engineer (retired). Back when I got my degree, you had to take 3 courses in computer design, though. Was pretty interesting; starting from some transistors, build a flip-flop. Or two. Or three. (Hmm.... monostabile multivibrator, then j-k, then D, iirc). Then build the basic gates (and, or, not, eor, etc).
Second class was build basic circuits using those gates. Latches, selectors, adders, etc. Third class was more high-level; using building-block circuits, build other 'blocks': address bus, data bus, basic cpu, instruction decoder, etc.
The guy who taught the class was really cool. At the end of each class, he actually brought in a huge breadboard, with all the various devices built onto it - and made totally from transistors (he did cheat a little - each 'chip' was on a smaller board, and the boards were wired together)
Hey, 1kHz may not be fast, but it did work. I think in the end we ended up with a 4 bit cpu.
elmer:
Huh??? If it's not actually masking off writes to the emulated ROM memory, then the capability is already in there and I don't need to do anything!
Have not tested with a cd system card. My test was with a regular card image. But since the actual card should be treated as ROM, I was pretty surprised to find out you could write to it :)
What are you looking for? Do you already have the SCSI and SCSI3 documentation?
What I'm looking for is a useful description of the registers used to access the scsi bus; I have docs on how it works, but knowing $0401 bit 6 is scsi select line (or ack, or whatever) would go a long way in decoding how to 'talk' to the cd reader itself. Right now, I just have a bunch of i/o addresses, with individual bits being toggled. Would be nice to know what those bits are actually doing.
what's wrong with the existing SuperCDROM BIOS???
There's a bug loading palettes when the cd boots.
I suspect (but am not positive of) there is a problem with the status register being saved correctly in some irq situation.
And I'd really like to have a faster cd loading routine.
Keep in mind, if we have more space in the bios rom, we can expand the funtionality; would be nice to have de-compression in bios, rather than RAM. Or the possibility of two different chip tune players :) Heck, we could even remove the cd check when bios boots a cd :)
Spenoza:
Now, I'm trying to remember a previous discussion some time back about how the system uses RAM. For main RAM, what is the max the system can use?
I'm fairly sure any page on a card could be RAM, with the exception of page 0 (which has to contain the boot code). I know a card can access 512K; I'm pretty sure that's only half the max size of a card.
TailChao:
I know nothing about fpga chips. But one request Tom would like I know is out of my league.
Would it be possible to mirror a bank of RAM into both the card space and the system space?
I -think- the idea there is to mirror the system RAM (page 7e, I believe) into an unused area of the boot/bios page. Not positive, though. You'd have to ask Tom about what he wants mirrored, and how.
-
(http://westergaard.eu/wp-content/uploads/2013/02/69645_10151435185946252_1541738680_n.jpg)
-
This is basically why I asked what people are looking for in a System Card. If all that's desired is 512KB ROM + 512KB RAM, MCGenjin already gives you that and is fully supported in Mednafen.
So no need to change Mednafen at all ... and the translation crew can just get to work! :wink:
All the MCGenjin work I did is here (http://tailchao.com/Extras/PCE/index.php).
Cool stuff! I hadn't seen that before ... really nice! :D
The Super System Card still needs to be modified though. I did a quick first try this morning.
I used the padded space at the end of bank 0 to add multi-region capability, automatically set up the MCGenjin ROM page select to the second 256KB page (so $20-$3F will be whatever you guys want to add to the BIOS routines), and patched EX_MEMOPEN to always yield A = $86 X = $03 and CLC.
Will try it with some games tonight, and distribute it here if it works.
I know nothing about fpga chips. But one request Tom would like I know is out of my league.
Would it be possible to mirror a bank of RAM into both the card space and the system space?
I -think- the idea there is to mirror the system RAM (page 7e, I believe) into an unused area of the boot/bios page. Not positive, though. You'd have to ask Tom about what he wants mirrored, and how.
It's possible.
I think a better way though is to have a 512KB ROM + 1MB RAM cartridge, where normally the ROM is fixed to banks $00-$3F and the RAM is set up with 256KB fixed and 256KB pageable in banks $40-$7F. Then add a new register to "switch out" the ROM and replace the whole cart address region in $00-$7F with the 1MB of RAM.
This way you could load whatever patches you want to the System Card, use it as a HuCard loader (which would be compatible with most everything), and just get more memory in general.
For now I'll just try and get MCGenjin + Super System Card + 512KB RAM working in mednafen in case people want to use it for translations. However, if there's a desire to actually do a developer run of cards, I suggest we do the latter setup with 1MB of RAM.
I'll leave this open to suggestion (not just from Tom, but anyone). Might be able to do a run in April or so.
-
For now I'll just try and get MCGenjin + Super System Card + 512KB RAM working in mednafen in case people want to use it for translations. However, if there's a desire to actually do a developer run of cards, I suggest we do the latter setup with 1MB of RAM.
I'll leave this open to suggestion (not just from Tom, but anyone). Might be able to do a run in April or so.
Way cool! Thanks for this.
Further points to consider as this snowball picks up speed ...
Are you going to make this work on the original CDROM systems?
You'd need to be able to map 256KB of your RAM to the regular System Card 3.0 banks ... but not do it by default in case you're running on a Duo or higher that already has that memory.
How are people going to get the modified System Card image on to the card in the first place?
Are you going to ship pre-flashed cards and risk the copyright issues that that would involve ... or is there going to be some other way to get the modified System Card image on to the cartridge?
-
Are you going to make this work on the original CDROM systems?
You'd need to be able to map 256KB of your RAM to the regular System Card 3.0 banks ... but not do it by default in case you're running on a Duo or higher that already has that memory.
Getting everything to work on the original hardware is the basic intention, yes.
I don't own a Duo (only a PCE, TG16 + CD, and Express), but I'm assuming its internal memory is enabled by the HuCard detect line (otherwise there would be a conflict with normal games). In which case we don't have to do anything.
However, if it doesn't work this way, adding a workaround in some modified MCGenjin CPLD is not a big deal.
How are people going to get the modified System Card image on to the card in the first place?
Are you going to ship pre-flashed cards and risk the copyright issues that that would involve ... or is there going to be some other way to get the modified System Card image on to the cartridge?
This is basically my major concern, and I don't want any legal trouble.
The "right way" is to roll our own compatible BIOS, but I'm definitely not doing this.
Having users able to flash the cartridge with a system card image in their home (assuming they don't own a chip programmer) would drive up the cost, too. What will probably have to happen if I do a run of developer cards is that they'll just have an empty 29F040 / 39F040 DIP socket, and the owner will have to toss the image on a chip themselves, or get a preflashed one from someone else.
Or a preflashed chip could happen to have fallen in the same bag as the board, I have no idea how that would happen though.
For now, let's just get the emulator support working and see what people want in the hardware.
Edit:
I was impatient, seems the patched System Card works okay with a couple games in Mednafen.
Are IPS patches okay with people here, or is it alright just to post a binary?
-
Getting everything to work on the original hardware is the basic intention, yes.
I don't own a Duo (only a PCE, TG16 + CD, and Express), but I'm assuming its internal memory is enabled by the HuCard detect line (otherwise there would be a conflict with normal games). In which case we don't have to do anything.
However, if it doesn't work this way, adding a workaround in some modified MCGenjin CPLD is not a big deal.
AFAIK, you're going to need that work-around.
People with DUOs have reported being able to run SuperCD games when using a System Card image on a TurboEverdrive, which definitely doesn't have the RAM.
The "right way" is to roll our own compatible BIOS, but I'm definitely not doing this.
Having users able to flash the cartridge with a system card image in their home (assuming they don't own a chip programmer) would drive up the cost, too. What will probably have to happen if I do a run of developer cards is that they'll just have an empty 29F040 / 39F040 DIP socket, and the owner will have to toss the image on a chip themselves, or get a preflashed one from someone else.
You definitely can't rely on people having a programmer!
Is the flash chip in-system-progammable from the PCE side?
If so, then you could pre-flash it with an absolutely minimal custom program that just loaded a modified BIOS off CD and then flashed it. Then that CD image gets put somewhere out in the cloud.
-
AFAIK, you're going to need that work-around.
People with DUOs have reported being able to run SuperCD games when using a System Card image on a TurboEverdrive, which definitely doesn't have the RAM.
In that case it's quite possible that the read sequence in EX_MEMOPEN (which I disabled) triggers this.
I'll investigate this more if we end up actually manufacturing cards.
You definitely can't rely on people having a programmer!
Is the flash chip in-system-progammable from the PCE side?
If so, then you could pre-flash it with an absolutely minimal custom program that just loaded a modified BIOS off CD and then flashed it. Then that CD image gets put somewhere out in the cloud.
Right now on MCGenjin cards no write control is given to the ROM, only RAM.
The reason is that the MCGenjin mapper is basically acting as a ROM data bus passthrough, deciding whether to invert the data lines depending upon our region. Having this act bi-directionally is complicated and I'll have to do some thinking about it, since the mapper also works by trapping ROM writes. Which means more control registers to unlock, etc.
-
Alright, sorry for the double post but:
Here's (http://penguinet.net/RejectedPizza/CD_Stupid_Card_3p5_PatchJP.ups) a UPS patch for the Japanese System Card 3.0 (Original MD5 should be 38179df8f4ac870017db21ebcbf53114).
Steps for Mednafen:
-Patch the Super System Card image.
-Replace your currently configured PCE-CD BIOS with this patched image.
-Disable arcade card emulation (in your .cfg file).
What this gets you:
-512KB of RAM from $40-$7F plus the base 64K of RAM for a total of 576KB.
-512KB of ROM from $00-$3F. Banks $00-$1F are the (modified) Super System Card. The rest are whatever your imagination can put there.
-Seems to work with most SuperCD games, if something is messed up, let me know.
-Would work in both a PCE and TurboGrafx with no modification.
Next Steps:
I am willing to make a "developer's" run of cards which could support these features and possibly a few more. I'll also release all materials associated with how the cards are designed, how the mapper works etc. Then you guys can do whatever you want with it.
I don't have the resources to do a mass production run or deal with the legal issues, my priority is creating games but I think this card would be a neat thing.
-
Right now on MCGenjin cards no write control is given to the ROM, only RAM.
The reason is that the MCGenjin mapper is basically acting as a ROM data bus passthrough, deciding whether to invert the data lines depending upon our region. Having this act bi-directionally is complicated and I'll have to do some thinking about it, since the mapper also works by trapping ROM writes. Which means more control registers to unlock, etc.
Well, a basic TL866CS programmer goes for about $47 on AliBaba ... so the translation crews might be happy enough to just have one guy buy one and send out updated ROMs to the others when they're needed.
It sounds like a total pain to me, but I'm sure that someone will have a better perspective on that than I do.
From my very, very personal POV, I'd much rather have the mapper simplified to get rid of the multi-region capability and allow the PCE's CPU to flash updates.
For a "developers" run and not a "mass-production" run, I would think that any developers are likely to be using Japanese systems, or to have a kisado/mirai available.
Anyone that really only had a US system could just swap in a bit-flipped ROM chip ... and the PCE's flashing software could take the region into account whenever it did the updates.
For a mass-production run ... it would just be a case of having some ROMs pre-flashed with a Japanese boot loader, and some with a US boot-loader.
But realistically ... it's not my call on this! :wink:
-
For a "developers" run and not a "mass-production" run, I would think that any developers are likely to be using Japanese systems, or to have a kisado/mirai available.
Anyone that really only had a US system could just swap in a bit-flipped ROM chip ... and the PCE's flashing software could take the region into account whenever it did the updates.
For a mass-production run ... it would just be a case of having some ROMs pre-flashed with a Japanese boot loader, and some with a US boot-loader.
But realistically ... it's not my call on this! :wink:
For any sort of production run, I'd rather just make the 1MB version I described earlier, since then you can just include whatever version of the system card you like with the CD game itself, and just load it at start.
Then you get to keep the multi region capability and get more memory anyway.
-
For any sort of production run, I'd rather just make the 1MB version I described earlier, since then you can just include whatever version of the system card you like with the CD game itself, and just load it at start.
Then you get to keep the multi region capability and get more memory anyway.
I sat back and gave it some more thought, and realized that I was entirely wrong ... but you'd already beaten me to replying and it was too late to retract! :oops:
Yes, a stable base version that doesn't change is more important.
Then you can either go the 1MB route and load a new BIOS, or just ship it as 512KB with a modded BIOS that vectors everything through new jump vectors in the extra RAM and so allows each game to patch/add just what it needs.
The 2nd solution would be a little cheaper to make, and potentially require less extra space on the game's CD.
-
Some of these technical aspects are a little over my head, but I am really grateful for the discussion happening now, and especially to TailChao for sharing so much.
Now we just need Bonknuts. I'll try and get at him again.
-
What I'm looking for is a useful description of the registers used to access the scsi bus; I have docs on how it works, but knowing $0401 bit 6 is scsi select line (or ack, or whatever) would go a long way in decoding how to 'talk' to the cd reader itself. Right now, I just have a bunch of i/o addresses, with individual bits being toggled. Would be nice to know what those bits are actually doing.
I wish that I could help you with that ... they're excellent questions.
I assume that we're both working from the same resources ... Charles MacDonald's brilliant work, the Hu7CD documentation, and the SCSI CD standards.
I do wonder if Hudson reused the same basic interface design for the PC-FX (which is a little better documented) ... but haven't really given it a serious look.
what's wrong with the existing SuperCDROM BIOS???
There's a bug loading palettes when the cd boots.
I suspect (but am not positive of) there is a problem with the status register being saved correctly in some irq situation.
And I'd really like to have a faster cd loading routine.
Keep in mind, if we have more space in the bios rom, we can expand the funtionality; would be nice to have de-compression in bios, rather than RAM. Or the possibility of two different chip tune players :) Heck, we could even remove the cd check when bios boots a cd :)
I'd heard of the palette problem ... just assumed that everyone worked around it with a multi-stage boot.
As for the other things ... a custom CD BIOS scares me because it limits the audience to those with your specific hardware add-on.
PCE owners are already fragmented enough with all the different variations!
-
elmer: this is what I was testing ROM writes with. You can see if your copy of mednafen blocks ROM writes.
.............................................................
/*.....................................................................................*/
/* emutest.c - program to test ROM writeability. */
/*.....................................................................................*/
#include "huc.h"
main()
{
init_satb();
if( emuCheck() )
{
put_string( "Is Emu", 0, 0 );
}
else
{
put_string( "Not Emu", 0, 0 );
}
while( 1 )
{
vsync(0);
satb_update();
}
}
emuCheck()
{
#asm
; map empty page in
tma #7 ; next to last page : $C000-DFFF
pha
lda #0 ; boot bank in ROM
tam #7 ; set page
lda #$aa
sta $dffe ; would be $fffe, the reset vector
ldx $dffe ; if mapped one segment higher, like normal
pla
tam #7 ; put page back
cpx #$aa
bne .fail
lda #0 ; return 1 if match
ldx #1
rts
.fail
lda #0 ; return 0 if no match
ldx #0
rts
#endasm
}
..................................................
Huc -scd emutest.c
mount iso and run it.
-
Slap on a pair of Air Zonk shades and that would be an amazing shirt.
(http://s12.postimg.org/lwndg2vv1/duodreams.png)
Jah feel?
http://printallover.me/products/0000000p-i-have-a-duo?social=true
Well damn. I totes bookmarked dat page, may purchase, may, may.
-
tma #7 ; next to last page : $C000-DFFF
Am I missing something here?
I'm not familiar with HuC ... but the general instruction form that I'm familiar with is tma 0-7 ... so you'd actually be switching the bank that's mapped into $E000-$FFFF ... and then you're doing the test by writing the byte at $DFFE, in a totally different bank.
Does HuC use tma 1-8 instead?
-
toymachine78:
Where do you learn to design boards? Are you guys computer engineers? Electrical engineers?
Actually, I'm a software engineer (retired). Back when I got my degree, you had to take 3 courses in computer design, though. Was pretty interesting; starting from some transistors, build a flip-flop. Or two. Or three. (Hmm.... monostabile multivibrator, then j-k, then D, iirc). Then build the basic gates (and, or, not, eor, etc).
That's cool. I would've liked some transistor experience when I worked on my CS degree now that I think about it and the interests I gained due to Le Steve. Funny enough I minored in physics and in one lab course is where we did quite a few projects teaching us the basics of resistors, circuit design and so forth revovling around Ohm's Law.
-
may, may.
https://www.youtube.com/watch?v=zYPhXA2zHCU
-
may, may.
https://www.youtube.com/watch?v=zYPhXA2zHCU
*unzips*
I'm waiting.....
-
*unzips*
I'm waiting.....
*unsheathes katana*
Hmph, you're almost not worth it...
*teleports behind you, cutting you in half*
heh...nothing personnel...kid...
*tips fedora*
-
Huc -scd emutest.c
mount iso and run it.
So ... HuC has built me a 900KB iso ... but the current version of Mednafen doesn't support physical CDs any more, so there's no point in mounting it ... and Mednafen refuses to run it from the command line, it wants cue&bin, not iso.
Any suggestions?
-
As for the other things ... a custom CD BIOS scares me because it limits the audience to those with your specific hardware add-on.
PCE owners are already fragmented enough with all the different variations!
It limits your audience, but not so much if the card is cheap.
This is actually the major reason I want to do the 512KB ROM + 1MB RAM version of the card. You can just include a very slightly modified 3.0 BIOS (i.e. startup area only, like the 512KB RAM patch I posted), and it will just work as a normal super system card.
But if the game requires (or optionally can use) the extended RAM or wants to use a patched BIOS, it just loads that into RAM, maps out the system card ROM, and continues on.
When I first got a TurboGrafx and wanted to play Super CD games, I literally couldn't do so until I added a region modification to the system. The US system cards were too expensive.
This way you get an affordable card which works with either system and would offer expanded capability for translations.
-
This way you get an affordable card which works with either system and would offer expanded capability for translations.
Everything that you've said makes perfect sense ... you've just got to get that low 512KB of ROM switchable for RAM, and then (switchably) mirror the top 256KB of RAM into the regular SuperCD RAM location.
I really look forward to being able to buy one! :)
Again, I apologize for the mistake. Guess you will have to fix mednafen after all :(
It looks like TailChao has already given you the capability that you want with the MCGenjin ROM, so I think that I still get to punt on the mednafen changes ... for the moment, at least. :wink:
There are ways around it (burn a cd, and rip it to a cue/bin) but at this point, it's not worth the time and effort.
IMHO, someone either needs to fix HuC to produce .cue/.bin, or you guys need to finally let HuC rest-in-peace and get on the CC65 bandwagon.
That's a later part of the dream (to keep folks from pressing a bunch of cds and re-selling them). If the card could be made cheaply enough, the people who want to play translations could buy it (and would only have to do so once) for that purpose.
Please don't kid yourself ... Tobias (or whoever) will be able to go to exactly the same Chinese factory that makes your production-version carts and get them to make some for him.
If you don't get them made in China, then he'll just get them reverse-engineered in China.
Then he'll put a PCEWorks logo on it sell it as the "offical" cart for his Deluxe Edition boxsets ... and sell it for more money than you're asking ... and the crazy fools out there will buy it anyway.
If you're doing this ... do it to encourage more/easier translations, please don't make the mistake of thinking that it will have any effect on the people that re-sell translations.
-
*unzips*
I'm waiting.....
*unsheathes katana*
Hmph, you're almost not worth it...
*teleports behind you, cutting you in half*
heh...nothing personnel...kid...
*tips fedora*
Talk about not knowing how to read someone. Jeeesh, were s'posed to wet your lips and close your eyes. This is the greatest gift I can give.
-
Talk about not knowing how to read someone. Jeeesh, were s'posed to wet your lips and close your eyes. This is the greatest gift I can give.
(http://i40.tinypic.com/98vmug.jpg)
-
Talk about not knowing how to read someone. Jeeesh, were s'posed to wet your lips and close your eyes. This is the greatest gift I can give.
(http://i40.tinypic.com/98vmug.jpg)
I quit.
-
Sorry, late to the party.
So a few things..
EX_MEM is useless, but a game might depend on it. There's also a 'register' in the $FFF4 of boot rom (fixed vector bank) that gives you the starting bank #num of the system card (either $80 or $68). I wouldn't change this either. The way I see it, is that you don't want to break any capability with existing games. If HuC relies on this, then that can be fixed/addressed. HuC would need a little bit of re-structuring for the starting bank address, but IIRC this is pretty easy to do (IIRC there are if/def for SCD and the value of the starting bank set to vale $XX). For ASM, this is a non issue.
For new dev, or even translations, checking for the extended ram would be a simple as writing a byte to each bank and reading it back (I did this to detect SGX even when the compatibility switch is set to PCE MODE).
My personal opinion; if we're gonna make a new extended version of the SCD 3.0 card - let's do it right and make the ram on the card 512k (there's still 64k on the CD base unit, for a total of 576k). Translations can make use of the extra memory for script compression issues, hombrew could make use of it specifically because it's more memory, and hacks can make use of it for holding more data (Megaman 2 and other larger NES roms running on PCE could also make use of it) - etc.
I'm aware of the palette loading bug, but I'm not really concerned with it. I'm not sure what status reg bug Old Man is talking about, but I do know the processor status register is always saved (the interrupt call does this automatically). As far as VDC status reg, I'm pretty it gets written to a ZP reg somewhere. If not though, you can put a ram bank in MPR slot #7 with those suck modifications - without changing the original (again, needs to be a boot routine but HuC can handle that).
On a side not, some SCD games try to write to rom (bios). Gate of Thunder actually tries to change the value of $fff4, which is $68, to something else. I suspect that it was part of a development thing. Obviously the change doesn't take effect (real system or emulator).
I think someone mentioned something about some mirrored stuff, that I mentioned previously? The only thing that I can think off the top of my head, for mirrored stuff, is that the system card rom is actually 256k, but it's mirrored as a 512k image. I have no idea of any game, or the system card itself, relies on this.
On a side note, have you guys ever tried to swap out the ram bank MPR to run a dual system? Pain in the arse because you also have to keep track of two 'stack' registers. The reason I bring this up, is because my nes2pce stuff have to have their own MPR 7 bank mapped and can't use the system card stuff, but for the CD hardware I have to switch over to that environment when I do such calls (play a CD track). It'd be really nice to have a documentation of how to directly handle CD hardware via the scsi-ish (it's not exact) command string and how the status regs are used, to avoid all of this.
As far as homebrew/huc, I have a new CD read routine that I ripped from Seiya Monogatari that will increase the read speed by decent amount (122k/sec vs 90k/sec of the original). There are some #$ff areas in the original CD boot bank, that when copied over to a ram bank and re-mapped there, could be used to call such new routines. There are some nice LZSS decompression routines from that game as well (decompress with a small ring buffer directly to vram, etc). Stuff like this can be made standard lib fair, but without modifying the original rom (but more of a patch done via ram and remapped).
-
EX_MEM is useless, but a game might depend on it. There's also a 'register' in the $FFF4 of boot rom (fixed vector bank) that gives you the starting bank #num of the system card (either $80 or $68). I wouldn't change this either. The way I see it, is that you don't want to break any capability with existing games. If HuC relies on this, then that can be fixed/addressed. HuC would need a little bit of re-structuring for the starting bank address, but IIRC this is pretty easy to do (IIRC there are if/def for SCD and the value of the starting bank set to vale $XX). For ASM, this is a non issue.
I really wonder how the Duo is enabling and disabling its internal 192K of memory, then.
Do you have any ideas?
As for the $FFF4 value, there's actually a large amount of cruft in the Super System Card's bank 0 right after the $FF padding and before the vectors aside from this. For the dummy 512KB ROM + 512KB RAM System Card patch I put up earlier, I plowed over most of it and the handful of games I tested happily continued along their way with no issues.
Wonder if anything actually depends upon those either.
On a side not, some SCD games try to write to rom (bios). Gate of Thunder actually tries to change the value of $fff4, which is $68, to something else. I suspect that it was part of a development thing. Obviously the change doesn't take effect (real system or emulator).
Great, I was hoping NEC would have been a little more strict about this. But I guess I'll have to implement some lock registers now.
-
I really wonder how the Duo is enabling and disabling its internal 192K of memory, then.
Do you have any ideas?
Charles Macdonald told me that the hucard detection pin is what the Duo and SuperCDROM units use in order enable/disable the rom+192k so that a hucard might take the whole lower 1mb range for itself. Technically, you could have a card that enables and disables this on the fly. The arcade card duo version, AFAIK, maps only two things to open bus area. One of the open bus area is banks $40-43, so it doesn't even set the pull the hucard detection pin to ground (pretty sure how that's how it works, or pulls it up). The other area is $1ffa00-1ffaff range (open bus in the hardware bank). So it doesn't even bother asserting the hucard detection pin.
As for the $FFF4 value, there's actually a large amount of cruft in the Super System Card's bank 0 right after the $FF padding and before the vectors aside from this. For the dummy 512KB ROM + 512KB RAM System Card patch I put up earlier, I plowed over most of it and the handful of games I tested happily continued along their way with no issues.
Wonder if anything actually depends upon those either.
I was assuming games don't use it. What were you going to use it for? Does you mapper header go there?
-
So ... HuC has built me a 900KB iso ... but the current version of Mednafen doesn't support physical CDs any more, so there's no point in mounting it ... and Mednafen refuses to run it from the command line, it wants cue&bin, not iso.
Any suggestions?
Just make a cuesheet that uses an iso file... like so:
FILE myawesomeiso.iso BINARY
TRACK 01 MODE1/2048
INDEX 01 00:00:00
I dunno if you need to add a pregap or postgap in there or not though... I personally always have a track 1 audio file and put the iso at track 2.
-
wait wait.
why doesn't mednafen support real CDs? lol
-
Charles Macdonald told me that the hucard detection pin is what the Duo and SuperCDROM units use in order enable/disable the rom+192k so that a hucard might take the whole lower 1mb range for itself. Technically, you could have a card that enables and disables this on the fly. The arcade card duo version, AFAIK, maps only two things to open bus area. One of the open bus area is banks $40-43, so it doesn't even set the pull the hucard detection pin to ground (pretty sure how that's how it works, or pulls it up). The other area is $1ffa00-1ffaff range (open bus in the hardware bank). So it doesn't even bother asserting the hucard detection pin.
Ok good, that was my original guess.
The only other way would be some magic register read sequence and I'm not too worried about that.
I was assuming games don't use it. What were you going to use it for? Does you mapper header go there?
Ends up I forgot how my own patch was written, I didn't actually change this value, so we're alright in this regard.
However, what I did nearby was the following:
*$FF0F becomes the new "native" region startup vector.
*$FFF0 becomes the new "swapped" startup vector.
*Additional startup code was added around both of these, in the latter (swapped) case I had to plow over some seemingly unused cruft before the vector table ($FFE0-$FFF3).
*The MCGenjin mapper header lives from $FFD0-$FFDF.
Ok, cool. It should be perfectly feasible to get a 512KB ROM + 1MB RAM dual-region cartridge working for both a Duo and TG16+CD with no issues and good System Card 3.0 compatibility.
I'll do some card + mapper specs and start a new topic after a few days of thought.
-
BTW, I sent an e-mail to Tobias :
"Hi,
> do you mean that the guies who translated the games
> will get royalties on this ?
we're talking.
Best
Tobias"
I'm pretty sure he's talking BS here. Can you confirm that it's the case ?
-
Just make a cuesheet that uses an iso file... like so:
FILE myawesomeiso.iso BINARY
TRACK 01 MODE1/2048
INDEX 01 00:00:00
I dunno if you need to add a pregap or postgap in there or not though... I personally always have a track 1 audio file and put the iso at track 2.
Thank you, that worked perfectly!
My bad for not remembering that I could do that ... it's been many years since I had to edit a .cue file manually. :oops:
-
Update:
I haz a dream: Someday Arkhan will tell me all of the Alantean boards are done, sold and shipped.
Check.
I haz a dream: Arkhan will total everything up, and we will have actually made a small profit...
And it's enough money to develope the new system card....
Check. And almost.
I haz a dream: We order prototype boards and all the pieces...
And I put them together without screwing things up...
And they work...
And the bios is reprogrammable, for future changes.
Check. There went my atlantean profits. And some extra $$
Sometimes. They're a pain.
Haven't finished complete testing, but it's looking good. Looks like it needs a filter capacitor added, though.
YES!
I haz a dream: Bonknuts has time off from school, and decides to work on translations....
And he finishes one using the new system card....
And expands on MegaMan-CD as well.
He's working on it again :) So maybe....
I haz a dream: With the extra flash space, we start adding useful routines for translations and developement....
Covell has an ML monitor.
(If you see this chris, lets talk licensing....)
Of course, I also have a dream where everyone from the turbo game shows appear at my door to use the bathroom,
piss all over the shower, and my wife says "They're your friends. *You* clean it up....."
No, but the cats have learned a new trick. Guess what it is.... :|
............................................................
No, I will NOT build you one. They are a royal pain-in-the-arse to build.
I already have people picked out to send them to, *as they are built and tested.*
(for free, but you have to be a developer. It's not much use to anyone else.)
No, even if I had a lot of them made, I wouldn't sell them. I'm not interested
in making $$. I'm interested in getting a -complete- free dev environment for
the pce set up - and brought up to date.
And I still have a lot to do on Sabre-Riders. That comes first.
With that said, the boards could be built for under $20, in lots of 50. All parts
included, At last check. They support ROM/RAM and are 'fixable' to support
ROM/ROM. Yes, an 8M bit game is on the to-do list. Eventually.
There is still a ton to do on the software side, though.
So, how long before someone decides to clone these?
-
Of course, I also have a dream where everyone from the turbo game shows appear at my door to use the bathroom,
piss all over the shower, and my wife says "They're your friends. *You* clean it up....."
No, but the cats have learned a new trick. Guess what it is.... :|
............................................................
Laugh of the day! :lol:
-
Laugh of the day! :lol:
Not on my end.
-
So, how does your system card project differ from TailChao's CD Stupid Card?
Is there a risk, at this point, of fragmenting system card advances, or do you think it's likely that after some development work, a singular "optimal" design will emerge from the various projects and become the defacto future of the system?
I ask because, speaking selfishly, I don't want to have to purchase a new system card every time I want to play a homebrew release, unless it's a card-format title and the system card is built-in. I would hate to have to buy a separate system card for every new CD release. They tried something a little like that on the Saturn and, while it was effective, it didn't help sales one bit.
-
So, how does your system card project differ from TailChao's CD Stupid Card?
I'm curious, too. :-k
But also in how your card differs from a TurboEverDrive v2 (now up to revision 2.4).
That's got 4MB RAM, AFAIK it can boot a customized CD BIOS, and it has a USB connection to a PC for game developers (so no messing about with the joypad port).
And it's available for anyone to buy now.
[EDIT]
Just tested a couple of SYSCARD versions on the TED 2, and "yes" they work fine booting Gate of Thunder, i.e. it works with a SYSCARD 3 image, and the CD displays an error message when booted with a SYSCARD 2 image, as expected.
-
So, how does your system card project differ from TailChao's CD Stupid Card?
But also in how your card differs from a TurboEverDrive v2 (now up to revision 2.4).
It's a lot simpler (and cheaper to make). I'm not out to take anything away from those cards.
It's basically a system card with more memory. That's all.
And it's available for anyone to buy now.
Well, anyone with the $$.
Most homebrew/translation people would like to have just a little more RAM. (see the xanadu thread. There are others, too, if you search around.) They do it for fun, and want the games played.
A cheap card would allow those of us who can't afford a StupidCard/Everdrive to play them.
Oh, yeah, let's not forget: Both those cards can do a lot more than this one. But you have to plan for which card to use (iirc, they use different schemes for accessing extra RAM). In theory, a homebrew dev could produce these cards without having to figure out how to do anything else (though I think Tailchao changed his card so it defaults to a relatively stock setup. )
And if you (as a developer) know anything about circuit design, it might me possible to add battery-backup to it...
-
It's a lot simpler (and cheaper to make). I'm not out to take anything away from those cards.
It's basically a system card with more memory. That's all.
So something like 512KB flash and 512KB SRAM ... or something different?
In-system flashable for upgrades?
Are you willing to share more details, yet?
Well, anyone with the $$. ...
A cheap card would allow those of us who can't afford a StupidCard/Everdrive to play them.
Hmmm ... well TailChao's CD StupidCard was $35, so you're definitely expecting to beat that, but the $20 margin isn't a huge deal in the grand scheme of things.
IMHO ... if you can't afford a $35 card, then I'm not sure how you can afford to buy any PCE games or other peripherals, but there's no denying that it's good to save money if you're still getting something that can do the job.
Oh, yeah, let's not forget: Both those cards can do a lot more than this one. But you have to plan for which card to use (iirc, they use different schemes for accessing extra RAM).
"Yes", that's the "fragmentation" that spenoza was worried about.
The CD Stupid Card gives you 512KB ROM & 512KB RAM out-of-the-box without running any card-specific code to flip banks.
If you do that, too, then you're not introducing any more fragmentation for developers/translators that just want a little bit of extra RAM.
I'm not sure what the TED 2 defaults to, as I've litterally just shipped off my v2.2 cards to be replaced with the new version. But even if it doesn't support it by-default, it should be able to be switched to 512KB ROM & 512KB RAM with a simple customized System Card image.
If translators can just rely on a simple 512KB RAM without having to do any card-specific checks (i.e. just by doing a general scan for RAM banks), then I think that you'll probably make everyone happy, and people can just buy whichever card they like, and all 3 would run an "expanded" translation.
Most homebrew/translation people would like to have just a little more RAM. (see the xanadu thread. There are others, too, if you search around.) They do it for fun, and want the games played.
I should be fine with Xanadu 1 & 2, but it could easily have worked out differently if Falcom had used a better compressor back in 1994/1995.
I can totally understand that giving translators that bit of extra memory to make their lives easier could well be a major benefit to the whole fanbase.
Most sane folks don't going to want to go through the programming gyrations that I'm going to be doing on the Xanadu games.
I think that my concern is that things remain "easy" for both translation programmers and end-users.
That means a simple ROM/RAM layout that doesn't need any card-specific detection, i.e. presumably the 512KB/512KB that the other 2 cards can already do, and that TailChao has already released a Mednafen image for.
In theory, a homebrew dev could produce these cards without having to figure out how to do anything else.
And if you (as a developer) know anything about circuit design, it might me possible to add battery-backup to it...
The idea of this scares me more than anything else!
If I'm writing a homebrew game, then the last thing that I want to do is to have to invest in manufacturing and stocking a generic add-on card just so that people can run my game.
Neither will any of us benefit if every developer produces their own customized version with a slightly different BIOS, or with/without a battery-backup, just to make sure that you buy their version of the card.
I'd rather point people towards KRIKKzz and let him deal with the hassle of "retail" hardware sales.
**************
Now, from my own personal POV of wanting to do some homebrew ...
If I'm going to write something that requires expanded memory, it's going to be requiring at least 2MB (i.e. CD Stupid Card or Turbo EverDrive 2 or Arcade Card). I can't see the point in programming anything new for 512KB RAM when the Arcade Card already set the "standard" at 2MB 20 years ago.
IMHO, if wanted to "go wild", it would be with the TED2's 4MB, because the card isn't that expensive, it provides one heck of a lot of functionality for it's price, and it's manufacturer actively supports it.
-
Interesting. So while these cards technically offer more, maybe they can all adhere to a new but lowest level standard? Something like SCD 3.2 with 512k rom and 512k ram. The ram part is easy, but what's that extra 256k rom going to be defined as? A few different fonts would be nice (6x12,8x8,8x12,8x16). Maybe a sets of small-ish common English dictionary tables (2byte, 3byte, 4bytes, etc). Sin, cos, tan, arcsin, arccos, arctan. Whatever - faster math/f(x) routines. Definitely wouldn't mind some non-linear ramps (look up tables).
Edit: maybe it doesn't have to be rom, but I still have the newer/faster CD_READ routines that I ripped from Seiya Monogatari. Who doesn't like a 27% increase in read speed? It's only 8k.
-
The ram part is easy, but what's that extra 256k rom going to be defined as? A few different fonts would be nice (6x12,8x8,8x12,8x16). Maybe a sets of small-ish common English dictionary tables (2byte, 3byte, 4bytes, etc). Sin, cos, tan, arcsin, arccos, arctan. Whatever - faster math/f(x) routines. Definitely wouldn't mind some non-linear ramps (look up tables).
Haha ... that's where we all start getting into trouble! :wink:
There's very little in that list of things that I wouldn't rather have available as source/libraries.
There aren't enough active developers to form a "standards committee", and gawd knows if anyone would want to ... and anyway, it's The Old Man's project, so he gets to do as he pleases.
From what he said a couple of messages ago, I think that he'd like to put Chris Covell's PCEMON into that extra 256KB, and that sounds like a great idea to me.
Put some extra tool functionality in there that's useful for a developer and that a curious end-user can play with, and that seems like it would be enough, to me.
If you've got 512KB of RAM on the card, then you've just gained 320KB more than a System Card 3.
That seems like plenty of memory to add a few new "library" functions into your own code.
I think that TailChao was 100% correct when he decided to make absolutely no new library functions available in the CD Stupid Card.
And that's the other thing ... that card is already out there, and so is the TED 2 (with its Street Fighter 2 mapper).
We've already got 2 cards with a 512KB/512KB split, and it's the one that makes the most sense from a hardware chip-select POV.
That doesn't mean that anyone has to suddenly use all the extra ROM space to add library calls that only serve to fragment the landscape for developers/users.
Edit: maybe it doesn't have to be rom, but I still have the newer/faster CD_READ routines that I ripped from Seiya Monogatari. Who doesn't like a 27% increase in read speed? It's only 8k.
IMHO, the best thing to do would just be to make the source to those routines available, and then anyone can use them as they wish.
I just looked, and they don't seem to be downloadable from your blog.
Have you disassembled them to source yet?
Actually ... off-topic, but what are you using to disassemble things?
-
Had a nice little point-by-point reply, but apparently I took to long to write it and got logged off.
Here's the simple version:
with 512k rom and 512k ram.
Yeah, that seems the natural split. Though you can replace the 512k RAM with ROM if you're using to produce your own cards. (that's why cost is a big factor)
I think that he'd like to put Chris Covell's PCEMON into that extra 256KB....
That seems like plenty of memory to add a few new "library" functions into your own code....
I would, for my own use.
I think developers have different needs for different games; since the card is re-flashable, you could set it up however you like. Or make a few, with different setups for different needs.
No, it's not in-system flashable:( The programming timing on the chip is too fast for the pce to handle, and if a block isn't programmed in that time-frame, the chip times out.
Yes, I'd love to have a faster cd read routine. I think I'm going to need it....
Mu goal isn't to mass produce and sell these. It's to build a card that -anyone- can make cheaply, and use for developement and/or hombrew productions.
-
IMHO ... if you can't afford a $35 card, then I'm not sure how you can afford to buy any PCE games or other peripherals, but there's no denying that it's good to save money if you're still getting something that can do the job.
Elmer: I can afford a $35 card. I can afford an everdrive. Can everyone?
Would you rather have people play your translation, or complain that it required a $35 card (that's not available anymore. Better check e-bay..) or a $100 card to play through?
(Not that Xanadu will. But then you run into the whole tobias reproduction problem....Which is another part of the cheap card idea.)
-
with 512k rom and 512k ram.
Yeah, that seems the natural split. Though you can replace the 512k RAM with ROM if you're using to produce your own cards. (that's why cost is a big factor)
Excellent! :)
It looks like your for competition ROM-only cards is getting tougher (http://www.pcenginefx.com/forums/index.php?topic=19848.0), but AFAIK, you'll be the only-game-in-town with affordable ROM+RAM cards ... if you guys at Aetherbyte decide to stock and sell them. :-k
No, it's not in-system flashable:( The programming timing on the chip is too fast for the pce to handle, and if a block isn't programmed in that time-frame, the chip times out.
That makes sense, thanks!
My goal isn't to mass produce and sell these. It's to build a card that -anyone- can make cheaply, and use for development and/or homebrew productions.
This is where I question the plan, but I've certainly been horribly wrong before. Are you sure that's going to make sense for small homebrew developers?
I think that ichigobankai has found out in the other thread that most people really don't want to solder surface-mount components onto boards.
Does your $20-per-card-in-a-batch-of-50 estimate include contract-production of the boards in China, all the plastic/spacers needed to make it fit properly, and shipping to the USA?
If so, then I'm going to have to drop $1000 (minimum) to get them, and I'd probably have to charge at least $30 or maybe even $40 per card in order to cover returns, interest, and my time in order for it to be worthwhile. Does that sound right?
I think developers have different needs for different games; since the card is re-flashable, you could set it up however you like. Or make a few, with different setups for different needs.
That's absolutely great for development use (but still not as good as a TED2-with-USB), but if I were to think about requiring one of these to play a homebrew CD game, then you're giving me a lot of extra trouble for that 320KB of extra RAM.
Are you perhaps thinking of these cards as acting as a sort of copy-protection method for homebrew CD games? :-k
Yes, I'd love to have a faster cd read routine. I think I'm going to need it....
Me, too! But for me, I suspect that I'd put it in a bank in the regular SCD RAM.
I can afford a $35 card. I can afford an everdrive. Can everyone?
Would you rather have people play your translation, or complain that it required a $35 card (that's not available anymore. Better check e-bay..) or a $100 card to play through?
I think that the idea would be to use the minimum of extra hardware that's necessary to make the translation run.
If someone can't afford the required hardware, then they can play the translation on an emulator for free.
Remember ... translations aren't like homebrew, they're basically "grey-area" from the start, and they're given away for free.
Do you really think that any translator is going to want to pay money to stock ROM/RAM cards just so that they can give away their translation for free???
I suspect that most translators don't have a burning desire to become shop-keepers ... and I certainly don't!
Also, if some translator started requiring people to buy a "custom" my-translations-only ROM/RAM card, then they'd get crucified by the rest of the translation community!
So "yes", if I needed to use extra RAM in a translation, then I'd make it compatible with emulators, and also with whatever ROM/RAM HuCard people can go out there and easily buy ... which at this point means the $80 TED2.
If Aetherbyte wants to make a generic 512KB/512KB "System Card 4" available for $20, then I'd try to make it compatible with those and point people in your direction.
If those cards become popular, then you may see people making homebrew for them.
(Not that Xanadu will. But then you run into the whole tobias reproduction problem....Which is another part of the cheap card idea.)
The possibility of Tobias doing a reproduction is definitely something that SamIAm and I have already talked about, many times.
Now that he's giving away the translations for "free", I'm not sure just how pissed that I can be.
Yes, it's really annoying that such an unscrupulous ass would be basically making a profit out of my work, but I'm certainly not going to start making my own illegal reproductions!
IMHO, requiring a new ROM/RAM card is counter-productive.
Most of Tobias's customers want shelf-candy, and it's not going to matter that they're going to have to come here to buy a ROM/RAM card (or just play it on an emulator).
In fact, if there's money-to-be-made, then Tobias will just clone the card and charge $60 for the "official" PCEWorks "Translation Card".
-
In fact, if there's money-to-be-made, then Tobias will just clone the card and charge $60 for the "official" PCEWorks "Translation Card".
Bundled with a Captain Midnight Decoder Ring? :lol:
-
If Aetherbyte wants to make a generic 512KB/512KB "System Card 4" available for $20, then I'd try to make it compatible with those and point people in your direction.
Designing cartridges with extra memory or capabilities is not very difficult, and great for new software.
CD System cards are an issue, as mass producing one without completely reimplementing Hudson's original software is... a very poor choice legally.
The Turbo Everdrive 2 is actually the only available card which is grey enough to be exempt from this, since you're loading the software on your own.
-
Bundled with a Captain Midnight Decoder Ring? :lol:
And a special gen-u-ine Certificate of Authenticity!
CD System cards are an issue, as mass producing one without completely reimplementing Hudson's original software is... a very poor choice legally.
Hahaha ... you sunk my BattleShip! :wink:
Yep, this is the other Elephant in the Room.
Again, it's not one of those lines that I'd like to cross, but everyone gets to make their own choices.
If AetherByte or any other homebrew developer wants to flaunt copyright laws and start selling a "System Card 4", then it's up to them to take the risk.
Given that Konami couldn't even bother to stop Tobias from pirating one of their signature-properties, then I'd say that the actual risk is pretty low ... but it puts you over a line that you can never step back from.
It's one of those things that would stop me from wanting to personally advertise/sell/ship a "System Card 4" like that.
-
It looks like your competition for ROM-only cards is getting tougher....
...if you guys at Aetherbyte decide to stock and sell them.
Understood, but I'm not sure I want to have to glue the cards together.
And the open chip on the bottom bothers me, too.
We're not planning on selling them; I'd like to see the plans/files
freely available (under a non-profit license), so anyone could make them.
I think that ichigobankai has found out in the other thread that most
people really don't want to solder surface-mount components onto boards.
It's really not that hard, people. But I wouldn't suggest it, when you can
build a re-flow setup from an old toaster oven for cheap. :)
Does your $20-per-card-in-a-batch-of-50 estimate include contract-production
of the boards in China, all the plastic/spacers needed to make it fit properly,
and shipping to the USA?
Nope. Parts/materials cost only. And slightly over-priced at that. I'll have to
dig out my invoices to get an actual price.
Do you really think that any translator is going to want to pay money to
stock ROM/RAM cards just so that they can give away their translation for free???
Nope. But some folks really don't like emulators. A note that says it will play
on real hardware with these cards (and list them all) could generate a lot
of downloads.
Also, if some translator started requiring people to buy a "custom"
my-translations-only ROM/RAM card, then they'd get crucified by the rest of
the translation community!
And rightly so.
If Aetherbyte wants to make a generic 512KB/512KB "System Card 4" available for $20...
NOT an Aetherbyte project. Something for the community to play with. Strictly
non-commercial.
In fact, if there's money-to-be-made, then Tobias will just clone the card
and charge $60 for the "official" PCEWorks "Translation Card".
My lawyer would love that :)
CD System cards are an issue, as mass producing one without completely
reimplementing Hudson's original software is... a very poor choice legally.
The Turbo Everdrive 2 is actually the only available card which is grey
enough to be exempt from this, since you're loading the software on your own.
Which is one thing we won't do. Somebody trying to make money at it, maybe. But we
wouldn't include an unmodified Bios, which in itself is a grey area....
(In fact, in most cases, we wouldn't supply a bios anyway. We're not mass-producing them)
Edit: Missed a / on the quote tag :(
-
We're not planning on selling them; I'd like to see the plans/files
freely available (under a non-profit license), so anyone could make them.
That's very generous :D ... and also just what TailChao has done with the CD StupidCard.
It'll be great to have a choice for small-scale production ... but I'm not going to hold my breath waiting for it to happen. :(
It's really not that hard, people. But I wouldn't suggest it, when you can
build a re-flow setup from an old toaster oven for cheap. :)
Hahaha! :wink:
I so wish that I hadn't lost my interest in electronics after a bad semester, and had kept up-to-date!
But for "normal" folks, including me, it's going to be contract-production-in-China-or-nothing.
It's just like how I find programming "easy", but most folks with real lives have different skills instead, a lot of which make me horrified by my pathetic ignorance. :oops:
It's a complex world!
Nope. Parts/materials cost only. And slightly over-priced at that. I'll have to
dig out my invoices to get an actual price.
Thanks!
Nope. But some folks really don't like emulators. A note that says it will play
on real hardware with these cards (and list them all) could generate a lot
of downloads.
I agree, being able to play on real hardware should always be the goal. But that hardware has to be reasonably "available".
For instance ... I'm really tempted to write something that uses the PC-FXGA's 3D chip, because the lack of that on the PC-FX is one of the biggest mysteries of the machine.
But if I do so ... then what? There are probably only a handful of active PC-FXGA setups on the entire planet!
NOT an Aetherbyte project. Something for the community to play with. Strictly
non-commercial.
Thanks for the clarification. That helps put the whole thing in context.
In fact, if there's money-to-be-made, then Tobias will just clone the card
and charge $60 for the "official" PCEWorks "Translation Card".
My lawyer would love that :)
Even ignoring the likelihood that it wouldn't take Tobias more than a few minutes to find a Chinese engineer to make a compatible-but-different design, let's say that he just took your exact design.
Let's also say that he couldn't just find a way to "sell" it that wouldn't violate your license (i.e. include it "at-cost" with a "deluxe" $200 game-package).
Then would you really throw away thousands of dollars to sue him? In Germany?
That's a question that I had to ask myself when I put my "copyright" on the code that I included in the Zeroigar translation.
(In fact, in most cases, we wouldn't supply a bios anyway. We're not mass-producing them)
Well, IMHO that makes it pretty much like the CD StupidCard.
Absolutely amazingly wonderful for the few of us developers that have it, but unlikely to ever get manufactured/used in serious volume. :(
-
But for "normal" folks, including me, it's going to be contract-production-in-China-or-nothing.
Something important to point out about this -
Most of the larger "new-game-for-that-old-thing" releases are manufactured overseas. That's fine, but I very very very much recommend that you design the cards here, and carefully so.
I've seen 3.3V parts on 5V consoles without proper level shifting and ghetto ass diode regulators to drop the supply voltage for them. This is not cool for the parts, the console, or you. But it's done again and again because it's cheap.
This came up recently on spritesmind (http://gendev.spritesmind.net/forum/viewtopic.php?f=13&t=2170) if you want more reading material. Taking advantage of the greater availability of 3.3V components is wonderful, but it needs to be done properly.
-
But for "normal" folks, including me, it's going to be contract-production-in-China-or-nothing.
Ever bake a cake? Using a re-flow oven is just about that easy :)
(Well, ok, it's tough to get the parts in the right place without a magnifier...)
Then would you really throw away thousands of dollars to sue him? In Germany?
Nope. But I would have the lawyer send cease-and-desist letters to E-Bay.
And any other website where he advertizes :(
(btw, c-n-d's are about $50 each. Would be SOOOO worth it.)
Absolutely amazingly wonderful for the few of us developers that have
it, but unlikely to ever get manufactured/used in serious volume.
I'm not so sure about that... (check your PM's in an hour or so)
But even if not, it's enough if the guys here have/use it. Then
maybe we will see more games...and more coding tips :)
Well, IMHO that makes it pretty much like the CD StupidCard.
Absolutely. But without the fpga and the hassles of programming it.
Tailchao:
Every thing on the card is 5V. But as I've found out, when the address bus
changes, the voltage drops to the chips, causing the RAM to glitch.
I think that's why I need to add a filter cap.(0.47uF, iirc)
And just to stir things up: do you have enough gates left on that fpga
to add a sound generator? Just curious...
-
This came up recently on spritesmind (http://gendev.spritesmind.net/forum/viewtopic.php?f=13&t=2170) if you want more reading material. Taking advantage of the greater availability of 3.3V components is wonderful, but it needs to be done properly.
Thanks, the link was really interesting! :-k
Good points in there ... but I suspect that Tobias wouldn't care if a cheaply-designed 3.3V out-of-spec design took a few years life off of a PCE as long as it worked well-enough to last for a 90-day warranty period! :roll:
Even then ... we're basically talking about a 5V 512KBx8 SRAM and a 5V 512KBx8 FLASH chip, both probably in TSOP32 footprint. These aren't exactly exotic items to specify/purchase!
Ever bake a cake? Using a re-flow oven is just about that easy :)
(Well, ok, it's tough to get the parts in the right place without a magnifier...)
Hahaha ... you want to keep me away from the kitchen, I can burn anything! :oops:
Nope. But I would have the lawyer send cease-and-desist letters to E-Bay.
And any other website where he advertizes :(
(btw, c-n-d's are about $50 each. Would be SOOOO worth it.)
:)
I'm not so sure about that... (check your PM's in an hour or so)
I'll look forward to it.
But even if not, it's enough if the guys here have/use it. Then
maybe we will see more games...and more coding tips :)
Yeah, doing something nice for the folks here sounds good. I like this place, and people's appreciation of playing games rather than collecting boxes.
And just to stir things up: do you have enough gates left on that fpga
to add a sound generator? Just curious...
Have you looked at the Cypress PSoC 5LP?
5-volt 80MHz ARM + 256KB flash + 64KB RAM + small FPGA-like configurable I/O in a single 100pin TQFP package.
Connect that through to the PCE with a 5-volt 8KB dual-port SRAM, and you've got one heck of an interesting add-on board.
Give it and extra 1MB of it's own SRAM and you could do some really crazy stuff!
-
Every thing on the card is 5V. But as I've found out, when the address bus
changes, the voltage drops to the chips, causing the RAM to glitch.
I think that's why I need to add a filter cap.(0.47uF, iirc)
One small decoupling cap per VCC and a larger one for the whole board is best. But you can get away with way less on this hardware.
Not that production boards should be this way. It's fine for developer tools though.
And just to stir things up: do you have enough gates left on that fpga
to add a sound generator? Just curious...
It's actually a CPLD, and therefore isn't all that big (36 macrocells, actually).
So nope, no extra audio channels on the MCGenjin or MCGenjin-CD. Although...
Have you looked at the Cypress PSoC 5LP?
5-volt 80MHz ARM + 256KB flash + 64KB RAM + small FPGA-like configurable I/O in a single 100pin TQFP package.
Connect that through to the PCE with a 5-volt 8KB dual-port SRAM, and you've got one heck of an interesting add-on board.
Give it and extra 1MB of it's own SRAM and you could do some really crazy stuff!
...these are basically why I've never bothered to do audio expansion on a larger CPLD. We can buy chips which are way more complicated than the SuperFX ever was for peanuts.
Although personally, I think the PCE's audio is good enough on its own. But I'm going for the STM32F3 family for the 7800.
-
I've been thinking about the copyright issue for making a System Card 4, and trying to come up with alternatives.
I think that TailChao had an idea with the CD StupidCard that might work.
If what we're trying to do is to create a cheap System Card with expanded memory, rather than create a homebrew game cart with extra RAM, the we could reduce costs further and just create a 1MB RAM-only cart.
That would let us boot a DUO or SuperCD (with the System Card built in), and then load a boot-program off a CD.
That boot program would enable the 1MB RAM (disabling the built-in System Card), and then load up a System Card image from the CD.
Once booted in this fashion, the "System-Card-in-RAM" would stay there until you power-down the DUO (i.e. it would survive a soft-reset ).
This gets around having to manufacture the hardware with any Hudson-copyrighted BIOS on-board.
"Yes", you'd have to have a CD image somewhere with the BIOS, but that's a much easier problem to solve.
It would also be easy to just have a CD that loaded up HuCard images instead of a System Card image, so this system would also let people do pretty much everything that most people want to do with a Turbo EverDrive, but much cheaper.
The hardware would just be a 1MBx8 SRAM chip and a 74HCT109 flip-flop, approx $6.60 plus decoupling caps plus the board itself.
With a bit more thought, I might even be able to get it to where you wouldn't need to ship the BIOS on a CD (but you'd still need to boot from a CD).
Does that kind of an idea interest anyone?
-
If the card doesn't have the system 3.0 bios on it, then that means you have to swap cards when you want to play normal CD/SCD games. Or, make the card in such a way that it only works with Duo or SuperCDROM units. Or.. make a pass through connector version for older CDROM units to pair a system card with it. It just gets messy at any angle you approach it.
If using the original bios is an issue, then a brand new bios could be made. Game Express did it, and they used the standard CDFS boot sector approach too (not needed but interesting anyway). We already pretty much know how to access and interface with the hardware directly, because of emulators. And the systems cards have been disassembled. (Also, I think you asked in another thread what disassembler I use... it's one MooZ had made). Gamers will still have to swap cards, but at least it solves the bios problem. The bios 3.0 software could even be effectively re-written in the exact same functionality and not have the security sector ID that the original has (which is copy-righted IIRC). Thus, it's not the exact bios image.
I'll be completely honest; at this point I don't see using the original bios image as an issue. From the point of view of homebrew, CD games already contain the infringing security string of text. So there's already an infringement right there. I know it's nice to be closer in the clear than in the grey, or clearly in the wrong, but I don't know if it's worth the effort.
I honestly think the most important thing is to have a standard layout that can be used by multiple cards out there already, and people could assemble the card themselves (DIY). That way, more than one source and flavor exists that's compatible between them all. And if it's simple enough, people can also assembler their own cards (pcb, rom, ram, solder skills, etc). 512k rom with 512k ram works for me, but the idea of wasting that upper 256k rom nags at me. 256k rom + 768k ram is better. And 256k rom (mirrored 512k lower on power up), with upper 512k ram, and with another 512k ram mappable to lower range (map out rom) - would be ideal. CD StupidCard supports this and the TED 2.x I think supports this. Well, however they would get to that configuration anyway. On a DIY card, a simple mapper could be made by doing a read ( or read. whichever's easier) at external address $000000 (each time flips the active line to either the lower rom or lower ram; you'll have to keep track yourself. I'd personally map it once and leave it).
In the end, I guess it's up to the software guys as what they want to support (lowest common factor), and write detection routines to see what card they loaded from. TED has gobs of memory, but who knows how long it'll be around. The availability of CPLD chip on the CD StupidCard worries me, but I guess that could be reimplemented on an FPGA in a worse case scenario.
But here's the most important thing that bothers me... no software. There's no software, that I know of publicly, that's creating a demand for this new system card. And without that demand, only the few diehards are going to bother with it. That's why I was hoping the TED 2.x would hurry up and get here. The CD StupidCard is viable, but not accessible right now. Things could be prototyped and shown on the new TED to garnish interests in such upgrades. I have a few things that are essentially waiting for new TED to arrive (because people are opt to buy it anyway). Basically show off stuffs and generate interest (i.e. have it available to the public; something tangible in their hands. d/dx) .
Am I close to the mark here or am I off in lala-land?
OldMan: I know there are concerns of fragmentation of new upgrade cards and requirements, but to be completely honest - I rather that happen then nothing at all. Take my babbling opinions here with a grain of salt and get this new card done ;)
-
Take my babbling opinions here with a grain of salt and get this new card done
It's not getting it done that is the problem (We had a prototype working as far back as ccag).
It's getting it to the point where everyone (who really wanted to) could do it that is the problem :)
then a brand new bios could be made. Game Express did it,
That's sort of what I've been working on, among other things. Trying to Understand the cd access routines. In both the sys bios and the ge one. Scsi hardware is a bit tough for me to follow though.
Hardware drivers generally are. (ugh)
CD games already contain the infringing security string of text.
Which is one thing I'd like to see go away, believe it or not.
256k rom + 768k ram is better. And 256k rom (mirrored 512k lower on power up),
That would take a couple more gates than I would prefer to use right now.
Not un-doable, but.....
Right now, I'm just using a 2->4 demultiplexer to split the space. (with 2 outputs open)
A 3-> 8 demux is definately doable, but the chip select would require an or gate to respond right.
(Possibly a wired-or ? Haven't tried it...) I use A20 as a master 'card control' and A19 to select the chip.
A mapper register would require a lot more gates to implement; at which point an fpga is a better solution. Unfortunately, I know (next to) nothing about programming them, and again it's an added expense....
There's no software, that I know of publicly, that's creating a demand for this new system card.
Right. But its a chicken/egg problem. Without the card, there won't be software. And without software, there isn't a need for the card.
That's one reason I'd like the card easily and cheaply buildable. Then maybe (just maybe) more folks will start writing games for our beloved pce. Which would lead to more card sales (hopefully) which would lead, eventually, to a better card.
-
If the card doesn't have the system 3.0 bios on it, then that means you have to swap cards when you want to play normal CD/SCD games. Or, make the card in such a way that it only works with Duo or SuperCDROM units.
Yep, the 1MB RAM approach would only work on DUOs and SuperCDROM.
It's a limitation ... but it would make it both cheap and producible without infringing anyone's copyright.
The TED v2 is a "better" solution in every way ... and definitely my "preferred" one, but there is the question of price.
Now it seems like a reasonable price for what it offers to me ... but YMMV.
If using the original bios is an issue, then a brand new bios could be made. Game Express did it, and they used the standard CDFS boot sector approach too (not needed but interesting anyway). We already pretty much know how to access and interface with the hardware directly, because of emulators.
That's a great solution ... but someone has to write it, and it can't be like the cutdown Game Express one if you want to make it compatible with System Card 3 games so that it can run translations.
The idea was to make translator's lives easier, not to make them swap out every CD BIOS call to work with a new BIOS.
Now, for newly-written homebrew, you can do whatever you like.
I'll be completely honest; at this point I don't see using the original bios image as an issue. From the point of view of homebrew, CD games already contain the infringing security string of text. So there's already an infringement right there. I know it's nice to be closer in the clear than in the grey, or clearly in the wrong, but I don't know if it's worth the effort.
If you're willing to manufacture new System Card 4 carts for people to buy that contain Hudson's BIOS, or contain your own replacement BIOS, then that's great!
I honestly think the most important thing is to have a standard layout that can be used by multiple cards out there already,
Yep, totally agree.
and people could assemble the card themselves (DIY). That way, more than one source and flavor exists that's compatible between them all. And if it's simple enough, people can also assembler their own cards (pcb, rom, ram, solder skills, etc). 512k rom with 512k ram works for me, but the idea of wasting that upper 256k rom nags at me. 256k rom + 768k ram is better.
That's where you start to lose me. I just don't think that most game players are going to want to spend $1000 or so on all the items that they'll need to manufacture a $20 System Card 4.
Of those people that do, not all will be willing to advertise/sell a cart that uses a stolen BIOS, and that would that open them and their family up to litigation.
IIRC, this thread started with the dream of producing a cheap System Card that would give translators a bit of extra memory to make their lives easier and encourage translations.
Going up to 768KB RAM just isn't needed for that ... but you'd get it anyway with the 1MB-RAM card (or the TED v2).
When you're talking about homebrew development ... then the-sky's-the-limit.
But unless you want to sell a custom cart with every CD and have $100-plus homebrew games, then you might as well just aim for TED v2. At least they're going to be available, and they can also play HuCards.
Once they're not available anymore, then you can just clone KRIKzz's memory map (which I believe is just the Street Fighter II mapper with all RAM).
My idea of putting 1MB of RAM in a cart was mainly so that it could also play the entire HuCard library cheaply. That would actually give people a reason to buy one.
If people don't want that, then TailChao has already suggested just doing a 256KB add-on cartridge that would work with any DUO or SuperCDROM, and not require any software or CD swapping at all.
It would be transparent to any existing game, and only show up to a game that checked for memory in the $80000-$BFFFF region.
It's still 2 chips, a 256KBx16 SRAM and a 74HC138 decoder, and it's $3.00 cheaper in parts (so $3.60 plus decoupling caps plus board).
It would be compatible with TED v2 and the CD StupidCard, so it's not making the landscape any messier.
That's probably the best option for translations ... but I'd be surprised if anybody would buy one until there are translations that need it.
I could make the Xanadu translations require extra memory in order to create a market ... and it would definitely make my job easier. But that doesn't seem like a nice thing to do, even if it might slightly lower the chance of a PCEWorks boxed-set.
On a DIY card, a simple mapper could be made by doing a read ( or read. whichever's easier) at external address $000000 (each time flips the active line to either the lower rom or lower ram; you'll have to keep track yourself. I'd personally map it once and leave it).
It's easy to make things as complex as you like if you're willing to make people buy/use a CPLD programmer on top of everything else.
I was trying to keep things as simple as possible so that it's easy to make (or preferably get cheaply contract-manufactured in China).
But here's the most important thing that bothers me... no software. There's no software, that I know of publicly, that's creating a demand for this new system card. And without that demand, only the few diehards are going to bother with it.
Yep, that's the big issue.
There's no need for a "System Card 4" yet, and until something with extra RAM is available, then any translation that needs more memory is going to limited to running in Mednafen, or with a TED v2.
That's why I thought the 1MB RAM cart made at least a tiny bit of sense ... you can actually do something useful with it.
That's why I was hoping the TED 2.x would hurry up and get here. The CD StupidCard is viable, but not accessible right now. Things could be prototyped and shown on the new TED to garnish interests in such upgrades. I have a few things that are essentially waiting for new TED to arrive (because people are opt to buy it anyway). Basically show off stuffs and generate interest (i.e. have it available to the public; something tangible in their hands. d/dx) .
Am I close to the mark here or am I off in lala-land?
Nope, I think that you're pretty much right-on.
At this point, anyone that wants extra RAM should make sure that their stuff runs on the TED v2.
When there's actually a need for a cheaper alternative, then someone can make one, with whatever design they believe make sense.
[EDIT]
Oh, BTW ... I just realized that it would be pretty easy to create a generic patch program that would add the CD BIOS to a translation's ISO before you burn it so that it would run on the 1MB-RAM cart without any CD-swapping. You'd just expand the patched-game's ISO track by another 256KB.
-
Honestly, different hardware will not bring the PCE/Turbo to a wider audience. Its slice of the pie is what it is now.
Adding advanced hardware to a system which won't enhance the experience of all games prior is just a novelty. Look at the MSU thingy for the SNES. It adds FMV and streaming audio to hacked/original games. Whoopee. It'll be put into repros and sold only to collectors.
-
Honestly, different hardware will not bring the PCE/Turbo to a wider audience. Its slice of the pie is what it is now.
I don't think that anyone has ever suggested that any of these alternatives would do that.
Adding advanced hardware to a system which won't enhance the experience of all games prior is just a novelty. Look at the MSU thingy for the SNES. It adds FMV and streaming audio to hacked/original games. Whoopee. It'll be put into repros and sold only to collectors.
Yep, that's my concern with any of the hardware add-on suggestions, even the ones that I'd like to see.
It sometimes reminds me of Amiga demo-scene programmers ... "yes" there are plenty of "cool" tricks that you can do, but what's wrong with actually trying to make a game with the machine?
We've already got 2MB with the Arcade Card, and that's a pretty huge chunk of memory to fill. I've not seen any homebrew that takes good advantage of that, yet.
But I can understand the idea of providing translators with extra memory to make their job easier.
As to whether there's really a need for it ... well, that's a different question.
-
I was mostly replying to this:
That's one reason I'd like the card easily and cheaply buildable. Then maybe (just maybe) more folks will start writing games for our beloved pce...
The (admittedly, very qualified) implication being that the barrier to new & more homebrew on the PCE is a lack of flash/system/ cards in general... which I don't believe is true. I think the barrier is a lack of nostalgia and cultural momentum outside of small pockets in France, the USA, and a shrinking group in Japan. It isn't technical. (And even if it were, I think CD games are far cheaper to produce, more distributable and reproducible.)
As to whether there's really a need for it ... well, that's a different question.
:D Yes, if everybody used SWD3 compression :D
-
The (admittedly, very qualified) implication being that the barrier to new & more homebrew on the PCE is a lack of flash/system/ cards in general... which I don't believe is true. I think the barrier is a lack of nostalgia and cultural momentum outside of small pockets in France, the USA, and a shrinking group in Japan. It isn't technical. (And even if it were, I think CD games are far cheaper to produce, more distributable and reproducible.)
Sorry, my bad, I'd forgotten about that post. :oops:
Yep, I 100% agree with you ... on all of that.
I don't get the ROM/RAM card idea unless you're going to make them dirt cheap and put a SystemCard3-compatible BIOS on them ... and that just opens you up to a world-of-hurt ...
... or to waiting for Bonknuts to write a compatible System Card 4 BIOS from scratch and still sell the whole package for a price that dramatically undercuts an $80 TED v2.
**********************
Now, I could easily write a small homebrew CD game that just-happened-to-include a compressed System Card 3 image on it that the CD pressing factory would never find, and make a $10 1MB-RAM card in China and still sell the whole package for half-the-price of a TED v2 ...
and then bootable images could find their way onto sites-that-shall-not-be-named that would contain every HuCard game (except Street Fighter II) that would run on this cheap setup.
But why-on-Earth would I!!! I have no desire to be PCEWorks!!! ](*,)
But I bet that Tobias would love the idea, though ... it would probably be a $300-$500 product for him, and the hardware is dirt-cheap. The "naughty" CDs could even be made to work on a TED v2 to cater to his collectards with IFUs. #-o
:D Yes, if everybody used SWD3 compression :D
Hahaha! That's just SO last-year, we're up to SWD5 now, with a new go-faster stripe and cup-holders! :wink:
But I think that your point is probably that the real issue is more one of finding programmers that are willing to do PCE translations rather than an actual limited-hardware problem ... and I suspect that that could probably be true.
I hope that my terminally-dull blog is giving people some idea of WTF it is that a programmer has to do on any reasonably-complex translation.
For whatever reason, there seem to be more active deeply-technical programmers that are willing to go-the-extra-mile on platforms like the NES and the SNES than there are on the PCE.
That sucks ... but I don't know what those of us that love the system can do about that.
-
FWIW ... I've done some more logic-designs for the 1MB-RAM ...
With two 15c logic chips instead of one, the 1MB-RAM card can be made to copy the DUO/DUO-R/SuperCDROM BIOS over to itself when booted from a CD.
That would avoid needing to ship a CD with Hudson's original BIOS, and would make the product 100% legal to manufacture and sell, and 100% compatible with the existing BIOS.
Add a 3rd 15c logic chip, and the 1MB-RAM card would be in "stealth-mode" and not appear at all until actually activated by a translation. That activation wouldn't "break" compatibility with translations that wanted to use the memory on a TED v2 or a CD StupidCard.
In that case, the 1MB-RAM could sit permanently in the cartridge slot of a DUO/DUO-R/SuperCDROM and not cause any problems with normal CD gameplay.
***************
The benefit of the 1MB-RAM card is that you could load and run regular (or translated) HuCard images onto this $10-in-parts card, just as you can currently do with an $80 TED v2 ... so it becomes a reasonable alternative purchase.
IMHO ... that would give it a market.
Now, as Bonknuts pointed out, it wouldn't work for original IFU/TG16CD owners.
So what?
They can still go out and buy a TED v2 to get the same functionality ... and we've already had exactly the same issue with the ArcadeCard PRO vs the ArcadeCard DUO, and it's not caused the entire PCE community to start fighting amongst each other.
So ... IMHO ... if there really is a need/desire for a cheap "Translation Card" as an alternative to the TED v2, then just do it as a 1MB-RAM card.
In the meantime, I'll just continue using the CD StupidCard, and the TED v2 (when it finally gets replaced and sent back).
-
I was mostly replying to this:
That's one reason I'd like the card easily and cheaply buildable. Then maybe (just maybe) more folks will start writing games for our beloved pce...
The (admittedly, very qualified) implication being that the barrier to new & more homebrew on the PCE is a lack of flash/system/ cards in general... which I don't believe is true. I think the barrier is a lack of nostalgia and cultural momentum outside of small pockets in France, the USA, and a shrinking group in Japan. It isn't technical. (And even if it were, I think CD games are far cheaper to produce, more distributable and reproducible.)
The problem with the CD audience is, it's a smaller subset of the already small audience, due to CD hardware being semi-retarded and breaking, followed by needing to be repaired.
The real goal of a card like this is something of a DoucheBag Deterrent (TM), that happens to add extra capabilities that you could, in theory, use for some other project.
All for a cheap price. Anyone with a US machine is usually pretty pissed when they find out the cost of a US System 3.0 card, for example.
I have some other ideas/reasons why the machine doesn't see more homebrew, but that is a different discussion altogether.
-
I thought it better to move this back into your thread ...
TheOldMan and I seem to have different ideas of what an affordable-and-practical card might be ... but at-the-end-of-the-day, ALL of the current and proposed cards provide a nice-and-simple 512KB of RAM for translators.
.....At the end of the day, I want to be able to pick up an empty pcb, add rom/ram as requested, flash the rom, pack it in a carrier and send it out.
That way, I only need 1 card blank for production, and I don't have to worry about over-buying boards.
That makes absolutely perfect sense.
It's a good idea, and just like ichigobankai's ROM-only card, which has surface-mount points for various different sizes of ROMs.
I believe that you're absolutely right that it's the way to go for small-scale home-manufacturing of the cards.
And your card (when flashed as a System Card) should be compatible with the TED v2 and CD Stupid Card for any translations that want that extra RAM ... perfect!
My only problem, is that as someone currently doing a translation, if I really need the extra memory, then the only "Expanded System Card" that is out there that people can actually go and buy now is the TED v2.
If you can change that landscape, then great! :clap:
The real goal of a card like this is something of a DoucheBag Deterrent (TM), that happens to add extra capabilities that you could, in theory, use for some other project.
If you want to use a ROM/RAM card as some form of a copy-protection dongle, then that's up to you.
I can see that function as potentially appealing to some developers. Not to me, to certainly to some.
All for a cheap price. Anyone with a US machine is usually pretty pissed when they find out the cost of a US System 3.0 card, for example.
I'll be interested to see what price you're going to ask for a manufactured-and-burned US System 3.0 card. :-k