|
Post by spenoza on Feb 14, 2023 16:51:35 GMT
I know some folks on here have dabbled in hardware creation. How complex would it be to implement a simple universal ROM mapper for the PC Engine? I'd love to see the system able to support large HuCard sizes, and there are already homebrew solutions for HuCard boards. How complex or expensive would it be to create a HuCard board with a mapper chip built into it? Are there any affordable chips that would be able to easily replicate mapper functions or would this need to be a PLA or CPLD? How complex is a mapper?
Would it be easier to take a Game Genie / Deck Enhancer style approach instead, where there's a standard mapper on an in-between cartridge that connects to the system and includes a card slot for games to connect to?
Just exploring these ideas to see what makes sense.
|
|
|
Post by crisgenjin on Feb 14, 2023 21:24:58 GMT
Just imagine a version of the Deck Enhancer made for Turbografx-16 by Camerica...it gives me the chills
|
|
|
Post by dshadoff on Feb 15, 2023 1:50:42 GMT
Not sure what you mean by "universal ROM mapper"... there are so many different techniques to do such paging (although NES and SNES are more the examples of that than the PCE).
It's not really realistic to consider such a thing in hardware, as there aren't really any 5V-logic FPGAs available - only a couple of very simple CPLDs, and they are no longer in production (so would likely need to be bought in the unreliable secondary market). When you move to 3.3V logic, there are a lot more options, but then you need to level-shift all of the address and data lines, which complicates matters by a lot. At that point, you are essentially creating a TurboEverdrive... so yes, it would be expensive.
But I have to ask - if the PC Engine lived out its entire life with only Street Fighter II needing a mapper of this type, why is one needed so much that people keep raising the topic ?
|
|
|
Post by spenoza on Feb 15, 2023 2:38:39 GMT
Because from the perspective of a home brew developer there’s a lot of cool things you can do when you have a lot of ROM space available that you can’t do with CD working from more limited disc cache. An 8 meg HuCard can get pretty restrictive when you’re a novice coder trying to do fun things without the benefit of tight compression and efficient coding. And when you want to target actual hardware there are reasons to want to target the lowest common denominator (larger audience for a physical product, among them), which is the HuCard medium.
There’s also that a project like this could be interesting and fun.
Given some of your own hardware projects and explorations I’m not sure why you’re so negative about this particular one. I legitimately don’t understand your antipathy toward it.
|
|
|
Post by dshadoff on Feb 15, 2023 4:29:00 GMT
It's more confusion than antipathy... for example, there is the very real cost of additional hardware to consider, which is always underestimated as I explained earlier.
If this is a question to discuss practical application, I think very few people have fully-utilized the currently-available memory on the system, so this is a long way from actually being put to use. In other words, this could a valid point to discuss when it is a common occurrence that such huge things are written, and once other avenues (such as CDROM) have been exhausted.
If this question is intended to daydream about doing "cool things", I might find it more interesting to add something completely new to the PCE (for example, a second screen or something). It's just that a memory mapper is so mundane compared to its development cost, and the range of problems that are solved by it are generally already solved by other means.
There is immense untapped potential in the console as it is - much of it completely untapped by the homebrew community.
Virtually nobody is discussing using assembly language to make programs smaller and faster, and creating new, cool things that way... and for some reason, discussion often comes back to augmenting the system with additional hardware (99% of the time, memory) to accomplish an unstated goal.
I get the feeling that memory is basically just a way to justify avoiding learning assembly language. If this is the case, perhaps another console might be more suitable - such as the PC-FX with a more efficient compiler, CPU which is multiple times faster, a huge bump in memory, and so on...
|
|
|
Post by spenoza on Feb 15, 2023 15:28:40 GMT
The problem with assembly language is that it takes a great deal more time and effort to learn well for hobbyist coders. Further, there are some entire genres of games which are simply impractical on PC Engine without, essentially, the Arcade Card: post-Final Fight beat 'em ups, for example. One need only look to Riot Zone and the size of the carts associated with those types of titles on the SNES and Genesis to see why. I see it this way: if we wait too long for a use case then the lead time on responding to the use case may result in that use case disappearing. Further, having a physical example means that can then be recreated in emulators and the Turbo Everdrive, ensuring compatibility for those who want physical objects and those who just want a ROM they can play. And planning ahead can result in some careful thought on the simplest, easiest, and/or cheapest way to implement this kind of solution.
Maybe the answer is a new Turbo EverDrive product with a HuCard slot on it so it can be a flash card AND an Aladdin Deck Enhancer all in one. Then there could literally be a line of EverDrive Enhanced HuCards. Talk about limiting your audience!
|
|
|
Post by dshadoff on Feb 15, 2023 16:01:11 GMT
I see it this way: if we wait too long for a use case then the lead time on responding to the use case may result in that use case disappearing. Further, having a physical example means that can then be recreated in emulators and the Turbo Everdrive, ensuring compatibility for those who want physical objects and those who just want a ROM they can play. And planning ahead can result in some careful thought on the simplest, easiest, and/or cheapest way to implement this kind of solution. I understand the way that you are thinking, but in the hardware world, thinking ahead doesn't always work the way that you expect (especially over the past few years where parts shortages have required multiple redesigns, chasing availability of parts). There was already one of these made many years ago called the "MC Genjin" here: www.tailchao.com/TurboGrafx/index.phpThis card: a) Was made with the lowest-cost available parts of the day, and still was not cheap. b) Was implemented into (at least one) emulator, Mednafen. c) Was basically not used for a single project (that I am aware of). d) Is now far more expensive (and problematic) to produce due to the fact that the 5V CPLD is no longer manufactured e) Has available plans so that you can get it remanufactured if you can obtain the parts. But just remember that "thinking ahead" does not always work out the way that you think it will, since this is significantly more difficult to make now than it was back then, due to part production lifespans.
|
|
|
Post by spenoza on Feb 15, 2023 17:46:37 GMT
It may be that a new TurboEverdrive or other multi-function peripheral may be the best way to explore this, simply as an added or additional capacity.
|
|
|
Post by dshadoff on Feb 15, 2023 17:53:56 GMT
I agree with this - trying to sell a HuCard with a mapper (or other new hardware) plus the game on it, is going to be a headache, partly due to expense and partly due to logistics of design and assembly.
Making it a one-time expenditure like a TurboED or the upcoming Pro model will be far easier, from the point of view of logistics, planning, and distribution.
The upcoming new Pro card will also have the ability to make RTL updates - which essentially means that some sort of mapper or special functions could theoretically be implemented as a downloadable component on the TurboED Pro... although it's not yet clear how expandable it would be, or how easy it will be to implement such a thing.
|
|
lunoka
Gun-headed
Diving into retrodev
Posts: 55
Homebrew skills: art, music
Fave PCE Shooter: Burning angels
Fave PCE Platformer: Ninja Spirit
Fave PCE Game Overall: Valis 3
Fave PCE RPG: Neutopia
|
Post by lunoka on Feb 15, 2023 18:26:50 GMT
Your discussion gives me some ideas What about an adaptor that leads to use a well known form factor, the GBA cartridge. It seems to be easy to produce some since molds exist. The Nintendo DS game box has a slot for gba cartridge and is also easy to find for a good price. That would lead to a nice complete game in box. The adaptor could look like this ( done quickly, sorry ) : Now, is it possible to refine a gba pcb with the right eeprom format for the cartridge, and how would be the pcb into the adaptor? Of course, this format can be interesting only if a bunch of developers are willing to use it. So it needs a line up, social network awareness and so on. My concern about the next Turbodrive is the price, prolly around 300 bucks with shiping & taxes which could be a no go for many people, except developers or "easy money" fans. An adaptor like this could be maybe less expensive. For the records, a full GBA game can be manufactered for less than 10 bucks actually. The current RetroBlaster PCE worths 24 bucks for the cartridge only ( the hucard slot 3d printed is another cost + the crystal box ). I've found something like 20 bucks for a full MD game, maybe less for a SNes game since the box in cardboard. Any opinion ?
|
|
|
Post by spenoza on Feb 15, 2023 20:09:28 GMT
One thing Dave definitely has right is that this is less about the challenge of designing a solution, since mappers are not complex things, but about dealing with existing parts and component supplies. The entire retro-gaming landscape has had to content with the shift from 5v to 3.3v parts. That said, I can't help but wonder if there aren't some easier ways to do this than using a CPLD or level-shifting 3.3v parts. Is there some way to embed some very rudimentary logic using some very basic parts? I know people used to hand-wire chip prototypes. Is there anything suitable for 5v use that falls between an unobtainable CPLD and hand-wiring something?
|
|
|
Post by spenoza on Feb 15, 2023 23:55:59 GMT
So, I don’t know what level of complexity would be required, but I’m seeing a lot of affordable CPLD chips that support 5V at Mouser. Amtel seems to still sell in this market.
|
|
|
Post by elmer on Feb 16, 2023 0:21:41 GMT
So, I don’t know what level of complexity would be required, but I’m seeing a lot of affordable CPLD chips that support 5V at Mouser. Amtel seems to still sell in this market. Yes, Atmel are still making 5V CPLD chips ... cool!
I look forward to seeing your logic design and board layout, and how it all fits into the physical space available for the circuit on those new homebrew flash cards.
|
|
|
Post by elmer on Feb 16, 2023 0:24:10 GMT
Question ... how much was it to manufacture a CD again, lets say with an order of 500?
|
|
|
Post by dshadoff on Feb 16, 2023 4:06:39 GMT
So, I don’t know what level of complexity would be required, but I’m seeing a lot of affordable CPLD chips that support 5V at Mouser. Amtel seems to still sell in this market. If you're talking about the ATF150x series, you would need to also purchase Prochip Designer software for $250, and a USB programmer cable for another $230 or so. Lattice also did the same thing a few years ago for their ispMACH4A series chips - took software which was once licensed at no cost, and suddenly assigned a very tangible cost to it. This is the world of 5V CPLDs.
|
|