New turbo dev board

[TurboXray]

http://www.penguinet.net/TailChao/Hardware/PCEngineKit/index.php

 Interesting

[Arkhan Asylum]

Nice timing, Tom.

No wonder you were bringing up PenguinNet recently!  It all makes sense

I figured this would be coming eventually seeing as the memory mapper came out awhile ago.

Too lazy to check atm, but what kind of cost is involved to get one ready to go?

[Nazi NecroPhile]

Aww, little Bonk's taking a nap on a chip.

I am le dumb, so the rest of it is mostly gobbledygook.

[Arkhan Asylum]

Aww, little Bonk's taking a nap on a chip.

Too bad thats not really on the chip.  It would be =3 worthy.

It's basically a fancy shmancy DIY dev board for testing HuCard games out on real hardware. 

[spenoza]

So, using this mapper, what is the maximum HuCard size that can now be achieved by the homebrew community? Does it add any other functionality? I noticed the dev board supports saves. Not sure what one does with the other chipsets on the board.

I still want to know if the card slot would allow for any kind of hardware upgrades, ala NES/SNES/GEN cartridges which added various co-processors and sound capabilities.

[OldMan]

So, using this mapper, what is the maximum HuCard size that can now be achieved by the homebrew community?

The 29F032 chip he's using is 32 Mbits, or 4M byte. (That's about twice what the card slot can access directly)

Does it add any other functionality? I noticed the dev board supports saves.

It adds on-cart save memory. So far as I can tell, that's all.

Not sure what one does with the other chipsets on the board.

One chip is memory for the mapper. It's kinda like the MMR registers on the pc-engine cpu.
The other chip is the backup memory (Static Ram).

I still want to know if the card slot would allow for any kind of hardware upgrades, ala NES/SNES/GEN cartridges which added various co-processors and sound capabilities.

The card slot does provide for external audio, so that's possible. I doubt a "co-processor" would be possible, since you only  have access to the address and data lines. It -would- be possible to add a "sub-processor", where you sent it values and it computed some result, probably by triggering irq2. Dunno, for sure, but it -sounds- possible, and may be how the Arcade System Card handles it's shift registers.

The major problems with any kind of external add-ons are pretty basic though. There's no access to the internal clock (so any external chips would need their own clock circuitry), and the power supply is pretty loaded just supporting the (albeit older) roms. For anything very powerful, you would probably need some source of external power, too.

[TurboXray]

So, using this mapper, what is the maximum HuCard size that can now be achieved by the homebrew community?

He has two versions; 4MB (32megabit) and 8MB (64megabit) versions. The SF2 extended mapper (supported by mednafen emulator) supports 68megabits, so it's still the largest. But this dev carts additional ram makes it pretty bad ass.

 

Does it add any other functionality? I noticed the dev board supports saves. Not sure what one does with the other chipsets on the board.

8k save ram(FRAM) and 128k SRAM (for general purpose extended ram). Though ram is mapped to banks $60 to $7f, so I guess there will be a 256k sram version at some later point or just the 128k ram is mirrored once. I really hope a 256k ram version is available. The mapper chip also supports switching the data lines. It's possible to set a hucard so that the single reset vector points to two legal addresses in the boot bank range, thus giving you bi-region boot support. If it boots in the 'wrong' region, it you have a small piece of code write to the appropriate control register (writes to even byte addresses in the lower 512k external address range) so switch the data lines, then continue on as normal.

 This card mapper isn't compatible with SF2 mapper. And as he has it setup now, it won't load 'commercial' roms that are larger than 512k (4megabit). The mapper might support up to 32Mbit and 64Mbit, but the address range is limited to the lower 512k. With the lower 512kbyte range split into two 256kbyte segments, the upper 256kbyte segment mappable. This card is for new dev, not playing old roms on a fancy new flash card.

No wonder you were bringing up PenguinNet recently!  It all makes sense

No, that was just pure coincidence. I just got a PM from TmEE with this link about 5 minutes before posting it here. I did get a PM from Osman over a month ago over at AA forums, but I've been so busy lately that I never looked into it or got a chance to reply.

