Membler Industries in 2015

[Memblers]

After a long period of inactivity, I'm happy to make this early announcement that Membler Industries is getting back into new hardware production, in a bigger way than ever. I had planned on waiting until I have several things ready to ship before announcing anything at all, but I thought if an early announcement may be beneficial to someone, I should go ahead and do it. Plus I'm super excited about all of this, I've been in a near-constant state of nerdgasm for the past year as I've gotten back into my NES projects, and have been able to apply my new-found knowledge and experience (still plenty to learn though, it never ends) into my favorite hobby.. dorking around with the NES. I hate to be a tease, but I'm not going to be posting about the project that is most exciting to me, except to say that it's a long-term project, my "great work" which is essentially evolved from why I started messing with the NES in the first place, nearly 18 years ago (holy cow). Once I start to see that light at the end of the tunnel, I'll definitely let everyone know, but it will be a while yet. But peoples' interests vary, so maybe the relatively mundane stuff I'll be soon detailing will be more interesting to most, who knows.

So first, maybe it's no surprise that I have created a new NES cartridge board. It is my 6th cart board design. Recently I was asked "better than the last board?", and the answer is no, it's cheaper than the last board. I call it Cheapocabra, or goat-ROM.
http://membler-industries.com/nes/cabra1.jpg
http://membler-industries.com/nes/cabra2.jpg
Those pictures are of the prototypes, the production version will be a different color and is a revised version, as well. After I make some changes and additions, I'll post the full documentation on it. But here's the basic functionality of the mapper:

• 512kB PRG-FlashROM, in 32kB pages, OR 256kB PRG-FlashROM in 16kB pages, upper or lower 16kB fixed
• 16kB pattern table RAM, in 8kB pages (see errata note)
• 8kB name table RAM, in 4kB pages, 4-screen mode
• 7.5kB bonus PPU-RAM at $3000-$3EFF, in 3.75kB pages
• no bus conflicts, no jumpers to solder, no variants, self-programmable by NES code
• 2 LEDs, 1 red and 1 green, controlled by NES software
• (optional) debug serial output connector

errata note: When one of the two the pattern table pages is selected, the wrong tile may be fetched by the PPU at the exact moment that the CPU writes to the mapper register. To avoid this, you must not write to the mapper during rendering. The other pattern table page is not affected.
Update, see this post:
viewtopic.php?f=4&t=12716&p=226364#p226364

This will be my first board that will be factory-assembled, and available to the public. About pricing, I'm interested in supplying it at a reduced rate to independent developers who are interested in self-publishing. I may be able to provide some distribution services, but this may depend on the availability of my time. I am also currently working with a new, small publisher who's doing some high-quality work. I'm open to working with other publishers or distributors, my only requirement is that they have absolutely no involvement with selling bootleg or "repro" carts.

With this board, as well as using it for some software releases of my own, I want to produce an inexpensive devkit, hopefully for no more than $35, that would include this cartridge, an NES-to-USB interface, and software to allow easy uploading and testing without removing the cartridge from your NES.

And secondly, since a cartridge isn't complete without a plastic case to put it in, I've teamed up with a few people to buy our own injection mold tooling. I will have my own cart shells.


*******
EDIT:

I'm expecting the assembled boards to arrive soon, but in the meantime, the cart shells are here.

The standard cart shell for Cheapcabra/GTROM is translucent charcoal grey. You can see the green rev2 prototype inside. The production boards will be black.

LEDs don't photograph very well, but I took a couple pictures of the LEDs lit up in the cart shell. If you're wondering about the NES, that's my home-made top-loader. And the toggle switch on it is a lockout disable.

*******
EDIT2:

Mapper specs were updated to include the "bonus memory" in PPU space at $3000-$3EFF. This can be used as RAM by the CPU, with the limitation that it must be accessed through the PPU I/O port ($2006/$2007).

Added errata note about pattern table paging. The nametable paging is also affected, but there is a software work-around that prevents it.

