New turbo dev board

[spenoza]

So, does this dev board have limitations that a commercial developer wouldn't have? How will this limitations potentially impact homebrew developers and development?

[Arkhan]

sounds like it will have issues when you approach large-as-f*ckness with your games.

and then comes the limitation of getting these made.  It's for hardcore tinkering, IMO

[BlueBMW]

They don't look too difficult to manufacture but with that many chips and the second board / chip the cost will definitely rise substantially over a simple single chip hucard solution.

[Arkhan]

They don't look too difficult to manufacture but with that many chips and the second board / chip the cost will definitely rise substantially over a simple single chip hucard solution.

yep.

plus it doesnt fit in a jewel case

[Bonknuts]

They don't look too difficult to manufacture but with that many chips and the second board / chip the cost will definitely rise substantially over a simple single chip hucard solution.

 The mapper itself is what the card is about, more so than anything else. If a game doesn't need more than 8megabits or FRAM or some special setup, then there's no reason at all to use this. And on that note, technically all that needs to be on the card to function is the mapper and the rom. SRAM and FRAM aren't required, they're just options. They can be cut/left out entirely.

sounds like it will have issues when you approach large-as-f*ckness with your games.

 What issue is that?

So, does this dev board have limitations that a commercial developer wouldn't have? How will this limitations potentially impact homebrew developers and development?

 From a new dev point of view, no. The only real limitation is for existing roms (no source code) that are larger than 4megabits because the specifically use part or whole of the upper 4megabit address range. Source code can and is easily made to accommodate the mapper's extended layout. I think the only real limitations you have is when you decided on a project that requires quite a bit of complex setup (fram, sram, large rom) since you'll need the additional ICs, but you'd want to somehow put that in the smallest slimmest form factor as you can. I personally wouldn't sell games for hucards looking like this. These are dev boards. Production boards would use much slimmer surface mount chips and possible (optimally) thin PCB board glued to a plastic bounding board much like with the original hucards. But I guess cost will ultimately determine how fancy your production run hucards will be.  

[Arkhan]

What issue is that?

You kinda answered it yourself! 

From a new dev point of view, no. The only real limitation is for existing roms (no source code) that are larger than 4megabits because the specifically use part or whole of the upper 4megabit address range. Source code can and is easily made to accommodate the mapper's extended layout. I think the only real limitations you have is when you decided on a project that requires quite a bit of complex setup (fram, sram, large rom) since you'll need the additional ICs, but you'd want to somehow put that in the smallest slimmest form factor as you can. I personally wouldn't sell games for hucards looking like this. These are dev boards. Production boards would use much slimmer surface mount chips and possible (optimally) thin PCB board glued to a plastic bounding board much like with the original hucards. But I guess cost will ultimately determine how fancy your production run hucards will be. 

Anything large always has issues.  It's never as easy as it sounds on paper   See: Mysterious Song.

Rover will attest to that, hah.

[spenoza]

So, basically, you can build large games, but if the game is larger than 4 MB and up to 8 MB you have to do a little reprogramming if you want it to work on a flash card. That doesn't sound like a problem. I imagine if you were doing a custom, super-large huey you'd have to use the dev cart mapper on the finished product anyway.

Has anyone tried to reverse-engineer the Street Fighter II' mapper?

[BlueBMW]

Just a hypothetical here... but would it be possible to have a game that ran off of the hucard but also had the proper access etc to also use the CDROM for either additional data or redbook?  With one of these larger hucards, I'd think you could have the system card rom as well as a game in some sort of hybrid.

[mrhaboobi]

now if we could get a dev board that had a USB slot to allow uploading of the game that would be awesome, with my yaroze it all connects to PC via USB, very easy to build, deploy and debug on real hardware  

[Bonknuts]

Just a hypothetical here... but would it be possible to have a game that ran off of the hucard but also had the proper access etc to also use the CDROM for either additional data or redbook?  With one of these larger hucards, I'd think you could have the system card rom as well as a game in some sort of hybrid.

 Well, technically that's what the system cards do. They're hucards that access the CD addon hardware. So there's no reason why any other hucard (non system card) couldn't as well.

[mrhaboobi]

What happened to this?

[TailChao]

sounds like it will have issues when you approach large-as-f*ckness with your games.

and then comes the limitation of getting these made.  It's for hardcore tinkering, IMO

Not so much for hardcore tinkering, it's purely for the development of new, larger games which will function in both regions from the cardslot. It's best to think of it like the MBCx mappers on the GameBoy, rather than a flashcard for playing commercial games.

There's no issue with running larger games from the card, unless you're trying to play commercial games on it. In which case you could only go up to 256KB (since the swappable bank defaults to mirroring the first 256KB on reset). If you're writing a new game, you can use all 8MB of the extended address space.

plus it doesnt fit in a jewel case

It is completely feasible to fit all of the components on a 4MB Plus card into something the size of a System Card 3.0, but of course that's only for actual manufacturing and not development.

What happened to this?

Not very much, actually.
I made a few custom 4MB ROM + 512KB SRAM MCGenjin boards for developers from some of my old testboards, and may do a proper layout of this configuration later in the year. Tomaitheous noted that something like that could be used as a new CD-System card, and I do like that idea.
Other than that I put together an additional notes document here: http://www.penguinet.net/TailChao/Hardware/PCEngineKit/MCGenjin_SP.txt, which contains some information about a suggested header format and some mapper "gotchas."

Emulator support was hinted at, and I will try to find the time to look into Mednafen's source and add it. But right now I am occupied by work and a new Lynx project, and have only really used my own 4MB Plus cards for some library tests and backing up the BRAM on my TG16-CD.
But of course, if any new things are done with the mapper they will be uploaded here: http://www.penguinet.net/TailChao/Hardware/PCEngineKit/index.php and I'll post the updates in this topic.

[Arkhan]

It is completely feasible to fit all of the components on a 4MB Plus card into something the size of a System Card 3.0, but of course that's only for actual manufacturing and not development

yeah, but then it's not DIY, and it costs a shit load


Also, I think larrrrrgeeeeee games are hardcore tinkering in general.  They're alot of work!