INL-ROM v2 flash 'simple' dev/repro USB boards

[infiniteneslives]

So INL-ROM v1 has been pretty successful thus far, but I've since came to realize the PITA that is EPROMs. So I cut the board and half and went all flash which is actually cheaper and easier to deal with anyways. The biggest benefit to all is providing fully assembled boards. There are a lot of challenges to providing and testing partially assembled eprom boards. Depending on the going rate for eproms this ends up being cheaper anyways. It would allow someone to release their own game with the only time investment being ~20-60sec of programming per board. The label, box, and shipping will take far longer than preparing the hardware. No longer need to be setup and prepared to solder in order to release your own homebrew in hard copy. I've got my first sizable batch of cases on the way as well; and working on a long term stable supply of them.

They still support MMC1, MMC3, and FME-7 etc. But I cut support for MMC2/4 and the synth for sunsoft-5b, those will remain on INLROMv1. I also added some jumpers for supporting VRC mappers with this version and other FC only's that use lower PRG Address bits for register select. I also cut out the discrete logic IC's partly because of the use of flash, and because discretes can go in CPLDs anyways if desired. I didn't really use the discrete logic IC's much anyways on v1.

I'm thinking about making a discrete only flash version down the road if there's interest. I figured out a way to make flash discrete mapper boards with only the memories, 1-2 chip 161/377/32, and a resistor. So even if you don't like all this fancy CPLD mapper stuff but your britches are too big for NROM; that may be an option on v3 I guess...

Part line up:

1. up to 512KB PRG / 256KB CHR flash ROM
2. 128KB PRG-RAM/WRAM
3. 32KB or 128KB CHR-RAM
4. ATmega48/88/168 series for 'mega USB version'
5. ATtiny20/24/44/84 series for 'tiny USB version'
6. SPI flash/ram 2MByte-16MByte? (only limit is however big you can find it...)

I've got a few 'big goals' of what I'd like to do with these aside from the standard MMC1,3,FME7 flash boards. Currently I've got my prototype up and running and am able to flash MMC3 games on via the cart connector and the kazoo. Should be able to flash them via any interface though including the NES. I'm able to differentiate between mapper and flash writes enough to not modify the mapper at all really.

Modest first big goal is 'Homebrew FDS' that's kinda along the lines with what I was discussing in this topic. The general goal is a single (small) CPLD with 128KB PRG-RAM, 32KB CHR-RAM, and spi flash with byte wide reads. Hoping for something like 4KB CHR banks, and a scanline/cycle counter. If I can pull it off I'll be using something like an attiny20 to act as a non-random access bootROM to load a startup routine into SRAM that would then uppack spi data to PRG-RAM and then hit the reset vectors. To start though, for mapper development I'll just use an actual boot rom. Sounds like a lot I know, but really it's not a lot of hardware. It's just squeezing the parts for all their worth with low production cost as a major goal. Adding a few more discrete components and going to attiny44 on that design would allow for USB reflashable SPI possibly. But if you're taking that step, may as well go for the gold with my next plan.

Next step up from there would be going to the atmega with something like what I brought up here. That would give enough i/o to do some pretty powerful things having the atmega running as a co-processor. USB, synth, interupts, ability to reflash the CPLD's and parallel flash ROMs if they were present, yadda yadda yadda... A pretty big oyster for not a lot of hardware actually. Speed critical stuff like bankswitching handled by a CPLD or two, and complex non time critical tasks tossed over to the mcu to take care of.

Here are the pics!

Not sure if there's room for another trace, signal, or even more parts...


Here's my first board with the ugly brown sockets. Setup for MMC3 TNROM/TKROM.

[byemu]

It is too strong!
And can you make one for famicom ?

[infiniteneslives]

It doesn't have to be all that crazy homebrew stuff I'm dreaming about. It'll run just fine as plain old vanilla MMC1/3, VRC1-4, etc.

I could make FC versions, but to be honest I hardly ever get requests for them. Last time it was requested was over a year ago when I was considering drawing up v1. There's not a whole lot of shrinking that needs to happen with the PCB to make it fit in a FC case. If I get some more interest I'll consider doing it. With all the different versions of FC cases I'm not sure what outline to give such a PCB anyways...

