Membler Industries in 2015

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:
http://forums.nesdev.com/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
viewtopic.php?f=9&t=16631

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

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!

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


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).


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"?


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.


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


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

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.


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.



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.



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.



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.


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.


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.

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.

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.

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.

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:

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.

Nice! New options are always good to have.

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.

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?

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

Very nice cases!

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.

I didn't think OAM memory was routed through the cart so I can't imagine how the cart itself could corrupt it.
Yet there is another 'layer' of sprite disabling and that's when the tile data is blanked. If that's the case, maybe the software workaround could be to upload the chr pages to both banks, i dunno.

Very weird issue nonetheless.

- I think I remember conversations about cartridges inducing OAM corruption before... I don't think we ever figured out what it must be, though it seems likely it has to be power consumption.

As an aside, if you're willing to answer, how much is proper gold plating on the card edge adding to the cost?

The first batch of PowerPaks had problems with OAM, which were later found to be fixable by resistors in the data lines. I have no idea WHY that works, or whether it has anything to do with Memblers' problem, but sprite corruption caused by the cartridge is not something unheard of.

The OAM data shows up on the data bus, so a cart can interact with it. I think that would be a neat way to copy data to the mapper, but that's for another topic.

In the past, I had OAM corruption when I used an EPROM emulator on my NES, I never was certain but I was thinking it was because it was reading it through an 74HC buffer, that would be outputting data much faster than a ROM or RAM would (like 15ns or something). And yeah in that case, resistors in series with the data bus fixes that. The glitch on that was much more erratic, it would only affect one sprite but it seemed to show up in almost every game, though occasionally not, on the same games. On the GTROM board there is a 70ns flashROM, it only outputs when the PRG/CE line is low, so I can only imagine there is something odd with that signal. I know from talking to kevtris that the NES pretty much changes into a different kind of timing pattern when it's doing the sprite DMA, so maybe it's related to that?

I haven't tried adding series resistors to the GTROM board, though I'm pretty sure it would fix it. It would prevent the cart's ROM from winning a bus conflict.


In the beginning of this year, laws in China changed, restricting use of arsenic for gold plating. But AFAIK, that's the only way hard gold plating is done. So it cost quite a bit more than I was expecting, I'd estimate it added about $2.00 each compared to what it would have cost a couple years ago.. it's something like a 3x~4x increase in the cost of the board. And that was with the manufacturer subcontracting that part out, the quote for them doing it was something like 8x the cost. I didn't get a lot of quotes for various options, but another manufacturer that offered to do it with 5 microinches of gold (vs 30) was maybe 40~50 cents cheaper. Immersion gold is much cheaper, but I believe it would wear off too easily. The IPC specs say it's good for 5 insertion cycles. 30 microinches is supposedly good for 1000 cycles.

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.



Actually, after looking at it again, I'd revise that number down to $1.50 or so.

It is good news to know that there won't be a reason to prefer an NROM board.

Also, that page of unaddressed memory lets me know where to put my ideal-world-mapper's register-spying storage.

e:Sure, why not.

What is your logic/circuitry with the PRG-ROM /OE and /CE?

I had similar OAM issues with EPROMs on my MMC1 design when I was controlling /CE with the mapper and /OE was grounded. Swapped them grounding /CE and /OE and fixed the issue. I'm assuming you don't have /OE grounded as you're flashable, but if you have some quirky logic there or aren't grounding /CE for some reason that's my guess.

That being said, I've tested all kinds of crazy logic configs with /OE and /CE with these exact chips on my discrete logic boards and never seen such glitches.. But not sure if I've tried whatever you've got going.

I figured it out eventually, it wasn't with the GTROM board at all, but was my custom code I put in the Game Genie that I use for programming blank carts. Problem was that I didn't completely initialize the GG registers before it enables the cart, and apparently the GG does not like that. Uninitialized hardware isn't good, I should have known better.

I've had a lot of trouble with these GGs, most of them screw up the cart's CHR after I put the new ROM on. I didn't put the 2 together until now, but I wonder if me not setting the registers has damaged the GG chip somehow, and that's why so many of the ROM mods didn't work while some others are fine. And actually I did have one of them suddenly "go bad" during development, pretty big clue there..

So the cart does work fine, I only suspected the worst case, heheh. The logic is simply PRG /CE to ROM /CE and inverted ROM R/W to /OE, which is why I was mystified at first.