To clarify about the availability of pictured cart shells, that particular type purple shell will not be for sale. Currently, only the 'Cheapocabra standard' translucent charcoal grey is in stock. The 'traditional' grey shells are not in stock, black shells are in limited stock, but either may be ordered. For $100 flat fee, you may order your own custom color. Pricing for 'non-standard' colors will vary by your lead-time requirements. Minimum lead-time is about 10 weeks. If you want any color besides charcoal grey, please make arrangements as far in advance as possible. If I'm aware of your time-table early enough to combine your custom color with another batch order, then it's possible that even your custom colored shell will cost nothing extra beyond the $100 flat fee. Shorter lead times are going to cost more.

*******
EDIT3:

Finally! It took longer than expected, but now the GT-ROM-02 production boards are here.

It's had a rough launch, with a board revision before production, and even this version has some quirks that I'm not happy with, but it is still usable. Weirdest issue is there are 2 8x8, or 1 8x16 sprite that can have one of it's OAM data bytes corrupted. It only seems to show up in a couple games so far (and the cart.nes test program). It is disappointing, but if your game needs to display all 64 sprites at once, this is probably not the board for you. It's still unclear what the exact cause is, probably won't be a software workaround for it other than hiding 2 particular sprites, but it's not yet certain. I guess I'm not seeing it most games, because there are 3 'layers' of disabling a sprite (x pos, y pos, tile number) and the corruption simply doesn't happen to all three bytes. Or it could be happening only in some specific case that I haven't noticed yet. (edit: The OAM glitch was caused by an uninitialized Game Genie, not the GTROM board) But anyways, if anyone wants to use this board for a release, I'd be interested in testing your program and investigating any issues. Going from NROM, UNROM, BNROM, CNROM, mapper #30, to this is all very painless.

If this mapper is too basic for you, I have another design in the works with some unique features that I will describe once it's fully tested. I finally bought myself an oscilloscope (Rigol DS1054Z) so I can see what the hell is actually happening.

********
EDIT4:

I've got good news on the sprite DMA glitches, it appears that it was only in my imagination. I mean, it was actually happening, but when I take the cart off of the Game Genie, it doesn't happen. This Game Genie, running my own ROM replacement, is what I'm using to program and test these boards, and I normally just leave it on. Maybe I left it's registers in a bad state somehow. It's a pretty big question mark sitting on the data bus. So it looks like I can put that issue to bed.

In other news, I've been putting these boards through the burn-in test and that's going very well. So far I've only had to touch up solder joints on a few of them. Already, over half of the boards in this batch are spoken for. But there are plenty left over. After I check if it's OK, I'll start naming the first games that will be coming out on this hardware. At least one of them even makes use of the flashROM for save data.

********
EDIT5:

Added link to Cheapocabra Devkit Quick Start Guide

********
EDIT6:

