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

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.

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

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

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?

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.

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

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.


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.


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.


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.


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.

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:


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.


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.


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.

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.

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.

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.

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.

So I'm planning on adding discrete mapper support to this board for appeal to homebrews which are content with a discrete mapper. I had plans to make discrete mapper boards flashable via the kazzo using an added resistor to pull down the /OE pin which would also be connected to EXP0. That would allow for writing via the kazzo. But that wouldn't allow it to be flashed via the NES for saves and such.

You could of course add some extra logic to make it work, but if the goal is to be as minimalistic as possible, a one chip discrete mapper is desirable.

I had a thought which I believe will work with a number of limitations. Can anyone see any reason this won't work? Or another limitation I'm missing?

The idea would be to ground the /CE pin on the flash, tie /WE to R/W, and /OE to PRG /CE. The /CE pin can stay grounded at all times. The /OE pin must be high for writes, and low for reads. The mapper would be connected normally, and work for UNROM, ANROM, BNROM, etc or even some hybrid that banks CHR-RAM or something. So writes to $0000-7FFF would write to flash, and writes to $8000-FFFF would be to the mapper, and read from flash. That would only allow the last bank to be writable since you could only really use $4020-7FFF for non-conflicted writes. That'd be okay for game use generally though since you shouldn't have to access all banks for the sole purpose of saves. But that does suck up a fair amount of space in your fixed bank (EDIT: for standard UNROM style only though)

(EDIT: For UNROM): You'd probably want to write to the mapper selected bank in $0000-3FFF, BUT you'd have to be careful because of the conflicts with other hardware mappings. Writes to RAM and the PPU could be easily recovered from though if you were smart about it. One other limit would be that you couldn't write to the mapper (or anywhere really) while in the middle of a flash writing routine. You'd have to make your flash writing routine run from RAM because you can't execute from flash while in the middle of write routines...

The only other thing you'd have to watch out for is some how accidentally writing the unlock and write/erase command routine to the flash when you were trying to just use the hardware mapped to those locations. I think the chances of that are pretty slim though based on all the hoops you have to jump through to unlock the flash (expressed in limitations above.)

That's an awful lot of work to avoid needing a extra gate or two. But for people content with a discrete mapper it might be worthwhile to have nvm for saves on a discrete board without any extra hardware. Thoughts???

Doesn't the FLASH write negotiation process involve toggling all the FLASH address lines? How does that interact with the colliding functionality thing? Seems like it would also pose a problem for using a too-large FLASH for a game that didn't fill it. Would needing to change the bank to set the higher address lines interfere with the negotiation process?

Well they don't have to toggle completely/exactly (poor wording, let me explain). This would be a /WE controlled write sequence, as such the address bits would only have to be valid while PRG R/W (/WE) was low. With the chips I'm using A0-14 need to be valid toggling between $2AAA and $5555 for unlock commands. This does bring up something I neglected though. My edit for UNROM only isn't completely true, because unlock commands would have to conflict with RAM $2AAA (mirrored to $02AA) even for 32KB banked mappers. So you'd loose operation of that byte in RAM while saving to flash for all discrete mappers. The $5555 unlock command doesn't conflict. There are other flash chips that only require as little as A0-A10 or A12 to be valid but I'm not using them on my v2 boards.

The mapper would control A15 and up, and those don't need to toggle for writes. You wouldn't have to write to the mapper durring after starting the write sequence. So you can avoid conflicts there by just selecting the save bank prior to executing the save routine.

UNROM is more of a pain, but still manageable. To have a save bank outside of the fixed last bank would be annoying for standard UNROM as you have to write data to $0000-3FFF. And you're operating from RAM this whole time. As such you'd only have ~half of the sectors to choose from for saves, but that's okay. You'd have to select a save sector that ended up in $2000-3FFF. Additionally for the $2AAA command to be valid on UNROM you'd have to choose an even bank for saves. That way you don't have to write to the mapper between unlock commands and writes.

What do you mean? a game that used less than a sector's worth of data for saves? The sectors are 4KB in size for PLCC-32 chips generally. Not sure I understand the problem you're considering.

$2AAA is not a mirror of RAM $02AA; it is a mirror of PPUSTATUS.


