So the good news is I recreated the MMC3 on my CPLD with the NESDEV1 cart I'm working on. But ever since Bregalad's chart in the discussion where Tepples created the
mapper wizard I've been thinking. Seeing that the community's solution to getting a scanline counter, and CHR-RAM (edit: and WRAM) was to hack up a hard to obtain Japanese cart was hard to swallow. Something as basic as these things shouldn't be difficult to get together. I'm thinking that there is a sizable need or use for a MMC3 reproduction cart similar to retrozone's repropaks but in MMC3 flavor.
Really now that I've proven to myself that I can make them and have a solid design, I'm looking to see what people think of the idea. I don't know of many MMC3 homebrew projects right now aside from miau's Super Bat Puncher. But if something like this were available maybe other people would use the MMC3 in their projects.
The secondary goal would be to give people another option besides hacking donor carts for reproductions. If there was enough demand I'd work on cases and CIC's in the future as well, but for now you'd have to head over to retrozone. His prices are pretty decent though, so I wouldn't see that as much of an issue aside from shipping.
In a basic version it would just be set up to accept different configuratons via jumpers. Like CHR RAM or ROM, TLSROM style 4 screen, larger WRAM etc... Also for the fami guys, depending on what the demand was I would make 60 pin versions of the boards as well.
The other thought kinda stems back to the original idea of the NESDEV1. I kinda went beyond the scope of what the project originally was intended for, but the tool I have now is really what I needed to easily develop these types of things. The CPLD I'm looking at right now should only have half of it's resources used for a stock MMC3. So if there was interest for a more better hybrid MMC3 it could also be implemented on the same board. Maybe try out Tepples' idea of checking CHR A13 for the scanline counter vice the cumbersome CHR A12 clocking. My other thoughts were perhaps Tengen's RAMBO-1 style counter that could be swapped over to a CPU cycle counter. Changes to bank switching and stuff should be within reason also. If something like this were to happen the mapper design would be published. That way the mapper's hardware details would be known by all.
I know there is other work going on with Member's 8T-ROM with it's MMC2/4 ish behavior and such. And we've got some dev/flash carts also in the mix. But there has been enough discussion of about when a MMC3 board is made available I thought I'd offer up the service and see what you guys think. My goal would be to have it for $10 or less, and offer pricing breaks for larger quantities and such. I'm not trying to strike it rich or anything, I just enjoy this stuff and would like to make these available.
I think someone should offer a MMC3 clone board to help discourage destruction of old games. People will certainly make reproductions, it might as well be done with NEW parts rather than destroying old games. After seeing some thread where someone was thinking about sacrificing Mega Man 2 that really bothered me. Mega Man 2 was an excellent game, why would you destroy it.
So if you can make up clone MMC3 boards that are functionally the same I think you should.
I would consider using the MMC3 in my projects if there was a reliable source of boards. Not that I'm sure I'll be releasing any game physically anytime soon, but it would be nice to know this is a possibility.
I had actually thought about this a while ago. I'm for this, especially if a Famicom version could also be produced. Translated carts for the win!
Okay well I'll start looking into more of the details of what's possible as far as manufacturing and end price goes. I'm guessing there isn't much market for it if I can't keep the price close to $10. It might end up being a pretty large investment for me to get it to that price off the start. If I'm having troubles it might end up that you'll have to buy 3-10 of them to get that price or it would end up closer to $15 in individual quantities.
Part of the biggest issue is there isn't much for 5V tolerant CPLDs that can fit a full fledged MMC3. Most cost effective option is 3.3V parts, but they then require supporting circuitry of level shifters and such which further complicates assembly. Chance are the ROMs used will end up being required to accept 3.3v logic signals, but that shouldn't have much effect.
If the only interest was for homebrew productions it's possible that the MMC3 could be minimized to fit on a cheap 5V tolerant part that would make less than $10 PCB and mapper without a problem. But people prefer different things. One solution would be to restrict CHR memory to 32KB (for CHR RAM presumably). Doing that would reduce the required logic almost by half. In that case it would easily fit in a 5V tolerant CPLD and $8-10 end cost would be simple and I could assemble them myself with the coarser pinned CPLDs. Something like this would be much more achievable for me to produce, but it ends up being our own mapper with MMC3 qualities.
How's big this market and how much peole ready to pay. Let's figure out price for 10 IC's, 50 and 100
infiniteneslives wrote:
I'm thinking that there is a sizable need or use for a MMC3 reproduction cart similar to retrozone's repropaks but in MMC3 flavor.
I asked bunnyboy and as far as I can remember, he said he's likely to start selling MMC3 ReproPaks once someone asks in good faith. "Good faith" in this case would mean that someone has finished a homebrew game that absolutely needs a scanline counter.
Quote:
I don't know of many MMC3 homebrew projects right now aside from miau's Super Bat Puncher.
And even that uses an MMC1, not an MMC3. The compo version uses SNROM, the same board as Metroid.
Quote:
But there has been enough discussion of about when a MMC3 board is made available I thought I'd offer up the service and see what you guys think. My goal would be to have it for $10 or less, and offer pricing breaks for larger quantities and such.
I support this, even though I myself don't have an MMC3 game made.
You should at least design them, just so there are more sources of materials. You would sell a few to developers here, but don't expect to sell much more other than for one or two repros that need specific boards. All other repro makers will still use the much cheaper donor carts.
I have had MMC3/VRC2/VRC4/etc boards available for homebrew production for a while, but I don't expect them to be used by anyone in the next few years. They cost me ~$12 with no profit, while an enhanced UNROM is under $3. Going from a $30 homebrew to $40 would be a large hit to sales so it will need a very good (and actually finished) game to justify the added cost.
Thanks for the info bunnyboy, I guess we were all wondering about that.
What is an enhanced UNROM?
512KB PRG (Battle Kid 2), self flashable (not yet used), and 4x 8KB CHR RAM banks (Assimilate) are very cheap additions to UNROM. Like the 8T-ROM using flash instead of battery backed WRAM removes much of the need for MMC1/MMC3. The CHR banking makes background animations usually done with CHR ROM easy. Still no IRQ but $5-10 cheaper per cart.
Thanks for that insight bunnyboy, you're confirming most my thoughts. Which is good since you've probably got the best pulse on what the market is for these.
After making my comment about a minimalized MMC3 to fit the logic into a 5V tolerant CPLD I got an idea... The issue is it's ~100 macro cells for the full MMC3. And the best priced CPLDs are somthing like the xilinx9500 family but only upto 72 mcell. If you step up to 144Mcells on the 5v tolerant device it starts to become more cost effective to switch over to level shifting on a non-5V tolerant part.
But... the MMC3 could easily be split into two separte smaller CPLDs. Bankswitching in one and scanline counter in the other. That would be around the same price as the larger non-5v tolerant devices but not require any level shifting. The other benefit is that there are more IO and Mcells available, even though you do lose some by doubling some items up. With that there would be room for improved MMC3 designs on the same board. Just flash the CPLDs differently and configure jumpers differently. Additionally they are easier to assemble with coarser pins, which makes it more reasonable for me to assemble the first batch myself, without pulling my hair out.
As for quantities I'd have to make up at least 50 in the first run. PCBs are far too expensive below that. I'm still waiting to hear back on what kind of price break I can get on the CPLDs, but I should still be able to do $12 for the PCB and CPLDs soldered on with a regulator. If I stepped up to making 100 I should be able to meet the $10 mark. Keep in mind this doesn't cover any memory, CIC, or case.
If using two CPLDs is cost effective that certainly shouldn't be ignored. I think to get both the homebrew base covered as well as the bit more shadey reproduction base you'd want to make a MMC3 compatible if not straight clone. Because if it is compatible with all existing MMC3 software that ensures a market will exist and you won't end up stuck with unsold units.
Particularly if the board can by like the RetroZone boards where the one board can be configured for various standards of the TxROM.
bunnyboy wrote:
512KB PRG (Battle Kid 2), self flashable (not yet used), and 4x 8KB CHR RAM banks (Assimilate) are very cheap additions to UNROM. Like the 8T-ROM using flash instead of battery backed WRAM removes much of the need for MMC1/MMC3. The CHR banking makes background animations usually done with CHR ROM easy. Still no IRQ but $5-10 cheaper per cart.
With the 32K CHR-RAM, is it just hooking up the upper bits to hold a 8KB CHR-RAM page I would guess?
Part of the reason to have a MMC3 for homebrew is definitely to have alot of CHR, which no homebrew yet has needed but certainly could happen. Alot of great games have such nice graphics thanks to tons of CHRROM.
MottZilla wrote:
With the 32K CHR-RAM, is it just hooking up the upper bits to hold a 8KB CHR-RAM page I would guess?
You could still use the regular MMC3 CHR switching scheme (i.e. 4 1KB chunks + 2 2KB chunks), but restricted to those 32KB of CHR-RAM. This would be really useful for character and background animation, pretty much in the same way as CHR-ROM is.
Quote:
Part of the reason to havea MMC3 for honebrew is definitely to have alot of CHR, which no homebrew yet has needed but certainly could happen. Alot of great games have such nice graphics thanks to tons of CHRROM.
Yeah, giving up CHR-ROM is not such a great idea, since that would certainly exclude the repro folks. For us developers though, the 32KB of CHR-RAM is almost as good, the only advantage being that the graphics will occupy space in the PRG-ROM, which has the fairly low limit of 512KB.
You could always add a counter logic chip to extend it to a 1MB+ chip on writes that would be very cheap but allow a lot more space over all.
Adding more bits to the PRG bank indices would probably be easy (it could go up to 2MB if all 8 bits written to the data register were used) if the CPLD can handle it, but not CHR, since all 8 bits are already used to index 256 1KB banks.
Okay well I did a little more research on the different options. The more I dig the more appealing the 2 CPLDs on one board becomes...
I could make a rockstar board that would be much more capable that used non-5V part with level shifting that would give 256 LUTs (~Mcells) and a boat load of other possible features and capabilities way beyond MMC3 due to the power of Lattice's Mach XO2 devices. The cool thing is it would only cost about $1 more than the double xilinx 5v tolerant board. The real draw back is it would be a lot larger risk for me because I'd have to invest in the parts, PCBs, and assembly ALL upfront because of part cost breaks and difficulty of assembly. The board is a novel idea, but I don't think any one is really ready to develop a game that could come close to utilizing everything the board could offer. It also over complicates the project I think as well.
The double xilinx board is could be very versatile and I'd really only have to upfront the PCB cost. I can buy the parts in small quantities and assemble them myself no prob.
The board would also be expandable to a point because the 36 Mcell and 72MCell CPLDs are pin compatible. So It could be used for various mapper configurations like some of the following options:
*ONE 36Mcell device: For something as simple as an advanced discrete logic (something like the "advanced UNROM" board by only using a single 36Mcell CPLD for a few dollars under $10. Or even some simple more custom setups for something like Tepples' Action 53 if demands exceed standard BNROM. The would be less of an obstacle to design and produce such "advanced discrete mappers" because I'd have them on stand by.
*ONE 36 Mcell and ONE 72Mcell CPLD: I need to test and verify this but I'm hoping that the MMC3 will fit in a configuration like this. If I can pull this off the $10 goal is easily achievable. Not much extra room here for added features to the MMC3. This would be the stock MMC3 setup hopefully.
*ONE 72Mcell CPLD: Might save cost if someone were to produce a MMC3 game but didn't use all of the features of the MMC3. It could still be MMC3 compatible game but if one were to use CHR RAM you could minimize the logic or make your own custom modifications to MMC3 to reduce production cost. This would also allow for the board to be arranged as MMC1, with a little space to spare if one wanted to improve upon the MMC1.
*TWO 72Mcell CPLDs: The MMC3 will definitely fit here and only cost ~$12. But this should also allow for more complex mappers. Maybe something like my Tengen RAMBO-1 idea. MMC2/4 like features who knows. The point is there would be a possibility to have more advanced features on the same PCB which is what's critical to keep quantities high enough to reduce the end cost.
Worst case I spend a few hundred dollars and end up with a bunch of highly configurable PCBs that no one is interested in buying. I'll just start making homebrew/hacked games for my self to add to my personal library once I get my 3D printer running
I don't have an issue taking on the risk in this scenario because there isn't much to lose.
Of course the more options that are allowed for the more complex the PCB becomes and could end up becoming too much bother. I don't want there to be 20 some different jumpers that have to be soldered in order to configure it for a given board. But I should be able to do quite a bit from within the CPLDs alone and the signals that will double up between the two chips.
So the question that remains is what memory packages to support. I assume most people prefer that it supports standard EPROMs for CHR-ROM and PRG-ROM. I do like the PLCC package for flash though. I'm thinking I'll require there to be support for 0.6" DIP EPROMs/FLASH. And if it's not too difficult I'll try to support 32-PLCC in addition.
As for SRAM I'm inclined to use 0.3" 28-DIP for CHR-RAM and WRAM. Partially because I've got a stock pile of them myself. But they are also one of the cheaper packages that are available as new stock. Would people have a hard time without their 0.6" SRAM? There are some other surface mount options that are appealing due to cost and board space. But they aren't as easy to align adjacent to EPROMs in a fashion like the repropaks, which makes PCB layout simple.
As for the CIC it'll support the CIClone pinout with NTSC jumper. I may also support pinout for the original CIC. I know it partially goes against the goal of not hacking up old boards. But if I support original CICs then it might keep some people from destroying a whole board, and they could just pull the CIC from a crap game and use the case. At least they wouldn't be inclined to hack up good games for the PCB and mapper.
I will ask again - how big this market? Why? Just think, how computers been made in "before CPLD" epoche. Answer is - CUSTOM CHIP. If community will swallow 1000+ IC's it's possible to order custom chip. And keep in mind, that you have to programm and verify CPLD.
80sFREAK wrote:
I will ask again - how big this market? Why? Just think, how computers been made in "before CPLD" epoche. Answer is - CUSTOM CHIP. If community will swallow 1000+ IC's it's possible to order custom chip. And keep in mind, that you have to programm and verify CPLD.
I think we've answered the question on how big the market is as best we can really. 1000 carts aren't going to fly off the shelf any time soon with a custom mapper or even the standard MMC3 at this point (EDIT: when you can get a case, CIC, PCB, and mapper from a donor for a few dollars). If you want to cough up the cash to remake the MMC3 as an asic go for it. But personally I'd rather invest my money in something that worst case, is still valuable to me if no one buys. If things went well with this and people started releasing a lot of great games that implemented the MMC3 or some other design chip assuming everyone could agree on one mapper (never going to happen IMO) then the idea of reproducing them as an asic could be a good idea. But even with something as standard as the CIClone I wouldn't imagine that it would be beneficial for bunnyboy to invest in a asic remake.
It's hard to beat the cost and configurability of programmable logic. Configuring and verifing the CPLD is moot if you already have to program and verify the ROMs as I see it. It would only take an hour or so to program and verify 100 CPLDs. You can always pay some one else to do it anyways. And with and asic you'd end up paying someone to verify it anyways.
ASICs have no appeal to me. I'd rather spend twice the cash and have a handful of CPLDs I can reconfigure and play around with all day long especially some all powerful Mach XO2 devices
. Plus I don't have much experience in asic design. I can't imagine dumping a large chunk of change into something that might not even work because I goofed something up as a noob in ASIC design.
infiniteneslives wrote:
As for SRAM I'm inclined to use 0.3" 28-DIP for CHR-RAM and WRAM. Partially because I've got a stock pile of them myself. But they are also one of the cheaper packages that are available as new stock. Would people have a hard time without their 0.6" SRAM?
If you are making the boards for repros you absolutely must have good reliable battery backed WRAM. Would have to check if the common .3" SRAMs are low power?
I haven't heard of custom chips in only 1000+ quantities. Typically it is more like 10000-50000 with massive start up costs. No way someone is going to make only 1000 chips for a price that beats these $4-8 CPLDs. Only one repro (MMC1+) and one homebrew (UNROM) has hit the 1000+ level anyways.
I can't really help or assist in any way with the hardware bits, infiniteneslives, but I can assure you that I would be quite interested in a board that supports the following:
* MMC3-compliant (heh, funny to say that) register layout
* 72-pin or 60-pin (I have both models of NES and a Famicom)
* Battery-backed RAM (SRAM/WRAM/ilikelettersRAM) or equivalent
* Scanline counter
* Uses EEPROMs or equivalent (e.g. flash) for PRG (and/or CHR)
* Includes ZIF sockets (not sure if this is possible given the front-loaders' limited cartridge height)
* If CPLD/FPGA/etc.-based, please make sure there is some way to upgrade the logic/firmware in case bugs are found
Hrm, I think that about does it.
I can't speak for others, but you could expect me to pay up to US$100 for such a device. I've been wanting something like this since, uh, 1999 or so. Yep still waiting... ;-)
bunnyboy wrote:
infiniteneslives wrote:
As for SRAM I'm inclined to use 0.3" 28-DIP for CHR-RAM and WRAM. Partially because I've got a stock pile of them myself. But they are also one of the cheaper packages that are available as new stock. Would people have a hard time without their 0.6" SRAM?
If you are making the boards for repros you absolutely must have good reliable battery backed WRAM. Would have to check if the common .3" SRAMs are low power?
Yeah I was thinking about that after my post... They are pretty much junk for low power. There are some decent SOIC's though, but I think it's better to stay through hole unless I sold em soldered on. But really I think 0.6" is best for the WRAM like you're saying to support battery backing. It would be simple enough to support 0.3" and 0.6" though. Then the cheaper 0.3" could be used if there wasn't any battery backing.
The CPLD separation is a little more difficult than I expected. The dang CHR bankswitching sucks up a ton of logic. It was pretty easy to split everything between TWO 72Mcell devices raising the cost ~$1. But trying to split it between a 36 and 72Mcell devices to cut the cost will require something to be thrown out. I'm trying smaller ROM sizes that would support repros but still haven't came up with a great solution...
Either way the $1 doesn't change things much. I can still get em out the door for around $10. So now I need to plan up the schematic and configurations possible via jumpers. Then it's just a matter up making up some PCBs and droping the cash for the first run of boards. I'll take input on the memory situation but PCB layout plays a sizable role in what I can or can't support. It'll probably end up with DIPs all around, something like 0.6" EPROM PRG-ROM, 0.6" CHR-ROM, 0.3" CHR-RAM (32KB), and 0.3"/0.6" WRAM with battery backing. If I can manage I'll slip in 32-PLCC flash for PRG-ROM to help support homebrew development.
koitsu wrote:
I can't speak for others, but you could expect me to pay up to US$100 for such a device. I've been wanting something like this since, uh, 1999 or so. Yep still waiting...
Is there some reason your set on socketed EEPROMs? I'm guessing it is so you can easily upload your recent build for testing. I know you've been looking for something like this since I started work on the NESDEV1. That project is really my solution to what you're looking for. It meets pretty much everything you're looking for but the Flash on board is PLCC and socketed. But you don't really need the Flash, the main memories are SRAM programmed via USB. I've still got some work to complete so that everything is updatable via USB for updates. Cost is a little iffy right now, but it shouldn't be far from $100. The real factor is assembly costs which I haven't quoted out yet. I'm planning to have the project polished off this year.
A lot of the things you're asking for could be met with this MMC3 repro though. Things that are a bit of a challenge are ZIF sockets and programmable CPLDs. But an alternative solution may be the Kazzo if I were to release supporting software to allow for flashing memories and the CPLDs. No guarantees on that, but it is something I'd like to do in the future.
infiniteneslives wrote:
Is there some reason your set on socketed EEPROMs? I'm guessing it is so you can easily upload your recent build for testing. I know you've been looking for something like this since I started work on the NESDEV1. That project is really my solution to what you're looking for. It meets pretty much everything you're looking for but the Flash on board is PLCC and socketed. But you don't really need the Flash, the main memories are SRAM programmed via USB. I've still got some work to complete so that everything is updatable via USB for updates. Cost is a little iffy right now, but it shouldn't be far from $100. The real factor is assembly costs which I haven't quoted out yet. I'm planning to have the project polished off this year.
A lot of the things you're asking for could be met with this MMC3 repro though. Things that are a bit of a challenge are ZIF sockets and programmable CPLDs. But an alternative solution may be the Kazzo if I were to release supporting software to allow for flashing memories and the CPLDs. No guarantees on that, but it is something I'd like to do in the future.
No, there's no reason I'm set on EEPROMs and ZIF sockets. In fact, if I had my way, I'd say scrap both and just use "something else" -- but that's outside of my skillset level (I'm not an EE guy).
The reason I listed them off as a pre-req is that 90% of the time people around here say "why do you need anything other than an EPROM?" followed by points given that EEPROMs make the job easier (which I agree), and then the discussion ends. Nobody seems to ever go past that (proposing things like what you just did -- "main memories and SRAM programmed with USB"). It's tunnel vision on the part of many people. Sorry if that sounds demeaning or insulting, but it's just something I've seen repeatedly non-stop over the years.
Anyway, that aside -- if programming can be done with this PCB natively via USB, then even better, that makes *my* life easier. Just please be sure to keep in mind that if the programming software requires drivers (very likely) that they exist for XP 32-bit, Windows 7 32-bit, and Windows 7 64-bit. If they don't exist for all 3, then you'll find nobody will be purchasing said product/board (including me, though my pre-reqs are XP 32-bit and 7 64-bit). Just something to keep in mind. :-)
The problem with making drivers for Windows 7 64-bit is that the developer has to pay a CA every year just to get them digitally signed. Otherwise, the user has to press F8 every startup and select Test Mode. I've checked into KMCS CAs, and a lot of them don't even allow individuals (as opposed to corporations or LLCs) to sign up. Or is this something that can and should be done in user mode?
Okay well I'm not planning for this project to include USB programability. But the NESDEV1 and kazzo do. My firmwares just use HID drivers which are trivial and I use on windows. I run them on windows 7 (64bit) and XP (32bit) all day long. So consider that issue solved.
Yeah EPROMs are a PITA to develop/test a game, I can't see how any homebrewer couldn't agree. But EEPROMs make the design of a devcart simple, which is what I'm guessing they were basing their argument off of. With the NESDEV1 you don't even need to cycle the NES power or remove the cart. Just click write on your PC and hit reset once it's done. Having something like this MMC3 repro board programmable by using the kazzo wouldn't be too bad. You'd have to swap the cartridge out between the console and kazzo each time. Which is about the same amount of work as the powerpak. I just have to release my own firmware and host software for the kazzo because the current stuff has driver issues, is slow, and difficult to work with IMO.
I wouldn't use any dev cart that uses memory with limited write cycles for constant development, I would just use it to test milestone builds, or code that uses obscure details not properly implemented in emulators, and for this I can already use the PowerPak, so I don't see the point in a cart that uses Flash or EEPROMs for PRG and CHR.
If a cart can be programmed though USB, it should have RAM for PRG and CHR, so that it can completely replace an emulator (except for the sometimes needed debug features) during development. That I would be interested in.
tokumaru wrote:
If a cart can be programmed though USB, it should have RAM for PRG and CHR, so that it can completely replace an emulator (except for the sometimes needed debug features) during development. That I would be interested in.
Agreed, that's why I implemented it that way in the NESDEV1. The extra flash that's there is to provide more PRG space (cheaply) and allow for testing things like saving game data on flash vice battery backed SRAM if one choose to go that route they would be able to test those features.
If someone got hard core and used up their write cycle limit on a cart like this MMC3 repro they'll have to replace the memories or get a new board. Not much that can be done about that. You could always throw in some rarer 0.6" SRAMs in it though and battery back them I guess. But I'm not too concerned about write cycle limits with this project.
I assumed that these MMC3 boards were meant for production carts, rather than development ones.
tokumaru wrote:
I assumed that these MMC3 boards were meant for production carts, rather than development ones.
You're right they are meant for production carts mostly. Some of the previous discussion was edging on getting off topic, so we may be getting each other confused on what we're referring to. But for someone who likes EPROM style development, or doesn't have money for $100+ devboard/powerpak these would be a better option than hacking up a donor and dealing with mis-matched pinouts and such.
infiniteneslives wrote:
But for someone who likes EPROM style development, or doesn't have money for $100+ devboard/powerpak these would be a better option than hacking up a donor and dealing with mis-matched pinouts and such.
But then you'll have to use regular DIP ROMs, so that people can easily use their own sockets and chips, otherwise they'll have to spend a significant amount of money on hardware to reprogram the cart, completely invalidating the fact that it's cheaper than a PowerPak. That's if they already have an EPROM programmer though... The fact is that if you don't already own a cart programmer or EPROM programmer, the PowerPak will be cheaper than other solutions.
tokumaru wrote:
But then you'll have to use regular DIP ROMs, so that people can easily use their own sockets and chips,
That was the plan in the first place. As far as I know people prefer standard EPROMs for producing carts. Unless I'm mistaken...
Supporting other memories (like PLCC for flash) would be a bonus.
The WRAM will have to support 0.6" SRAM for reasons that bunnyboy pointed out with battery backing. But I should be able to easily support 0.3" SRAM just like original production carts did.
CHR RAM is the one that's kinda up in the air, the easiest and cheapest solution I see is 0.3" SRAM, since there is no need to battery back and PCB layout would be simple. If I were to try and support CHR RAM and ROM at the same time I might be able to pull it off with SOIC SRAM soldered to the back of the board without making the PCB much larger. But unless someone provides a convincing argument as to why I should do that I probably won't. I think it'll end up being more hassle than worth to do that.
What is the problem to support both 0.3" and 0.6" JEDEC complaint SRAM?
80sFREAK wrote:
What is the problem to support both 0.3" and 0.6" JEDEC complaint SRAM?
None as far as I'm concerned with WRAM that's why I'm planning to implement them on top of each other like NES boards did for WRAM. CHR-RAM is a little different story though. I obviously have to support CHR ROM and RAM on the same PCB. So CHR-RAM probably won't support both 0.6" and 0.3" like WRAM, because I'm already working around the footprint of the CHR-ROM. So CHR RAM will most likely only be supported by 0.3" SRAM because it would be easiest and effectively consume no board space.
Well I've got a few updates on this matter.
As jim's cool posted I've been in contact with him to help out in testing his NES CIC and will be helping out with the FCB flavor of CIC. He's done some great work with re-REing the CIC and has plans for some great release terms on his design. So I'm planning on incorporating his AVR CIC on this board. Good news is they will be on the cheap, so adding a CIC to the purchase of a PCB won't cost much for those unwilling/able to clip the pin from their NES.
I've also made some good progress on my 3D printer which is actually printing things besides giant globs of plastic mess now
I should be able to get it up to snuff and make some decent cases in the near future to go along with these boards. Keep in mind 3D printing doesn't end up with near the polished look of injection molding like the original cases or retrozone's but they are still durable and should work out nicely. One cool factor is you can do things like dual color printing and such so if I decided to get real fancy I could print the name or graphic of a game 'into' the face of the cart shell. It might end up being more hassle than it's worth though so we'll have to wait and see. Here's an idea of the extreme of what's possible I probably won't go this far with 4 colors and all but it gives you the idea. (not my work, or face
BTW)
So in the next couple months I'll be working out the actual design of the board and logic and everything. I found a place that'll make PCBs on the cheap and not charge any different based on minimizing board size or not (for this scale). So I may get more versatile with this if there is more board space without extra cost. The one significant issue with that deal is the boards are coated with HASL (solder) which isn't nearly as great as plating like the original carts and such but I don't have much evidence to support that. So I'll have to see if I can get that resolved with them. Otherwise I'll go with everyone's input on the matter.
I've pretty much decided on the two CPLD method so unless something goes wrong during prototyping that's the plan. Since jim's cool is working on the FCB CIC as well I may very well support it also. It's just a bummer that it won't support the MMC3 due to lack of /IRQ support. But MMC1 and discrete additions would be better than the 20 games that were released for it. If you have interest in the FCB (Famicom Station) in this project let me know. Because your interest mostly decides whether it's supported or not. It's possible I'm asking the wrong crowd though...
My goal is completing the design and prototype over the summer and have a small run of PCBs made up in August/Sept time frame. Larger runs to follow based on demand.
Well finally finding some time to make this project a reality. I'm working on the prototype now and will be finalizing the PCB shortly and ordering the first batch of board next week.
Assuming there are no surprises I'll be making them available for $11 plus shipping. That would be for the PCB and full blown MMC3 512KB (PRG & CHR). Also includes power regulator (3.3V), power and noise caps for mapper.
It is possible to get down to my original goal of $10 but mapper optimizations have to be made to allow for a smaller CPLD. Basically that means the modes are fixed and the ROM limit is 256KB PRG 128KB CHR. That would work for many games but not all obviously.
Additionally it'll be a MMC1 compatible board that only needs one of the larger CPLDs for $8.
PCB alone will be $5
Some more details:
EDIT: *** The cpld is a 3.3V part that is 5V tolerant. *** This means you can run it in a 5V NES with no problem, but it will drive it's outputs to 3.3V. You can select your own parts to ensure Vih is satisfied (fine for most parts). The only thing you might question is things like CIRAM A10 that's the cart controls. I've tested and verified that this is not an issue and performs great. This isn't of much concern, but I want to fully disclose everything.
* It's a larger board ~10cm (4") square. And will have some 'perf board' style space to allow for simpler mapper testing, demoing, and prototyping all on one PCB (crazy things like NROM-368 etc...). My goal is around the size of a 40pin DIP (room for AY-3-8910???) or more of free perforated area. I'm considering preconnecting some of the holes for a 8x flipflop's inputs for super UNROM style that would require running some extra connections manually.
* 32 pin EPROM for PRG/CHR
* 28 pin 0.6" DIP and SOIC WRAM
* SOIC VRAM 32KB (possibly DIP, but not pushing for it at the moment)
* CIClone, and Jim's Cool CIC (8-soic) support. Jim's Cool CIC should be available soldered on at a low cost (details to come). Possibly FCB CIC support as well.
* Battery backing compatibility
* Gold plated finish and 0.47" board thickness (no surprises...)
* A probably maze of jumpers to allow for configurationability. Things like four screen mirroring and such. Although I'm going to try and keep it simple for common set ups and let any complex choices get resolved in the perf area.
* Extended connector "fingers" that actually go INTO the shell of the cart. That way something like EXP pins can EASILY be tapped off without hacking away at the cart shell like you do with original carts.
Don't have much of a solution for cases. Retrozone is the place to go for these. If demand for these boards grows enough I'll consider ordering a large amount from him and reselling them at cost to save people shipping from two separate places.
I'm also stocking up on the rest of the parts required to populate the board. Once I figure out how much time in involved with assembly I can provide assembly costs. But if you want to buy the unassembled parts from me it'll be something like:
Parts ONLY:
$1.50 32KB soic SRAM (<5uA stby current should be decent for battery backing).
$1 power caps, diodes (SMT), clip, and battery.
?? ROMs
So everything above is about as low as I could get the cost. I'm only ordering a few dozen boards and parts worth for now. I'll guarantee the above prices until that stock is gone. Prices are subject to change for future orders, but I don't expect them to change. If it looks like the demand will suck up everything quickly I'll consider ordering more to start so there are enough to go around. Additionally if these become popular enough for a second run and enough people request, I'll order some 60pin famicom versions the second time around. Although expect a ~$1-2 more due to lower quantities to start.
I'm just letting everyone know this is becoming a reality and wanted to see what the pulse was on what if any immediate demand there may be for these. Release is expected in late September after I've had a chance to assemble a few and verify everything.
If you have any feedback or final suggestions before I finalize the design feel free to let me know. I'm still at the point I can consider requests, but act fast because the I'm trying to order boards next week.
EDIT: Additionally around the time I'm ready to release them I'll publish my MMC3 logic design so there are no mysteries of what's going on inside.
Can't wait to see this happen!
Now, who's gonna make the first homebrew to use theses? hehe.
infiniteneslives wrote:
It is possible to get down to my original goal of $10 but mapper optimizations have to be made to allow for a smaller CPLD. Basically that means the modes are fixed and the ROM limit is 256KB PRG 128KB CHR. That would work for many games but not all obviously.
Could you consider a 512/32 version for people who don't need CHR ROM support and think they can make the next Mega Man 4/6?
Otherwise, I'm looking forward to it.
tepples wrote:
infiniteneslives wrote:
It is possible to get down to my original goal of $10 but mapper optimizations have to be made to allow for a smaller CPLD. Basically that means the modes are fixed and the ROM limit is 256KB PRG 128KB CHR. That would work for many games but not all obviously.
Could you consider a 512/32 version for people who don't need CHR ROM support and think they can make the next Mega Man 4/6?
Yeah I plan to check that one out. My guess is it should work allowing for the $10 board. The main issue is the large amount of logic needed for the C and P bits to be changeable in reg0:
http://wiki.nesdev.com/w/index.php/MMC3I checked a game or two, but I'm guessing most games set these bits and never touch them again. So if I hard wire those bits a LOT of logic is minimized. Additionally the ROM sizes needed to be limited 256Kb PRG, and 128Kb CHR. So 32Kb of VRAM should be cake assuming C and P are fixed. I'll check to see if the implementation of switchable C/P bits, or 512Kb PRG can be added back if CHR is limited to 32Kb.
I'll do my best to keep matters like this simple. But to some degree it requires the user to have a detailed knowledge of their application, and what the C and P bits do exactly. Basically, for a novice user, or for indefinite applications one is probably best to spend the dollar on the full fledged MMC3. If it got to the point where someone wanted to release a game using these boards though the optimization if possible would be well worth it. Once i ship a board with C/P fixed to one value, you'll never be able to switch it to the opposite value really.
EDIT: I did have someone wondering if I was making them available to everyone. The answer is yes. If you're interested in getting any number of them from the first batch, I recommend PMing me with the quantity. NO OBLIGATIONS, it will help me gauge that I've got a good quantity while I'm ordering everything. Additionally, once they are ready to go out the door, I'll send them in order of request. If you change your mind, no big deal or hard feelings. I'll just move down the list. I'd rather have a couple dozen extra than a couple disappointed folks who have to wait until I can get the next batch and full production together.
infiniteneslives wrote:
Additionally the ROM sizes needed to be limited 256Kb PRG, and 128Kb CHR.
Any chance I could persuade you to go into where these limitations came from?
It's nice to see you're going to get this going. Be sure to post some pictures of a completely assembled pcb when you can.
lidnariq wrote:
infiniteneslives wrote:
Additionally the ROM sizes needed to be limited 256Kb PRG, and 128Kb CHR.
Any chance I could persuade you to go into where these limitations came from?
A CPLD (complex programmable logic device) is made up of macrocells. You can think of each macrocell as holding one bit of state. MMC3, with its fine-grained bankswitching, has 7+7+8+8+8+8 = 46 bits of state for the CHR ROM banks alone. Cutting to 128 KiB shaves that to 6+6+7+7+7+7=40 bits, and cutting to 32 KiB (as one might if dropping CHR ROM support in favor of exclusive CHR RAM support) cuts it further to 4+4+5+5+5+5 = 28 bits.
lidnariq wrote:
infiniteneslives wrote:
Additionally the ROM sizes needed to be limited 256Kb PRG, and 128Kb CHR.
Any chance I could persuade you to go into where these limitations came from?
Yeah Tepples' explaination is pretty accurate. The number of states doesn't usually directly equal the number of macro-cells but it's a fair approximation. You can find some of the things earlier in this thread that led me to this. But basically the most cost effective way to recreate the MMC3 was use TWO separate Xilinx 9500 series CPLDs. They come in 72 and 36 Mcell flavors. Basically the Scanline counter, PRG bankswitching, and WRAM control fits into one 72 Mcell CPLD and CHR bankswitching and mirroring ALONE take up a second 72 Mcell device. I was hoping to be able to make things fit into a smaller CPLD (or One big 72 and one small 36 Mcell). The thing that was actually limiting the CHR wasn't the logic amount (Mcells) but actually the number of terms (inputs to the logic). Basically there are so many terms that things have to be broken up into more Mcells to complete the operation.
So I just tried to think of some ways that the logic could be minimized to allow it to fit on One 72 and one 36 Mcell part (108 Mcells total). Honestly I've only checked 1-2 games, but it's logical that there isn't much point to change the P and C bits of reg0 after initializing the mapper. You just pick your preference and never touch them again. So if you know what the game uses, or are creating your own game it can be coded/designed with this in mind. That solved the number of terms problem but didn't quite cut it down to 108 Mcells. So after that, realizing there was only one game that ever used 512KB PRG and CHR, I figured we could shave the ROM sizes. Cutting 2 bits from CHR and 1 from PRG allowed everything to fit and compile. It actually required some blocks to be juggled around to make things fit well. The large CPLD gets ALL bankswitching, and the smaller one holds the scanline counter, mirroring, and PRG ROM /CE.
The separation of blocks kind of opens things up to the idea of some interesting mappers. I know there has always been a high cost associated with the idea of a scanline counter. But in reality it'll fit in a pretty small CPLD with room to spare for extras. If you're willing to put up with discrete style bankswitching, one could even incorporate some cheapo logic gates in tandem with the scanline counting CPLD. The idea of this board being that you could easily demo up something like that without requiring you to design a PCB and shell out large sums of money for a small run. We'll see how things go, but a simple board like this allows some difficult hurdles for most people to be jumped easily. I would have killed to have something like this when I first started out making boards and such.
For any advanced users interested I'll be making the board arrangement to allow for socketed CPLDs. The won't satisfy case clearances, but since I'm using PLCC, it allows convinces like that. If someone decided they want to try out programming a CPLD to brew up their own mapper, this would be a great tool.
I've got all the parts in hand now so I'll be using my "NES-protoboard" to protoype things out this weekend. That way there are no surprises when the boards show up
EDIT: oh and I'm officially naming the board INL-ROM
Could you clarify, will a full fledged MMC3 clone be an option? Supporting everything the MMC3 does, in terms of ROM size and mode switching?
MottZilla wrote:
Could you clarify, will a full fledged MMC3 clone be an option? Supporting everything the MMC3 does, in terms of ROM size and mode switching?
Yeah sorry,
The FULL FLEDGED MMC3 just like Nintendo made it is the $11 option. It uses TWO 72Mcell CPLDs, the minimized version uses one 36Mcell and one 72Mcell CPLD and saves you a $1. So that's where the possible savings comes into play, but only for specific applications.
Honestly the minimized version probably isn't worth messing around with unless you're looking at higher quantities. It's possible it'll end up being more hassle than it's worth from my end, and I may only offer the minimized version on special request. Otherwise the only way to attempt to avoid confusion is tell people the board is only good for a specific game. I don't think that's the route I want to go unless it were a homebrew game with author support. Never the less I'm designing it with the option available to help achieve my goal of versatility and configurability.
In my honestly opinion, I love this. But if you don't make sue it works as an option to recreate new MMC3 games without killing older games, you put yourself at risk because you can't sit on these and wait for an MMC3 homebrew. The repro guys will use it more far sooner than anone here because nobody is writing MMC3 games because they know they're harder to make on a cart and aren't as easy as MMC1, UNROM, etc. games. As for the slimmed down version, I think you shouldn't do that until they've got somebody who is GOING to use a bit of them. Saying a board will work for MMC3 games UNDER X and Y prg/chr will turn off anybody wanting to use it for a repro, especially because often times that use 1 board for every type. Plus, tons of MMC3 games are over 128KB Program...
So are you saying that, even though what I'm offering will support full MMC3 capabilities with 512KB PRG/CHR, the discussion alone of less support will confuse people and convince them not to go for it? I'm starting to consider that too, so that's why I started making statements about not concerning yourself with the minimzed version.
Until I figured out exactly how to separate the FULL mmc3 into 2 cplds it appeared that I might not be able to make it fit. For a little while I thought a minimized version might be the only option. That's not the case currently with what I've got compiled, it took a couple dozen compiles to find the winning fit. So that's kinda where the minimized thoughts started. Lets just hope there aren't any surprises when I finish assembling the proto and test everything out tomorrow hopefully.
Like you're saying, I think it's best to hold off on the minimized discussion because it even manages to confuse myself at times. The board will inherently support it because it only takes things away from the full MMC3. If your interested in more details a private discussion is probably best.
So I'm nearing the end on the PCB work. I was pretty happy with how much I was able to condense things to maximize the available area. I even snuck in a '377 8x FF w/enable and some '32 OR gates. So yeah the options are pretty open here, it's basically set up for everything except MMC2/4/5. So it can take the form of nearly all Nintendo boards. There are a fair number of solder bridge jumpers, but I kept them on the bottom side so it's cleaner and easier to keep an eye on everything. It also leaves space for a some good on board jumper legends to keep it simple, I also only pre-configured standard Nintendo mappers with the jumpers. If you want to create something obscure you're on you own.
The '377 8x flipflop and '32 is prewired up for all the inputs (D0-7, R/W, /CE). AO/MROM, BNROM, CNROM, and UxROM are configured with a few solder bridges on the outputs. If one wanted to play around with the other '377 outputs (D4-7) you'll have to jumper off the pin and wire things up however you'd like. But basically 95% of the work is done for you if you're looking to make a super UxROM or BNROM or something.
The perf board area ended up around 27x10 so sound chips and such should fit nicely along with some room to spare if the heart desires. I figure it'll also be good for such things as multicarts or other mapper and interfacing projects.
There's ~7 Free I/O on the top left CPLD (named "B") and a single I/O available on lower right CPLD "A". So those will be available for future use for extending capabilities or playing around with by advanced users. There should be a few free macrocells but not many for the FULL MMC3 for anyone curious.
So I'll finish the board this week and can now fully wire up my prototype fully test things before I put in the order.
MottZilla wrote:
It's nice to see you're going to get this going. Be sure to post some pictures of a completely assembled pcb when you can.
Well here's a teaser of what it'll look like:
Here's what I've been starring at all weekend...
It also gives you a better idea of how I set up the DIP/SOIC setup on SRAMs.
I can guess why you've left the '377 as through-hole (ease of soldering for people who aren't practiced); I'm curious about why the '32 isn't SOP. (Not being distributed pre-soldered?) Are the discretes there so that you can just order one set of PCBs and populate as necessary? (Which would make sense...)
I'm also curious about what's preventing MMC2/4 support—pin count? routing complexity? a lot of work for only 4 games? If it is either of the first two it feels like a 5+ input AND gates should easily solve it.
Barely more legitimate (by NesCartDB profile counts, with 32 games vs 23 for mmc5 and 4 for mmc2+4): any idea how much of a Namco 163/175/340 you could fit? Obviously without sound or internal RAM.
Looks cool, can't wait to see a photo of a completed board. Good luck with testing.
lidnariq wrote:
I can guess why you've left the '377 as through-hole (ease of soldering for people who aren't practiced); I'm curious about why the '32 isn't SOP. (Not being distributed pre-soldered?) Are the discretes there so that you can just order one set of PCBs and populate as necessary? (Which would make sense...)
Yeah I hadn't really considered making the '32 SMT. You're right about the '377 being TH for soldering ease. I did plan to allow the user to populate discrete mappers on their own, so I'll prob keep it DIP. That's not to say I won't consider supplying populated discrete boards. This way the user could buy some without having to make the decision in advance as to which discrete mapper they might use the board for.
There also isn't much room to be gained by going SMT on the '32. Although I did consider laying out some NAND gates for bus conflict avoidance. Going SMT with both those chips would allow them to fit in that space. The issue is I'd have to charge for populating and supplying parts. Assuming most users can't solder SMT the added cost and requirement to make up your mind at time of purchase is what deters me from going SMT on these. Plus I figure the perf area would allow for plenty of options if you want to toss in your own NAND gates for bus conflict avoidance and such.
Quote:
I'm also curious about what's preventing MMC2/4 support—pin count? routing complexity? a lot of work for only 4 games? If it is either of the first two it feels like a 5+ input AND gates should easily solve it.
Really it's just the fact that I haven't recreated those mappers on my own yet. So I can't make the informed decisions about what signals need to go to which CPLD and such. Once this thing is running smoothly, I would like to consider other mappers. I wouldn't say I'm intentionally "preventing" them though. Actually I'm making them more possible by leaving the CPLD pins unassigned. I'll be adding some contact points for these unused pins. That way I could easily connect them wherever they are needed. Your probably right about pin count being an issue, and NAND gates being a solution. When the time comes I can simply add the NAND gates in the perf area and wire things up by hand. If demand became high for those configurations I'd consider adding the NAND gates to the layout as SMT. There is still a fair amount of free space near the power supply (top left).
Quote:
Barely more legitimate (by NesCartDB profile counts, with 32 games vs 23 for mmc5 and 4 for mmc2+4): any idea how much of a Namco 163/175/340 you could fit? Obviously without sound or internal RAM.
The namco kinda fits into the discussion above as well. I'd also consider the FME-7/Sunsoft5, and RAMBO-1 to be possible but can't really say at this point. The real question with these is available logic. Out of all these I've only started redesigning the FME-7 and have it working partially, with IRQs not working yet. Off the top of my head It's pretty comparable to MMC3 in size. This will all be pending future development... If the need/market is really there I've got some sure fire solutions that would make use of a lattice CPLD/fpga. But quantities would have to be pretty high to make something like that cost effective, but that might not be the case a few years down the road with part cost/capability changes.
Related to the improvement discussion, but more acheivable with this board is the implementation of some sort of mapper hybrid MMC3. I'm trying to set it up as is to use the 32Kb VRAM as 4screen support. That would allow for 6-7 pattern tables, and 4 AT/NT to run as 4screen. I'd also like to play around with Tepples' idea of CHR A13 sensed scan line counter. Things like 32Kb WRAM as well. These would all be minimal logic to implement and provide significant benefits from the factory MMC3. Of course it's all moot if no one wants to develop a game using all this though. If I can ever put down the hardware long enought to create my own platformer, maybe I'll be that developer...
It's awesome to see this come to life! Would this project cover TN-ROM by any chance?
I can't say for sure but it's very likely TNROM will be supported.
SnoopKatt wrote:
It's awesome to see this come to life! Would this project cover TN-ROM by any chance?
Thanks! And yes Mottzilla is correct, TNROM will be supported. That board alone was one not being available in the US is one of the biggest motivators for this project.
I've already recommended your board for that very purpose too. People wanting to make Final Fantasy 3. I hope this all works out and we see alot of new boards.
Ossum possum! You can definitely count me in for a board.
MottZilla wrote:
I've already recommended your board for that very purpose too. People wanting to make Final Fantasy 3. I hope this all works out and we see alot of new boards.
and a lot less mario 2's sacrificed!
SnoopKatt wrote:
Ossum possum! You can definitely count me in for a board.
MottZilla wrote:
I've already recommended your board for that very purpose too. People wanting to make Final Fantasy 3. I hope this all works out and we see alot of new boards.
and a lot less mario 2's sacrificed!
Anyone that still thinks you need some rare 72 fingered version of Mario 2 to mimic TNROM style layouts is a fucking retard.
All you actually need is a basic TLROM pcb and half a brain to turn it into a TNROM with the ever so "uber rares 3774 FF3 engilshes".
nintendo2600 wrote:
SnoopKatt wrote:
Ossum possum! You can definitely count me in for a board.
MottZilla wrote:
I've already recommended your board for that very purpose too. People wanting to make Final Fantasy 3. I hope this all works out and we see alot of new boards.
and a lot less mario 2's sacrificed!
Anyone that still thinks you need some rare 72 fingered version of Mario 2 to mimic TNROM style layouts is a fucking retard.
All you actually need is a basic TLROM pcb and half a brain to turn it into a TNROM with the ever so "uber rares 3774 FF3 engilshes".
They are really not that rare, when I was first looking around for one, they were just as common as the non-72 pin version, and they were not any more expensive.
And of course you can do that, but it's quite a bit of work, and manually attaching a pin will never be as reliable as a real 72 pin cartridge from a factory. Unless there is some 72 TLROM cartridge, but after poking around on the database, I didn't see any. Even still, adding those extra chips would be tedious.
Once this PCB comes out, as far as TNROM is concerned (and probably the rest of the boards), it doesn't seem like the other solutions are worth the trouble, and not having to sacrifice again is alone a good reason.
nintendo2600 wrote:
Anyone that still thinks you need some rare 72 fingered version of Mario 2 to mimic TNROM style layouts is a fucking retard.
Please leave your offensive comments elsewhere.
infiniteneslives wrote:
nintendo2600 wrote:
Anyone that still thinks you need some rare 72 fingered version of Mario 2 to mimic TNROM style layouts is a fucking retard.
Please leave your offensive comments elsewhere.
While I think the comment is fine, it is a forum....but it'd help if he was at least right. Which he is not. TLROM boards to a MMC3 with 8KB CHR-RAM? find me one with the CHR-RAM R/W pin. I'd love that.
http://bootgod.dyndns.org:7777/search.p ... 9+20+41+53There are none. Not even if you just pick out games that Konami made their own boards for with all the pins in their late years:
http://bootgod.dyndns.org:7777/search.p ... 9+20+41+53I don't even know what else to say....way to go dude. You're proven you don't really know what you're talking about.
I believe he was talking about "adding" the pin. That's not a reliable method in the long term. But he was probably pointing out that the "rare fully pinned SMB2" cartridges are not the only way to make bootleg FF3 English carts.
MottZilla wrote:
I believe he was talking about "adding" the pin. That's not a reliable method in the long term. But he was probably pointing out that the "rare fully pinned SMB2" cartridges are not the only way to make bootleg FF3 English carts.
bingo!
Update:
Finally got my JTAG and EPROM programmer issues resolved to allow me to get some functionality out of my prototype. Still have a few bugs to work out, but with the mess of wires I have I'm not sure if it's worth the effort until I get boards in hand. It'll certainly be much easier.
Bit the BIG bullet this past week on a large order of parts and boards. Lets just say there should be enough to go around for a while
Boards will be here in a few weeks, I'm excited to see how they turn out!
GOOD NEWS!!!
Well the boards showed up Monday and I got the first one up and running perfectly this evening.
As I feared the yellow turned out a little more like lime when there isn't copper below the solder mask. But oh well, I'm still pretty happy with how they turned out!
I did have one bonehead error with ONE thing, the dang battery. During design I changed it I don't know how many times... Anyways I messed it up and got the polarity backwards. The silkscreen is right, i just mixed it up in the schematic and didn't catch it. Not that big of deal though, easy fix with an exacto knive. Not to mention since I used surface mount components for the battery backing circuitry I had already planned on assembling all of those parts for anyone who requests battery backing. To make my loss your gain I'll probably just provide atleast the clip and soldering for free for anyone who thinks the might maybe at some point choose to use the battery backing. If you know you'll NEVER use it and would rather me not solder on the clip then I can leave it off at your own risk.
Anyways I've only tested and ran the full fledged MMC3 with 512KB PRG-ROM and 256KB CHR-ROM, with WRAM. So I've still got to test out a few more configurations on the MMC3. Then I'll move on to MMC1, discretes, customs, etc...
My goal is to make up a wiki for them to explain exactly how each jumper works and provide pictures with each board config and such. There is quite a bit of configurability on these to allow them from going to NROM, CNROM, BNROM, AxROM, UxROM, MMC1, MMC3, CHR RAM/ROM, 28-or-32 DIP PRG and CHR memories. Four screen, 32KB WRAM, ENIO, yada yada yada... So all those solder jumpers you see on the bottom are what select all those choices. I think I labeled things pretty well with silk screen, and ALL the jumpers are on the bottom for easy access. I have an unfair advantage since I designed them, but based on the silk I can make all the jumper choices without needing to look a the schematic or board layout, which I will be providing to some degree to keep people from needing to reverse engineer the thing to figure out what signal goes where. But I'm thinking the wiki will be more useful for that stuff. Additionally if you designate which mapper/board and memories you plan to use I'll configure all the solder jumpers for you at no charge.
Other than that I for anyone interested in getting boards supplied with socketed memory/cpld's like seen in the photos I'll be allowing that as an option for a small cost. That would allow someone to use one board and swap out mappers and such as desired. Or if a 'new' mapper were to come out like the
hybrid MMC3 we're discussing currently, you could just buy new CPLD's and slap em in yourself. The CPLD sockets will fit inside a case but the DIP ROM sockets obviously don't...
Things are in pretty good shape now. I will be ready to start selling them in a few weeks. If there's a specific mapper/board you'd like to see tested sooner vice later feel free to chime in. TNROM will be one of the first ones up now that I've basically got TNROM/TKROM verified.
That's great to hear! I love that everything just drops in as well. Good stuff
Awesome. Congrats on getting this far. I'll be looking forward to hearing more. Shame about the battery polarity mix up but it could have been worse.
Thanks for the compliments!
MottZilla wrote:
Awesome. Congrats on getting this far. I'll be looking forward to hearing more. Shame about the battery polarity mix up but it could have been worse.
Yeah definitely could have been worse, I'm glad it ended up being something that I can repair that's mapper independent. So I can make the repair and hopefully not concern people much. It'll only cost me the few mins to do fix each board. Not sure the best way to handle the fact people might not even want the battery clip on there though. Because the components for the battery backing are SMT as well, and it doesn't make sense to put those on for every board if people don't intend to use it at all. The battery clip it's self is pretty cheap, I'd be more than willing to take the hit on one of those for each board I ship, making it so you'd basically have to opt out to not get the clip. Then getting the components to support battery backing would be optional with the associated (small) cost. At least that way there wouldn't be the conundrum of changing one's mind if you actually wanted battery backing. The clip would always be there as if it were considered part of the PCB, and you could add SMT or through hole components on your own down the road if desired. My real goal is to prevent people from being concerned/doubtful of the board/battery backing. If I can spend the cost of the clip to alleviate those concerns I'd be happy. Do you guys have any other suggestions? Or does this sound like a decent solution?
thefox wrote:
All in one board, nice!
Yeah I think I always had the misconception that making a board that supported nearly every licensed mapper wasn't very possible. But once I got working on this thing it really started to show it was possible and not actually that hard. It really helps having the CPLDs high configurability. Additionally the fact I'm using 2 separate CPLDs really helps out. Because you don't have to have one big (expensive) CPLD to allow for a 'simple' MMC1. You could have something excessively more powerful than discrete for only ~1.20 (36Mcells). Or you can have a FULL MMC3 with two larger CPLDs for $2.25 x 2 = $5.50 (144 Mcells total). With all those choices it allows the mapper cost to be trimmed to as low as possible. The large perf area is just the icing on the cake that allows for practically anything. Since the PCB supports them 'infinite' configurability I was able justify the investment to buy in fairly high quantities to get the best cost per PCB and pass the savings on to everyone.
I'll be keeping the same prices I posted
a few pages back for small quantity/individual sales since everything went as planned. I'll probably have some deal where if you buy so many boards you get one more free as well. If anyone is interested in using them for publishing a homebrew we can negotiate cost, but basically I'd only be looking to charge for labor costs essentially.
I'm going to be making a few batches this week. I'm actually using a $5 toaster oven I picked up from goodwill to solder on the surface mount components
I can't believe how well it works! Just bake until all the solder melts then shut her down to cool. The key is in the solder paste stencil I had made up that makes sure you've got just the right amount of solder paste. I'll have to post some pictures to share the process with you guys.
I think that is the sexiest PCB I've ever seen!
Congrats and count me in for a at least a half dozen to start.
Some good news!
Sat down with good ol' FME7 this evening. I was able to get nearly the entire chip without much trouble. I've tested and ran 256KB PRG, 256KB CHR, and 8KB WRAM and it's working great! At the moment I wasn't able to fit the 512KB PRG in there, I think I can fit it in if desired but it might come at the cost of something minor that's not necessary. I might be able to fit it in if I mix things up again between the two CPLDs. But it plays both games that used this mapper, and any desire to have 512KB would be a homebrew so things could be modified as desired for the full 512KB PRG if desired. Actually it wasn't the number of macrocells that was causing fitting problems with the extra PRG A18 bit, it was trying to "map 64 equations into 5 function blocks" that prevented it from fitting. I've ran into that a few times, so if I mix things around enough I can probably fit everything in, but should be good enough for now
Next task is to iron out the details of slapping the YM2419/8910 FM synth on the board to get the
GLORIOUS Sunsoft5 with full audio!
That sounds pretty epic! Good to hear it's going well
Even better news:
infiniteneslives wrote:
Next task is to iron out the details of slapping the YM2419/8910 FM synth on the board to get the
GLORIOUS Sunsoft5 with full audio!
Mark that one off the list
LONG LIVE THE JOKER!!!
So the clock divider and $C000/E000 decoding is all within the CPLD. One other bonus I forgot to point out that I made use of here is the 3.3V regulator provides a reset signal at power up. So that's the blue wire you see on top that resets the synth, you could use it for anything if desired. But you can also choose the power up state of the CPLD cells internally so it's not of much use except for cases like this.
A few wires here and there but really not too shabby. The mixing resistors are all below the 8910, but they'd fit nicely elsewhere if I had concerns about closing it up in a case. The bottom side of the PCB would actually have been even better than the route I took.
Wowzers I can't believe the how awesome it sounds coming out of the NES. I knew it was supposed to be good but wow. I've only heard it in emulators and youtube previously, hearing it from the NES is like hearing your favorite band in person for the first time.
Awhile back I heard that they really didn't use the 8910 for much more than percussion, not sure what they were smoking...
infiniteneslives wrote:
Wowzers I can't believe the how awesome it sounds coming out of the NES. I knew it was supposed to be good but wow. I've only heard it in emulators and youtube previously, hearing it from the NES is like hearing your favorite band in person for the first time.
Awhile back I heard that they really didn't use the 8910 for much more than percussion, not sure what they were smoking...
Actually, they used it for 3 square channels in Gimmick!, and ignore the noise and envelope generators. The reasons are sensible, I think. The 2A03 already has noise. The envelope generator as an envelope is kind of made obsolete by volume macros. The envelope generator as bass is okay, though at the given clock rate it's really hard to tune. However, Sunsoft already had a strong tradition of DPCM bassline technology, so it wasn't needed anyway.
The other thing is it's a YM2149F, not an AY-3-8910, and the reason this is important is that the YM2149 has a pin setting that divides the input clock by half (which is how it is used in the Sunsoft 5B), so if you're using an AY-3-8910 you'll need to manually divide the clock if you want the correct pitch.
rainwarrior wrote:
Actually, they used it for 3 square channels in Gimmick!, and ignore the noise and envelope generators. The reasons are sensible, I think. The 2A03 already has noise. The envelope generator as an envelope is kind of made obsolete by volume macros. The envelope generator as bass is okay, though at the given clock rate it's really hard to tune. However, Sunsoft already had a strong tradition of DPCM bassline technology, so it wasn't needed anyway.
The other thing is it's a YM2149F, not an AY-3-8910, and the reason this is important is that the YM2149 has a pin setting that divides the input clock by half (which is how it is used in the Sunsoft 5B), so if you're using an AY-3-8910 you'll need to manually divide the clock if you want the correct pitch.
Thanks for breaking it down for me on the sound technicalities.
Yeah I actually have both a YM2149 and the AY8910 pictured, and tested both. For the AY8910 I'm dividing the clock within the CPLD to keep things proper. I also noticed the YM was significantly quieter than the AY which I brought up
here. I should be able to tune it better to make up for the lack of volume but the 8910 will do fine. I had thought about configuring the CPLD so the YM was required since the clock wouldn't have to be divided. But it only saves a single macrocell, and 8910's are much easier to find and thus cheaper as well. I figure I'll just configure it to provide clock division so any chip will work including the smaller 8912. If there are volume issues just pick other values till you find what's best, or use a 10K pot for your audio mod.
rainwarrior wrote:
Actually, they used it for 3 square channels in Gimmick!, and ignore the noise and envelope generators. The reasons are sensible, I think. The 2A03 already has noise. The envelope generator as an envelope is kind of made obsolete by volume macros. The envelope generator as bass is okay, though at the given clock rate it's really hard to tune. However, Sunsoft already had a strong tradition of DPCM bassline technology, so it wasn't needed anyway.
Actually, even if the 2A03 has a noise channel, I think a second one is still useful for sound effects, so you can use i.e. a thin rattle noise effect without disrupting the drums. In fact, that would make that audio expansion a sensible choice for a game, as AY derivatives was used a lot in older game consoles and proved to be good sounding. I think it is really reasonable to use the 2A03 exclusively for music, and the "AY part" for FXs and music accompaniment.
I was just giving justification for not using it in Gimmick. Gimmick never uses sustained noise in its music, it's all hats and snares basically, and the snares are usually backed by triangle or DPCM anyway, so they still come through partially even when it's interrupted by SFX. I don't personally think
any of the YM2149F features are useless, I'm just saying I can see why they ignored them.
On an unrelated note, I was listening to the
Black Tiger soundtrack the other day (great use of theme and variations), and apparently it uses an OPN chip, which is essentially a YM2149 + 3 channel 4-op FM. In Black Tiger all the SFX go on the PSG side and all the music is done through FM, so they never conflict. I guess the Genesis has a similar hardware configuration, i.e. several "music channels" and a few PSG "sfx channels", by design. (Though there are many Genesis games that make great use of the PSG for music.)
rainwarrior wrote:
The envelope generator as bass is okay, though at the given clock rate it's really hard to tune. However, Sunsoft already had a strong tradition of DPCM bassline technology, so it wasn't needed anyway.
Perhaps a noob question: Out of curiosity would it then be much of an advantage if it could be clocked directly by m2 vice m2/2? Or not really worth the hassle?
It's not a big deal for the squares, but clocking it directly by M2 would get you another octave of usable tuning range for envelope bass. As-is the 5B envelope bass is just barely usable in my opinion, but at the full rate it's directly comparable to the ZX or Atari ST, much more viable.
I thought driving it directly with M2 would pitch it an octave up from M2/2, not the other way around.
It does pitch it up an octave. This takes an octave off the bottom of the squares' range, but it also adds an octave to the top of the envelope's range. So, you get an extra octave of usable envelope bass tones. So, it's a trade-off. Do you want an extra octave at the bottom of the squares (M2/2), or do you want an extra octave at the top of the envelope bass (M2)?
Well, calling it an extra octave is maybe not the best description. At the bottom of the range where there's a lot of numerical precision it feels like you're gaining or losing an octave. At the top of the range, you don't really have much precision and the highest few possible pitches increase rapidly (you don't have entire scales available). What you're really gaining is precision, which allows more tunable notes in the high end of the range.
So, if you use M2, the squares have the same range as the VRC6 (can go one octave lower than APU), and the envelope bass has a lot more flexibility. If you use M2/2, the squares can go an octave lower, and envelopes can be very slow (~20 seconds, vs ~10 seconds) but overall pitch precision is halved.
Personally I'd stick with M2/2 for compatibility with Gimmick, but M2 will give you capabilities that are a lot closer to the "classic" AY sounds you'd get from a ZX or Atari ST.
compare:
- Toki on Atari ST
http://www.youtube.com/watch?v=UGVy2_rIuLQ#t=3m35s- translation to Sunsoft 5B: toki_stage_6_on_5b.mp3 (attached)
I made this attempt to translate my favourite Atari ST soundtrack to Sunsoft 5B earlier and discovered just how little envelope bass resolution the 5B has available. As you can hear from this example, the envelope bass just doesn't have the precision to play the notes needed for this tune.
rainwarrior wrote:
Personally I'd stick with M2/2 for compatibility with Gimmick, but M2 will give you capabilities that are a lot closer to the "classic" AY sounds you'd get from a ZX or Atari ST.
But what if you could have your cake and eat it too?
My thought was to have a bit in one of the registers control if the mapper was sending the 8910 M2 or M2div2. It could start up and default to a value that gimmick didn't affect keeping it at M2div2. But if a music man wanted to get some better performance because the hardware existed to do so they could. The option could be left out completely and only added in upon request as well I guess.
I am drooling over this sexy board! Please sell me one!
I'd love one configured for stock MMC3 with PRG-ROM, CHR-ROM, SRAM, battery and sockets for the ROM chips as I'll be using it as a dev board. Please advise how long it'll be and what the final cost will be.
This is exactly what the NES dev community has needed for a long time! Thank you so much!!!
Any idea what the ball park would be for a pre-assembled 50 board run with programmed EPROMs? Just curious on how production runs would work for finished games.
Thanks qbradq, recently I was actually thinking about shooting you an email about this project. I know it was something you had been working on/hoping for well over a year ago when I was first getting into nesdev. Really I have you to thank for the idea and brainstorming of the
NESDEV1 project. I've taken a break from that for a bit to work on these boards mostly because of assembly challenges...
I've addressed the costs here in this thread:
Quote:
I'll be keeping the same prices I posted
a few pages back for small quantity/individual sales since everything went as planned. I'll probably have some deal where if you buy so many boards you get one more free as well. If anyone is interested in using them for publishing a homebrew we can negotiate cost, but basically I'd only be looking to charge for labor costs essentially.
For production runs I'd prefer to discuss details in private. I'm willing to do the work to provide fully assembled boards EPROMs and all. There will most certainly be discounted rates for larger orders and homebrew productions. I've already made up a few of these and have some good ideas for the second version that will allow me to assemble them with a lot less time and effort so that should be a win win as well.
Right now the only thing I'm waiting on is Jim's Cool open CIC to be finished up. He's made good progress recently and I expect the CIC's will be verified and available soon. I've worked out all the kinks on my MMC3 design for these boards so I could sell them now especially for homebrew development needs. I've yet to put the formal documentation together which I'd like to do for the formal release.
Additionally I did pick up a fair quantity of PLCC sockets for the CPLDs. I thought they might be of interest to deving with the boards. One could buy several mappers and one fully socketed board and just swap out the mapper chips as desired. I've also got several other mappers in the works so 'upgrading' would be easy. One could even try thier hand at creating your own mapper if one had a jtag programmer, I can recommend a ~$30 one I picked up recently.
That's funny, your work on this and NESDEV1 are the reasons I came back to NES dev
Looking forward to using this sexy, sexy board!
I forgot to ask this. I got confused over the six page read. Will my memory chips need to be 3.3v tolerant on the signal levels or not?
Thanks!
qbradq wrote:
I forgot to ask this. I got confused over the six page read. Will my memory chips need to be 3.3v tolerant on the signal levels or not?
Thanks!
Yeah basically the Vih of your memory needs to be below the Voh of the cpld. The data sheet says 2.4v with 4ma load. It's above 3.0v from what i remember under normal address line loading. All the data sheets say 2.0-2.2v for Vih on memory.
Effectively i doubt you could find a 5v memory that isn't compatible... It'd have to be a pretty bum chip to not sense 3v as a logic 1.
So when the CIC is finished you'll begin taking orders for boards? Any idea when the CIC will be done, like an educated guess?
MottZilla wrote:
So when the CIC is finished you'll begin taking orders for boards? Any idea when the CIC will be done, like an educated guess?
You'd really have to ask Jim's cool about that. For what its worth I would like to see my boards for sale in a month or less.
It's been a month. Is there any news? =)
MottZilla wrote:
It's been a month. Is there any news? =)
Thanks for pinging me on this. Unfortunately illness has dominated our household over the past month so it's been a challenge to make significant progress. Good news is we seem to be operating near 100% now
Jim's cool did hook me up with a CIC build that is working on about 20% of the attiny13's I pop out of the tube brand spanking new. I've found the same results on 3 different lots of parts and both SOIC and DIP packages. So something funky is going on shortly after startup/reset. He's had some obstacles of his own, so I started trying to debug it myself starting fresh from the disassembler. Worst case I'll pick up where he's paused, this being my top project at the moment.
I have successfully tested TNROM. Still want to try some other more obscure MMC3's in the future but not very high priority.
Not top priority, or release limiting but I've yet to pop my version of the MMC1 on to it yet but don't expect much issues (or high demand) from MMC1.
I did dig into MMC2/4 a little while back for the first time. One of those things I always assumed was more complicated than it actually is. Really they are probably the simplest of all the MMC's IMO. It'll require a little wire jumpering to gain an input from a NAND gate to sense the CHR addr lines with few I/O. So at some point I'll ensure support for these as well. Best solution for these will be on a second PCB version that has connections for a discrete NAND gate removing the need for jumpering. I'll probably do the same to remove Sunsoft-5A jumpering on the Synth.
I've actually ignored the discretes thus far except the multi-discrete for the bundle. I do have a minor issue with PRG A13 on the PCB, but I can fix this by hand and will make sure to cover it for the next version.
Sorry more of a TODO list than an update list... But really the only thing holding back release at this point is the CIC. MMC3 is the priority here due to lack of availability anywhere else. The next step after that is setting up a wiki to help document the numerous jumpers so it's easier for people to use. But the wiki will most likely be in tandem with the release or motivated by user demand.
If anyone's aching for a board and doesn't care about the lack of a CIC I'll entertain the idea private requests. The
prices throughout have been consistent, and still stand the the time being.
I have a toploader NES, so I don't need the lockout chip, so I ordered a couple boards and recently tried them out. So far, they're awesome!
I made Final Fantasy III and Mr. Gimmick, and the process was flawless. No rewiring, just soldering in the appropriate chips and being on my way. I had a couple broken games with chips I could use, so I used the parts from there, and I now have complete working brand new repros!
So far, the games seem to work great. No noticeable glitches or crashes. I'm definitely buying more boards later on
Glad they worked out for you snoopkatt, thanks for being one of the guinea pigs
Things are going pretty well with these. Thanks to Jim's cool CIC "tennis" I've decided to put these in a 'beta' release of sorts. NTSC is the only confirmed region at the moment. Working to confirm other regions right now. Still have some testing to do for mapper configs including MMC1 and a few others. But I've tested a fair number of MMC3 games with great success including clone consoles. I've also been able to make test out some simplifications to keep costs down where possible. Things like TNROM for FF3 can be minimized down to ONE larger 72Mcell CPLD. From what I can tell the game never actually uses the bankswitching available on the 8KB of CHR-RAM so that simplified things greatly to allow only one CPLD to be used.
The large part of my first order has been spoken for or is already out there in use. So I'll be ordering the second batch soon correcting things like the polarity issue on the battery. Any units shipped with the error I've just corrected by hand and included the battery clip at no charge. I'll also be changing things like moving the surface mount caps/resistors to the top of the PCB and other minor things that simplify assembly and removing some jumpers I've deemed unnecessary. My plan is to stay as the 'beta release' until I get the second shipment of boards up and running. Just email or PM any requests directly for now, and be patient while I assemble/test it specific to the order.
I still haven't quite decided the best way to make things easy for configuration and assembly while still keeping things relatively easy and simple for me to produce. While still in beta release I've decided to handle each order as a 'custom' order where you can specify exactly what you're looking for and which options you'd like. Based on what seems to work best on this beta release I'll decide what options to provide in the future. Things could be as basic as mapper/CPLD and it's power supply alone, or as complete as mapper, CIC, discretes, battery, & SRAMs (all but ROMs).
I'm also realizing how much of a pain EPROMs can really be... So I'm planning to have a second version once this first EPROM/(and other DIP memory) version is in fully released. The second version will probably ditch through hole components completely and might slim down the board as well. The goal with version 2 would be to use SOIC Flash memories which are actually cheaper than EPROMs and have a LOT less headaches. The only challenge is programming since I'd actually plan for these to come FULLY populated including ROMs. Only selling them as fully populated will allow me to load them up with a test ROM to verify everything and hopefully reduce chances of problems for the end user. So to program them I'll be using the kazzo like/compatible hardware with my own software and firmware. Some extra programming signals will be routed through the EXP connector and/or an additional 'side' connector for programming things like the CPLD and CIC most likely. Basically this would be more of a 'plug and play' version that only requires a computer and kazzo to create repro/homebrew games. No worries though, I plan to continue to offer the rev1 'EPROM' version after rev2 becomes a reality for those who still want to do everything themselves. That and the rev1 will be better for hacking/prototyping for people who like to do things like make their own multicarts and are savvy enough to overcome hardware challenges themselves making use of the perf area.
I was hoping for an update from you soon. Good to hear things are progressing. You did say that MMC2/MMC4 would eventually be supported right? I wonder if that might only need 1 CPLD since it's relatively simple as far as mappers go. And I forget if you mentioned if down the line you planned on supporting the Konami VRC series at all. I'm glad you got the CIC worked out now.
MottZilla wrote:
You did say that MMC2/MMC4 would eventually be supported right? I wonder if that might only need 1 CPLD since it's relatively simple as far as mappers go.
Yeah MMC2/4 is next up after I verify MMC1. I've already written up and tested MMC1 on the NESDEV1 so that one shouldn't be an issue. The MMC1 will fit on ONE CPLD. The FULL MMC1 will take a larger 72mcell CPLD, but something like SNROM fits pretty well inside a smaller 32mcell CPLD last time I compiled it due to only having 8KB CHR.
I haven't written up MMC2/4 yet, but you're right it is pretty simple and shouldn't require much logic. I'm expecting that it'll fit in a smaller 32mcell CPLD. But I'll also be using an external set of AND gates to reduce the number of inputs (and simplify signal routing/jumering) on the CHR address lines to sense $FD/$FE.
Quote:
And I forget if you mentioned if down the line you planned on supporting the Konami VRC series at all.
I haven't mentioned the VRC series yet, but it's definitely something I'd like to do down the road. I'd also like to see some NAMCO and such. Only issue with some of those is I won't be able to get any sound extensions inside the CPLD due to the massive amount of logic that'd be required. Stepping up to the Mach-XO2 CPLDs would solve the logic demands but not sure if I'll ever put synth re-engineering high enough on my priority list to make happen
There are always external synth options but the 8910 for the sunsoft-5B is the only one that appears to be an option for this route.
I've got a few other plans revolving around making my own mapper that is tailored to my boards that'd be a mmc3 improved hybrid of sorts. That's a little more fun to work on so I'll probably try to tackle that project first before working on some of the more obscure FC only mappers.
infiniteneslives wrote:
The MMC1 will fit on ONE CPLD. The FULL MMC1 will take a larger 72mcell CPLD, but something like SNROM fits pretty well inside a smaller 32mcell CPLD last time I compiled it due to only having 8KB CHR.
Would something mostly compatible with SUROM fit on the smaller one?
Quote:
not sure if I'll ever put synth re-engineering high enough on my priority list to make happen
Especially since it has been
discovered that the logic to get the synth doing anything on a 72-pin deck would cause audible jitter at every OAM DMA.
tepples wrote:
infiniteneslives wrote:
The MMC1 will fit on ONE CPLD. The FULL MMC1 will take a larger 72mcell CPLD, but something like SNROM fits pretty well inside a smaller 32mcell CPLD last time I compiled it due to only having 8KB CHR.
Would something mostly compatible with SUROM fit on the smaller one?
Yeah it'd be close, any extras may take it over the top. If one was modifing the MMC1 and wanted to minimize logic the best thing to do is cut out the serial writes (granted it's not much of a MMC1 after doing that though). The counter and extra shift register sucks up quite a bit of logic. The MMC1 minimized pinout but that's not much of a limitation with these CPLDs. You're better off to handle the register writes in more of a MMC3 fashion since pins are abundant and logic is not if you're trying to cut cost.
infiniteneslives wrote:
If one was modifing the MMC1 and wanted to minimize logic the best thing to do is cut out the serial writes (granted it's not much of a MMC1 after doing that though). The counter and extra shift register sucks up quite a bit of logic. The MMC1 minimized pinout but that's not much of a limitation with these CPLDs. You're better off to handle the register writes in more of a MMC3 fashion since pins are abundant and logic is not if you're trying to cut cost.
In other words, it'd be a good idea to mapper hack games developed for MMC1+CHR RAM to use the multi-discrete mapper that we worked on. The layout of port $80 is even (intentionally) similar to MMC1's register 0.
infiniteneslives wrote:
The counter and extra shift register sucks up quite a bit of logic.
You can cut the counter by increasing the length of the shift register by one. Rather than having a counter that counts from 0 to 4, instead have a six-bit shift register that's preloaded with 1, and when the MSB is set, load.
I don't know if that's enough, though.
(Also, sorry if I'm telling you something you already know)
Technically, you need only a 5 bit shift register.
Reset: 10000
Shift bit A: A1000
Shift bit B: BA100
Shift bit C: CBA10
Shift bit D: DCBA1
Load bit E: Don't shift. Take bit 4 from D0 and bits 3-0 from shift register bits 4-1, then reset the shift register.
But perhaps even this logic requires too many macrocells for intermediate results. Is there a "disassembler" of sorts in the Verilog compiler that tells exactly what each macrocell is doing? Perhaps this might help fill us in on the difference between the 25 flip-flops required for the MMC1's architectural state and the size on the CPLD.
That's not a bad idea, I'll have to give it a try and see how much logic it actually saves. I haven't really revisited my MMC1 design since I made it almost a year ago. It was my first ASIC to re-create so it's fun to look back at my old 'noob' code.
I used a 4bit shift register and 3 bit counter. So should be around 7 macrocells based on number of states.
Ditching the counter for an extra bit in the Shift reg would presumably cut it down to around 5 macrocells. More logic can also be saved if you allow consecutive writes from RMW opcodes.
As for a disassembler type thing I'd have to check my text file outputs from synthesis (aka logic compilation). That's where you'd find that kind of data if it is available. Honestly though the best way I've found is to actually compile the thing for the target device. I've ran into some weird issues and found that most of my designs save a few macrocells if I optimize for speed instead of density. Kinda messed up, but based on the other xilinx webpack issues I've seen I wasn't that surprised...
My point was really to cut the ~5-7 macrocells for the input shift register completely buy utilizing easier and faster parallel direct register MMC3 style writes if you're already making a custom mapper. The I/Os are there, may as well use them if they're saving you logic for a 'non-standard' mapper. You could also stay serial and shift writes directly into the final register based on A13/14 instead of only watching the last write. You m ight even be able to do this with many licensed games assuming they don't put the bankswitching code in the bank that's disappearing post bankswitch. This would also rely on start up proceedure, resets aren't really needed when you've got known start up register values. I think some games like to 'prime' the MMC1 which wouldn't work out so well.
For my custom mmc3 hybrid mapper I went as far as restricting ranges of the banks. This makes a lot of sense for CHR especially if you keep sprites and bg tiles in segregated pattern tables which makes sense anyways based on NES limitations. Those assumptions allow you to cut a few bits from each register, and when you've got several registers the savings adds up.
infiniteneslives wrote:
This would also rely on start up proceedure, resets aren't really needed when you've got known start up register values.
After the player presses the Reset button on the Control Deck, there's not as much faith in the register values, unless perhaps you're using loss of oscillation on M2 to reset the mapper.
Quote:
For my custom mmc3 hybrid mapper I went as far as restricting ranges of the banks. This makes a lot of sense for CHR especially if you keep sprites and bg tiles in segregated pattern tables which makes sense anyways based on NES limitations. Those assumptions allow you to cut a few bits from each register, and when you've got several registers the savings adds up.
You might not necessarily have segregated sprites and background tiles if you map the same bank into banks 0 ($0000) and 5 ($1C00-$1FFF) so that objects can transition from being in the background to being sprites and back without tripping up the scanline counter. I remember recommending this to tokumaru. But another thing that saves flip-flops in an MMC3-alike is to design it for CHR RAM. Just restricting the range to the 32K in a 62256 CHR RAM saves 18, and hardwiring all CHR banks but banks 1 ($0800-$0FFF) and 2 ($1000-$13FF) saves even more.
tepples wrote:
You might not necessarily have segregated sprites and background tiles if you map the same bank into banks 0 ($0000) and 5 ($1C00-$1FFF) so that objects can transition from being in the background to being sprites and back without tripping up the scanline counter. I remember recommending this to tokumaru.
And it was a very good recommendation. I'll definitely do this when I make an MMC3 game.
tepples wrote:
infiniteneslives wrote:
This would also rely on start up proceedure, resets aren't really needed when you've got known start up register values.
After the player presses the Reset button on the Control Deck, there's not as much faith in the register values, unless perhaps you're using loss of oscillation on M2 to reset the mapper.
yeah it's not really a great idea, more of a frugal one.
tepples wrote:
Quote:
For my custom mmc3 hybrid mapper I went as far as restricting ranges of the banks. This makes a lot of sense for CHR especially if you keep sprites and bg tiles in segregated pattern tables which makes sense anyways based on NES limitations. Those assumptions allow you to cut a few bits from each register, and when you've got several registers the savings adds up.
You might not necessarily have segregated sprites and background tiles if you map the same bank into banks 0 ($0000) and 5 ($1C00-$1FFF) so that objects can transition from being in the background to being sprites and back without tripping up the scanline counter. I remember recommending this to tokumaru. But another thing that saves flip-flops in an MMC3-alike is to design it for CHR RAM. Just restricting the range to the 32K in a 62256 CHR RAM saves 18, and hardwiring all CHR banks but banks 1 ($0800-$0FFF) and 2 ($1000-$13FF) saves even more.
Yeah your solutions were mine as well. That and your idea of a bullet proof scanline counter that senses CHR A13 should resolve that issue as well, while saving even more logic. CHR ROM really doesn't make much sense for homebrew use when large parallel SRAM and large serial flash is dirt cheap.
On a related note, another interesting thing I realized a while back is 128KB SRAM is actually cheaper than 32KB SRAM when buying sizable quantities. So I'll actually be moving to 128KB SRAM even if it's not all useable under typical configurations...
Good news! Another mapper 'knocked-out'. Hearing Mike Tyson on the Bob & Tom show this week gave me a little extra motivation
So MMC2 is up and running, still need to actually test MMC4 too. It's as good as done though too with it's subtle differences between MMC2.
Wanted to verify this one before ordering the next batch. I've already converted most of this wire mess needed to run MMC2/4 into PCB traces for rev2.
I was actually kinda surprised how much logic the thing sucked up. It's only got 27 state bits but it's taking up around 38 MCells with all the other logic going on so it doesn't fit in the smaller CPLD's but oh well. Still fits in a single 72Mcell CPLD and the MMC4 should as well. I used a 74HC30 (8 i/p NAND gate) to sense CA3,6-11 high to reduce the number of I/O. So the second rev will have a SMT footprint for that guy.
MMC1 is still kicking my butt for some reason. It's practically working but for some reason CHR A11 keeps going high durring sprite fetches. It's the darnedest thing too because I was trying out SNROM and tried having the NES drive CHR A11 directly and the mapper doesn't even touch the signal. So I still gotta figure what's up there. One other weird thing is that there are 3 levels of 'severity' almost as if it's somehow related to CPU/PPU alignment. I put the oscope on the trace and I can see the line getting tugged high and everything. I'm going to try and debug using an original MMC1 to figure out where the bug's at exactly...
Anyways I should be ordering another batch next week after the Chinese new year. I figure I'll debug mmc1 while they're in production/shipping over here. Pretty sure whatever's going on with the mmc1 isn't PCB related so I should be safe.
That's great to hear that MMC2/4 is near done. And even better that on the next board revision it won't require all those wires! =) I'm sure you'll sort out MMC1, it might be one of those things where you feel silly for making a minor mistake. But who knows, it might be something more clever.
I received my boards just today and will get to try them out later today.
Awesome progress since the last time I checked! Maybe it would be cool to add another 8 pin IC footprint overlapping the Ciclone location for AVRCICZZ. It would be trivial to just run wires to the correct pin or cut the trace and rewire them but I figure it would take 2 min to add and it would be very nice to have the possibily to just drop the attiny13 on the board without extra wire/modification.
SkinnyV wrote:
Maybe it would be cool to add another 8 pin IC footprint overlapping the Ciclone location for AVRCICZZ.
Yeah I actually already had the first rev set up for the t13 using Jim's Cool CIC 'tennis' for the SOIC footprint and the DIP was for the CIClone. The AVRCICZZ only has a couple signals swapped compared to the tennis. You could actually make them identical if you recompiled it. I'm actually dropping CIClone support on rev2 and replacing it with t13 DIP footprint so it'll support the tennis in both SOIC and DIP. So it in essence already supports AVRCICZZ if you rebuild it with matching pinout.
This is all looking great
Good news. Finally got out the second revision to be assembled. Pretty sure I can't fit much more on this thing...
Should have the next batch available in about a month. Many thanks to all the people who tried our the first batch and provided great feedback for the next rev.
Aside from a few errors, there wasn't really anything that changed compared to the eariler rev. I really only ADDED things.
Additions:
1) Support for SOIC-44 PRG-ROM Flash up to 1MBytes. I made some connections via EXP0 that should allow this memory to be programmed via the
kazzo or similar (cart edge alone) This would allow for a somewhat simple flash cart assuming CHR-RAM was used.
2) MMC2 & MMC4 support, no wire jumpers or anything. Just drop in your ROMs.
3) MMC1 all configs SXROM, SUROM, SOROM, SNROM, SLROM etc with a single CPLD and no wire jumpers. Still have to get the MMC1 debugged though. I wired up an original MMC1 and still had the same bug, grrr... Hoping to fix this before they show up in a couple weeks.
4) AY-3-8910 synth for Sunsoft-5A support. No wire jumpering. Just drop in the synth. The mixing circuitry is included in surface mount form. I'm actually planning on stocking up on synths soon, so people don't have to hassle with overseas ebay suppliers.
5) EXP connections. Connected up JTAG for the CPLDs and /RESET for the AVR used for the CIC. Doesn't really mean much, just makes assembly easier for me.
6) All discrete components are surface mount on the top side. Makes assembly easier, still have the through hole capacitor support for people interested in bare PCBs.
7) Discrete mappers are also supported by using surface mount '161/'32. The through-hole '377 and '32 are still there.
8) Slightly smaller board outline, since they were tight in original NES cases.
9) New design on the solder jumpers (see below). Basically this was the number one source of errors I had making games. There are over a dozen jumpers that need to be closed, but most of them are closed in the same position for nearly every configuration. It's pretty easy to miss one... So the board is 'pre-configured' for normal operations. If unique configs are used, then the little trace making the default connection can be easily nicked with an exacto knife. It can be easily re-made by solder jumpering again if desired. This also saves time on assembly. And since it's easier to ignore most of the solder jumpers I made a few more for things that became more common like PRG A12 mapper input, WRAM /WE -> PRG R/W, PRG-ROM A19 jumper, a few others for MMC2/4.
Aside from that I'm going to be working on a few other mappers while waiting on the boards. Starting to target some rarer famicom only mappers, and some multicarts. Going to test out Motzilla's NROM multicart, and thinking I'll give Farid's megaman multi a try. One easy addition should be mapper 78 (holy diver) in a single small CPLD. Thinking I'll give the RAMBO-1 a try at some point also. I'd like to start on the VRC's and Namco's and such as well, although I don't have the board set up for lower address bit inputs common on the VRC's and similar. I had a thought about giving the VRC-7 a shot at some point using an external Yamaha YM2413 OPLL. Yes it wouldn't be a true VRC-7 since there are some differences, but it'd be better than nothing at all. The VRC-7 is pretty hefty though, I might have a hard time fitting all the logic in 144 Mcells... We'll see how far I get on that list in the next month
MMC1 up and running
Details
here for those curious about what was racking my brain for the past month... Going to start testing out the various MMC1 PCB versions. So far only SNROM tested and verified.
Boards are being manufactured as we speak. Should have em in about a week along with a slew of parts to populate em.
Wow, this is looking fantastic
Great to hear MMC1 is all fixed up, as well as the progress on the other mappers. Good stuff
Well the new batch showed up last week finally
They turned out kinda orange this time vice yellow like last time, but oh well. It's not the 'norm' so I'm still happy.
I've tested out most mappers that were working on the original boards. The 8910 synth's drop directly in now and everything seems to be working there. Had a small bug on MMC2 that showed up on the new boards and not the proto. I guess the new boards are a little faster than that wire mess I had previously because CHR A12 started becoming invalid. Turns out latching the addresses on the positive edge of CHR /RD is not a good idea. I found I had to put a pull-up resistor on CHR A12 to keep it valid long enough. Switched over to latching on the negative edge of CHR /RD and all is good (no pull up needed).
Still need to play around with the new PRG-ROM Flash and everything. Started investigating VRC's and realized they aren't actually that difficult to implement with my current setup. I've coded up VRC I & II so far, need to test them out still.
So far so good, no major errors and I'm liking the changes thus far. I have started taking orders on these. But I'm trying to get caught up with a few things and make up a good supply of them in advance before I list them up on my site.
As a kind of dirty hack, I was idly wondering how feasible it would be to use the AY-3-8910 to badly emulate the VRC6's audio. Obviously it's not trivial: the '8910 lacks duty cycle control, the sawtootth wave uses a ÷14 instead of ÷16 divider, and the AY-3-8910 expects indirect addressing while the VRC6 registers expect direct.
It's probably a terrible idea, but at least you can still buy NOS AY synthesizers.
lidnariq wrote:
As a kind of dirty hack, I was idly wondering how feasible it would be to use the AY-3-8910 to badly emulate the VRC6's audio. Obviously it's not trivial: the '8910 lacks duty cycle control, the sawtootth wave uses a ÷14 instead of ÷16 divider, and the AY-3-8910 expects indirect addressing while the VRC6 registers expect direct.
It's probably a terrible idea, but at least you can still buy NOS AY synthesizers.
Yeah it'd probably be difficult to do without some level of rom hacking to go along with it but it is a interesting idea. I was actually considering trying out emulating VRC6 sound on a microcontroller and DAC. Of all the extra sound chips to emulate with a mcu I think the VRC6 would be a good place to start.
With the VRC7 I was thinking about trying to use the Yamaha YM2413 OPLL since they're still available to some degree. Yes it wouldn't be identical to the true VRC7 due to their minor differences, but for new music composition it might even be seen as an improvement. With only the one game that used VRC7 sound you're really better off to buy the original cart if you want 100% authenticity anyways.
That picture my friend is the closest thing we might get to NES porn
I'll be keeping an eye on this project as I will probably buy one of the next board revision. Only thing I wish it could have is a port to program it without external hardware but I doubt this would be possible.
SkinnyV wrote:
Only thing I wish it could have is a port to program it without external hardware but I doubt this would be possible.
Oh it's certainly possible the trick is to do it as simply as possible to keep the cost from being prohibitive. I'm working on it right now. My preliminary plan is
here.
Pretty cool to see a board that mostly fills up the whole cart case. And the amount of option jumpers almost rivals Nintendo's Playchoice game boards, heheh.
Are you still using the XC9500XL family parts? I was curious what you're doing to reset yours. I've tried initializing the registers in the build options, and in the verilog (e.g., reg [3:0] PRG_PAGE_0 = 4'b1111;), but doesn't seem like it ever starts in the bank that I want. Did I miss something, or do I just need a dedicated reset pin? I hate to lose an input pin, but I need to move forward on a board revision.
I'm still using XC9500XL family for these boards. I love the lattice Mach XO2 family, but it's cost inhibitive for this project. Xilinx claims there is some way to designate startup of individual registers. I tried it once and wasn't successful.
In the processes window, right click 'fit' and then select 'process properties'. There is an -init flag that allows you to choose high or low startup value of all regs. FPGA equivalent is also a choice, perhaps that's what you have to select to designate start up in your verilog. I've had sucess with both startup high and start up low in practice. If you need different regs' to start up hi/lo I just use inverse logic so they can all start low or high together.
Couple other advanced notes. Under 'Design goals and strategies' there is also a means to select start up value. Don't trust it, it lies. You can verify the settings if you view the 'detailed reports' 'CPLD fitter report (text)' at the bottom it will tell you your selected settings. It wasn't until I saw this that I realized my CPLD wasn't really in low power mode like I told the design goals and strategies to do. It saved me ~30% power consumption when actually set properly. Additionally in the -optimize flag a few below the -init flag, I've found that 'speed' actually synthesizes to a macrocell or two smaller than 'density' most times. Messed up, but true in all my experiences...
Thanks for the tips, it's much appreciated. I believe I was setting it under the "design goal and strategies", what a crock.
Anything definitive that states that the Sunsoft 5A has audio hardware and access to 512K PRG yet?
B00daW wrote:
Anything definitive that states that the Sunsoft 5A has audio hardware and access to 512K PRG yet?
Since there were no games that had 512KB PRG I haven't invested much time in seeing what'd have to be done to make it work. The current version that supports 256KB PRG & CHR (and WRAM) takes up 134Macrocells out of 144 available. So it might fit with some trickery, but when I was initially compiling it I recall that I had issues fitting all the CHR due to routing constraints, not because of available logic. It's possible that some of the same settings that were burning Memblers were burning me back then as well though...
Either way 512KB is directed towards homebrew, and there could be simplifications made to make 512KB fit. One easy choice is to limit the range of some of the CHR banks. Something like that probably wouldn't even limit the homebrew, it'd just have to be considered in the design.
An even better solution would be converting to 32KB CHR-RAM (or ROM). That'd work well for one who was just looking for more PRG for the sole purpose of audio storage. I'd expect that would allow 512KB PRG no problem, and probably even support expansion to 1MB of PRG or more if you wanted it.
If you're interested in such a mapper let me know and I'll add it to the list.
As for the audio, it's fully supported on the new revision. All you've got to do is drop in and solder in the AY-3-8910, I put that whole mess of wires into the PCB traces. I also picked up a batch of them so those can be sold along with the board for $8 more, that way people don't have to mess around with the foreign suppliers on ebay...
B00daW wrote:
Anything definitive that states that the Sunsoft 5A has audio hardware and access to 512K PRG yet?
There's no way the 5A has both; they use the same pins. People have experimentally determined elsewhere in the forum that the 5A doesn't have audio. I wouldn't be surprised if the 5A had neither, and maybe had just the inverter/amplifier.
Does anyone know how I order these boards?
Nothing on his website, and I've PM'ed him, and get no response.
Thanks
Sorry I can't always respond within 24hrs, I've replied to your PM.
Figured it's about time for an update on these boards since they've come up a few other places, and there's been some newer happenings. I tend to shy away from updates like this, because I always feel like I'm spamming. But oh well, since this thread is devoted to these boards I suppose it's okay. Sorry it's one gigantic post that covers quite a few topics.... When I started writing some of the last couple paragraphs I considered branching it off to another topic, but felt too much like spam. Perhaps I can branch it later if necessary. The 'bigger news' is towards the end, so maybe just skip there if you're not in for some light reading.
First off I'd like to thank everyone in the community for their support for this project. I can say it's been extremely more successful than I would have ever expected. If it wouldn't have been for all the early support in the beginning especially I very well may have never considered the project to be worth the effort. I struggle with the idea of sharing this info with concern of sounding pretentious as if I'm trying to toot my own horn. But really one of the big motivators I had for this was knowing the large number of original boards out there getting sacrificed everyday for repros. I know I'm not the only one here saddened by that, so I can proudly say that there are currently over 1000 of these boards out there in the world today which have saved the lives of many good games. Much to my surprise repro-makers are becoming open to the idea of new boards. While they do cost more, the time savings is great. Additionally they don't have to be as selective since they're using donors for cases only at the moment. It's safe to say I'm starting to put a dent in the number of 'better' MMC3/MMC1/FME-7 games being sacraficed to the repro-man... Because of the success of this project I can say without doubt I will be making the jump to acquiring new cases as well to bundle along with the boards.
Secondly after a year of working on these boards I can officially say many of the popular mapper and board configurations are fully released. No longer are they only available by request. I've got em posted up on my
site. The most popular variants are posted up for immediate checkout. I'm trying to ramp up on pre-assembled stock right now, but I'm struggling to keep up with all the different variants and my constant urge to support more mappers, board configs, and features. Currently around half of sales are built to order and end up with a 1-2week lead time.
As for my current status of this board; I'm officially calling this large through hole board "INL-ROM v1" aka "EPROM" or "Through-hole" version. The initial first batch was v1.0 and had support tailored mainly for MMC1,3,FME-7, and discrete mappers. Earlier this year I whipped up v1.1 which added support for the 8910 synth for Sunsoft-5B with full sound, and MMC2&4 as well. Recently I created
INL-ROM v2.0 which is directed towards providing a fully assembled board that requires no soldering. This original version1 isn't going anywhere though. It will stick around since it's the only version to have 8910 synth support, and MMC2&4. Additionally this version will remain mostly through hole compatible. Honestly I haven't gotten any requests for an unassembled board, but as a do-it yourself type of guy I want to ensure the option exists. So if someone wanted to produce a discrete mapper board sourcing their own component through-hole components and everything; that option will continue to exist with these boards. Part of this is also due to the uncertain future of retrozone's repropaks, I have a feeling they may become a thing of the past much like their MMC1 repropaks once their shelf is empty. It's well known their focusing their efforts on some other special project over there, so their future uncertain.
I'm about to start making some tweaks to this for v1.3 since it's getting the time it's about time for me to order another batch of this version. Most changes are just component footprints. Some planned changes are removing through hole WRAM. Having it effectively requires a surface mount CPLD/mapper and power supply. That and suppling the entire battery backing circuitry including SRAM ensures proper lower standby component part selection. It's also because I'm try to stop stocking 32KB soic SRAM. I can get 128KB soic SRAM for the same price and it has a wider footprint. CHR-RAM is staying 32KB, but moving to SOJ package since it's a smaller footprint and cheaper. Additionally I'll be adding PLCC flash chip support for PRG and CHR ROMs, this is mainly since MMC2,3,sunsoft5 stay on this version. I'll probably add jumpers to gain support for VRC mappers, trading upper PRG data bits for lower address bits. Maybe a few other minor details will get in there as well.
Lastly, I feel that I owe a great deal to the nesdev community I owe so many people so much. I'm trying to come up with some ways that I can use the success of this project to give back to the community. One of the biggest goals of this project was to try and provide a hardware solution to help people release their own homebrew game/project. There weren't many options in the past especially if you weren't the electrical engineering/hardware type of guy. The large investment is certainly daunting to acquire everything needed to make your own cartridges especially if you don't know how to solder. And if you didn't want to get into all that your only option was to try and sign a deal with retrozone, not sure what that deal is/was exactly but it appears somewhat restrictive. Either that or one may have felt their game/project wasn't 'grand' enough for a retrozone release. I'm not trying to knock retrozone here, I appreciate everything they've done for the community. They've pioneered much of the type of projects I do myself, and bunnyboy has supported me with numerous projects of mine including this one. They too have saved many original cartridges from the repro-man. They're just not everyone's taste when it comes to releasing homebrews as I understand.
I don't have a lot of details of what I'd like to offer exactly at the moment. But the biggest thing I can help share is the power of scale that I've generated. It wouldn't be difficult for me to cover the initial investment in a modest production run of a homebrew title. I know acquiring funds for such an effort are prohibitive expensive for many. I have no interest in gaining 'publishers rights' for your homebrew titles for something like a long term contract. I'd only look to do whatever the artist intended. Just want to make a batch of 10-50 carts and see how it goes to start? Then perhaps consider what other options there are for a second/longer term release after you've built up some funds? Cool with me, I'd love to do what I can to help. If someone wanted to presell carts on their own site/ebay or something and then pay for the hardware after the presale that could work as well. If there's interest I could sell titles on my site as well, but I'd never try to push that option; I'd just be available if the artist chose to for however long fit their fancy. IDK, I'm probably not wording this too well, and perhaps I should be more formal. But I figure I'll just toss it out there and see what your response is. My only real concern at this point is that my gestures will be misconstrued as seeking my own personal gain. I'm trying to just be as open and honest as I can, not sure how else to get a message like this across without sounding like a salesman or something... If it helps I can say that I'll even go as far as to provide my products as close to cost as I can for an 'initial batch' trial run of anyone's game. So that would give decent discount on a batch of boards compared to what's listed on my site at any given time. I can also help you pinch pennies on the hardware design to tailor the board/mapper for your game specifically.
Feel free to chime in on any thoughts you may have on that last part (either publicly or privately). If there's interest for something like this even if it were to be months/years down the road, I suppose it'd be a good idea to try and formalize some of this and post it on my site or something after getting some feedback. If something like this sounds of interest, but you're thinking you may never even end up making the game you've been meaning to for years, I'm still interested in your thoughts on this. I don't want to make this a one time deal or anything. I'd love to offer something like this to the community till the day I die, you guys are the best.
First off new here and got to say THANK YOU! INL. Your flashcart is just what I've been looking for. WaHoo!!
Just a little background: I'm coming from a chiptune point of view. For a while Neil Baldwin has been producing some great homebrews for the chiptune crowd, and a few of his titles are designed for SXROM mapper. So to run on real hardware the choices are: PowerPak/N8 or try to find a FC SXROM cart or try to convert a NES SNROM to SXROM. The success rate has been low for the conversions. There seems to be an issue between the Nec MMC1 and the Sharp MMC1 chips. The problem is compounded by the fact that Neil doesn't have the time or resources to test his code on other people's hacked carts, so there may be a slight issue with the code or with the conversions or the mappers or with the user's NES. It works fine in Nestopia and on the PowerPak or the N8, judging from the user reports.
The PowerPak seems out of production (ATM or forever?) and the cost is not trivial. The cost for the N8 is also a barrier for me. The one point both these carts shine at is the access to save states, this is a major ++ when working on music.
SO when I stumbled on to your work I got really excited! Your V1.X board seems like the ticket. I will be ordering one and a USB dumper very soon!!!
A couple questions:
1. Is it possible to dump/load save states on your V1; would you consider that as a option on the V2 design?
2. Are new cases going to be a reality? Hate killing a cart for the case.
3. After reading through the V2 thread, the inclusion of a uC sounds great. Will it be usable for Exp Audio/Midi? There are allot of people that would like to see a new 'MidiNES' type cart.
Thanks again for your efforts, it really is great having a low cost second source for carts!
Yogi
yogi wrote:
The PowerPak seems out of production (ATM or forever?)
On IRC, bunnyboy told me it should be back in a couple weeks.
yogi wrote:
1. Is it possible to dump/load save states on your V1; would you consider that as a option on the V2 design?
Do you mean the SRAM that is battery backed?
tepples wrote:
yogi wrote:
The PowerPak seems out of production (ATM or forever?)
On IRC, bunnyboy told me it should be back in a couple weeks.
Thanks for the news, been check'n the site weekly for a while
Though I will be getting one at some point, my hopes are for a multiple NES setup, kind of crazy 'NES band', so more then one PowerPak starts getting costly.
Yogi
MottZilla wrote:
yogi wrote:
1. Is it possible to dump/load save states on your V1; would you consider that as a option on the V2 design?
Do you mean the SRAM that is battery backed?
Yes. Neil's ROMs are native trackers, so song data is saved on the cart. Being able to dump/load the song data allows composing on a PC and/or the NES. The PowerPak or N8 makes this a very painless process, but the cost is a concern.
INL's flash cart doesn't have the flexibility that an SD or CF card based cart does but with the Kazoo/ Usb dumper it comes very close at a far lower cost.
Yogi
yogi wrote:
A couple questions:
1. Is it possible to dump/load save states on your V1; would you consider that as a option on the V2 design?
2. Are new cases going to be a reality? Hate killing a cart for the case.
3. After reading through the V2 thread, the inclusion of a uC sounds great. Will it be usable for Exp Audio/Midi? There are allot of people that would like to see a new 'MidiNES' type cart.
Thanks again for your efforts, it really is great having a low cost second source for carts!
Yogi
Thanks for the kind words Yogi, here's answers to your questions.
1. If I understand you're question, you're asking if you can use the kazzo to load/dump save files to and from SRAM on the cart. That is independent of what version of my boards you're using. Both would support reading and writing to SRAM. The real question is whether the firmware of the dumper/programmer supports reading/writing to SRAM. The kazzo's original firmware already supports this to my knowledge. I haven't spent any time adding this feature to my version of the firmware, but have intent to soon.
2. Yes, I am in the process of getting cases. I'm officially pulling the trigger this week and cutting a check for the initial mold cost. I can't be 100% certain when I'll have cases available, but you can expect early next year. Details on this are still to come, but I can say I plan to be a cost effective option especially when paired with the purchase of a board.
3. There are lots of possible capabilities with the inclusion of a mcu on a cart. I've yet to actually start developing things beyond the PCB for this kind of capability. Sound is a goal I plan to develop myself. I don't have plans for MIDI, but it's a possibility that's more likely if developed by someone else.
Thanks for the reply, I went ahead and ordered last night, just too excited!
I been reading all I can find on the forums about the Kazzo and gathered that it could access the Bat backed ram; I guess I wasn't too clear with my thinking, it's not really a factor of the cart but the Kazzo. At any rate, looking forward to updates to your firmware/app, but it seems easy enough to upload the appreciate AVR firmware and use the orig app.
As to the V2/3, your ideas are great. As I mentioned before, there is allot of interest in a modern 'MidiNES' which your design would make a great platform. Will keep watching your progress.
Yogi
Yogi,
Using the original Kazzo board with the original firmware and client software, you could read and write SRAM on unmodified NES carts. Based on those reports, and the assumption that INL's programmer is 100% backwards-compatible with the Kazzo, you should be able to buy one of his programmers and boards and do the following:
1. Flash the programmer with INL-Retro firmware
2. Use the INL-Retro software (or the inlprog Linux utility) to flash the program and / or character ROM area(s)
3. Flash the programmer with Kazzo firmware
4. Use the Anago software (or the Linux port) to read or write the SRAM area
I will try to confirm this tonight if I have time.
qbradq wrote:
Yogi,
Using the original Kazzo board with the original firmware and client software, you could read and write SRAM on unmodified NES carts. Based on those reports, and the assumption that INL's programmer is 100% backwards-compatible with the Kazzo, you should be able to buy one of his programmers and boards and do the following:
1. Flash the programmer with INL-Retro firmware
2. Use the INL-Retro software (or the inlprog Linux utility) to flash the program and / or character ROM area(s)
3. Flash the programmer with Kazzo firmware
4. Use the Anago software (or the Linux port) to read or write the SRAM area
I will try to confirm this tonight if I have time.
Thanks for your help/testing, qbradq. I do remember seeing a post in this thread (? or may be the Kazzo one) that touched on writing Saves to WRam with Anago, but no how to. Last night I read the Anago readme, it shows an example of this; so I'm feeling sheepish, should have started there.
Having this ability on non-flash carts is HUGE for me, rechipping a SNROM with Neil B's NTRQ ATM.
Yogi
Right, so the Anago software that I ported does not have SRAM read function, and the Unagi software that does have that option is not finding the board. Not sure what's going on there, and I can't test it on Windows.
qbradq wrote:
Right, so the Anago software that I ported does not have SRAM read function, and the Unagi software that does have that option is not finding the board. Not sure what's going on there, and I can't test it on Windows.
I know I read it somewhere, may have been the Unagi readme. At this point I've been reading all I can find and getting a bit crossed eyed.
You're running Linux, right? I'm still holding onto XP for dev and such; so I'll be working it out when my stuff shows up, no biggie for now.
The bottom line is that the hardware is capable and the orig AVR firmware should be capable also. Not sure about the differences between Anago and Unagi, the latter being enhanced. Are they GUIs that use the same firmware, or are these two separate firmwares!?! Back to the downloaded zips to check this.
Thanks again qbradq
Yogi
EDIT: Ok so checked the packages for Anago and Unagi downloads, there two anago_en.txt readmes that are almost the same but only one mentions the ram saves, so may be in one but not in the other. Very confusing. Will have to install both and check them out I guess.
Unagi is the legacy software that supports a number of older parallel port programmers in addition to the Kazzo. Anago is a stripped-down version of Unagi that only supports Kazzo, but left out the SRAM function. The Kazzo firmware supports this, however.
Cool, thanks. Clears things up for me.
Yogi
My MMC1clone with state display, lol.
Looking good! Also very impressive that it plays DVDs, VCDs, and mp3s.
infiniteneslives wrote:
Looking good! Also very impressive that it plays DVDs, VCDs, and mp3s.
That's CTRL register status. :3
But using a DVD as a background, as in the old LaserDisc games and Beatmania IIDX, would be sort of cool in its own way. "Write to this register to select a chapter, then poll this register to synchronize with the frame number..." Even just an MP3 player interface would work as a poor man's MSU1 on any Famicom or audio-modded NES.
New (3rd) revision of the boards in today!
Nothing drastic changed, but there were a number of tweaks and improvements:
*Support for surface mount CHR-ROM flash (PLCC-32)
*Changed packages on chr-ram as I'm retiring the original soic-28 packaged SRAM
*Increased PRG-ROM flash to 1MB
*Increased WRAM from 32KB to 128KB
*Cut support for DIP WRAM to gain some space, I'm pretty sure it was never used by anyone on earlier revisions
*Added jumpers to support for color dreams, VRC family, and a stripped down nsf mapper
*Added jumpers to simplify assembly of MMC2/4 mappers so I can finally fully release these
*fixed multiple minor errors, silk, etc.
Nice! You caught my attention with NSF mapping and VRC support
I've been on a OPLL tear last few days (week), dropped a little money on EBay for a few YM2413s (prob clones but were very cheap to mess around with) mainly for adding FM to GameGear. But also interested in VRC7 sound; which brings me to a thread that may be old news here:
http://www.famicomworld.com/forum/index ... pic=8888.0Not that I am too interested in the FC Basic patch but the YM mod does seem cool.
So one thing leads to another:
1 Do you plan support for VRC7 sound? Verilog/VHDL IP core?
2 Could there be a config on the rev3 board somewhat like your Sunsoft 5B but with a YM2413 chip. CPLD doing the VRC7 mapping and interfacing to a YM chip. Just the proto space and mapper would be good too, I could mount the YM and mixer components, given access to the data and control pins.
I know there are issues/differences with the ROM instruments and channel count but it seems like the YM2413 would be somewhat backwards compatible, to a point. The other issue would be emu/tracker support, but I feel this is not too big of an issue.
With only one game ever using the VRC7 sound, the expanded audio from the YM chip would mainly affect new music titles. Seems like the chiptune community would welcome the added hardware sound for new compos, even if it's not 'authentic' Nintendo.
Yogi
VRC7 is a little problematic, since the VRC7 has a custom patch set that is not shared by the YM2413. You can put a YM2143 on an NES board, but it wouldn't be great for a Lagrange Point repro. All of the tunes will sound at least a little off, some a lot.
It might be a fun board to play with, but you could put any popular FM chip on there, really. Why stick with the YM2413 specifically? Why not stick something better on there? OPL2? OPL3?
Another approach might be to try and replicate the digital logic and patches of the VRC7 with a CPLD but I imagine this would be difficult, since it is quite complex.
The VRC7 is well liked by a small portion of the chiptune community, especially since Famitracker supports it well. A few of us have played new tunes through a Lagrange Point cartridge now and then.
Forever ago, I bought a sound blaster clone card that had implemented the OPL2 in an 8051 clocked at 12MHz (≈ 500KIpS) with an 8 bit R-2R-4R-&c resistor DAC.
We should be able to reimplement the VRC7's synthesizer in a fast modern microcontroller just fine, especially given that the Lagrange Point code waits at least 6µs between writes. The original implementation uses two lookup tables ( log(sin(x)) and exp(x) ) and an adder, so it's not like a multiplier is needed.
Anyway, it doesn't make any sense to enshrine the YM2413 as an "officially allowed" wrong way for the VRC7 to sound.
rainwarrior wrote:
VRC7 is a little problematic, since the VRC7 has a custom patch set that is not shared by the YM2413. You can put a YM2143 on an NES board, but it wouldn't be great for a Lagrange Point repro. All of the tunes will sound at least a little off, some a lot.
It might be a fun board to play with, but you could put any popular FM chip on there, really. Why stick with the YM2413 specifically? Why not stick something better on there? OPL2? OPL3?
Another approach might be to try and replicate the digital logic and patches of the VRC7 with a CPLD but I imagine this would be difficult, since it is quite complex.
The VRC7 is well liked by a small portion of the chiptune community, especially since Famitracker supports it well. A few of us have played new tunes through a Lagrange Point cartridge now and then.
See your point but putting aside the only produced cart, LP, all other titles are 'new' compos, not that 'new' is bad but there isn't a huge repo lib to support. So for me, compatibility isn't too much of an issue. Yes it would be a new Expo SND board that is 'very similar' to VRC7, so it may not appeal to everyone.
The similarity to VRC7 would help ease the hardware side as well as the software. With an OPl2/3 there is the external dac as well as the more complex control/patch software. At least with the YM2413, the reg structure is the same; so the changes for tools supporting VRC7 to adding support for the OPLL should be slight. Of course the sonic possibilities are so much greater with an OPL, but it's hard to see the NES competing with AdLib Tracker ][ . For me, the YM2413 makes more sense on a small system, ala MSX.
I'd love to have a CPLD/FPGA VRC7 cart but till one is available this kind of hack could be very fun.
And OT, been enjoying your ref recordings Thank You!
Yogi
lidnariq wrote:
Forever ago, I bought a sound blaster clone card that had implemented the OPL2 in an 8051 clocked at 12MHz (≈ 500KIpS) with an 8 bit R-2R-4R-&c resistor DAC.
We should be able to reimplement the VRC7's synthesizer in a fast modern microcontroller just fine, especially given that the Lagrange Point code waits at least 6µs between writes. The original implementation uses two lookup tables ( log(sin(x)) and exp(x) ) and an adder, so it's not like a multiplier is needed.
Anyway, it doesn't make any sense to enshrine the YM2413 as an "officially allowed" wrong way for the VRC7 to sound.
I've been thinking along similar lines for awhile. Have seen/heard some amazing work on dsPICs over at electro-music.com. As well as this:
http://www.roninsynth.com/Which is a dsPIC synth shield for the Arduino, but the basic dsPIC hardware/firmware could be used.
Anyway I'm just looking for an easy fit, I feel like new synth HW should be developed on new platforms. For me, one could go all out trying to turn a NES into a Shruti synth, but would probably be better just making a better Shruti in the first place.
VRC7 seems to be a subset of the OPLL so it's not too alien and INL's board may be able to host it with minor effort. Just seems like a good fit ATM if there is mapper support.
Yogi
The thing is, once you start adding novel hardware—and yes, the YM2143 counts as novel hardware, even though it's similar to the VRC7—there's no reason to constrain what you add at all. Maybe it's a VRC7 clone ... that only outputs 50% duty square waves. Or maybe it's a VRC7 clone ... that actually is an OPL3. Or maybe it's a TV tuner that does its best to convert its input to the NES's constrained palette.
Once enough people have a hardware "just kidding, it's not actually a VRC7" you'd have to add support for it in emulators. (There was a fuss made when FamiTracker updated its VRC7 patchset to newer, more accurate values.) And once you've added support for an arbitrarily new peripheral that was never used before, you may as well have aimed for something a bit more sophisticated. It's not like any of the sound synthesizer ICs ever manufactured are available as anything but Working Pull and New Old Stock anymore.
Anyway, asking the internet, a person who goes by fadis_ on twitter wrote an
FM library for the mbed (
youtube). Looks like it's only fast enough for 16 operators ... but the VRC7 should only need 12.
lidnariq wrote:
The thing is, once you start adding novel hardware—and yes, the YM2143 counts as novel hardware, even though it's similar to the VRC7—there's no reason to constrain what you add at all. Maybe it's a VRC7 clone ... that only outputs 50% duty square waves. Or maybe it's a VRC7 clone ... that actually is an OPL3. Or maybe it's a TV tuner that does its best to convert its input to the NES's constrained palette.
Point taken. I do enjoy the 'retro' HW but I also embrace a modding POV. These are the same currents within the Atari 8bit community, so I can appreciate the resistance to innovation. But I truly feel that the OPLL isn't too strange from a HW point. If no one else ever does this hack that is fine with me.
But most people will never have access to a Lagrange Point cart and the best we can hoped for is a clone or PowerPak emu. Of my options this seems like a good compromise.
Quote:
Once enough people have a hardware "just kidding, it's not actually a VRC7" you'd have to add support for it in emulators. (There was a fuss made when FamiTracker updated its VRC7 patchset to newer, more accurate values.) And once you've added support for an arbitrarily new peripheral that was never used before, you may as well have aimed for something a bit more sophisticated. It's not like any of the sound synthesizer ICs ever manufactured are available as anything but Working Pull and New Old Stock anymore.
Well, just seems to me that many of the commercially produced mappers fell into the "arbitrarily new peripheral that was never used before" catagory, back in the day.
True that a better, more advanced chip could be used, but where is the NES support for them (never mind that there are no 'new' synth/tone chips, just DACs and DSP). Would be starting from scratch; may be worth it in the long run. But with a YM hack there is already a lot of common ground. 'Similar' is fine for me ATM; I've plenty of long term projects (my MidiBoxFM needs some love).
Again if INL's V3 board can support a VRC7 mapper that can provide the necessary bus interface I would 'wire it up'. Sounds like a weekend project. But Hey if you know of a repo VRC7 board, point me to it
Quote:
Anyway, asking the internet, a person who goes by fadis_ on twitter wrote an
FM library for the mbed (
youtube). Looks like it's only fast enough for 16 operators ... but the VRC7 should only need 12.
That interesting, will have to look closer at it. I've been eyeing this for awhile:
https://sites.google.com/site/preenfm/homehttp://xhosxe.free.fr/PreenFM/PreenFMXavDemo.mp3Looks/sounds tasty!
Yogi
Quote:
never mind that there are no 'new' synth/tone chips, just DACs and DSP
With DSP synths, there's still a problem of how wide to make the interface. A pure sampler like the Super NES DSP produces static, muffled sounds compared to an actual synth that provides variable-controlled filters, but if a synth is too flexible, the 6502 might find it hard to keep the synth fed with commands while running game logic and animating the graphics.
tepples wrote:
Quote:
never mind that there are no 'new' synth/tone chips, just DACs and DSP
With DSP synths, there's still a problem of how wide to make the interface. A pure sampler like the Super NES DSP produces static, muffled sounds compared to an actual synth that provides variable-controlled filters, but if a synth is too flexible, the 6502 might find it hard to keep the synth fed with commands while running game logic and animating the graphics.
Good point but I really didn't want to suggest such a mod. I feel that sample/wavetable based synths are only viable on 16bit and above platforms that have far greater resources. You really need a very high clock rate and/or wide data path to get a clean sound or else a dedicated co-processor to handle the bandwidth; so one would end up with a ARM synth that masquerades as a NES. For 8b systems, you really only have a choice of outdated PSG/FM chips; all of which are discontinued/obsolete.
As you point out with the SNES, using the SPC700 (which is at heart a 8bit platform) is prone to issues. The Amiga was ground breaking due to it's Paula and eclipsed Atari's ST which still used the AY-3-8910 (a holdover from the 8bit era).
The Adlib card (OPL 2 8bit ISA) was a low cost competitor to the Roland MT-35 tone hardware that was sample based. The only reason the Adlib/Sound Blaster cards survived into the 16b ISA gen, was an established user base. Chip based FM faded quickly as DSPs improved.
WOW, just had my dinner and debated flushing all the above, it's so off topic. But what the hey
I wants me some FM
Yogi
yogi wrote:
These are the same currents within the Atari 8bit community, so I can appreciate the resistance to innovation. But I truly feel that the OPLL isn't too strange from a HW point. If no one else ever does this hack that is fine with me.
It's not even resistance to innovation. It's that ideas are cheap: if every idea anyone ever thought of had been implemented in an emulator somewhere we'd have long since run out of space in the entire NES2.0 16-bit space.
Quote:
Well, just seems to me that many of the commercially produced mappers fell into the "arbitrarily new peripheral that was never used before" catagory, back in the day.
So if you make a new game that uses it, go for it!
Quote:
But most people will never have access to a Lagrange Point cart and the best we can hoped for is a clone or PowerPak emu. Of my options this seems like a good compromise.
Millions of people got famiclones that have a bug where the 1/4 and 1/2 duty cycles were swapped. It's definitively wrong, yet that's what they grew up with and expect. It'd be nice to not further exacerbate that.
I'm not even saying "don't add a YM2413 to a NES"; I'm just saying "don't take steps to allow people to self-delude into thinking the VRC7 is sufficiently similar to a YM2413". About half of the instruments are similar; the rest only sound similar in the sense that they both sound like FM synthesizers. (
Bizhawk's source provides the current best guess (reverse engineered) lookup tables for both the YM2413 and VRC7. There are significant differences: immediately obvious to me are instruments 6, 13, and 15 with significant differences in their ADSR curves.)
Quote:
Would be starting from scratch; may be worth it in the long run. But with a YM hack there is already a lot of common ground. 'Similar' is fine for me ATM; I've plenty of long term projects (my MidiBoxFM needs some love).
The other really huge advantage of using the YM3812 (or a clone) is we know exactly how it works. There's no mystery parameters that have to be reverse-engineered laboriously by switching back and forth between two things with hidden parameters.
lidnariq wrote:
yogi wrote:
These are the same currents within the Atari 8bit community, so I can appreciate the resistance to innovation. But I truly feel that the OPLL isn't too strange from a HW point. If no one else ever does this hack that is fine with me.
It's not even resistance to innovation. It's that ideas are cheap: if every idea anyone ever thought of had been implemented in an emulator somewhere we'd have long since run out of space in the entire NES2.0 16-bit space.
Well, where is a VRC7 repo ; I'd buy one ASAP. Waiting for a 100% recreation to be created, seems more pie in the sky then a hack to add a simular FM chip. I really don't want to make waves but every repo board takes liberties with the original designs. I understand your concerns but I dislike the idea that we need to suppress hacks and mods to preserve an emu standard. The authors of the emus will decide if they want to support an extension based on how popular it is; so if I'm the only one interested then I wouldn't expect anyone to support it, no sweat. I'm not demanding anything of anyone.
Quote:
Quote:
Well, just seems to me that many of the commercially produced mappers fell into the "arbitrarily new peripheral that was never used before" catagory, back in the day.
So if you make a new game that uses it, go for it!
Hum I guess I really touched a nerve, I apologize if this is the case. Was just trying to point out everything is new once.
More then once INL had posted that he is open to unique mappers and changes. If he has or will have a VRC7 mem mapper VHDL IP but lacks the on board/CPLD resources to include the FM, this could be a one off option that I would be interest in. Doesn't seem to need any change to the boards layout, but I could be wrong.
Quote:
Quote:
But most people will never have access to a Lagrange Point cart and the best we can hoped for is a clone or PowerPak emu. Of my options this seems like a good compromise.
Millions of people got famiclones that have a bug where the 1/4 and 1/2 duty cycles were swapped. It's definitively wrong, yet that's what they grew up with and expect. It'd be nice to not further exacerbate that.
I'm not even saying "don't add a YM2413 to a NES"; I'm just saying "don't take steps to allow people to self-delude into thinking the VRC7 is sufficiently similar to a YM2413". About half of the instruments are similar; the rest only sound similar in the sense that they both sound like FM synthesizers. (
Bizhawk's source provides the current best guess (reverse engineered) lookup tables for both the YM2413 and VRC7. There are significant differences: immediately obvious to me are instruments 6, 13, and 15 with significant differences in their ADSR curves.)
Never said it's a direct replacement, only that it shares the same structure on a HW level so it would work to some degree with the existing tools and mapper. Even though there is support within FamiTracker for VRC7, few will be able to hear their compos on true HW. Nothing would change with that, but if they wanted to compose for a similar chip there could be an HW option.
This chip is well documented and the Yamaha pubs are on the net, so it's better known than the VRC7 FM. You must know this chip was used in the Sega Master Sys (JP release), the MSX computer as well as quite a few Yamaha keyboards. Maybe not the best there ever was but not a total unknown.
Quote:
Quote:
Would be starting from scratch; may be worth it in the long run. But with a YM hack there is already a lot of common ground. 'Similar' is fine for me ATM; I've plenty of long term projects (my MidiBoxFM needs some love).
The other really huge advantage of using the YM3812 (or a clone) is we know exactly how it works. There's no mystery parameters that have to be reverse-engineered laboriously by switching back and forth between two things with hidden parameters.
Well, the OPL2 is much harder to source, requires the specialized DAC (bi-polar power) and is far more complex to control. We are talking about a 6502, so I have doubts.
With the OPL2, you have just added the need for instrument patch storage in your rom along with the overhead of running the chip; it's far more complex than a PSG. It would be forever before we would see FamiTracker support the OPL2 and it's multiple settings, might as well come up with a Adlib Tracker fork that outputs NSFs.
The whole reason the OPLL was limited by design was to accommodate these simpler systems that have fewer resources.
But look, if someone has a better option I'm open to it. I know there are better chips but with them one needs a better system.
Yogi
ROMs using just the 2A03 PSG already have to store duty, volume, and pitch envelope data for instruments. A table of FM parameters for a 2-op FM chip wouldn't be that much bigger.
Don't forget that besides the different patches, VRC7 is also only a subset of YM2413. If you really wanted Famitracker to support the YM2413 you should also add 3 more channels and the option to use the percussion mode. I still think if you're going to do this you should go with something better, like at least an OPL2.
Also, for what it's worth, there's a second reason you won't see a Lagrange Point repro besides the difficulty of reproducing the audio. The original cartridge is neither rare, nor particularly expensive. They sell regularly on eBay for less than US$40.
I appreciate the discussion on this subject everyone. I don't consider it off topic in the slightest since I had actually already had thoughts of incorporating a FM synth on this board. I can't say it's the highest priority on my project list, but it is indeed something I'd like to do with this design.
I'm really not that well versed in the history and variety of these chips, so I appreciate the mini history/tech lesson today.
By all means keep the discussion going!
My thoughts prior to today:
"hey I wonder if I can rig up a YM2413 on this board to operate similarly to the VRC7 with the
known differences." Speaking of, is there a typo on the wiki? "YM2413 OPLL, which is itself a cost-reduced version of the
YM3182 OPL2"
My goal of putting a FM synth on the board wouldn't be to make repros of a Japanese only game that was only partially translated, but never released. The japanese version is plenty available IMO. I'd guess I've got about a 70% chance of fitting all the logic required for a makeshift VRC-7 hack that'd play LP anyway. So it'd be directed for new material specifically composed to run on my board if there were ever to be such a person.
I actually went out and bought a copy of LP for any RE/testing needs for the interface and a couple YM2413 chips off ebay for a couple bucks. I haven't gotten much further than popping open the damn no screw famicom case to take a gander at the board and listen to the FM goodness on my FC.
Fast forward today, something like a year later:
We appear to have found at least one guy who'd like to compose something for such a board config.
I like the idea of not restricting a FM synth on the board to being similar to the VRC7. I had never actually considered the YM3812 (OPL2), the idea of being free to design the interface myself in which ever way makes it simplest in hardware requirements. The VRC7 method of interfacing with a YM2413 (OPLL) does seem a little cumbersome. But perhaps putting a DAC on a OPL2 is more of a pain.
While there are differences, they are very compatible in the operational sense. I'd imagine tracker/emu maintainers would rather get requests to add support for a variant of something that's already supported. Seems better than asking to support something completely homebrewed and lacks anything similar except a few boards I put together. But I'd guess there are more non-NES trackers that support the OPL2 compared to the OPLL. So if one had already decided to go with a non-NES tracker expecting to convert their tracks to the NES, perhaps there is more OPL2 tracker support.
The question is really boils down to in my position is what are people more likely to actually use. I'm not concerned with sheltering people from being deluded. That said, I think there's room for both options on this board. I'd love to offer both options, the more restrictive item for me at this point is development time. I had planned to start with the VRC I, and work my way up. I coded up the VRC I over a lunch break, the first test was a fail, and I haven't picked it up since. At this point I'm more motivated to put something together that has a planned user such as Yogi. I'll put the OPL2 down on the list as a fun project though. Perhaps it could be a good fit for the parallel-MMC1 design I have in mind which would fit on a 36Mcell CPLD. Having a good homebrew mapper to go hand-in-hand with the OPL2 would help motivate tracker/emu authors to support the mapper as a whole, and the sound extension could be optional.
The best sound option I see is utilizing a mcu as a synth, mainly for cost and availability reasons. That and the mcu could serve other non-sound purposes. But that requires even more development, but it is on the TODO list.
Creating an interface for an OPL vice the entire OPL is more reasonable for the nearer future and a good starting point.
yogi wrote:
Well, the OPL2 is much harder to source, requires the specialized DAC (bi-polar power) and is far more complex to control.
How is the OPL2 harder to source? I'm just going by ebay, the seem equally available and equally priced.
Does it really require a specialized DAC and bi-polar power? While it does need a DAC, does it really need to be a special bi-polar one? I'm guessing you're saying the YM3014 is the most reasonable DAC for the OPL2?
Is the OPL2 really that much harder to control? Sure it has more registers and waveforms. But if you want to restrict your use of the OPL2 within the capabilities of the OPLL wouldn't the control be comparable? I guess the instruments can be utilized more so to keep things simpler to control.
IMO, a DAC of any sort not being needed with the YM2413 is pretty decent incentive alone. Admittedly, I'm not looking much past the end of my nose with that statement.
In conclusion, my primary goal of all that perf area was for synth experimentation. I'm more than willing to provide bare boards to anyone who doesn't want to wait around for me to devote development time to this. So everyone is welcome to pick up their favorite synth choice and get to work!
tepples wrote:
ROMs using just the 2A03 PSG already have to store duty, volume, and pitch envelope data for instruments. A table of FM parameters for a 2-op FM chip wouldn't be that much bigger.
Well from:
"Programming the AdLib/Sound Blaster"
http://bochs.sourceforge.net/techspec/adlib_sb.txtQuote:
The sound card possesses an array of two hundred forty-four registers....
Address Function
------- ----------------------------------------------------
01 Test LSI / Enable waveform control
02 Timer 1 data
03 Timer 2 data
04 Timer control flags
08 Speech synthesis mode / Keyboard split note select
20..35 Amp Mod / Vibrato / EG type / Key Scaling / Multiple
40..55 Key scaling level / Operator output level
60..75 Attack Rate / Decay Rate
80..95 Sustain Level / Release Rate
A0..A8 Frequency (low 8 bits)
B0..B8 Key On / Octave / Frequency (high 2 bits)
BD AM depth / Vibrato depth / Rhythm control
C0..C8 Feedback strength / Connection type
E0..F5 Wave Select
I think it's safe to say there is substantial overhead compared to a OPLL, in addition to the 2A03 apu.
@ rainwarrior
Yes kind of thinking the added channels are a plus but my main point is the fact that the YM shares the same register design with the VRC7 (or rather vise a versa) so some support already exists now.
Fitting any other chip would necessitate a far larger project IMO, not that it's impossible. For myself, a long term goal would be a Midi interface akin to Membler's boards (which I've already convo-ed with INL about not long ago).
Thanks for the heads up on LP carts, I'll look into them. Being a FC JP release only, discouraged me and like I had said earlier I have some YM2413s en-route for another project (really hoping they aren't junk/fake).
Yogi
yogi wrote:
Hum I guess I really touched a nerve, I apologize if this is the case. Was just trying to point out everything is new once.
Sorry! One can't convey tone on the internet... That was supposed to have been enthusiasm. I would love to see more completed original projects! I would be tickled pink to see more completed original projects that used new mappers. I would be quite amused by a ROM hack of Somari to the VRC7 that reintroduced the Megadrive's music (although necessarily lightly remixed to accommodate the instrument changes and reduction in number of voices ).
Quote:
This chip is well documented and the Yamaha pubs are on the net, so it's better known than the VRC7 FM. You must know this chip was used in the Sega Master Sys (JP release), the MSX computer as well as quite a few Yamaha keyboards. Maybe not the best there ever was but not a total unknown.
Sure, and if people want to write music that targets the YM2413, they can write VGMs that target the Mark 3. But if they're using MML or FamiTracker or whatnot, and they then go to play it back on a YM2413-containing cartridge instead of a VRC7, they'll be disappointed when the sounds are wrong.
Quote:
With the OPL2, you have just added the need for instrument patch storage in your rom along with the overhead of running the chip; it's far more complex than a PSG.
The original Ad Lib card came out in 1987, for the IBM AT and clones. While the 286 had more memory and was faster than the 2A03, hard drives were still moderately uncommon, so a game that fit on a 360K floppy is still comparable to a 256 KiB NES game. Anyway, loading eight bytes per instrument instead of one isn't really appreciably harder. (It's really the exact same as programming instrument 0 on the OPLL, just once for every channel)
Quote:
It would be forever before we would see FamiTracker support the OPL2 and it's multiple settings, might as well come up with a Adlib Tracker fork that outputs NSFs.
And why should FamiTracker support the OPLL instead? It's not like either was ever used during the FC's commercial life. If you want a general purpose retro softsynth, Deflemask and many other retro trackers are out there.
infiniteneslives wrote:
Does it really require a specialized DAC and bi-polar power? While it does need a DAC, does it really need to be a special bi-polar one? I'm guessing you're saying the YM3014 is the most reasonable DAC for the OPL2?
The native bitstream out of the OPL2 is a funny 16 bit word made of 3 bits of padding, 10 bits of mantissa, and 3 bits (actually 2.8, "0" is forbidden) of exponent. Converting this to a 16 bit I²S, S/PDIF, or even AC'97 encoding should be rather straightforward.
Anyway, the YM3014 is unipolar, Vsupply and ground. Its output is centered around Vsupply/2, so either a highpass or an opamp to center things is desirable.
lidnariq wrote:
Anyway, the YM3014 is unipolar, Vsupply and ground. Its output is centered around Vsupply/2, so either a highpass or an opamp to center things is desirable.
And costs nearly twice as much as the OPL2 itself based on the current ebay rates...
infiniteneslives wrote:
I appreciate the discussion on this subject everyone. I don't consider it off topic in the slightest since I had actually already had thoughts of incorporating a FM synth on this board. I can't say it's the highest priority on my project list, but it is indeed something I'd like to do with this design.
I'm really not that well versed in the history and variety of these chips, so I appreciate the mini history/tech lesson today.
By all means keep the discussion going!
My thoughts prior to today:
"hey I wonder if I can rig up a YM2413 on this board to operate similarly to the VRC7 with the
known differences." Speaking of, is there a typo on the wiki? "YM2413 OPLL, which is itself a cost-reduced version of the
YM3182 OPL2"
Yes the OPLL is derived from the OPL2 but is reduced in scope. the VRC7 is a slightly reduced OPLL. I think the interface/register design are the same between the OPLL and the VRC7. At least from my read of the wiki.
Quote:
My goal of putting a FM synth on the board wouldn't be to make repros of a Japanese only game that was only partially translated, but never released. The japanese version is plenty available IMO. I'd guess I've got about a 70% chance of fitting all the logic required for a makeshift VRC-7 hack that'd play LP anyway. So it'd be directed for new material specifically composed to run on my board if there were ever to be such a person.
I would be interested very much. Like I've said earlier, provided that there are data and control traces (I assume so for AY 3-8910 support) to the proto area it should be very workable with the YM2413, the need of the VRC 7 mapper is only to keep a slight compatibility with the tools that are in place.
Quote:
I actually went out and bought a copy of LP for any RE/testing needs for the interface and a couple YM2413 chips off ebay for a couple bucks. I haven't gotten much further than popping open the damn no screw famicom case to take a gander at the board and listen to the FM goodness on my FC.
Fast forward today, something like a year later:
We appear to have found at least one guy who'd like to compose something for such a board config.
Quote:
I like the idea of not restricting a FM synth on the board to being similar to the VRC7. I had never actually considered the YM3812 (OPL2), the idea of being free to design the interface myself in which ever way makes it simplest in hardware requirements. The VRC7 method of interfacing with a YM2413 (OPLL) does seem a little cumbersome. But perhaps putting a DAC on a OPL2 is more of a pain.
An alternate chip could be the YM2612 as used in the Sega Gen/Megadrive. It has a similar bus interface to the OPL2 but has an integrated DAC.
http://en.wikipedia.org/wiki/Yamaha_YM2612 6 channels and like the OPL2 would need an increased amount of PRG rom for patches. The Sega/VGM homebrew community has some info on developing for it also.
Quote:
While there are differences, they are very compatible in the operational sense. I'd imagine tracker/emu maintainers would rather get requests to add support for a variant of something that's already supported. Seems better than asking to support something completely homebrewed and lacks anything similar except a few boards I put together. But I'd guess there are more non-NES trackers that support the OPL2 compared to the OPLL. So if one had already decided to go with a non-NES tracker expecting to convert their tracks to the NES, perhaps there is more OPL2 tracker support.
The question is really boils down to in my position is what are people more likely to actually use. I'm not concerned with sheltering people from being deluded. That said, I think there's room for both options on this board. I'd love to offer both options, the more restrictive item for me at this point is development time. I had planned to start with the VRC I, and work my way up. I coded up the VRC I over a lunch break, the first test was a fail, and I haven't picked it up since. At this point I'm more motivated to put something together that has a planned user such as Yogi. I'll put the OPL2 down on the list as a fun project though. Perhaps it could be a good fit for the parallel-MMC1 design I have in mind which would fit on a 36Mcell CPLD. Having a good homebrew mapper to go hand-in-hand with the OPL2 would help motivate tracker/emu authors to support the mapper as a whole, and the sound extension could be optional.
Well I'm up for any and all. The advantage with the YM2413 is the relative NSF support in place for VRC7 that translate well. Both the OPL2 and the YM2612 (OPN2) offer emus that would aid with tool support. The OPL2 is the more complicated of these and the community is SoundBlaster centric, tool wise. So the transition to the reduced specs of the 6502 would restrict the effects that are common on dos trackers. This also applies to a lesser extent with the YM2612, but the Sega 16b platform is a bit closer to our goal so it may be a better fit.
Quote:
The best sound option I see is utilizing a mcu as a synth, mainly for cost and availability reasons. That and the mcu could serve other non-sound purposes. But that requires even more development, but it is on the TODO list.
Creating an interface for an OPL vice the entire OPL is more reasonable for the nearer future and a good starting point.
yogi wrote:
Well, the OPL2 is much harder to source, requires the specialized DAC (bi-polar power) and is far more complex to control.
How is the OPL2 harder to source? I'm just going by ebay, the seem equally available and equally priced.
Does it really require a specialized DAC and bi-polar power? While it does need a DAC, does it really need to be a special bi-polar one? I'm guessing you're saying the YM3014 is the most reasonable DAC for the OPL2?
Is the OPL2 really that much harder to control? Sure it has more registers and waveforms. But if you want to restrict your use of the OPL2 within the capabilities of the OPLL wouldn't the control be comparable? I guess the instruments can be utilized more so to keep things simpler to control.
As to Ebay, just took a quick look and you are correct. But the associated DAC, YM3014, may or may not be replaceable with a modern chip, just don't know. Seems to me the DAC for the OPL3 was a must have when I was sourcing parts for a MBFM.
Drawing from the MidiBoxFM OPL3 design, a bipolar opamp is used following the DAC. Can this be changed to unipolar, I'm sure, but at the expense of the audio likely. Just going by a proven design for the OPL3. R&D required here.
The complexity lies in the 244 registers compared to the far reduced set on the YM2413. The OPLL has a defined patch set as opposed to the OPL2 where every instrument needs to be loaded at runtime.
The YM2612 is also a complicated beast, but not as bad and offers more sonic options then the OPLL. Here is a example circuit from Wikipedia;
http://sue.niko.to/ps98/ym2612_sch.png Plus there is at least one member 'here' that has a lot of first hand programming experience with the YM2612/VGMM (cough*Shuri*cough).
I could be underestimating the capabilities of the 6502 but the MidiBox runs the PIC18F at 10mips and it is at it's limit with servicing the OPL3, UI and Midi coms.
Quote:
IMO, a DAC of any sort not being needed with the YM2413 is pretty decent incentive alone. Admittedly, I'm not looking much past the end of my nose with that statement.
In conclusion, my primary goal of all that perf area was for synth experimentation. I'm more than willing to provide bare boards to anyone who doesn't want to wait around for me to devote development time to this. So everyone is welcome to pick up their favorite synth choice and get to work!
Well I'm on board. I know I have a OPL2 SB board in my bone yard as well as the YM2413s coming so will start off with some testing.
Yogi
Instrument patches aren't really a significant burden on data size compared to pattern data. OPL2 wouldn't even create significantly more patch data, there's only about 1 more byte of data (extra waveform selection, and an output level control for the carrier). The 14 patches you get "for free" with the VRC7 are worth 112 bytes, if you're using all of them.
2A03 macros are much larger than VRC7 patches.
The cost difference between these chips isn't very significant when you're talking about a one-off. If you're going to make 50 of them it might start to matter, but we're not there yet. As lidnariq said, ideas are cheap.
Anyhow, you clearly like the YM2413. If you wanna get started with this, NSFPlay has an option in the .ini file to use YM2413 patches instead of the VRC7's, no hacking required (the extra channels or percussion mode would require some minor modifications though). Famitracker is easy to modify if you have a version of Visual Studio with MFC (Express versions don't come with this).
However, it's a lot less extra work than you might think to modify Famitracker to do OPL2 instead of VRC7, and I think you could get a lot out of that freedom from the one-patch restriction. The reason I keep suggesting it is that this is already a custom job, why not squeeze some more power in there while you're at it? (This is just my friendly opinion, though; obviously I don't have a stake in this if I'm not doing any of the work.)
That and a lot of those registers will be loaded with the same values. For example, three voices playing a piano sound will all use the piano parameters.
@ Ladnariq Glad we're 'Good'.
My main direction with the YM2413 was motivated by the similarity with VRC7 and the fact that INL had interest in a VRC repo board. Fitting a CPLD with the FM core is a task and in a hope to see a FM cart, this chip seemed the closest fit to the direction INL was going.
You are right that there can/would be Op Error and some confusion as to the two FM expansions using the same mapper but again one is a very close subset of the other. Just some reassigning of instrument names and adding support for the increased channel count, but I could be over simplifying things.
Quote:
so a game that fit on a 360K floppy is still comparable to a 256 KiB NES game
Point taken. But I will point to the 8bit ISA bus speed as a factor also. Don't remember the historic specs but 4-8MHz springs to mind, which is a factor of ~4-6 improvement in though-put compared to the NES.
How much this will impact things, can only guess. Just by my gut, seems like some of the signature sound of Adlib music will be lost to some extent.
Quote:
And why should FamiTracker support the OPLL instead? It's not like either was ever used during the FC's commercial life. If you want a general purpose retro softsynth, Deflemask and many other retro trackers are out there.
This I can't really agree with. If a tool supports VRC7 then it supports a sub set of the YM2413. In fact I'm guessing that some of the framework for VRC7 FM emus were adapted from existing YM2413 code (Konami was producing games on the MSX (YM2413 sound) before Nintendo). It's a far closer match than an OPL2 IMO. There's much to say about all the great softs out there but as good as their emus are, there is a 'need' to hear it on real silicon.
Good info on the DAC, there may be hope for a replacement. I'm just going by the similar OPL3 and the MBFM hardware design. Just seems like the Yamaha OPLs and DACs are a 'hand and glove' design
@ rainwarrior
In regards to
Quote:
instrument patches aren't really a significant burden on data size compared to pattern data. OPL2 wouldn't even create significantly more patch data, there's only about 1 more byte of data (extra waveform selection, and an output level control for the carrier). The 14 patches you get "for free" with the VRC7 are worth 112 bytes, if you're using all of them.
I'll take your judgement as well as Tepples' on this. It just seems that comparing the restricted OPLL to the OPL2 is difficult. The OPL2 is completely configurable where as the OPLL was, by design, minimized for ease of use. Or was it only cost savings? To me the OPLL looks more like it was trimmed to fit into the PSG model of sound production.
The OPLL saw far more use on smaller, slower systems where as the more complex chips were on faster machines, just cost? I don't know but I don't mind having several option in my 'stable'
Not married to the YM2413, just thought it fit better with an NES without major changes. But looks like there is interest and support for a really out of the box expansion. 'More FM for the World'
yogi wrote:
But I will point to the 8bit ISA bus speed as a factor also. Don't remember the historic specs but 4-8MHz springs to mind, which is a factor of ~4-6 improvement in though-put compared to the NES.
You fell for the MHz myth. The 6502 does much more in each cycle than an 8088 does; I direct you to any Spectrum vs. C64 flame war. On how many of those cycles is the PC actually transferring data?
Quote:
The OPL2 is completely configurable where as the OPLL was, by design, minimized for ease of use. Or was it only cost savings?
It might have been cost savings. Consider the APU in the 2A03: cost of ROM vs. RAM, no fine-grained period control for noise and DMC, no destination address for DMA, etc.
yogi wrote:
It just seems that comparing the restricted OPLL to the OPL2 is difficult. The OPL2 is completely configurable where as the OPLL was, by design, minimized for ease of use. Or was it only cost savings? To me the OPLL looks more like it was trimmed to fit into the PSG model of sound production.
Definitely cost savings; 1kbit of RAM is significantly more expensive than the corresponding 1kbit of ROM and 200 bits of RAM. Also, the integration of the substantially cheaper (multiplexing) DAC, rather than using an adder and a separate discrete one.
Honestly, the complexity of configuring a OPL2 voice is equivalent to configuring the OPLL's custom patch (registers 0-7) and the channel configuration registers (0x10, 0x20, 0x30). Then duplicate that once for each of the 9 channels in the OPL2.
Also, on most frames you don't need to configure anything. The tendancy is to use the same patch on a single channel for lengthy stretches. CPU usage for controlling FM chips under typical usage is far less than the with the macro-driven approach typical for 2A03 where every frame requires an update.
Yogi, the VRC7 code in Famitracker (and several other things that support VRC7) is a commonly available YM2413 emulation written by Mitsutaka Okazaki in 2001, simply with the custom patch set put in. It's not custom written for Famitracker at all, just a drop-in solution, really. This is why it'd actually be pretty easy to drop-in an OPL2 emulator in its place. Not a lot of code is needed to interface with this kinda thing, just a few lines to initialize and recieve the emulated sound, and another few lines to map the 2A03 CPU writes to the registers of the OPL emulation.
infiniteneslives wrote:
The VRC7 method of interfacing with a YM2413 (OPLL) does seem a little cumbersome.
Well I think I only really looked at the vrc7 audio wiki to come to that conclusion. Looking over things again, it's uber simple to configure the CPLD to interface with the OPLL. The only real difference in the interface comapared to the VRC7 would be the wait. You wouldn't have the wait restriction with my implementation, writes could be back to back successive.
It's literally just one logic function:
Code:
If CPU A14-12==0b001 & PRG/CE==0 & PRGR/W==0 & CPU A4==1
Take OPLL pins /CS and /WE low
else
Take em high.
The A0 pin would get connected directly to CPU A5 and that's pretty much it.
Just need a good solution for mixing the melody and rhythm together, perhaps the same mixing circuit I have for the AY-3-8910 would suffice?
I'd probably interface the OP2 the same way and tie the /RD pin high. One other support peice the OP2 needs in comparison to the OPLL besides a DAC is an input clock, but that's not a big deal. The OP2 also has the benefit of /IRQ generation which might be handy.
FWIW I picked up a few YM3812's and YM3014's for playing around with as well.
The best platform/mapper for this I don't feel is something like a VRC7. Afterall we're not after the PRG/CHR bankswitching or counter. Just the sound for the purposes of this right now. In that light I'd say it better belongs on my stripped down NSF mapper. The VRC7's port choice of $9010/9030 is convenient in the fact that it doesn't conflict with many other common mapper ports. So with this you could fairly easily tack on any OP to any common mapper if you really wanted to.
This setup on the NSF mapper wouldn't be a VRC7 variant. It'd just be an extension of the NSF mapper which currently doesn't have definitions for the OPLL or OPL2. It just uses the same port locations because it's convenient. So that might make some people happy as well. You pick and define your OP, the port definitions are the same.
tepples wrote:
You fell for the MHz myth. The 6502 does much more in each cycle than an 8088 does; I direct you to any Spectrum vs. C64 flame war. On how many of those cycles is the PC actually transferring data?
I guess a lot of my concerns stem from my background with the Atari 800. 6502 processing is effectively within the VBlank period and halted during GITA access. Not a problem on the NES if I understand.
Lidnariq wrote:
Definitely cost savings; 1kbit of RAM is significantly more expensive than the corresponding 1kbit of ROM and 200 bits of RAM. Also, the integration of the substantially cheaper (multiplexing) DAC, rather than using an adder and a separate discrete one.
All good points; I'm sure I've glossed over a lot of factors and money usually trumps other concerns in business.
Lidnariq wrote:
Honestly, the complexity of configuring a OPL2 voice is equivalent to configuring the OPLL's custom patch (registers 0-7) and the channel configuration registers (0x10, 0x20, 0x30). Then duplicate that once for each of the 9 channels in the OPL2.
rainwarrior wrote:
Also, on most frames you don't need to configure anything. The tendancy is to use the same patch on a single channel for lengthy stretches. CPU usage for controlling FM chips under typical usage is far less than the with the macro-driven approach typical for 2A03 where every frame requires an update.
Well, I'll bow to your collective opinion. I don't necessarily love the OPLL (I've been a sucker for OPL3 music for a long time) and if you all feel an OPL2 wouldn't be a dog, cool.
What are your feelings with the YM2612, Sega Gen FM? 6 voices vs the 9 on the OPL2. Build in DAC, some homebrew tools & Sega community development. Seems same price on Ebay, $3-$10 and would eat less board space. Thought?
Yogi
@infiniteneslives Don't know if you need any of this?
Here is an Arduino shield w/YM2413 that may assist with the output mixing
http://htlab.net/products/electronics/ym2413-shield-1/and
http://htlab.net/wp-content/uploads/201 ... er_1.0.pdfLooks like a basic opamp mixer. Using a quad but could just as well use a dual opamp.
As well as this
http://etim.net.au/smsfm/smsfm.htmlMaster system FM mod
yogi wrote:
@infiniteneslives Don't know if you need any of this?
Thanks, this does help out.
Quote:
http://htlab.net/wp-content/uploads/2012/12/YM2413_Shield_Ver_1.0.pdf Looks like a basic opamp mixer. Using a quad but could just as well use a dual opamp.
Looks like they did do the mixing with resistors similar to how I was thinking, and a coupling capacitor into the amp stage. Correct me if I'm wrong, but those opamps don't have much todo with mixing, they're solely amplifying. Assuming the output strength of the OPL's is comparable to the YM2149, they will need some amplification though.
Quote:
What are your feelings with the YM2612, Sega Gen FM? 6 voices vs the 9 on the OPL2. Build in DAC, some homebrew tools & Sega community development. Seems same price on Ebay, $3-$10 and would eat less board space. Thought?
Well considering things in the scope of a NSF board, and not some variant of the VRC7 mapper, I think there's room for pretty much anything of this sort.
Quote:
One other support peice the OP2 needs in comparison to the OPLL besides a DAC is an input clock, but that's not a big deal.
This isn't exactly accurate. The YM2413 has a built in oscillator, so it only needs an external crystal. The OPL2 and YM2612 need an external oscillator. Sourcing the exact xtal for the OPLL was no prob. I found what I believe is close enough to exact for the OPL2 with 3.579545Mhz. Finding a 7.67Mhz oscillator for the YM2612 on the other hand... Best I can do with digikey is a 7.5Mhz with a lead date of Apr-22nd, and it running w/3.3v supply...
Having just dealt with sourcing the components for everything the OPLL is the clear winner of the three in this front. They're all pretty comparable on ebay for the actual chip.
YM2412: readily available xtal, No DAC, op needs mixed if you want the rhythm.
YM3812: readily available oscillator, needs external DAC YM3014 or similar (costs more than synth), no mixing needed.
YM2612: oscillator hard to find, No DAC, needs mixed if you want left and right channels together.
I didn't bother acquiring the YM2612 like I did the other two, mostly due to not wanting to deal with the oscillator issues. Maybe I'll consider it come April.. The YM3812 isn't too bad really, it is a little more expensive, but the added cost also buys more capability.
Is it possible to create a phase locked loop or something that multiplies M2 by 2 to get 3.58 MHz or by 4 to get 7.16 MHz?
infiniteneslives wrote:
Finding a 7.67Mhz oscillator for the YM2612 on the other hand... Best I can do with digikey is a 7.5Mhz with a lead date of Apr-22nd, and it running w/3.3v supply...
Apparently the 7.67MHz of the Genesis is supposed to be NTSC×15÷7. (bluh). Obviously a PLL could be used, but that would hurt.
You can get 15.36MHz xtals pretty easily, and apparently US patent #4980655 (long expired) details a method for using a 74HC74 to both drive a crystal and divide its output by 2. That gets you to within 2 cents of correct, too. And it looks like the 74HC74 shouldn't have any problems at those frequencies.
(Unfortunately, the 74'4060, almost explicitly designed for this task, doesn't have a divider output smaller than ÷16)
Quote:
YM3812: readily available oscillator, needs external DAC YM3014 or similar (costs more than synth), no mixing needed.
Hm. The complexity of translating the bitstream to ordinary I²S is definitely within the range of the least CPLD, if not just a microcontroller. And the cheapest I²S DAC I can find is also about a dollar.
Then again, new old stock or working pulls of the YMF262 (OPL3) are also about the same cost as the YM3812 on ebay, and
its DAC looks to be usually cheaper than the OPL3.
infiniteneslives wrote:
Thanks, this does help out.
well I've been searching and have some links for OPL2 designs also.
A DIY Adlib card
http://www.malinov.com/Home/sergeys-pro ... -opl2-cardA midi synth
http://kikyoya.files.wordpress.com/2013 ... =465&h=303The C64 Sound Expander
http://kikyoya.files.wordpress.com/2013 ... =465&h=303Yamaha Datasheets attached
Quote:
Looks like they did do the mixing with resistors similar to how I was thinking, and a coupling capacitor into the amp stage. Correct me if I'm wrong, but those opamps don't have much todo with mixing, they're solely amplifying. Assuming the output strength of the OPL's is comparable to the YM2149, they will need some amplification though.
The RCs on each pin are low pass filters, just prior to the mixing Rs. The first stage is summing for the mix and the second is a buffer. Must have the summing for the mix and isolation; could may be do without the buffer amp but there isn't much point, not saving any pins with a single opamp package.
Quote:
The OPL2 and YM2612 need an external oscillator. Sourcing the exact xtal for the OPLL was no prob. I found what I believe is close enough to exact for the OPL2 with 3.579545Mhz. Finding a 7.67Mhz oscillator for the YM2612 on the other hand... Best I can do with digikey is a 7.5Mhz with a lead date of Apr-22nd, and it running w/3.3v supply...
If there's room, could build a xtal osc with a Schmidt Trig inverted, but it adds a 14p package. I'll look into this.
An added note for the OPL2, it needs a buffer amp on the DAC's output and another amp for the DAC's sample/hold section as per the DS.
Quote:
Having just dealt with sourcing the components for everything the OPLL is the clear winner of the three in this front. They're all pretty comparable on ebay for the actual chip.
YM2412: readily available xtal, No DAC, op needs mixed if you want the rhythm.
YM3812: readily available oscillator, needs external DAC YM3014 or similar (costs more than synth), no mixing needed.
YM2612: oscillator hard to find, No DAC, needs mixed if you want left and right channels together.
I didn't bother acquiring the YM2612 like I did the other two, mostly due to not wanting to deal with the oscillator issues. Maybe I'll consider it come April.. The YM3812 isn't too bad really, it is a little more expensive, but the added cost also buys more capability.
Another option for OPL2 parts could be finding a SB or SB2 card at a good price. If snagged at $10 that would be comparable to the HK chips, and no worries about clones/fakes, just have to be concerned with IF IT WORKS
(so may be it's the same as the HK chips?!?!)
Yea, If you want to drop the 2612 that's cool, I'm feeling much better about the OPL2. I ran across the C64 Sound Expansion; uses a OPL (1) and the favored mod was to drop in a OPL2. So, for me, it's kind of a proof of concept 6502 wise. This was the first application I've seen using the OPL2 on a 8bitter, I guess the cost was the main stumbling block BITD.
Thanks for your great work,
Yogi
tepples wrote:
Is it possible to create a phase locked loop or something that multiplies M2 by 2 to get 3.58 MHz or by 4 to get 7.16 MHz?
This is a bit of a tangent, but it should be able to devise a simple multiplying PLL using a 74HC4046 (VCO will PLL) and a divider of some sort (e.g. 74HC4059, 74'393, &c). The original CD4046 isn't very useful: it's only viable up to 1.5-2MHz. But this later 74 series version of it claims to be good for up to 17MHz.
Fixed odd multiples are more easily done using an LC tank and a few inverters.
Anyway, 2×NTSC colorburst is 14/15 of the Genesis's nominal frequency, so things will be off by 120 cents.
All that means is that playback code will need an Amiga tuning table instead of the one for the Genesis. The NTSC and PAL Amiga computers have CPUs clocked at what amounts to four times M2 on the Famicom and Dendy respectively.
Attachment:
3_5MHz Pierce Osc.png [ 6.13 KiB | Viewed 3888 times ]
OK so here is a simple Pierce Osc @3.579545. My Xtal is 3579.454KHz
I used 4.7M instead of 1M @ R1
1.8K instead 2.2K @R2
C1=C2=22pf
and a 74hct14
One could delete the second inverter gate butit's nice as a buffer.
There is a ton of examples on the net but this was a help with the theroy
http://www.mpdigest.com/issue/articles/ ... efault.aspStarted up first try; DMM reading 3.581MHz but I couldn't put it on a scope to test further
Yogi
lidnariq wrote:
You can get 15.36MHz xtals pretty easily, and apparently US patent #4980655 (long expired) details a method for using a 74HC74 to both drive a crystal and divide its output by 2. That gets you to within 2 cents of correct, too. And it looks like the 74HC74 shouldn't have any problems at those frequencies.
Good call, do you have a link to it? Search on Patent Office site only turns up an Expiration notice.
Depending on the costs could just use a xtal osc can into the FF also (so a quick search is not promising for can osc). About the same board real estate.
Yogi
google provides this link from the image in the patent:
http://patentimages.storage.googleapis. ... 0655-1.pngThe patent looks like it expired in 2003 due to failure to pay maintenance fees. It should have expired in 2007 regardless.
The 74HC74 datasheet indicates two separate inverters in its truth table:
Code:
Input Output
/SD /RD Q /Q
L H H L
H L L H
L L H H
The claims look to narrow enough that with that we should be able (were it necessary) to make a "technically doesn't do what the patent specifies" by using the other inverter inside the first flipflop.
- Tie Z1A CP and D high
- Tie Z1A /R low
- Move the crystal-resistor-capacitor blob to between Z1A /S and Z1A Q
- Tie Z1B CP to Z1A Q instead.
If I had a 74HC74 lying around I'd try both, to double-check and make sure it worked at higher frequency crystals.
lidnariq wrote:
google provides this link from the image in the patent:
http://patentimages.storage.googleapis. ... 0655-1.pngThe patent looks like it expired in 2003 due to failure to pay maintenance fees. It should have expired in 2007 regardless.
The 74HC74 datasheet indicates two separate inverters in its truth table:
Code:
Input Output
/SD /RD Q /Q
L H H L
H L L H
L L H H
The claims look to narrow enough that with that we should be able (were it necessary) to make a "technically doesn't do what the patent specifies" by using the other inverter inside the first flipflop.
- Tie Z1A CP and D high
- Tie Z1A /R low
- Move the crystal-resistor-capacitor blob to between Z1A /S and Z1A Q
- Tie Z1B CP to Z1A Q instead.
If I had a 74HC74 lying around I'd try both, to double-check and make sure it worked at higher frequency crystals.
Thanks, Very cool. Will knock it together in abit. Will have to use what ever xtal val I have on hand to test, sure I have a 16MHz ( AVR/Arduino stuff). Same ball park
Any thoughts on the feedback R, I'm guessing something around 1M?
Yogi
1M is as good of a guess as any. The 74HC74 as used here is equivalent to three CMOS inverters in series, whatever impact that'll have...
lidnariq wrote:
Quote:
YM3812: readily available oscillator, needs external DAC YM3014 or similar (costs more than synth), no mixing needed.
Hm. The complexity of translating the bitstream to ordinary I²S is definitely within the range of the least CPLD, if not just a microcontroller. And the cheapest I²S DAC I can find is also about a dollar.
I²S? or I²C? Granted I didn't look too hard, but digikey turned up a I²S DAC for $1.50, and I²C for ~$0.60. IDK the thought of utlizing a CPLD/mcu for DAC feels like overkill. I know it's really not when you just look at price, but when you consider you could put a synth in the mcu instead it just feels wrong to use a mcu just for that.
The benefits I see of using the yamaha line including the DAC is it's more turn key development. That and it's standardized to some degree. The components aren't new, but they're reasonably sourced. Additionally I can always leave the sourcing/choice of the specific OPL and DAC to the user to assemble themselves. In reality I don't think and of this is going to end up in volume production anyways. The real motivation for this right now is just to get a FM synth in the hands of guys like yogi without hacking up a famicom cart.
Quote:
Then again, new old stock or working pulls of the YMF262 (OPL3) are also about the same cost as the YM3812 on ebay, and its DAC looks to be usually cheaper than the OPL3.
This combo does seem like a better solution compared to the OPL2 and YM3014 depending on goals. Making a shield for them to be soldered onto as one unit would be a neat way to keep em socketed too. I could make the shield pin compatible with the ay-3-8910 which is already wired up, probably throw an opamp and discretes on there all together too.
infiniteneslives wrote:
lidnariq wrote:
Quote:
YM3812: readily available oscillator, needs external DAC YM3014 or similar (costs more than synth), no mixing needed.
Hm. The complexity of translating the bitstream to ordinary I²S is definitely within the range of the least CPLD, if not just a microcontroller. And the cheapest I²S DAC I can find is also about a dollar.
I²S? or I²C? Granted I didn't look too hard, but digikey turned up a I²S DAC for $1.50, and I²C for ~$0.60. IDK the thought of utlizing a CPLD/mcu for DAC feels like overkill. I know it's really not when you just look at price, but when you consider you could put a synth in the mcu instead it just feels wrong to use a mcu just for that.
The benefits I see of using the yamaha line including the DAC is it's more turn key development. That and it's standardized to some degree. The components aren't new, but they're reasonably sourced. Additionally I can always leave the sourcing/choice of the specific OPL and DAC to the user to assemble themselves. In reality I don't think and of this is going to end up in volume production anyways. The real motivation for this right now is just to get a FM synth in the hands of guys like yogi without hacking up a famicom cart.
For the scope of what we're discussing, the added cost of an 'all Yamaha' solution seems worth it for a simpler design. The R&D to adapt a modern DAC does not seem trivial and I'm afraid it would really add to feature creep. Not that it's unobtainable, it just looks like a minefield of unknown issues to overcome when there is already a growing todo list
Quote:
Quote:
Then again, new old stock or working pulls of the YMF262 (OPL3) are also about the same cost as the YM3812 on ebay, and its DAC looks to be usually cheaper than the OPL3.
This combo does seem like a better solution compared to the OPL2 and YM3014 depending on goals. Making a shield for them to be soldered onto as one unit would be a neat way to keep em socketed too. I could make the shield pin compatible with the ay-3-8910 which is already wired up, probably throw an opamp and discretes on there all together too.
Very interesting idea, I like it. If the OPL3 is an option on the table, for prototyping I might recommend the MBFM board. It's available through SmashTV's shop at $8.
http://www.midibox-shop.com/buy.htmlIt's far too large to be viable within an NES cart but for proof of concept and dev it could help?
If you do develop a OPL3 shield, going all SMT would shrink it quite a bit even though that would complicate DIY building. I've had good results hand soldering down to 0805 parts if the layout isn't too tight, so I would be up for a bare board. But I'm sure many would need/like a prebuilt option. Which of course leads back to the demand of an inventory of parts and sourcing issues.
Just gotta say the interest and support in this effort is really great from everyone! Even the OPLL expansion would be of major interest to a number of chiptune musicians; an OPL2/3 or OPN2 board might cause riots in the streets!
Yogi
lidnariq wrote:
google provides this link from the image in the patent:
http://patentimages.storage.googleapis. ... 0655-1.pngThe patent looks like it expired in 2003 due to failure to pay maintenance fees. It should have expired in 2007 regardless.
Well good news and bad news.
First: I'm using HCT74s, R=1M, C=22pF
The first tests I've run are on solderless proto boards so there is a lot of stray C, but with a 2MHz xtal the Osc side does start up fine. The only way I can couple to the /2 FF is by running the /Q output through a HCT14 inverter gate. Also, with the osc running I can see the 2MHz signal at the /Q - Xtal node but not at the Q output; I thought that this should be oscillating also, due to the /Q-Reset oscillations, strange.
If I directly couple the output to the CP input of the /2 stage, as per the patent doc, I see the 2MHz signal at it's outputs with no division. Inputting a higher drive level signal (my 3.58MHz HCT14 osc) to the divider works fine.
Moving on to a 8MHz and then a 16MHz xtal worked as per above (had to set up a second HCT 74 as a /4 prescaler; my DMM F counter tops out at 4MHz.) So it seems to work in this 2chip solution but would be nice to have only 1 chip.
So I will be trying to adjust the feedback R values to get better drive out of the osc and eliminate the HCT 14 gate.
Yogi
EDIT
YEA! After doing a better search and reading the Patent, I got a little better understanding of the operation.
Quote:
The resistance of R1 and the capacitance of C1 are selected such that the time constant R1C1 is much longer than the time for one half cycle of the crystal's resonant frequency.
This is somewhat flexible from my tests , the patent circuit ran with a verity of 14 through 16 MHz xtals; using the combo of C=370pF and R=10M. A NOT gate was
not needed!
yogi wrote:
The only way I can couple to the /2 FF is by running the /Q output through a HCT14 inverter gate.
[…]
If I directly couple the output to the CP input of the /2 stage, as per the patent doc, I see the 2MHz signal at its outputs with no division. Inputting a higher drive level signal (my 3.58MHz HCT14 osc) to the divider works fine.
Hm. What kind of voltage swing are you seeing on /Q?
The only guess I have is maybe HCT voltage thresholds are inappropriate for cascading here, so this might only work with 74HC or 74AC gates. The datasheet seems to indicate a schmidt trigger input on the clock lines, though, so I'm not clear why the separate schmidt trigger inverter would work while the integrated one wouldn't.
I was going to initially suspect loading, and suggest replacing the '14 buffer with a large resistor ... but that would have stopped the oscillator, not the ÷2.
You might also be able to use a large resistor divider to move the center voltage of oscillation ... but that won't help if the amplitude is too low.
Quote:
Also, with the osc running I can see the 2MHz signal at the /Q - Xtal node but not at the Q output; I thought that this should be oscillating also, due to the /Q-Reset oscillations, strange.
Unfortunately when using the half of the 7474 as an oscillator we don't get SR latch behavior anymore: Q (per the truth table above) will remain high.
Quote:
So it seems to work in this 2chip solution but would be nice to have only 1 chip.
Bad comes to worse, we could use a 74'1G14. (It's as cheap as a single MOSFET anyway)
lidnariq wrote:
yogi wrote:
The only way I can couple to the /2 FF is by running the /Q output through a HCT14 inverter gate.
[…]
If I directly couple the output to the CP input of the /2 stage, as per the patent doc, I see the 2MHz signal at its outputs with no division. Inputting a higher drive level signal (my 3.58MHz HCT14 osc) to the divider works fine.
Hm. What kind of voltage swing are you seeing on /Q?
The only guess I have is maybe HCT voltage thresholds are inappropriate for cascading here, so this might only work with 74HC or 74AC gates. The datasheet seems to indicate a schmidt trigger input on the clock lines, though, so I'm not clear why the separate schmidt trigger inverter would work while the integrated one wouldn't.
I was going to initially suspect loading, and suggest replacing the '14 buffer with a large resistor ... but that would have stopped the oscillator, not the ÷2.
You might also be able to use a large resistor divider to move the center voltage of oscillation ... but that won't help if the amplitude is too low.
Quote:
Also, with the osc running I can see the 2MHz signal at the /Q - Xtal node but not at the Q output; I thought that this should be oscillating also, due to the /Q-Reset oscillations, strange.
Unfortunately when using the half of the 7474 as an oscillator we don't get SR latch behavior anymore: Q (per the truth table above) will remain high.
Quote:
So it seems to work in this 2chip solution but would be nice to have only 1 chip.
Bad comes to worse, we could use a 74'1G14. (It's as cheap as a single MOSFET anyway)
(I ninja-ed your post editing my last post above.)
Turned out it was a matter of the free running RC OSC needing to be lower; Increased my R to 10M and C to 370pF got the Xtal circuit running in the 16 MHz range
My values aren't optimized; just happy it's running.
On a side note, I located the Yamaha datasheet for the YM2608 (the parent of the YM2612; the same FM core). the Interesting thing I found is it's nom Master CLK is 8MHz, so I think Sega just under-clocked it, based on the chosen system clock. So, could use a standard 8 MHz can; but it may be better to maintain compatibility with Sega VGM values?
Yogi
yogi wrote:
Turned out it was a matter of the free running RC OSC needing to be lower; Increased my R to 10M and C to 370pF got the Xtal circuit running in the 16 MHz range
My values aren't optimized; just happy it's running.
Weird. The original frequency was already just 7kHz, I'm surprised dropping it to 40Hz helped things (as opposed to, say, simply reducing the strength of the bias resistor). Or maybe the extra capacitive load did something. That large of a capacitance should definitely drop the effective frequency of the crystal, though. (How do 22pF and 370pF compare to the parallel parasitic capacitance of the crystal?)
yogi wrote:
On a side note, I located the Yamaha datasheet for the YM2608 (the parent of the YM2612; the same FM core). the Interesting thing I found is it's nominal Master CLK is 8MHz, so I think Sega just under-clocked it, based on the chosen system clock. So, could use a standard 8 MHz can; but it may be better to maintain compatibility with Sega VGM values?
Hm. I wonder. Page 19 of the translated OPNA datasheet shows there's a selectable clock divider of 2,3, or 6 for the FM synth, but I'm not certain what else that changes. After all, the OPNA contains its own DAC, so there's no minimum clock speed to hold a serial bitstream. Anyway, when at a divider of 6 (claimed necessary for behavior above 4MHz), the output sample clock is Mclk/144. (Much like the OPL3's is Mclk/288, or the OPL2's is Mclk/72).
Beyonds changing the necessary tuning tables, this will also slightly affect ADSR rates, the timers, and the various free-running LFOs (e.g. "AMS" and "PMS"). Not certain exactly what they're using, since their rates don't seem to be tunable.
If we can extrapolate from the OPL3, the FM LFO is fixed at Sclk÷8192, and the AM LFO is fixed at Sclk÷13440. (MESS says these magic numbers are shared with the rest of the OPLx family, but who knows if that's true for the OPNx. Apparently the OPMx family can actually control the LFOs!)
----------------------
infiniteneslives wrote:
I²S? or I²C? Granted I didn't look too hard, but digikey turned up a I²S DAC for $1.50, and I²C for ~$0.60.
I²S. I²C can't maintain the necessary bandwidth (at least 2+3×9=29 bittimes per sample, so 1.4Mbit/s). But let's drop this, for the other reasons you laid out.
lidnariq wrote:
Then again, new old stock or working pulls of the YMF262 (OPL3) are also about the same cost as the YM3812 on ebay, and its DAC [YAC512] looks to be usually cheaper than the OPL3.
Gluing these two trains of though together, I thought I'd go ahead and compare the bitstreams we're talking about here:
YM3014 (OPL2 DAC) input format
- 16 clocks per sample (800kHz)
- monaural
- falling edge of word clock marks end of word
- three idle bit periods per word (650kbit/s)
- UNsigned, LITTLE endian, µ-law-like
YMF262 (OPL3) output format
- 18 clocks per sample (1.79MHz)
- two channels interleaved per data line, two data lines, nominally quadraphonic
- two word clock lines, falling edge marks end of word
- two idle bit periods per word (3.2Mbit/s)
- UNsigned, LITTLE endian, PCM
I²S stream
- any number of clocks per sample, but many receivers require at least 8
- two channels interleaved per data line
- word clock toggles on bit before end of word
- Signed, BIG endian
- Many DACs annoyingly require a clock input at 256 times the sample rate.
And one even bigger tangent: Since the OPL3 doesn't really support "useful" quadraphonics (each voice can either be mixed or skipped for each output channel), I thought it would be nifty to have controllable VCFs on the DACs' outputs, and downmix that all to mono. But a digitally controlled VCF should really be done all in DSP anyway, so that's really just a pipedream.
lidnariq wrote:
- Many DACs annoyingly require a clock input at 256 times the sample rate.
I wonder whether that has anything to do with using a narrower (or even 1-bit) DAC and dithering to push the quantization noise into ultrasound. This is, for example, why SACD uses a sample rate of 64*CD.
tepples wrote:
lidnariq wrote:
- Many DACs annoyingly require a clock input at 256 times the sample rate.
I wonder whether that has anything to do with using a narrower (or even 1-bit) DAC and dithering to push the quantization noise into ultrasound. This is, for example, why SACD uses a sample rate of 64*CD.
Probably, these are almost certainly sigma-delta DAC.
Quote:
Weird. The original frequency was already just 7kHz, I'm surprised dropping it to 40Hz helped things (as opposed to, say, simply reducing the strength of the bias resistor). Or maybe the extra capacitive load did something. That large of a capacitance should definitely drop the effective frequency of the crystal, though. (How do 22pF and 370pF compare to the parallel parasitic capacitance of the crystal?)
My observation with the original RC osc (no Xtal in circuit) measured @ ~16MHz. In the early stages of my poking, I had tried a 10M with the 22pf value but it had the same problems as stated earlier. After reading the Pat.; just increasing C to ~30pF started it running without the HCT14 gate.
I then began increasing C in the free running circuit till I lowered F to the range of 10MHz.
I haven't seem a major deviation of the Xtal F, in the range of 5-10 KHz lower than the printed F on the Xtal. This could be due , as you point out to the C, or the cal on my DMM or the tolerance of the Xtals I pulled out of my junk box
Some test Xtals are long ago pulls from radios, and I have no idea on the specs, only the marked Freq and that is down to only 2 decimal places. The only 'known' spec is the 16MHz one, 20pf load cap AT cut, which measured spot on.
Initially, I was assuming this circuit was close to the Pierce but I'm doubting that a little. Of course, may see different performance on a proper layout.
Quote:
Hm. I wonder. Page 19 of the translated OPNA datasheet shows there's a selectable clock divider of 2,3, or 6 for the FM synth, but I'm not certain what else that changes. After all, the OPNA contains its own DAC, so there's no minimum clock speed to hold a serial bitstream. Anyway, when at a divider of 6 (claimed necessary for behavior above 4MHz), the output sample clock is Mclk/144. (Much like the OPL3's is Mclk/288, or the OPL2's is Mclk/72).
Beyonds changing the necessary tuning tables, this will also slightly affect ADSR rates, the timers, and the various free-running LFOs (e.g. "AMS" and "PMS"). Not certain exactly what they're using, since their rates don't seem to be tunable.
If we can extrapolate from the OPL3, the FM LFO is fixed at Sclk÷8192, and the AM LFO is fixed at Sclk÷13440. (MESS says these magic numbers are shared with the rest of the OPLx family, but who knows if that's true for the OPNx. Apparently the OPMx family can actually control the LFOs!)
I've only just started digging into the DS. But Is there a real need to maintain Sega's clk selection? With a 'new' design would there be an advantage to replicating Saga's HW? Would people want to use Saga VGM patches on a NES platform, sounds kind'of cool but IDK.
Yogi
yogi wrote:
My observation with the original RC osc (no Xtal in circuit) measured @ ~16MHz.
There's no hysteresis with this driver, and no second-order effects. Even if RC there is 22µs, it's still going to self-bias right to the middle of the transfer function and ring as fast as it can.
I wonder if it's actually the parasitic inductance of the 10MΩ resistor that matters here? 10MΩ is so huge ... does the osc work if you omit it entirely?
Quote:
I haven't seem a major deviation of the Xtal F, in the range of 5-10 KHz lower than the printed F on the Xtal. This could be due , as you point out to the C, or the cal on my DMM or the tolerance of the Xtals I pulled out of my junk box
You can usually get about 1000ppm of depression from nominal frequency by adjusting the load capacitance before the oscillator stops working... or about 16kHz on a 16MHz oscillator. Sounds consistent to me.
Quote:
Initially, I was assuming this circuit was close to the Pierce but I'm doubting that a little.
It certainly should be... only differences that come to mind are:
1- they're omitting C2/using the 2Ck input as C2.
2- It's not a single inverter but instead an inverter and two NOR gates
Quote:
Quote:
Beyonds changing the necessary tuning tables, this will also slightly affect ADSR rates, the timers, and the various free-running LFOs (e.g. "AMS" and "PMS").
[…]
If we can extrapolate from the OPL3, the FM LFO is fixed at Sclk÷8192, and the AM LFO is fixed at Sclk÷13440.
I've only just started digging into the DS. But Is there a real need to maintain Sega's clk selection? With a 'new' design would there be an advantage to replicating Saga's HW? Would people want to use Sega VGM patches on a NES platform?
I don't think there's a need to maintain complete compatibility. It involves some things that can be compensated for (changing F numbers) and accepting the things that can't (5% increase of speed of ADSRs and LFOs). Is 5.8 Hz vs 6.1 Hz something a musician would care about? I'm definitely not the right person to ask.
OTOH, if we don't have another more convenient source of clock, using a 15.36÷2 driver vs an 8MHz source isn't so big.
One other question: does the YM2612 have the same input clock divider available as the YM2608? If so, would we want to consider running it off M2 instead? It should be equivalent to using a 5.4 MHz crystal. (and a corresponding slowing of the ADSRs and LFOs by 30%)
Last day and a half I've been testing the HCT74 osc. I've compiled a data set of the tests to try to understand the circuit better. Keep in mind that my test circuit is on solderless breadboard which has a lot of stray C and my DMM only has a range to 4MHz with 4 digit precision. In order to test in the ranges of interest, a prescaler was constructed using a second HCT74.
Attachment:
HCT74 Osc testing Data1.xls [10.5 KiB]
Downloaded 230 times
The testing was done with a range of 3 R values, 4 C Values and 4 Xtal Frequencies. For each Xtal F, the output from the xtal osc was recorded as well as the free-running output for all RC combinations.
Two Xtals, the 11.525NHz and the 14.960MHz, were pulls with unknown specs, the other two, 16MHz and 18.432MHz, are AT cut 20pF load. The former two Xtals had unexpected performance with certain RC combos that leads me to suspect cut and load differences from the later Xtals.
Some of my conclusions:
1 I had a connection issue in the first build of the circuit that caused the strange behavior and the need for a inverter gate buffer. Through out this round of tests, the same R/C/Xtal combos that failed on the initial circuit now work.
2 The circuit is fairly forgiving with the RC selection but certain combos misbehave in a unexpected way. Example: The 16MHz Xtal running @ 19MHz with 5M/150pf but measured @ 16MHz with 5M/220pf. I'm sure some of these deviations are due to the mechanical problems with the breadboard as well as errors with my DMM coupling. But it could also indicate a cut/loading issue with the Xtal in some cases.
3 The Xtal to Free-running relationship seems to show a lower limit to acceptable RC Frequence. The Xtal Osc fails to lock when the free-running Freq is about 10% below the Xtal Freq. Further analysis is needed to understand the limits of Pat.'s description of the relationship between the RC TC and the Xtal Period.
At this point it should be clear that this circuit is quite capable, compact and could be considered as a replacement of a 'can' osc module if need be.
Yogi
Thanks for taking the time to explore this!
Naïve question: any idea why the free running frequencies not independent of the value of the missing crystal? The really visible outlier is no xtal/14.96MHz/10MΩ/220pF.
I've been trying to figure out a good way to graph this but there's four dimensions of input
lidnariq wrote:
Thanks for taking the time to explore this!
Naïve question: any idea why the free running frequencies not independent of the value of the missing crystal? The really visible outlier is no xtal/14.96MHz/10MΩ/220pF.
Are you asking in regards to the vast difference between the RC TC Res Frequency and the circuit's free-running frequency? This point has me very curious. For a single gate osc the RC should free run in the low KHz range for most these chosen values; I think with the added gates of the FF and associated Prop delays, the mode of operation is closer to the Ring Type Waveform Generator outlined at this site:
http://www.electronics-tutorials.ws/wav ... ators.html OTOH, Are you asking about the odd free-running outputs for crystal group? In most cases the same RC combos in the different data sets are close, ~10% ( I essentially tested the same 12 combos 4 times), but a few reading aren't even close to the average.
For each test I changed/added/removed test components, so with the moving and handling of the breadboard, quite likely changed some of the stray C. Or RC oscillators at these frequencies are just very unstable.
For the one you quoted, I'm thinking it's a transcription error (I recorded the raw meter reading then went back through my notes transcribing them into the spreadsheet. Could have been my handwriting). Or my meter acting up, it seemed sensitive to the poor test point on the breadboard and the tip on my test lead.
With some of the others odd readings, such as the 11.525MHz xtal data set and 68pf cap. I reran these tests and tried another 68pf cap from the same batch. The best I can say is it could be related to the unknown specs of the xtal.
One thing that seems the most important to me is the upper limit to the C value at these frequencies. This appears to be unrelated to the TC of the combo, as other RC combos with a similar TC allow osc lock. The Patent suggests that the RC TC should be > 1/2 the period of the Xtal, which in all the test cases is true. So the questions remains how close to "1/2 the Period" is acceptable and what is the impact on that particular Xtal.
Quote:
I've been trying to figure out a good way to graph this but there's four dimensions of input
That would be interesting. I wish my data set was larger though
Yogi
yogi wrote:
Are you asking in regards to the vast difference between the RC TC Res Frequency and the circuit's free-running frequency? This point has me very curious. For a single gate osc the RC should free run in the low KHz range for most these chosen values; I think with the added gates of the FF and associated Prop delays, the mode of operation is closer to the Ring Type Waveform Generator outlined at this site:
http://www.electronics-tutorials.ws/wav ... ators.htmlI was asking about the point you've attributed to the typo.
In Intro EE lab in college, we built a ring generator, and specifically played with the length of the wire on the long loop back. It was pretty easy to get enough inductance out of the aerial wire to get tens of volts on the input to the first inverter... In any case, I think you've got the right of it. There's no hysteresis at all with this circuit topology, the resistor just biases the inverter chain to its center point, so any oscillations we're seeing are propagation speed through the gates.
I guess it is useful because it gives us a likely upper bound on the crystal we can use, though. Not that there are all that many fundamental-mode crystals above 20MHz...
I went back through my notes in regards to the mentioned odd readings. The test procedure for each Xtal group was to insert the Resistor then run through the different Capacitors, taking the readings. For the 14.970MHz Xtal group I broke this pattern; starting with 68pf and then realizing that I had skipped the 22pf, ran that test last.
SO when I entered the data in the spreadsheet, the 14MHZ/5M set was copied out of order, Sorry guys
Here is an corrected xls; I also added the TC for each RC combo (very redundant, but handy for comparing different combos).
Attachment:
HCT74 Osc testing Data1.1.xls [12 KiB]
Downloaded 182 times
Yogi
It's a me again. Will you make available boards with built in flash chips for discrete mappers like NROM, UNROM, etc.? How much $$$?Now that bunnyboy doesn't do repropaks anymore I think InfiniteNESLives is the only site with a reasonable new board solution. Plus it's way easier to program a new board with the Kazzo than desoldering old mask roms.
Sorry I missed your post Punch..
Punch wrote:
Will you make available boards with built in flash chips for discrete mappers like NROM, UNROM, etc.?
Yeah I actually designed a separate
3rd version of my board tailored towards discrete mappers. There turned out to be a few hiccups found in the prototyping of greater than NROM designs. That kept me from releasing them on time with my original plans. I'll address the specific issues on that thread, but the good news is I've got the final design all laid out now and will be ordering the first production batch in the next week or two. That would put their sale available in June if all goes as planned.
Quote:
How much $$$?
Good question. I haven't fully decided yet, they'll be comparable to the pricing of my other products. Notably cheaper than my CPLD full flash boards. I made those boards extra small in efforts to keep cost down and help offset the cost of providing a fully assembled flash board with no soldering required. I also plan to have significant tiered pricing to provide benefit to homebrew production.