rainwarrior has added support for Cheapocabra (mapper #111) into the FCEUX emulator. Including FlashROM support! Only lacking features are the LEDs and extra PPU RAM at $3000-$3EFF, due to the way the emulator was originally written. I've uploaded a Win32 build of it here:
http://membler-industries.com/nes/fceux-r3293.zip

********
EDIT7:

List of games that have been distributed on GTROM (let me know if I missed any), roughly in order of release:

• Swords and Runes, Sole Goose Productions
• 0-to-X, Sole Goose Productions
• The Incident, KHAN Games
• KHAN Games 4-in-1 Retro Gamepak, KHAN Games
• Sly Dog Studios’ 3-in-1 2P Pak, Sly Dog Studios
• Cowltiz Gamers Adventure
• Scramble, KHAN Games
• Tailgate Party, Orab Games
• Four, by zi (music cart)
• Spook-o'-tron, Sole Goose Productions
• Candelabra: Estoscerro, Sly Dog Studios
• NEScape!, KHAN Games (coming soon)
• ????, Membler Industries (coming eventually)

********

EDIT8:
GTROM mapper for PowerPak, by NovaSquirrel
https://forums.nesdev.com/viewtopic.php?f=9&t=16631

[koitsu]

Don't forget to allocate a mapper number! :-) Absolutely love the name!

[tokumaru]

This is great news, Memblers. Cool little mapper/board too. I hope you didn't forget those interesting IRQ ideas you hared a while ago!

[tepples]

Good news. To avoid dumb questions later, let me get them out of the way now:

I call it Cheapocabra, or goat-ROM.

Please be careful with the word "goat". In Christian circles, a "goat" is identified with those sentenced to death for not caring for the poor. And in tech circles, I shouldn't have to explain (see Wikipedia).

512kB PRG-FlashROM, in 32kB pages, OR 256kB PRG-FlashROM in 16kB pages, upper or lower 16kB fixed [...] no jumpers to solder, no variants

So you have one version with BxROM (#34) style PRG, one version with UxROM (#2) style PRG, and one version with UxROM (#180) style PRG. How are these not "variants"?

self-programmable by NES code

With erase pages how big? I ask because I noticed no work RAM in CPU space. Will games need to repeatedly bankswitch between the full flash page holding the save data and the just-erased flash page to which the the save data is being copied?

In addition, lack of work RAM breaks the model of running a large, complex simulation that has a good reason to use more than the 1500 bytes of game state you typically get on the NES. (This is 2048 bytes, minus 256 for VRAM transfer buffer and stack, minus 256 for OAM transfer buffer, minus about 36 for machine state things such as NMI count, controller state, NMI trampoline, local variables, and the like.) I guess games needing this much space can be redesigned to be turn-based without DPCM usage so that they can wait for vblank to access the second pattern page.

2 LEDs, 1 red and 1 green, controlled by NES software

Are these GPIOs, or are they useful only for LED output?

I'm open to working with other publishers or distributors, my only requirement is that they have absolutely no involvement with selling bootleg or "repro" carts.

Does that exclude me because I was planning to sell a clone of a famous Russian video game prior to a 2012 court decision?

[Memblers]

There are no IRQs on this one, this board is really simple; it's my replacement for NROM. I know it looks like it would cost more than NROM, but considering that you can't buy 32kB FlashROMs (and PPU doesn't have enough address lines to issue commands to SST39-series FlashROM), 74HC parts are cheap, getting them factory assembled in a large quantity is also cheap, hopefully the extra features makes it usable for a wider variety of situations, so my thought is that the additional costs are made up in volume.

I haven't forgotten about my mid-range 8T-ROM board, it's still possible that I will put that into production once there is need for it. There was a game in development that would have used it, but I haven't heard any news on it for a while, and I don't know if the developer is still interested in using my hardware for it. I thought I would use it for Garage Cart #2, but it is kinda overkill for that. It would have made for a nicer devcart certainly, with the WRAM and IRQ. I would totally go forward with that, if I was sure I could sell several hundred of them at least. In the meantime, there have been more uses for a low-end board, so I've made Cheapocabra.

Please be careful with the word "goat". In Christian circles, a "goat" is identified with those sentenced to death for not caring for the poor. And in tech circles, I shouldn't have to explain (see Wikipedia).

Interesting, I wasn't aware of the former association, and the latter, I guess I should be glad I didn't put any big circles on it, and I'll have to remember not to make a revision numbered "EO3" or something similar, lol. I just like choosing interesting animals as mascots/totems for my boards, you might notice my past NES boards have had a squid, a turkey, and my board for Playchoice has a sea turtle.

So you have one version with BxROM (#34) style PRG, one version with UxROM (#2) style PRG, and one version with UxROM (#180) style PRG. How are these not "variants"?

The hardware is the same for all of them, what it does is interleave the fixed bank in software, by repeating it when the cartridge is programmed. My programming code does this automatically by checking the header in the iNES file when it is uploaded. That does waste half the ROM, but the price difference between 256kB and 512kB is smaller than ever, and I feel that the savings of not having to build and stock different hardware variants more than makes up for the cost (it's back to the solution of lowering costs by higher volume). One could consider 32kB paging to the preferred 'native' mode.

With erase pages how big? I ask because I noticed no work RAM in CPU space. Will games need to repeatedly bankswitch between the full flash page holding the save data and the just-erased flash page to which the the save data is being copied?

The sector size for erasing is 4kB, which is pretty reasonable. So, unless the save data is fairly large, it can be done without bankswitching. In any event, you must execute code from RAM when doing the write/erase commands because the ROM is unreadable at that time, so copying between banks wouldn't add much complexity to the code.

In addition, lack of work RAM breaks the model of running a large, complex simulation that has a good reason to use more than the 1500 bytes of game state you typically get on the NES. (This is 2048 bytes, minus 256 for VRAM transfer buffer and stack, minus 256 for OAM transfer buffer, minus about 36 for machine state things such as NMI count, controller state, NMI trampoline, local variables, and the like.) I guess games needing this much space can be redesigned to be turn-based without DPCM usage so that they can wait for vblank to access the second pattern page.

Yeah I know, my previous boards with Flash all had WRAM, so going without does make the Flash seem less useful. One thing the specs didn't mention, is that in the PPU space there is RAM available at $3000-$3FFF, 2 pages of it, so 8kB in total (bankswitched in tandem with the nametables), counting the part that overlaps palette memory. Obviously that's no replacement for CPU RAM, but it's something.

I think it may still be possible to create a large, persistent simulation with this small RAM + large Flash setup, if you're able to divide the world into smaller zones and allow for some load/save time when changing zones. I'm planning on writing a filesystem that includes wear-leveling, so while each sector allows for "only" 100K erases (minimum), this can be extended into the millions by spreading it out. And easily tens or hundreds of millions, if your data "file" is small.

Correct me if I'm wrong, but counting (NTSC) CPU cycles with this chip, sector erase time is 18 milliseconds, and byte programming is 14 microseconds. I'm coming up with 3,221 CPU cycles to erase, and 2.5 CPU cycles to program a byte. That seems pretty fast for programming, the actual command sequence to program is significantly longer than that. So you could probably do an erase or program operation without interrupting music playback (not DPCM though).

So really, with this board, if one has a game that's more suited to WRAM, it's probably worth considering using a board with WRAM (I could move 8T-ROM into production like I mentioned, it's just going to cost more). If you successfully redesign such a game for Cheapocabra, you could either sell it cheaper, or take some additional (well-deserved) profits.

Are these GPIOs, or are they useful only for LED output?

You could call them GPOs I suppose, heheh, since they are output-only. But yeah, that 4-pin debug connector outputs the same 2 bits that control the LEDs, plus 5V and GND.

Does that exclude me because I was planning to sell a clone of a famous Russian video game prior to a 2012 court decision?

Definitely not, I don't think that either of us could have reasonably predicted that something as simple as shapes in a game could be legitimately copyrighted. Plus, there were countless previous clones of the same game over the years.

If anyone was curious about the logic used, the prototype in the picture uses 2 74HC00s, but the next revision will use a 74HC02 and 74HC10. The functionality is the same, but I had some out-of-spec timing for the mapper latch (it works when I wire in an RC filter), so I had to change it.

[lidnariq]

and PPU doesn't have enough address lines to issue commands to SST39-series FlashROM

Tangent: try duplicating address lines from the PPU to multiple different SST39SF010A address lines, even to even and odd to odd. A0=A2, A4=A6, A1=A3, A5=A7. As long as the FLASH sees 0x2AAA and 0x5555, it doesn't matter if the PPU addresses were actually (e.g.) 0x02AA and 0x0555.
It effectively shrinks the 4KiB sectors to 256 bytes, which makes the 8KiB window a little more convenient.

Shrinking by a odd number of bits produces weirder addresses, although it's still workable.

[Memblers]

That makes sense, as the address commands are just even and odd bit patterns. That would be a good way to do an NROM cart.

[lidnariq]

Correct me if I'm wrong, but counting (NTSC) CPU cycles with this chip, sector erase time is 18 milliseconds, and byte programming is 14 microseconds. I'm coming up with 3,221 CPU cycles to erase, and 2.5 CPU cycles to program a byte.

Since you asked ... I'm getting closer to 32000 cycles for erase, and 25 cycles to program a byte.

That said, 32000 is just a liiiiittle larger than 1vblank time, so you could probably still get away with waiting for audio updates, then waiting for the erase, and doing another audio update as soon as the flash is readable again.

[Memblers]

Thanks for checking, it's good news that I wasn't too far off. Previously, I had just assumed the erase time in general would be annoying based on my tests on other boards with an AM29F040B (and a non-B revision), the erase times seemed to vary by each chip and were seconds long, while it's almost instant on the SST39SF. Slightly longer than a frame sounds great. It mentions that in the datasheet:

Code: Select all

The SuperFlash technology provides fixed Erase and Program times, independent of the number of
Erase/Program cycles that have occurred. Therefore the system software or hardware does not have
to be modified or de-rated as is necessary with alternative flash technologies, whose Erase and Pro-
gram times increase with accumulated Erase/Program cycles.

[Memblers]

Here's an update, I'm excited to announce that Cheapocabra has entered production. If all goes well, I'm estimating that in 6-8 weeks I'll have both the cart shells and the boards ready to ship.

I also have prototypes of the the new cart shells, and the quality is really awesome. I'd say they're as good as Nintendo's own, and RetroUSB's cart shells. I don't currently have plans to stock traditional grey cases, I could help get some though if it's "must" for anybody. Cheapocabra's standard case will be a new color (I'll post it as soon as I see it for myself). I can order other colors, and I did order a couple other styles, but if you want the best price, you'll be getting the standard color.

As soon as I get the bootloader in a more user-friendly state, I'll be hand-assembling some pre-production boards, I probably have another 10 or so that are currently unclaimed. If anyone else is interested in getting an early start at using them, just contact me and I can add you to the list.

I don't have any prices to announce yet, but they will be really good. I'm willing to be negotiable on cost vs quantity, so it's possible you'll be able to get a good deal without being required to pay for hundreds of them a time. Keep in mind that despite the name of the board, the goal isn't to be bottom-of-the-barrel cost, with only passable quality. They're being electrically tested at the factory instead of just hoping they work, I'm not saving pennies by leaving off bypass capacitors, and the connector is not immersion or flash gold, but is 30 microinches of actual hard gold. So I feel the build quality will be higher than has been seen on any homebrew carts to date, even though the price for it's functionality will be lower than anything previously available.

I've been working closely with Sole Goose Productions on this project, and he's made this project possible. So I'll be able to continue my NES R&D work, and you'll have a second source for this hardware.

[thefox]

Nice! New options are always good to have.

[Memblers]

I'm expecting the assembled boards to arrive soon, but in the meantime, the cart shells are here.

The standard cart shell for Cheapcabra/GTROM is translucent charcoal grey. You can see the green rev2 prototype inside. The production boards will be black.

LEDs don't photograph very well, but I took a couple pictures of the LEDs lit up in the cart shell. If you're wondering about the NES, that's my home-made top-loader. And the toggle switch on it is a lockout disable.

[Drew Sebastino]

It seems like it would benefit from some plastic molding on the top, if you are capable of making something like that. I'm guessing that unfortunately there's no easy way to flip the cartridge slot conectors around?

[Drag]

That purple shell looks pretty neat. It looks nicer than the red/green/blue ones at retrozone for some reason.

[tokumaru]

Very nice cases!