|
Post by spenoza on Dec 20, 2019 3:29:17 GMT
Nintendo was always the king of mappers and extra memory and chips on carts, but even Sega dabbles lightly in that space. And now there are “home brew” carts with those kinds of augmented capabilities for hobbyists. Has anyone considered doing this for PCE, aside from tapping into the Turbo Everdrive? An extra 128k or RAM and a little CPLD with some additional functions? I know the CD units and system cards help the PCE put a bit, but I like the idea of having something available for programmers aiming for a Core or Turbo but who still want some extra tools or extra oomph.
|
|
|
Post by dshadoff on Dec 20, 2019 3:44:42 GMT
I had considered the possibility when I recently made a HuCard in this thread: pcengine.proboards.com/thread/847/homemade-backup-hucard-tennokoe-hardwareThe first post is a little long, but right at the end I wrote a few things under the "Note for Future" heading. ...Having said that, this was pretty recent, and I haven't thought too seriously about how to make it happen (or specific reasons which would make it worthwhile...). Do you have some ideas on the subject ? I mean, "limitless HuVideo" would be a thing which might be nice... Or, "filesystem-based access to at-least-CDROM-sized-media" as well... Or real-time clock ? ...What feature(s) would you desire ?
|
|
|
Post by gredler on Dec 20, 2019 6:45:47 GMT
...What feature(s) would you desire ? Ignorant astronomical request: Additional tile support to streamline/improve offsetting and animating tiles
|
|
|
Post by dshadoff on Dec 20, 2019 13:38:32 GMT
...What feature(s) would you desire ? Ignorant astronomical request: Additional tile support to streamline/improve offsetting and animating tiles Hmmm... not sure what you mean. Are you speaking of video-processor-related functions ? Those would need to go on the back port, and may need to reimplement the Hu6270/6260 combo. Actually, I was just thinking that a dev cart using memory in banks $88-$DF or so (out of the way of regular programs) would be useful for debug.
|
|
TailChao
Gun-headed
I Must Eat Muffin Gear.
Posts: 68
Fave PCE Game Overall: Bonk's Adventure
|
Post by TailChao on Dec 20, 2019 14:54:56 GMT
I released the MC-Genjin in 2011 and the MC-Genjin CD (as part of the CD Stupid Card) in 2015, the latter of which supports acting as a substitute for a System Card 3.0 but with enhancements. A handful of the CD Stupids are in circulation - I think I sold them for $35 each back on the PC-Engine FX boards.
Both of these featured extended memory and dynamic region switching (swap D7 - D0) so you could use the same codebase for either the TurboGrafx or PC-Engine with a dumb reset vector trick. No switches required.
I did a few drafts for updated versions to better target component pricing now and better support how I'd write the game software, settling on the feature set below.
- 512KB NOR Flash
- 32KB - 256KB EXRAM
- Dynamic region switching
- SPI Interface w/ 16MB+ NOR Flash(es) (cost thing, it's also easy to isolate this as the only 3.3.v component)
- At least two cursors into the EXRAM with configurable autoincrement
- Ability to "insert" ST1/ST2 between bytes of EXRAM, or possibly between SPI fetches
The idea with the SPI Interface was to fill a large region (8KB+) with the last byte read from the bus, then reading within the region would trigger the next sequential fetch. The mapper could interleave these results with ST1/ST2 opcodes to allow data to be shoved directly into the VDC. You'd keep the majority of your consumable data (graphics, stage maps, bla bla) in the SPI Flash and copy it to EXRAM or VRAM. Since then, Alliance started offering high capacity 5V NOR Flashes so using the SPI Flash isn't as big a gain.
I think the biggest improvements come from extended RAM and a few cursors into it or ROM, both make larger stages and gratifying character movement significantly easier to reach.
|
|
|
Post by spenoza on Dec 20, 2019 16:04:17 GMT
I don’t have a specific use case, but was more interested in simply what kind of additional functionality was available through the card slot, in part because every single PCE model has this slot and not all of them have an expansion port. Can co-processors be added? What kind of additional processing could they reasonably provide? Additional graphics functions? NES mappers in particular offered a lot of this, but the base NES was pretty constrained, and the PCE not as much. Audio? We know mono sound is available. That could be useful for some things. But I think additional RAM is the real benefit, most likely.
|
|
TailChao
Gun-headed
I Must Eat Muffin Gear.
Posts: 68
Fave PCE Game Overall: Bonk's Adventure
|
Post by TailChao on Dec 20, 2019 16:37:38 GMT
I don’t have a specific use case, but was more interested in simply what kind of additional functionality was available through the card slot, in part because every single PCE model has this slot and not all of them have an expansion port. Can co-processors be added? What kind of additional processing could they reasonably provide? Additional graphics functions? NES mappers in particular offered a lot of this, but the base NES was pretty constrained, and the PCE not as much. Audio? We know mono sound is available. That could be useful for some things. But I think additional RAM is the real benefit, most likely. Haha, sure.
Adding a coprocessor akin to Nintendo's Super FX, SA1, or Sega's SVP is feasible, and as with any of these it could provide anything from a few small graphics effects (in software) to running the majority of the game logic. The limitations here are mainly the dimensions of your wallet, the HuCard, and how much power you can draw before it becomes exceedingly rude. With what's available today adding a 70MHz+ ARM would be trivial.
Graphics expansion is a little more problematic, you could add hardware which "assists" in rendering tiles or doing some magic bit-twiddling - but the results still have to be uploaded to VRAM. This is pretty much on par with what the Genesis or SNES offer, even with Sega CD all those fancy scaled and rotated graphics still have to be copied in manually. The NES had a dedicated bus for all its graphic data which was exposed on the cartridge slot, allowing for those drastic improvements - you could mess with the tile or map data directly.
Mono sound is available as well, yes. I'm not sure if the mixing is consistent among all hardware variants.
|
|
|
Post by dshadoff on Dec 21, 2019 1:06:08 GMT
I released the MC-Genjin in 2011 and the MC-Genjin CD (as part of the CD Stupid Card) in 2015, the latter of which supports acting as a substitute for a System Card 3.0 but with enhancements. A handful of the CD Stupids are in circulation - I think I sold them for $35 each back on the PC-Engine FX boards. Both of these featured extended memory and dynamic region switching (swap D7 - D0) so you could use the same codebase for either the TurboGrafx or PC-Engine with a dumb reset vector trick. No switches required. Cool stuff ! I don't think I saw that page before (and I don't think I was around PCEFX when you made the original hardware). I did a few drafts for updated versions to better target component pricing now and better support how I'd write the game software, settling on the feature set below.
- 512KB NOR Flash
- 32KB - 256KB EXRAM
- Dynamic region switching
- SPI Interface w/ 16MB+ NOR Flash(es) (cost thing, it's also easy to isolate this as the only 3.3.v component)
- At least two cursors into the EXRAM with configurable autoincrement
- Ability to "insert" ST1/ST2 between bytes of EXRAM, or possibly between SPI fetches
The idea with the SPI Interface was to fill a large region (8KB+) with the last byte read from the bus, then reading within the region would trigger the next sequential fetch. The mapper could interleave these results with ST1/ST2 opcodes to allow data to be shoved directly into the VDC. You'd keep the majority of your consumable data (graphics, stage maps, bla bla) in the SPI Flash and copy it to EXRAM or VRAM. Since then, Alliance started offering high capacity 5V NOR Flashes so using the SPI Flash isn't as big a gain. I think the biggest improvements come from extended RAM and a few cursors into it or ROM, both make larger stages and gratifying character movement significantly easier to reach.
Hmmm... it all comes down to this philosophical question, I think: Are you (a) planning "temporary" improvements, to enhance the debugging experience which still targets original hardware, or (b) planning to fundamentally change the platform ? For me, I have feelings on both sides of this, but I definitely lean toward considering the original platform as a target... although I also support "fundamental change" if the hardware can be available to the masses (a) as part of the game cartridge, or (b) as close to an official peripheral as possible. Having said all that, I'd probably do much the same as you, without some of the fancy stuff (ST1/ST2 interleaving). SPI flash is cheap and can be part of a final package (SDCard via SPI is also an option). FPGA hardware needed to enable this stuff is becoming cheap in some areas ( for example) - again, potentially cheap enough to consider packaging with the release of a game. However, I think I would capitulate to needing level-shifters and running mostly 3V logic simply for the availability of parts. For a dev board, I would have RAM in banks $00-$88 (with write-protect from PCE if simulating a ROM), and copy HuCard info into it; the reason it should be RAM is so that debug routines could inject breakpoints into it. I would position these debug routines (and a bit of RAM) somewhere in banks $88-EF. I would also have some communication with a PC. But again, all this is a set of capabilities to fulfill my own goals - not a set of new goals for a HuCard...
|
|
TailChao
Gun-headed
I Must Eat Muffin Gear.
Posts: 68
Fave PCE Game Overall: Bonk's Adventure
|
Post by TailChao on Dec 21, 2019 15:10:40 GMT
Hmmm... it all comes down to this philosophical question, I think: Are you (a) planning "temporary" improvements, to enhance the debugging experience which still targets original hardware, or (b) planning to fundamentally change the platform ? Agreed. Generally I prefer to embed debugging enhancements within the console itself rather than on the card. You can drop a 62256 style SRAM in a regular TurboGrafx or PC-Engine without much effort and gain another 24KB of Work RAM without having to shell out for a SuperGrafx - that's already a big gain. For actual game software enhancements I think it's best to embed everything in the card or cartridge, nobody needs another 32x.
However, I think I would capitulate to needing level-shifters and running mostly 3V logic simply for the availability of parts. Keep in mind that switching entirely to 3.3v isn't always necessary, large SRAMs (32KB - 256KB) are still available as 5V parts. Board realestate and the additional time to assemble are also factors. The idea of switching to a mid-sized Parallel Flash accompanied by a large SRAM and 3.3v SPI Flash was to isolate the level conversion to something like a MAX3373... which was also nudged by the desire to keep large chunks of uncompressed graphics and stage data. But again, all this is a set of capabilities to fulfill my own goals - not a set of new goals for a HuCard... I think this is the most important design requirement, as hardware is largely useless without software to run on it.
|
|
|
Post by Black_Tiger on Dec 21, 2019 17:49:10 GMT
Nintendo was always the king of mappers and extra memory and chips on carts, but even Sega dabbles lightly in that space. And now there are “home brew” carts with those kinds of augmented capabilities for hobbyists. Has anyone considered doing this for PCE, aside from tapping into the Turbo Everdrive? An extra 128k or RAM and a little CPLD with some additional functions? I know the CD units and system cards help the PCE put a bit, but I like the idea of having something available for programmers aiming for a Core or Turbo but who still want some extra tools or extra oomph. Populous has extra ram in the HuCard. I hope that no homebrew prodictions make anything exclusive to a new hardware configuration. Too many classic consoles are experiencing an increasing number of new games being dedicated to new hardware that wouldn't have been feasible bitd or are straight up FPGA hardware from the future pretending to be 80's arcade hardware and only incorporate an element of the console it's sold for.
|
|
|
Post by DarkKobold on Dec 23, 2019 19:22:35 GMT
Nintendo was always the king of mappers and extra memory and chips on carts, but even Sega dabbles lightly in that space. And now there are “home brew” carts with those kinds of augmented capabilities for hobbyists. Has anyone considered doing this for PCE, aside from tapping into the Turbo Everdrive? An extra 128k or RAM and a little CPLD with some additional functions? I know the CD units and system cards help the PCE put a bit, but I like the idea of having something available for programmers aiming for a Core or Turbo but who still want some extra tools or extra oomph. Populous has extra ram in the HuCard. I hope that no homebrew prodictions make anything exclusive to a new hardware configuration. Too many classic consoles are experiencing an increasing number of new games being dedicated to new hardware that wouldn't have been feasible bitd or are straight up FPGA hardware from the future pretending to be 80's arcade hardware and only incorporate an element of the console it's sold for. I don't know of any homebrew that won't play on the original system it was programmed for.
|
|
|
Post by spenoza on Dec 23, 2019 19:32:10 GMT
I think sticking to an add-on that can reasonably ride on the cartridge is pretty fair game.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Dec 23, 2019 20:21:59 GMT
edit: nevermind
|
|
|
Post by turboxray on Dec 25, 2019 6:09:41 GMT
I released the MC-Genjin in 2011 and the MC-Genjin CD (as part of the CD Stupid Card) in 2015, the latter of which supports acting as a substitute for a System Card 3.0 but with enhancements. A handful of the CD Stupids are in circulation - I think I sold them for $35 each back on the PC-Engine FX boards. Both of these featured extended memory and dynamic region switching (swap D7 - D0) so you could use the same codebase for either the TurboGrafx or PC-Engine with a dumb reset vector trick. No switches required.
I did a few drafts for updated versions to better target component pricing now and better support how I'd write the game software, settling on the feature set below.
- 512KB NOR Flash
- 32KB - 256KB EXRAM
- Dynamic region switching
- SPI Interface w/ 16MB+ NOR Flash(es) (cost thing, it's also easy to isolate this as the only 3.3.v component)
- At least two cursors into the EXRAM with configurable autoincrement
- Ability to "insert" ST1/ST2 between bytes of EXRAM, or possibly between SPI fetches
The idea with the SPI Interface was to fill a large region (8KB+) with the last byte read from the bus, then reading within the region would trigger the next sequential fetch. The mapper could interleave these results with ST1/ST2 opcodes to allow data to be shoved directly into the VDC. You'd keep the majority of your consumable data (graphics, stage maps, bla bla) in the SPI Flash and copy it to EXRAM or VRAM. Since then, Alliance started offering high capacity 5V NOR Flashes so using the SPI Flash isn't as big a gain. I think the biggest improvements come from extended RAM and a few cursors into it or ROM, both make larger stages and gratifying character movement significantly easier to reach.
I remember this! I'm pretty sure I had one haha. Yeah, the whole inserting st1/st2 opcodes every other bytes is something the PCE REALLY needed haha. It's faster than Txx and doesn't stall interrupts. Self incrementing (signed) ports into ram/rom on the bus (but not built in ram) is also something the PCE could have really used. Of course, more ram always helps. 8k for hucards really starves the system of optimization techniques and good compression engines. A higher resolution timer on the hucard port would have also been nice. Something much higher than 7khz. And be able to resync it to a frame if needed. Since PCE never got a sound upgrade (outside of CD audio.. they really should have also included more WSG or a generic FM chip or something... a single ADPCM channel is crap! haha), it would have been nice to see some support to augment what's already there; DDA mode. A higher res TRIQ, a 16bit or 24bit fixed point phase accumulator port (2 or 4) to stream resampled frequencies to DDA channels. A higher res TIRQ could mean it could also be used to drive both samples and video effects, cutting out VDC interrupts altogether (like later NES games do). But even just simple integer autoincrement set of indirect ports with a higher res TIRQ would drastically improve PCE sound. I've never felt I needed a faster processor (coding in assembly, at least). But a few augmented stuff to help optimize video and audio stuff would be nice. I rather have that than a co-processor. A co-processor just feels overkill and out of the spirit of the system. I guess a fast 16+16->32bit MUL/DIV operator would be nice. That always seemed like something the CD unit should have added, among other things. It's not incredibly import, but it'd be convenient. Paired with a fast linear-to-planar converter, would have made pixel based operations more of a thing for CD games. I mean both things exist on the System card, just not accelerated. I've always wonder what was originally planned for the CD unit, and what was eventually cut. All those pins and potential with the backplane port, and NEC builds thee most minimal CD expansion unit possible haha. I mean, not even a simple DMA from CD data to CD ram smh - unless you count that 2k of sector data and even then it's a manual copy from the buffer hahah.
|
|
|
Post by Arkhan on Jan 13, 2020 11:46:47 GMT
Oldman made an extended RAM card or something as a test project.
Desh might have one.
I think he showed you it at CCAG a few years back.
|
|