[tepples]

If you can find a source for new FC cases, you could just outline that.

Anyway, it's looking great. As for the "SPI flash interface" mentioned in the other post, I wonder how its disk images will be represented in emulators. I imagine that each mapper supported (MMC1, MMC3, FME-7, and possibly multi-discrete) will need a variant that maps the SPI interface at $5000 or thereabouts. This might cause problems with the multi-discrete mapper, as its configuration register is at $5000. And how much gets loaded at boot time? Have you decided?

[MottZilla]

It's looking good. I suppose depending on the configuration, a board with PRG-RAM/CHR-RAM and SPI Flash could potentially be used as a multi-cart supporting tons of smaller discrete games. If the serial flash can be written, perhaps existing FDS games could be converted. Lots of possibilities I'm sure.

[lidnariq]

Does it make any sense to try to stuff the IRQ into the microcontroller?

[infiniteneslives]

If you can find a source for new FC cases, you could just outline that.

Yeah I've got to fully tackle NES case molds first. Not sure how long it would take to payoff a mold with FC cases, might be prohibitively expensive. Although I probably would have said the same thing about things I'm doing right now 1-2 back... It might be possible to design the PCB to fit inside a handful of the more popular cases out there. Target to specific donors for cases, but thinking about that makes me sad... That and opening and re-using FC cases is a royal pain, I think I've finally got a method figured out to open them without harm though.

Anyway, it's looking great. As for the "SPI flash interface" mentioned in the other post, I wonder how its disk images will be represented in emulators. I imagine that each mapper supported (MMC1, MMC3, FME-7, and possibly multi-discrete) will need a variant that maps the SPI interface at $5000 or thereabouts. This might cause problems with the multi-discrete mapper, as its configuration register is at $5000.

All of that has yet to be finalized. I've got a design drawn up and synthesized for the shift register inside a CPLD. I'm planning on using $5000 & $5001 mirrored up to $6FFF. To some degree the only value in slapping the SPI interface onto a standard mapper like MMC1,3,FME7 is for a multicart or when you don't want covert the game's mapper so the game would be oblivious to the engine underneath it all.

If we're talking homebrew development you'd want a significantly re-vamped version of a 'stock' MMC1,3,fme7 so you could fully utilize the 128KB of PRG-RAM, and 32-128KB of CHR-RAM. There isn't any point to support greater than 128KB parallel memory with the mapper. That was kind of the goal of the multi-discrete. It has a complicated structure for the sole purpose of supporting large parallel ROM. Large parallel rom is expensive on the logic cost/consumption, that's only one of the big benefits of the SPI interface, expansion is dirt cheap. So instead of modifing the multi-discrete mapper, I'd suggest a whole new mapper. Really the homebrew FDS I've got plans for could be structured to behave similarly to the multi-discrete in the eyes of the game. Only loss would be the limit of 128KB of PRG-"ROM". A game that wanted more would have to become aware of the underlying homebrew FDS interface to some degree; there could be helper functions similar to what the FDS boot rom has.

And how much gets loaded at boot time? Have you decided?

I haven't finalized anything. But the end goal would be to have no traditional bootrom. The only ROM would be SPI, all parallel memory would be RAM. The mcu would act as a non-random access ROM to load up NES's onboard SRAM via a series of LDA/STA instructions. That startup routine in SRAM should be pretty small, I don't know exactly though (perhaps 100-200 bytes?). The mcu would then have the NES jump to SRAM and execute the load routine. There really wouldn't be a limit as to how much the bootloader now residing in SRAM could load into PRG-RAM and/or CHR-RAM. But if the game (or multicart menu) is a homebrew, there isn't much point to blindly fill everything. Something like just loading up the last 8KB (or whatever fixed PRG banks there were) would seem to make the most sense. So the developer could rely on the last fixed PRG bank to be loaded once their game started up. All other memory would be assumed as unknown start up values, and loading from SPI to RAM would be up to the game.

It's looking good. I suppose depending on the configuration, a board with PRG-RAM/CHR-RAM and SPI Flash could potentially be used as a multi-cart supporting tons of smaller discrete games. If the serial flash can be written, perhaps existing FDS games could be converted. Lots of possibilities I'm sure.