Anyways the Game Genie device is something I'm phasing out for general use, being replaced with an on-cart bootloader. It should be fairly safe, to ease my erase/update paranoia I've come up with a system that is basically 2 slots. One is like a "safe mode" bootloader that normally wouldn't be erased, and other slot is for the updated versions. 32kB ROM reserved in total. And when erasing vectors in any bank, the reset vector is immediately restored.

The Incident, the first game to use the GTROM board, has been released by KHAN Games.
http://khangames.com/

The Incident can be purchased directly from the developer here:
http://khangames.com/store/index.php

So what's the programmer's interface for this board? It looks like the logic (74'10, 74'02, 74'377) makes a single register somewhere that contains 4 bits for PRG banking, 1 bit for CHR banking, 2 bits for LEDs, and whatever the last bit does.

There are 2 CHR bits, one for pattern tables and another for nametable. Seems that I totally neglected to release the docs. I meant to make it look better and add more to it, but I'll just leave that for later, I've attached the PDF to this post.

But the register map is the important part, and here's that:



I was thinking of going for iNES mapper #111 for this. At least for now, that's what my bootloader software recognizes.

Here's a link to the Cheapocabra Devkit Quick Start Guide, I wrote this a while back but never posted it in here.

But the main reason for this update is that I've finally started on some emulator support for the GTROM board. So far I've been unable to compile FCEUX, but I found that Nintendulator's mapper sources were easy to work with. Right now it has PRG paging, pattern paging, and nametable paging. I haven't checked the nametable paging visually, but it does pass the memory test. What's missing is FlashROM, LEDs, and CHR-RAM at $3000+. But it's a start. I've attached the file to this post. It is mapper #111.

Next, I'm working on adding FlashROM emulation, after that, possibly USB adapter emulation.

Er, my computer has no serial port. Is it possible to use USB-USB instead? Perhaps a simple serial-USB adapter is all I need...?

I missed seeing this question until now. It uses USB, but the driver on your PC will have it show up with a COMxx port number like a serial port.

Ah, perfect. Thank you.

I have made a preliminary implementation for FCEUX: https://sourceforge.net/p/fceultra/code/3287/

(No self-flashing implemented yet, and CHR at $3000-3FFF seems to be a hard mirror of $2000-2FFF, so I don't really plan to implement that.)

I have some questions:


1. What does GTROM CHR-RAM test.nes do?

I get a grey screen with a pattern of beeps in the following rhythm: B . . . B . . . B . B . B . . . B . . . B . B . B

Is that correct?


2. Is the self-flashing process documented somewhere?

The self-flashing process should be almost identical to the self-flashing implemented for mapper 30/UNROM512; both boards use the SS39SF040 flash ROM for PRG storage. (Identical other than that GTROM uses 32KiB-at-a-time banking, and so issuing the flash command sequence doesn't require bankswitching)

PPU $3000-$3EFF shouldn't be a mirror of $2000-$2EFF if I remember what Memblers said correctly... IIRC it's basically "the bottom 8KiB and top 8KiB of PPU address space can each choose one of two separate banks of RAM, with no sharing"

I meant that FCEUX makes $3000-3FFF a forced mirror, so I can't implement it. (It seems his nintendulator implementation ran into the same problem?)

There's vague information on how to flash at the UNROM 512 wiki, but it's kind of underspecified as to how the flash chips respond to things (e.g. what causes the sequence to reset, etc.). I guess I can probably dig up a datasheet with that flash ROM part name though (thanks for that).

I was just hoping that Memblers had already written guidelines for it.

Wow, that's great, thanks.

Yes, that sounds like the correct beep sequence. The test ROM writes an LFSR sequence into all of the CHR-RAM banks, resets the seed and reads them back for comparison. If it passes, it lights the green LED and sits in an infinite: JMP infinite loop. If it fails, it lights the red LED and sits in a loop repeatedly writing to the sound registers with my beep macro (makes a high-pitched screech on NES, may be inaudible or nearly so on emulators though..). During all this, it's sending text strings out the controller port at 19.2kbaud, not that that's useful in emulation (would be cool to do a high-level emulation of that sometime though, by adding a fake UART register for easier emulation).

I've attached the full version of the test program if you want to have a go at the FlashROM, it does things in this order:
check flash chip ID
erase flash (full chip erase)
blank check
CHR-RAM check
write $8000-$8800 of every PRG bank (shortcut instead of writing the full 32kB)
verify $8000-$8800 of every PRG bank

Works the same as the RAM test program did, it was just a cut-down version of this.

The Flash programming commands are best documented in the SST39SF040 datasheet, and like lidnariq mentioned it is similar to mapper 30. With GTROM the command unlock addresses are mapped to $D555 ($5555 on the chip) and $AAAA ($2AAA).

And yeah that memory at $3000-$3EFF is it's own region but is tied to the nametable bank select. No one is using that yet, not even my test ROM. I believe INL said one of his boards has a similar kind of feature too (not sure if or how it's banked in that case though).

If it helps, here are my flash routines (these have to copied into RAM and executed there for obvious reasons). The byte_program routine is probably kind of overkill, it follows what the datasheet says pretty closely though the NES is probably too slow for it to matter.


edit: forgot this part for reading the chip ID


edit: I removed the prg0.nes attachment since it's self-destructive to bootloaders. If you need it for emu testing or board testing with game genie, send me a PM.

Okay, didn't seem too tough to do the self-flashing once I got my hands on the datasheet.
FCEUX r3290

I didn't implement the software ID thing. Is it important?

Seems to run my dump of The Incident mostly fine. Though one or two curious things are happening, not sure if due to the mapper implementation. Saving seems to also turn off the game music for some reason, and going to erase data does erase but switches to the level editor mode for some reason (don't want to try and see if it does the same on my cart, because I've got a save halfway through the game).

Hmm, I implemented the software ID thing.

Anyhow, your test ROM (once I set the mapper number to 111, and "battery backed" to enable the flash features) sounds like it's running. Whole lotta beeping, then eventually stops.

The last written value was 0x40, which according to your PDF is a red light. Dunno what test it failed, though.

There's 57 beeps, and it doesn't end in a busy loop. This is where it ends:

The last sound written to the first square channel here is clearly not high frequency, and it's using the length counter, i.e. it's a regular "beep". This doesn't seem to be the failure noise you described?

Edit: oh wait, I didn't realize 0 turns an LED on. 0x40 means "red LED off" doesn't it, so it's actually a success, eh?

Hmm, I've noticed that your test ROM does not write the mapper register before doing the Software ID test. According to the datasheet, reading the Software ID requires A1-18 to be low. How does it manage to pass that test on hardware? Does this rely on the mapper powering on in bank 0?

As near as I can tell, when in Software ID mode, reads from addresses other than 0 and 1 are undefined and don't pass through to the underlying flash.

On many other EEPROMs, Software ID mode seems to just ignore all the high address lines altogether, effectively replacing the entire ROM with a two-byte (or occasionally larger) mask ROM. I wouldn't be surprised if that's the case here, even though the datasheet disagrees with that comment about "5. With A_MS-A₁ = 0;"

Ah, that makes sense. I'll implement it as 2 bytes mirrored everywhere then.

Also, it's kinda funny that since this is a self erasing test, I have to delete the .sav every time I run it. Probably was more annoying for Memblers who had to reflash it every time? (Is that what the modded Game Genie was for?)

That's great, thanks a ton for getting that to work. It is passing the test. I've uploaded a Win32 build of it here, if anyone wants to try it out already:
http://membler-industries.com/nes/fceux-r3293.zip
Pretty cool to see it in FCEUX, I've used that emulator so long that it's kinda like a modern-day NESticle.

That prg0.nes is what I use for testing before shipping, after running it on many hundreds of boards it is slightly surreal to see it (or hear, rather) run on an emulator. Though the beeps are little more satisfying when accompanied by the text output in the terminal, heheh.

Yeah it is kinda funny that the test self-destructs, I should probably hide that file now so when people use the on-cart version of the bootloader they don't forget what it is and ruin their day. I'll have to make a less dangerous test ROM if anyone else wants to support it in their emulators. Yep, that gets loaded from my Game Genie. It's pretty crazy how fast the full-chip erase happens, it gets annoying using the sector-based one after being used the full-erase, when you watch it go "loading, loading, pause, loading, loading, pause, ..."

I completely missed that footnote in the datasheet about the upper addresses needing to be zero when using the ID mode. The reason it never affected me was because I only load that program through the Game Genie, my loader puts it in the first bank, runs as soon as it's loaded and naturally the GG loader had set the bank reg before running it. The mapper when running by itself in an NES does certainly seem to have random startup state (especially easy to notice random LED state if the cart is blank).

Do you know what the chip does when in Software ID mode and you don't have all 0s? Does it just mirror those 2 bytes everywhere? (Maybe it doesn't matter... lidnariq suggested it's "undefined".)

I managed to get my dump of The Incident working in FCEUX, but I had to patch it slightly. It seems like the time it takes for writes to settle on the real flash is significant enough to make a difference here. I think the problem is that because timing has shifted there's an NMI happening at an very inopportune moment that causes a crash. All I did was add a BIT $2002 to clear the vblank flag at the offending moment, kind of a dodgy fix, but enough to verify that changing the timing makes the problem disappear.

I've let Kevin know, in case he decides this is something to be fixed. (Or if he has some other insight, still could be the emulator's fault in some way I don't forsee.)

I gave it a quick test, and it's not repeated. I'd agree with undefined, as there's some unknown results in there. I did a full chip erase, went into ID mode, then dumped the first 256 bytes ($8000-$80FF) and it looks like this:



edit: For giggles I tried changing the PRG bank before entering ID mode, it still works and returns the same thing.

I made a simple SNES PCB that takes a SST39SF040 and wrote a few simple tests...
First 64 bytes of the ID memory on this random one I have are:

The next 448 bytes are all FF except for two- at $00100 there's a $68, and at $001FF there's a $C8. The second 512 bytes are a repeat of the first 512, and this 512 byte pattern appears to repeat for most but not all of the memory.

Note that this flash is NOT empty.

I guess I should write a "real" memory explorer so that I can actually see where the pattern changes...

memblers: np, the post content was still in my browser history

facepalm.. sorry man, I just accidentally mangled your post. thought I was editing mine. I need to go to bed.

edit: OK, I hit the back button to recover it and hopefully have restored it

I must have made a typo in my previous test; with my kinda ugly memory dumper, I only ever see the same 512-byte pattern regardless of what all the higher address lines do.

Two different SST39SF040s have the same bytes at offsets $3B-$3D, so maybe that's a lot code (since it differs from Memblers's)

I wonder if those varying bytes are a date? 0E0C04 could be 2014-December-4 and 0F0601 could be 2015-June-1 ... The datecode on my two (with 0E0C04) is 1446, 46th week of 2014, or mid-November...

I just had a chance to check the date, and it is 1522 on that chip. June 1st was the first day of 23rd week, that's about the right time. That's kinda cool to be able to read that in the software.

This was certainly a very interesting read even though I just noticed it was a bit (very) old

Btw, are these assumptions correct?

-Everything is physically in 32kB banks.
-The tool just takes the same 16kB block and writes it one time in each 32kB bank, at your option, to mimmic a fixed-swappable configuration.

-this means that outside of the tool as-is, one can configure custom partitions; for example:
-8kB interleaved/fixed, 24kB swappable per bank, or vice versa.
-Have a 32kB bank and then a number of banks that behave like 16-16 ones.
-basically any partition you can think of to be useful for your project.

You are correct.

32K banking allows for a surprising amount of versatility, including emulating fixed/switchable banks that aren't a power of two.

I can note something I would have preferred to have: That the register is mapped at $1000-$1FFF and $3000-$3FFF in addition to $5000-$5FFF and $7000-$7FFF (although the $3xxx mapping will rarely if ever be used, it is still there simply due to how the logic is working), and it is written regardless of whether you read from or write to those addresses (if you read, it writes the value read).

Other than that it look like good, I think.

RAM and PPU registers are mirrored there.
https://wiki.nesdev.com/w/index.php/CPU_memory_map

I know that. (Those addresses would access both the RAM/PPU and the cartridge simultaneously, which can be useful, but regardless of that, it means one less bit of logic (two, if you also ignore R/W).)

Would it be theoretically possible to remap the registers individually in a future revision, or is it too inconvenient hardware-side?

My impression so far has been that while it looks practical to have it all in one and the same register, it is actually a bit inconvenient code-wise since you need to load merge states with changes before writing.

Separating things out into different registers will likely at least double the mapper logic required, so I'm guessing it wouldn't align with the Membler's goal with the mapper. The amount of discrete logic chips will start to compare to a small CPLD which could provide a much richer feature set. In reality once you start separating things into separate registers you're getting into the MMC1 scale mapper level.

Seems like a good size for a Greenpak.

Are prices of those guys posted anywhere? Looks like the slg46824 would be the best part to target as it's I2C in system programmable and also comes in more friendly TSSOP-20 packaging with high i/o and flipflop count in comparison to other versions (17 i/o & FF's). Other parts appear to have pretty good pricing available for purchase on their site $0.30-0.50ea if you can handle the 100-3k min qty. No indications of the slg46824's pricing though, shot off a sales inquiry to see what they have to say..