Earlier someone mentioned flash with 64K sectors, the kind that would need a log-structured file system to use effectively. Besides, most discrete mappers lack the 7420 needed to decode WRAM, and games without WRAM can't really use a save bigger than 1K.

I guess the negotiation process varies so widely by specific flash that it's not clear there's a unifying set of problems. For one that only used the 12 LSB address lines, it clearly wouldn't matter regardless of banking style. On the other hand, for something like the SST39SF0x0 series which uses all 15 LSB address lines, the command sequence for sector erase ends (write $55 to $2AAA, then write $30 to the sector to be erased) with the opposite value of A14 than for byte program (write $A0 to $5555, then write the value to the address), so I'm not altogether clear you could safely use those specific ICs on a reprogrammable UNROM board.

I was assuming more than 16 bits of address were required to enter any programming mode. But, given that these parallel flash are most often used in microprocessors with a 16-bit address bus, maybe that's foolish.

One other possible complication is that the 6502's R/W goes to its final value (along with the rest of the address bus) at the beginning of Φ1, and the value of the data bus isn't guaranteed to have settled at least until the beginning of Φ2. And M2 is even later than Φ2...

. Man, I impress myself some times with my ability to convince myself of such ridculousness as $2AAA > $1FFF...

Having the conflict with PPUSTATUS is actually perfect. Although I'm assuming nothing actually happens when you write to a read only PPU register. There's no reason to even write to $2AAA when you're normally reading from $2002. With $5555 not conflicting with anything, it's safe to say you'll never accientally jump through all the required hoops to accidentally write/erase flash.

Well that discussion was under the assumption that a more complex mapper (> discrete) was being used. Even still, those 64KB sectored flash chips usually have one sector broken into smaller ones (as small as 8KB) for the MX29F*00C. With a save size of 1K you could still make good use of 4KB-8KB save sector(s) with multiple save profiles and retaining outdated copies for redundancy. 'Wasting' 3KB of a 128KB chip doesn't seem like a sizable loss IMO. For something without banked PRG-ROM that might not be the case, but that's kinda besides the point.

Of chips in production today there are really only two flavors x8 and x16 (in BYTE mode). Their command set is effectively the same though aside from the one bit shift in addresses.

I always saw the ones with fewer required valid address bits to be preferable. But in this case having the lack of mirroring actually makes it simpler $2AAA doesn't mirror down into SRAM address space.

Yeah that's why I was saying you'd have to choose a save sector that was in an even bank. You need A14 to toggle between $0000-3FFF and $4000-7FFF without writing to the mapper. Selecting an even bank to contain the save sector would satisfy that, you'd just have to deal with the fact you're writting to the PPU (or RAM) at the same time. If you choose the two sectors mapped to $2000-3FFF you can avoid most likely deadly conflicts with RAM. You'd just have to get clever with handling PPU conflicts. I'd say just turn rendering off after each write to a mirror of $2001. Or just let the PPU go crazy for fun. Then assume the entire PPU needs initialized and redraw everything after writing save data.

Yeah I'm unaware of any such chips. That and it doesn't have to be a universal solution for every flash chip that ever existed. Just needs to work with ones choosen to solder onto the board.

Yeah I was thinking about that too. I think this is the real threat to my idea here.



So the address needs to be valid when R/W goes low. That might be an issue... Now that I can pull out my scope and compare, it looks like PRG R/W rises and falls with the address lines. Tas (address setup) is zero on these chips, but it's hard for me to say that the address will indeed be valid by the time R/W goes low. I always have a hard time conceptualizing zero times, really Vil of the /WE pin is what decides the timing. It might just work, or perhaps could work well enough with verification and repetition. You might be able to cheat and put a small cap on R/W but that's not exactly kosher... EDIT: One thing that does help is that we'll satisfy the 30ns hold time without issue. But I still think the chances are slim.

As for data being valid when R/W goes high, that's a non-issue with the help of bus capacitance. Data is usually valid well into the next cycle.

If the setup time on the address bus doesn't work out, the smallest piece of logic I can think of that'd solve the issue is to put an inverter to drive /CE with M2 inverted. Hey if you did UNROM with NAND gates, and 128KB PRG or less, you could get an inverter for free.

ITYM NOR gate.

Well that'd work too.

