nesdev.com

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.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

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.