The SPI flash will be writable one bit at a time via bit banging. This allows for saves without the cost of a battery for homebrews. I've considered implementing official FDS interface with something like this in order to run FDS games without hacking them. That was too complex for this design though even with cutting out the sound. If one were to get super tricky and have the mcu 'sniff' the PRG data bus so it'd know the CPU's execution without actually seeing the entire address bus it might be possible. Probably too extreme though... To do it right though, I'd probably need to step up to something like a machX02 CPLD.

If the FDS games were hacked to some degree you could probably make it work with this design.

Does it make any sense to try to stuff the IRQ into the microcontroller?

For some things it certainly makes sense. If using the mcu as a co-processor for complex math, sound, and SPI interface you'd want to use IRQ's to signal the CPU that the co-processor was complete with it's task. There are some decent timer/counters in the mcu. You probably wouldn't want to try and count CPU/PPU cycles exactly or have a traditional MMC3 scanline counter. But you could set a timer every frame at a known time, and be able to expect the mcu to provide an interupt with decent precision. Basically have the mcu keep track of time on it's own and use timing equations to get a set number of CPU/PPU cycles based on the difference in time base between the NES and mcu.

[lidnariq]

Does it make any sense to try to stuff the IRQ into the microcontroller?

For some things it certainly makes sense. If using the mcu as a co-processor for complex math, sound, and SPI interface you'd want to use IRQ's to signal the CPU that the co-processor was complete with it's task. There are some decent timer/counters in the mcu. You probably wouldn't want to try and count CPU/PPU cycles exactly or have a traditional MMC3 scanline counter. But you could set a timer every frame at a known time, and be able to expect the mcu to provide an interupt with decent precision. Basically have the mcu keep track of time on it's own and use timing equations to get a set number of CPU/PPU cycles based on the difference in time base between the NES and mcu.

I know PICs have an external clock input (or two) that could easily be connected to PPU A12 or M2; in combination with its 'toggle pin on counter match' it would be awfully easy, with almost no firmware involvement, to implement either a cycle-counting or scanline counter. I assume the ATMegas have something comparable?

Tangentially: I was idly thinking about how much of the N163 could be implmented in a microcontroller, and came to the conclusion that both the IRQ and sound (and internal RAM) were all slow enough to be implementable so, leaving a CPLD to "only" have to do the relatively complicated bankswitching.

[infiniteneslives]

I know PICs have an external clock input (or two) that could easily be connected to PPU A12 or M2;