OR gates: last 16KB fixed to last bank (no free inverter) 'standard mapper 2'
AND gates: first 16KB fixed to first bank (no free inverter) 'non-standard mapper 180'
NAND gates: first 16KB fixed to last bank, mapped bank number inverted (free inverter if 128KB or less) EDIT: this one might be preferred to avoid conflicts with PPU for writes.
NOR gates: last 16KB fixed to first bank, mapped bank number inverted (free inverter if 128KB or less)

Right?

That depends on whether the small sector ends up in a fixed bank or in a switchable bank.

And if it turns out that we must use mapper 180 for whatever reason, that's not too much of a problem for homebrew unless DPCM in the fixed bank is needed. It's not hard to put the vectors at the end of each 16K PRG bank. The problem comes when testing the game in an emulator.

you'd pick the part with the top or bottom boot sector to get the desired placement of the smaller sectors. Either way it ends up the last/first sector is 16KB, below/above that are two 4KB sectors, and then the remainder for 32KB bank. So the two 4KB banks end up in the second or second to last bank which should work regardless.

Isn't it actually preferred to be able to bankswitch on the DPCM bank? So AND/NAND gates are preferred?

Yeah there's always that hurdle. However my opinion is "If you build it, they will come."

Samples in the fixed bank allow decoding level data without interrupting drums or sound effects. If you have a lot of speech and only rarely access level data, the Crazy Climber layout becomes a good choice.

I gave a heads up about the INL-ROM cart to the chip music crowd @ ChipMusic.org
http://chipmusic.org/forums/topic/12922 ... rt-dumper/
The SXROM flash cart is a god send for running Pulsar and PR8. Thanks again!
Yogi

Glad to see other communities interested in the project.

To answer your question from you other thread:
You mean flashing the atmega via the cart edge? If so yes, I connected the SPI signals to the EXP port. But that's not only for programming the avr, primary purpose for routing those signals there would be to program a SPI flash.

The idea is for the CPLD to decode $5000 for the avr and use one signal for a "avr select" for the CPLD to interupt the avr. Whether the avr or CPLD would decode A0 is TBD, and dependent if it would be necessary.

I know you're in early stages ATM, but at some point do you think there could be a 'Arduino' development version? With an ATMega 328 @16MHz and access to the Rx/Tx pins you have the basic Uno. Coupled with your 'FDS' ram cart design this could be a great platform, for both the NES and Arduino community.
For myself, I fall more into the 'PIC fan' club, but the Arduino IDE and community offers allot. Seems like there is a Arduino project for just about every application one could dream up, so there is example code everywhere. This could make the transition for a NES developer very easy, but a little less for the Arduino user going from C/C++ to 6502 assembly (cc65 would help here).


OK. I could see where using A0 (and also A1) would be useful for passing some state data to the Mega. Example, the address that the 2A03 read from would signal the uC what to expect at the next access cycle; this could provide cycles for the Mega to fetch from flash or process data on demand and be ready to output at the next read.
Anyway, sorry for rambling. Looking forward to your progress.
Yogi

I've got it setup for re-flashing the AVR via a USB bootloader, it's the same way you're able to update the firmware on your kazzo. So it's the same chip as an arduino, but significantly simpler/cheaper to program. Personally I feel the arduino is an unnecessary level of abstraction.

Pretty much yeah. It's all a juggling game between features, user friendliness, timing, speed, and i/o on the mcu and CPLD.

I assumed you would have a bootloader. I was just thinking about the development environment and the vast community of developers that are using Arduino's.

Agree 100%, 'Arduino' does carry a lot of overhead. While it's true that anyone planning to jump into a NES/AVR project will need skills beyond the 'blinken lite' wow factor, if one is developing in '6502', jumping into AVR assembly also, may seem daunting (or not?). Being able to use Arduino's libs and another user's code base allows fast tracking the AVR side of a project at the expense of CPU cycles.
Of course, all of the above assumes a GP development platform, rather than a more turn-key HW design. More than likely, there are only a few people interested in developing on both platforms at the same time. So a limited feature set makes more sense for the NES development community.


So true.
Sorry if I seem to be harping on the whole Arduino thing. There is just so much development going on with Arduino synth projects it's hard to ignore, seeing as you are at 95% Arduino compatible with your design.
Whatever form the released version takes, it will be great!
Yogi