They stopped offering volumes less than 100 a couple years ago. Looks like the SL46824 is brand new too.

I'm a little confused by their claim that the '824 there supports 17 I/O—unlike some of the older ones, I don't see a way to turn off the I²C logic unit, so that's two pins permanently lost.

But I bet 15 I/O is still enough—for something that's the same features as GTROM but with three registers would require ... in: /rs a14 a13 a12 m2 d0 d1 d2 d3 ppua13 ; out: a15 a16 a17 a18 chra14 — that's exactly 15.

... oops, that doesn't include one input and output to invert R/W into W/R for self-flashing. Hm.

From the datasheet, "The SLG46824 has a total of 13 GPIO, 2 GPO and 2 GPI Pins which can function as either a user defined Input or Output, as well as serving as a special function (such as outputting the voltage reference). ... GPI: SCL and SDA serve as General Purpose Input Pins."

Looks like they're general purpose IN only, and including them in the i/o count because of that.

Yeah, but even allowing them to be exclusively inputs, I didn't see a way to disable I²C so that the general fusemap could use them in logic, nor did I see SCL and SDA show up in the matrix (pages 30-31) for use.

Too bad they only mention the '824 and '826 as coming in packages with legs.

Ahh I see, possible them being as new as they are the tools aren't fully updated with the silicon's abilities. Sounds like may be worth asking support directly.