[Arkhan Asylum]

The PCE doesn't need any external sound addons.  The PSG is perfect.  Anyone who disagrees is deaf.  We don't need any external add-ons, really.

I think the overall goal of this is to give developers doing larger HuCard games the means to test it on real hardware since emulators are not 100% reliable.  The current flash cards out there right now sometimes have issues with large games.  I know NeoFlash doofs out with Coryoon around level 3 or 4.  Sprites stop showing up properly.

It sounds like this cards mapper problem is similar to NeoFlash's.   Large HuCard games on NeoFlash go all retarded.

Does he ever have plans to assemble and sell the things directly to people, or will it forever be a DIY process? 

[OldRover]

I'm curious as to the power drain on this thing... that's a lot of circuits.

[Arkhan Asylum]

I wonder if we will see any of it in action?  I myself don't plan on building one.  At least not any friggin time soon.

[thesteve]

it could be worthy of having the boards made up if the demand for larger home brew cart games is there

[Arkhan Asylum]

The demand is already here.

The problem is finding someone who can commit to something of that caliber.  So far, there ain't alot of that.

[BlueBMW]

Im ready and willing to make a home brew hucard.  Ive got a 1mb design nearly ready to go but I don't want to step on anyones toes since I know some of you are already making cards.  So you guys let me know what you'd like to do.   Up front it will cost about $160 + chips for 8 prototypes (to make sure the design is sound and reliable)  then beyond that it will take a healthy investment to.produce larger quantities.  Minimum $500 and upwards of $1500 depending on how many are made.

I just want to see it happen!!

[Arkhan Asylum]

Im ready and willing to make a home brew hucard.  Ive got a 1mb design nearly ready to go but I don't want to step on anyones toes since I know some of you are already making cards.  So you guys let me know what you'd like to do.   Up front it will cost about $160 + chips for 8 prototypes (to make sure the design is sound and reliable)  then beyond that it will take a healthy investment to.produce larger quantities.  Minimum $500 and upwards of $1500 depending on how many are made.

I just want to see it happen!!

Dont worry duder, we got you covered.    What do you think the prototypes are to raise funds for? Moar cards!

[TurboXray]

I'm curious as to the power drain on this thing... that's a lot of circuits.

Yeah, but the chips use /CE and/or /OE which keeps the device/chip disabled until the chip is accessed. Keeps the power consumption low. The custom mapper is a CPLD, which should be less power consumption than says a series of logic chips or an MCU. But it would be nice to know how much is draws. The Arcade Card Pro by comparison has much more ICs on it, along with an external crystal (round can), the interface logic (AC regs, dram controller), 4 dram chips, two sram chips, and one rom chip.

 I just got a reply back from Osman. Apparently CS0 and CS1 are the full 256k address ranges each. You can put whatever you want there (that fits the surface mount pin configuration). You can run two 256k sram chips for a total of 512k sram in the upper 8megabit range. Or an audio device upgrade for one of the 256k mapped range. The 4MB card also has the additional address line to access the full 8megabyte rom range, you just need to make an adapter board for such a rom setup (like his tsop to 40 pin dip board adapter).

 I'm gonna pay him for an assembled board so I can mess around with this. I have no idea if he plans to build them on request or not, but he put the VHDL source and board layout out there for anyone to do it themselves - so it's not unreasonable that someone else couldn't make up a batch of these instead if he doesn't have the time.

It sounds like this cards mapper problem is similar to NeoFlash's.   Large HuCard games on NeoFlash go all retarded.

The difference is Neoflash has support for the full 8megabit address range for rom, where this card doesn't (at all). I know some hucard games are setup where they need some parts of the rom to be mirrored into the additional address range (and the game accesses it in that mirrored range), even if they aren't that big as a ROM file itself. Completely different issue.

[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 Asylum]

sounds like it will have issues when you approach large-as-fuckness 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 Asylum]

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

[TurboXray]

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-fuckness 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 Asylum]

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

[TurboXray]

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-fuckness 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 Asylum]

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!