Well the project isn't intended to be a mapper development tool, the intent is for me to design the mapper and supply it for game development. That said, I'd be more than willing to help someone who wanted to develop their own mapper using the board by providing pinouts and schematics and such. But developing a mapper of this nature isn't a simple task, I'd expect someone interesting in doing something like that to want to take off the arduino training wheels and develop for the raw atmega. I'm not very savvy in the arduino ways, but as I understand the idea of cycle counting and writing assembly for time critical operations is beyond the scope of most arduino users.

That and the arduino requires a separate mcu just to program the thing, where V-usb only needs a set of diodes and some resistors.

What part is incompatible? AFAIK once the code is on the mcu and up and running it really isn't an arduino anymore, it's just a standard avr. Arduino is the IDE and means of getting your compiled code onto the avr. If someone knew what they were doing I'm pretty sure they could take a synth developed on an arduino and get it up and running on this board just as long as they didn't rely on the TTL serial port while operating. Either that or just convert it to the arduino means of programming yourself.

Tell ya what. I need to move things around on the ports anyways after realizing I don't want the data bus on PORT D (which is where the Rx/Tx pins are). So that works out nicely. I'll ensure that those pins are available for use buy a developer via solder pad. So you'd have to attach your own TTL serial programmer, but there wouldn't be any pcb hacking necessary to do so. I'm not going to say it's an arduino, but I'll make it as easy as I can for someone to convert it to one on their own.

I hope I didn't give the impression that I was criticizing, it really wasn't my intent. I'm very impressed with your work and want to see a midi synth happen.



Understood. I wasn't really thinking about re-inventing the mapper wheel. Just seeing a really great platform to develop a midi synth on.
For my limited tunnel vision, an 'Ideal' platform provides enough rom and ram area for a basic NES UI and sound engine, with a memory mapped data port for a midi synth/bridge controller. As far as mappers go MMC1 is probably over kill, just as long as there is expanded WRAM for processing note and effects data. As I look at the V2 board all the elements are in place!
I totally understand your POV, the majority of this community has a very different focus, but there are a great many folks that would welcome an alternative to the midiNES. There was a bit of a let down with the Chip Maestro project, because hopes were very high, even though Jarek's design is pretty good and worked as planned. I see a lot more possibilities with your board.



