8-Bit Hero Trainer

After seeing ThinkGeek's April Fools 2015 RPG fitness-gauntlet hoax, I got to thinking that sort of thing would be totally doable on NES. A few months later, some time and incentive opened up in my schedule to build it out: 8-Bit Hero Trainer, the worlds first first-person RPG combat sim for NES

Edit: FULL GAME WITH DOCS: http://www.psychsoftware.org/portfolio/ ... rainer.zip



The project is surprisingly small but technically novel, making use of BOTH the PowerGlove and PowerPad for a full-body real-time interactive play experience.

There are a few more details I'll likely be adding/polishing before committing any "final" version to the Internet in general, but I've finished a playable feature-complete beta which I figure folks here are more likely than anyone to have the hardware setup to actually playtest.

Fair warning: the first time I tried playing end-to-end, I got almost all the way to the "final boss," BUT my whole body, and particularly my legs, were screaming bloody murder at me for the next 3 days >.<

http://www.psychsoftware.org/stuff/temp/8BHT_b035.zip
Edit: Full version link at top of post

This is awesome. It'd be nifty to see footage of people's reactions to playing it

well, videos do speak louder than words
https://www.youtube.com/watch?v=Ab5DpjaQM4s
The hardware requirements unfortunately make it unlikely that too many others will end up playing it if I don't physically take my setup to them, but I may try bringing it to a local gamedev group or something like Awesome Games Done Quick at some point.

That is really cool too see those accessories used together in playable game. Kinda reminds me of how years ago a friend and I were talking about making a game that's a parody of the show COPS, using the Power Pad, Zapper, and Power Glove (I have no idea if all that stuff would even work with a 4-player adapter though). I've had a Power Glove for a long time, it was free and missing the sensor bar though, now I find myself wanting to get a working setup.

Heh. It's actually normally a rule NOT to use multiple peripherals at once because it cuts the potential audience down to whoever has all the required peripherals. I'm just dodging that rule
a. because I'm not planning to profit anyway
b. because anyone who kept a working NES around this long is probably a collector with peripherals anyway
c. because I want to.

Iirc, the high-level theory on the 4-way adapter is that it just interleaves the serial streams from the inputs, however I've never actually played with one to be sure. If it passes through all pins, there's nothing stopping combining peripherals, but each one has a quirk, so certain combinations of devices and ports may work better than others. Iirc, the light gun uses the standard data pin but operates asynchronously (ignores the latch signal), the Pad uses a combination of 2 nonstandard pins but by doing so fits itself into 1 standard 8-bit read, and the Glove coerces itself into the standard pins but operates bidirectionally in a timing-dependent manner and, when in full boogie, sends many bytes of data. So it really will boil down to whether the 4-ways pass through or buffer, what pins, and what precisely they do/expect with the latch.

Awsome indeed! I love every bit of this work! It reminds me of Dragon Quest Kenshin.

If you would consider making it compatible with the Family Trainer (which apparently is different from the Power Pad) I might pick up a Power Glove someday. I guess I'd need to make a compatible splitter for the expansion port though.

So the situation you're in is you have a Famicom and no NES so you want to use the Famicom mat and hardware-hack the glove? Or... okay, right, the Famicom has hardwired controllers, didn't it? So BOTH peripherals would need to talk through the expansion port, and... ow. Okay. If YOU can vet out the wiring to run through the expansion port so that the Glove shows up on $4016 and the Trainer shows up on $4017 then...
*pins http://problemkaputt.de/everynes.htm#controllersmats for reference*
...
Okay, I was going to say that should be a simple polling code change, but upon further study, I think it would be at best unsafe and at worst impossible. The clincher is that, as I discovered this project, both controllers SHARE $4016 for writing. This is typically safe enough since programming the Glove over $4016 writes just looks like garbage to a gamepad, and if the Glove gets a normal poll latchbit, it will queue up its header byte and proceed for normal read activity. However, it looks like the Family Trainer takes actual data over $4016 writes as well, and has its own timing requirements. It MIGHT still mesh; it MIGHT be that the Glove will ignore bits 1 and 2 of $4016 writes and basically just write off the Trainer polling as the occasional degenerate access and all prior programming will hold so long as $4016 isn't held long enough to trip it back into program mode, and the trainer will happily accept being switched in and out of Row 1 while the Glove is being polled and still return nice data in its intended polling loop provided I wait the 1800 cycles, but... that really is a rabbit hole I'd need actual hardware access to vet out >.<

The Famicom having slightly different hardware sort of reminds me of how there were several Japanese-developed USA-exclusive titles. None of the aforementioned games did anything as ambitious as this, but it wouldn't be surprising if this was made back in the day and had to be USA exclusive only for technical issues.

Then again, there's also the AV Famicom, which appears to be a modified NES-101, and might be able to work with that. However, Famicom accessories had specialized plugs while this uses the 7-pin connectors the worldwide NES used, so that would still pose an issue regardless. Interesting how the same hardware has minor nuances across the various regions it was released in.