It most certainly does, and I actually knew that but for some reason it hadn't crossed my mind to consider that option. Unfortunately I connected up the data bus on the port with those input pins... Ah well, not that big of a deal at this point. I can move the data bus over to PORTC, it'll just require the reset pin to be disabled which I had figured I'd end up doing anyways. Not to big of a boo boo at this stage in the game, this first batch of boards is pretty small and honestly would be gone by the time I get the attiny version up and running anyways. Just glad you helped me come to my senses now vice later. The attiny has the same option, but those inputs reside on the only byte wide i/o port. So you can't have a data bus (on it's own dedicated port anyways) and have external timer/counter clock inputs. So a counter of this nature would need to step up to the atmega version.

Here's what the i/o port line up would be then:

Code: Select all

PORTB not many options with this port based on required i/o
PB0,1: USB D-,D+ (could be placed on portD)
PB2-5: SPI bus (required)
PB6,7: XTAL/resonator inputs (required)

PORTC
PRG Data bus (required to disable the reset pin)
This port is also dual purposed for CPLD TDI, TDO, and TMS signals for programming CPLDs when removed from NES for firmware updates

PORTD 
PD4,5 timer/counter inputs:  PD4 (Timer0 clock):M2 for certain, possibly some CHR signal for timer/counter1.
PD6: Sound output (waveform generator from 8bit timer/counter0 is output here)
AVR select (signal from CPLD to decode when CPU is addressing AVR)
PRG R/W, IRQ
PRG A0?
CPLD JTAG TCK?

ADC6&7:
Couldn't come up with many useful things for these two analog to digital input pins.
Figured I could use one as a bootloader switch.
Possibly use the remaining pin to sense some other user or system input

So some things would still be fairly up in the air on PORTD.
I'd probably go for CHR /RD or CHR A13 as an input for the timer counter instead of CHR A12.

Also thought about using PRG A0 as an input on this port to allow the avr to have two addresses, but that isn't really necessary. The input could be useful for sensing one CPU cycle/access from the next though as well.

CPLD TCK signals would need a pin or two to allow for firmware updates without an external JTAG programmer. This could be dual purposed though by means of a jumper or something since you'd only perform this while the cart is removed from the NES.

in combination with its 'toggle pin on counter match' it would be awfully easy, with almost no firmware involvement, to implement either a cycle-counting or scanline counter. I assume the ATMegas have something comparable?

Although the two timer counters are 8bit the other is 16bit. software could handle the rollover though if the counters weren't as big as desired.

Tangentially: I was idly thinking about how much of the N163 could be implmented in a microcontroller, and came to the conclusion that both the IRQ and sound (and internal RAM) were all slow enough to be implementable so, leaving a CPLD to "only" have to do the relatively complicated bankswitching.

That's pretty much along the lines of what I came up with as well. Splitting tasks between the CPLD and mcu are what really allows for each device to shine where it's best suited. A single mcu or CPLD/FPGA that could handle both types of tasks would be prohibitively expensive to be sold as a single game cartridge. This type of structure allows you to scale down as far as you'd like.

[lidnariq]

That's really weird. Why didn't Atmel give you PORTC7 instead of just two analog ADCs on the 32-pin version? (I know, I know, die size) ... oh well.

Goofy options for ADCs, if used as ADCs:
Photocell. Microphone. Thermistor. Orientation.

I see one can configure the ADCs using the comparator as an edge-triggered interrupt, too, so it's not just a digital input.

[infiniteneslives]

Yeah figure I'll just leave it unused so a developer could do something with it if they pleased. That's a good point about the comparator interrupt, it could be put to fairly valuable use with that.

The only other thought I had was to use it to sense 5v power from the NES or USB. Might be useful to know when a usb cord is plugged in or you're actually inserted into the NES. You could determine that from other inputs though, so unused is probably be better off. It'll be there waiting for when the situation arises that it can prove itself useful.

[chromableedstudios]

quite an impressive board! does this bring the cost down much since the footprint looks about half as big as 1.1?

[infiniteneslives]

quite an impressive board! does this bring the cost down much since the footprint looks about half as big as 1.1?

Thanks! The pricing will differ compared to my other boards, but since this design will only be sold as fully assembled it'll actually cost more based on the added flash chips. But my goal is to make them available for around the same price as the combined cost of my eprom boards and EPROMs that you would have to acquire yourself. The end cost should be about the same depending on what kind of price you find on eproms. But you're getting a lot more benefit compared to eproms. Far fewer issues related to assembly on both my end and end user's end since the boards are fully testable before going out the door, and no assembly required by the user. On a production scale the time savings is huge, along with the headache factor of eproms. You could easily program ~dozen of these in the time it'd take to program and assemble ONE eprom board.

That whole issue was one of the big motivators for this version. A lot of the issues I have with the first version was due to the inability to fully test something that's only half assembled. It's getting to the point where I spend about as much time helping people with their first assembly than I do actually assembling them myself. I can't keep that up for long. So this should resolve a lot of those issues for people who only want a board or two. Once they're fully up and running I'm planning to change things up a bit to where the partially assembled eprom versions are required to be purchased with a min qty of 5-10 or so. That will allow me to stream line things enough on my end to where I can still make both versions available. Not that I'd never sell an individual v1 eprom board again, but it'd probably only be by special request or for mapper/board configs that are really only desirable for homebrew use.

[MottZilla]

I got my kazzo yesterday along with my NES and SNES flash boards. It takes only a little bit of time to figure out what you're doing with the software and after that it's awesome.

[jensma]

I got my kazzo yesterday along with my NES and SNES flash boards. It takes only a little bit of time to figure out what you're doing with the software and after that it's awesome.

I second that.