I think I have you schematics that you posted a one point (but could've been the Kazzo), just need to load the CAD package that you use, only have Eagle installed ATM.
You're right in that trying to run C or C++ on a 8 bit mcu has lots of limits, but Arduino code isn't much worse than AVR C. In line assembly is allowed but few people use it, true. With a cart specific lib to handle the NES interface, a developer could get about their project a little quicker.
The advantage is the abundance of code examples with the Arduino; finding AVR assembly examples would be difficult in comparison. So getting a project off the ground would be faster, but more limited; although at almost 16 MIPS the hit isn't to bad. And sharing the note processing on the 2A03 helps as well. There are tons of midi related projects that are pure Arduino so performance wise it's not TOO bad.



Well, yes and no. The Uno (based on the ATMega 328) uses the UART, regular old TTL RS232; but to add USB, a FTDI chip is needed. An external USB/serial dongle would do; could be switched out for 5 pin midi din dongle depending on the user's setup.
The serial/USB connection can also be used for console IO or midi over USB at runtime, and in the context of a synth would be useful. I could see Famitracker redirecting it's output to a NES for live play.
As I understand, V-usb is bit banged? This could be a problem for use with a real time midi app. Using the HW UART takes a tremendous burden off the uC.


Well, the xtal (don't know what clock speed you are planning on), bootloader and the HW UART with a CTS/RTS controlled reset are really the only 'Arduino' specific elements, so lets say closer to 98%
I'm not an expert on the Arduino firmware's internals, but I think there are runtime accessible communication routines the IDE expects to be there, so it's a little more than just a boot loader AFAIK. But no it's not byte-code like a Basic.
Goes without saying that there isn't anything magic about the Arduino. Anything that can be done in C++ can be optimized in assembly, it's just a matter of skill and time available.
Your board is a great platform as is and will make a good synth in the right hands. But finding people that are AVR/6502/Midi competent programmers and motivated to spend the time on this kind of project, is a challenge. The net is just wider by including the Arduino community is my only point.


YES That would work very well. Whenever the redesigned boards are available I'll definitely have a go at one.
Yogi

Oh no worries, I didn't feel that way. Sorry if it sounded as I was getting defensive, I was just trying to explain my take on things. I'm glad you've brought this up, as sound capabilities has been a goal of the atmega version. That and it's a very minor mod to the board to allow for TTL flashing arduino style with an external programmer. To be honest I'll probably never write a synth myself. I'd like to, but I'm really not a sound buff, nor do I plan to devote the time required to become one anytime soon. So having a means for others to develop a synth that could be incorporated to my design is the best chance for success here.

Yeah it should be pretty easy to provide that.

Yeah I've actually talked with Jarek about his chip maestro before, I also saw a thread on chiptune where you guys were discussing this issue, and desire for a NESmidi replacement. I'd like to support that effort if possible especially if someone else was doing the heavy lifting on the synth side.

Well my intent for the USB was only as a bootloader for the avr and flashing nes rom image, athough there could be other uses. Once the .hex is generated and loaded onto the avr, it doesn't really matter how it got there. I can get any pre-generated .hex loaded onto the mcu even without a bootloader.


My plan was 16Mhz, although anthing compatible with the atmega could be used if V-USB wasn't being implemented. Just a matter of soldering on a different clock.

Indeed, I'm the guy lacking the midi component. With little motivation to pick it up.

Not sure when that'll be at the moment. I actually hacked out the atmega on the batch I just ordered and put a BNROM chip in it's place. That was a temporary move to suit my immediate needs and knowledge that things needed swapped around on the pin assignment. That and I have a lot of development work to do with just the attiny alone before I can step up to the atmega. The next batch I order will put the atmega back on there with discussed modifications with the data port and TTL access. Should be ~6 months is my guess.

So glad to hear, (so very hard to tell on the interwebbes sometimes)

Well, I don't know that I'm up to the task either but really want to try. Have some ideas for a prototype SOROM board hack to test with, but we'll see how that works out.

\o/

Yea, some people were thinking about reverse eng'ing the midiNES to reproduce it. In most cases I would frown on that; but I have some old, hard feelings on that project, so I'm 'conflicted' on that idea.
In fact it's kind of how I found my way to your projects, I was researching Membler's Squeedo.
IMO you already have done a lot of the heavy lifting! The hardware part of this sort of project is a huge milestone.

V-usb is very slick, and to be honest very new to me. Never considered bit-banging USB in the past. My only concern is with the runtime performance but I am only guessing that there could be an issue. It's obvious that it works fine with the Kazzo.
With SIO pins connected to the cart edge, re-flashing the Mega shouldn't be a problem, even with a factory fresh chip. I've got a few solder tail 72 pin connectors floating around here, be easy enough to wire up a AVRtinyUSB to Game PAK adaptor for my use.

Perfect. 16MHz

Just keep doing what you're doing! Really Great!
The right mix of skill sets is hard, that's what makes open source so great for these types of projects, 'many hands makes the lifting light'.

No rush, got plenty to do myself. Looking forward to it!
Yogi

Good news!

Pokun pointed out to me that krikzz made a new famicom mold to support his everdrive. They're currently available for purchase: http://shop.retrogate.com/Famicom-shell ... oductId=26

I ordered a case to learn the dimensions needed on the PCB, so I'm planning to make a 60pin version of these v2 boards. Hoping to have them available some time this summer.

Too bad it says "Everdrive" on the bottom

Honestly I don't see this as an issue. I'm just thrilled to have new cases available regardless of what they look like. Others (especially collectors) probably feel differently I suppose though. The location of the wording is in a decent location to put a sticker over the top of it. So for a released title that'd be a nice way to cover it up.

That price is laughable. Might as well find 4 people willing to make a game and sell 125 copies of each and get your own made for that price.

I believe that's what the competitions are about. Proceeds from sales of each compo multicart go toward growing the infrastructure for small-volume publishing of NES games.

The price you see isn't the end all be all. I contacted them and it sounds like they can provide them in large quantities for around the same price we purchased cases for the release of the first volume.