Yeah but the number of NES games that doesn't work on Famicom is quite small. It's mostly non-Japanese made NES games that fail to support external controllers (I guess they either didn't understand the mostly Japanese dev manuals they were given or just ignored the Famicom expansion port since they were developing on the NES anyway) or games that requires pressing start or select on Controller II (the NES versions of Battletoads does this). I also heard there are games that rely on the lockout chip which is missing on the Famicom.

Homebrewers also often forget to check that extra bit in $4016 and $4017 for external controllers (hint hint).

For peripherals it's mostly Four Score and Power Pad games, but you can adapt these peripherals for Famicom as well.


Yeah I haven't had a NES for years (sadly it was thrown in the garbage without my consent) and only have a Famicom and Family Trainer mat. I just thought it would be a good idea for you to support both mats in your project but I didn't think it would be that much different from the Power Pad, since the Famicom expansion port have most of the pins in the NES controller ports. I don't even have a Power Glove anyway.

BTW I love the early Nintendo game style manual!

Thx! Yeh, when I release an actual complete game, I try not to half-ass it. The full release zip has separate PDF manuals for reading and printing, full box art (PDF front/back and PNG whole-box), and a cart label. I'm actually half way thinking of pinging RetroZone and trying to get a small run of actual carts fabricated. It's mapper 0 and only uses 1 CHR and 1 PRG block, so it ought to be fairly trivial.

And as far as Family Trainer support, it might legitimately doable; the nature of the interference doesn't completely exclude it (i.e. there are no $4016 writes which are critical to one peripheral but which explicitly mean something non-benign to the other), but I'm headed off to a job interview today/tomorrow and then may be into a month of relocation chaos, so I wanted to get the initial release buttoned down into something I could afford to shelve for a bit.

Yes, but they're "just" analog things—the Family Trainer mat is nothing but a physically huge 3x4 button matrix, and the Famicom scans it by driving one OUTx bit low at a time, waiting a while, and then reading back which lines have been pulled low through through the huge buttons.

It connects to the ordinary 7-pin joypad port, right? I don't see how it could pay attention to these other two bits...

But I don't think we even have any documentation about how the Pax Power Glove differs; it's conceivable that this would only work on an A/V Famicom with a Mattel (US) Power Glove.
It really sounds like someone was told "eh, wait 1ms", rather than anything rigorous. I wouldn't be surprised if it worked a bit faster... but maybe not enough faster.

We did some verification in this thread: http://forums.nesdev.com/viewtopic.php?f=10&t=12447

Basically as long as you use the standard Famicom controller reading technique of listening for both bits 0 and 1, the PAX Power Glove should behave as the US version. The PAX just comes through on bit 1 like normal Famicom expansion controllers.

Hokay.
So the answer still appears to be a solid "maybe."

The rubber would hit the road when the Trainer pad needs to be polled. For the Glove or any typical controller, I raise and then immediately lower bit 0 of $4016, then read $4016/$4017 however many times, usually a multiple of 8.
The Trainer pad, according to the first doc I found, uses $4016 write bits 0-2, inverted(?), to select which of the 3 rows to return on reads. Does anyone know the timing of the row-select write? E.g. would it be a write of the select code to $4016, then a 1800 cycle wait, then a read, or could it be a write of the select code, an immediate write of 0, a wait, and then a read? The former almost certainly WILL screw up the Power Glove, since iirc it uses the duration of the latch pulse to determine whether to go into read mode or program mode (8BHT just recycled my init code from Nesglovphone/GloveTestKit, so I haven't put eyeballs on this recently). If any read of the Trainer pad means holding a 1 in bit 0 of $4016 for any length of time, that probably scuttles the concept.

Yes, inverted.
Closer to this, but I don't think we know the exact timing. It's a big analog thing, not digital propagation timing.
From description, it's clearly something like this:Either this, or there's a diode in series with each button instead of just three at the input.
How long is that threshold?

The writes are not the relevant timing here; rather it's "after some amount of time with a specific value latched in $4016, the value read back from $4017 is stable". So at least you can poll the top row for ≈free.

In fact, you might be able to use some kind of clever inferences to avoid ever requiring 4016.0 be left high:
* [$4016]←6; wait; read top row
* [$4016]←4; wait; read bitwise OR of top two rows
* [$4016]←2; wait; read bitwise OR of top and bottom rows

Obviously there are certain button combinations that that can't detect (mostly: {a button in the top row and another button in the same column} as different from {just the button in the top row})...


We probably should start off with a test ROM, if Pokun's willing to do some characterization for us...

Heck, technically all 8BHT needs is the OR of all pads in each column, so if that comes free by leaving $4016 at 0 and just reading as-is, that would be slick...

I'm about 90% confident that that would work correctly... It still would be nice to get someone to double-check.

Probably still want to wait 1ms after you're done talking to the Power Glove, though.