I see, so it would require quite the redesign involving at least a greenpak and it'd need to be price-comparable to the currently used off the shelf logic devices; which would narrow the range of possibilities further.

I think the most useful division would be the 2 ppu page selects from the cpu page select since they're quite central. separating the 2 ppu page selects from each other or the blinkenlights from the rest seems like "only if there's logic left to use" options.

Eh, just a GreenPak with enough I/O.

Because I enjoy greenpak golf, I was able to stuff something like GTROM into one SLG46537, with the following function map:

I created this rumor, and I can finally put it to bed. The work-around is dead simple - don't use absolute indexed addressing mode to write to the register. E.g., do STA $5000 instead of STA $5000,X. That was easy.

Why this happens, is because the 6502 accesses memory on every cycle. LDA ABS,X takes 4 cycles, 5 if a page boundary is crossed. But STA ABS,X always takes 5 cycles. By the time it hits cycle 4, it's already read the opcode and is working on fixing up the high byte of the address (for page boundary cross) but it's still going to access memory. You wouldn't want it to do a write, because the address hasn't been fixed up yet. So it does a read, and discards it. The mapper register is sensitive to reads, so the register value becomes the open-bus value (the high byte of the address) for one CPU cycle.

That explains why there have been zero complaints about it. It was my testing method that failed. I've hacked a few UNROM games and simply changed the mapper address, but not the opcode, so the glitch manifests. It seemed weird that I didn't see it happening in my own programs. Mystery solved.

So now instead of a bug, we have a strange new feature. It could be used like the PPU 'monochrome bit' to benchmark your CPU usage. Or you could write to it in an idle loop to create a glitchy screen noise effect. It can affect the attribute table as well, which can get pretty colorful. Just do a STA $5000,X if you want to try it.

GTROM - $9.25 each, if you're looking for a cheap simple mapper. $35+shipping for a devkit.

Here's what the mapper write looks like (74HC377).
1(yellow) is register clock (inverted M2)
2(cyan) is register enable !(PRGCE & A12 & A14)
3(magenta) is data output (supposed to be low)

first image is normal write - STA $5000

second image is glitched write - STA $5000,X

Kool. Good job figuring it out!

I just wanted to briefly follow up on this. At my request Markfrizb looked at a couple very recent (date silk 1844) SST39SF040s and the date bits are not present. The first 32 bytes are unchanged relative to above.