nesdev.org

Well it's been awhile since I've given an update...

I had to post this video for school: http://www.youtube.com/watch?v=sqHCfyMR ... ture=g-u-u it's a few months old, but shows the operations of it. The only thing that has really changed is some mapper support. As I've posted in other threads, I've gotten the MMC1 and MMC3 up and running on it. I started on the FME-7 and have everything working except the counter (the only part that's a challenge). Once I sit back down and debug it I shouldn't have much issue, I just haven't devoted the time yet.

So as far as the project goes it's pretty much done in respect to what was required for the school project. But have no fear I'm not dropping it here

As for future plans I plan to finish up the FME-7 and then RAMBO-1 because it's basically a cross between the MMC3 and FME-7. So the RAMBO-1 (or similar) I would imagine would appeal to a lot of people and I should be able to fit into my MMC3(ish) reproboards as well.

I don't have much plans for original game mappers beyond that unless there are some big requests. Maybe some VRC stuff but I don't know if I have the motiviation to figure out the sound stuff. I might know someone who can help out though. Since there is a HDL source available for the sunsoft 5B's YM2149 (AY-3-8910 with bells on) I plan to implement that once I toss a DAC on the board. I think that would satisfy most sound guys.

I do plan to develop some of the MMC5's abilities, but I don't intend to copy it EXACTLY. Mostly because there are too many unknowns and I don't see the value in probing the real deal to try and reverse engineer everything to the T. I'd rather re-design something that is just as good, or better actually. And since we came up with it everything about it everything would be KNOWN, no guessing and hoping things are proper. After all it's not meant to be a device to play every rom on the planet, it's truly a development tool.

I may be slow to make progress in the up coming months due to graduation, moving, and the new job. But I'm looking forward to more free time to work on it once things get going at the new place. I'm also taking some time to learn how to program on the NES and get a better understanding of the PPU. I've gotten through most of bunnyboy's nerdy nights in the past week and my knowledge holes are quickly becoming filled. So thanks for those bunnyboy

And with the programming knowledge I'll be able to write some ROMs to test out some of these hair brained idea's we've been discussing with the dual ported memory and all. The more I learn about the PPU the more I get excited about what will become possible with this thing. So that's some good motivation. My only concern right now is getting the synchronous SRAM to act as asynchronous, I've got a plan so hopefully it'll work out.

AFAIK only DAC is not enough. VRC6, VRC7 using wave tables. I would try to make these sound extensions with discrete IC's 8)

Well the VRC7 is running a derivative of the YM2413 as well. With the logic available in the CPLD I won't need much more than a DAC to get the YM2413 running. Unless I'm missing something here I wouldn't expect the VRC7 to be much different. What are you suggesting I'd need for hardware? Sorry I know you have a love for the discrete IC's but I don't think there will be much of those in the design...

I'm no sound guru though (nor do I have plans to become one), so I'm probably wrong. That's why I was suggesting I'd need some collaboration to get anything beyond the standard YM2413. I know someone with the VRC6 and he may very well be interested in doing some work with this.

When you can do discrete, it's more compact and easy to convert into CPLD. I know, that VRC7 is derivate, but how far? Haven't compared them yet, but have real YM2413. And i will try to get real VRC7 as soon as one will turn up with right price(Hello to Poland)

I think you need a quite large CPLD to put the YM in it, people put YMs in FPGAs and they use up fair chunk of them.

infiniteneslives wrote:I plan to implement [Sunsoft 5B audio] once I toss a DAC on the board.

A delta-sigma DAC can be as simple as an adder and a register as wide as the digital signal. Every M2 cycle, add the DAC's current value to the register. Put the adder's carry out on one pin, and that's your audio signal. There'll be a bunch of noise well over 100 kHz in the signal, but a simple low-pass filter will remove that.

The other problem is that most 72-pin consoles haven't been modified for expansion sound. Your DAC would operate by causing an IRQ whenever the audio signal level changes and providing the digital signal on $4011 reads in the range 1 through 127. Then the IRQ handler reads the value from the mapper, writes it back, and returns: Yeah, I know, 19 CPU cycle overhead to process, but it could be worth it for slower-paced parts of a game.

If it's for NES, why not to make sound output from cart? RCA or 3.5mm jack will do the job

How would the audio from the RCA or 3.5mm jack be mixed with the audio from the NES?

TmEE wrote:I think you need a quite large CPLD to put the YM in it, people put YMs in FPGAs and they use up fair chunk of them.

Yeah I know it supposedly sucks up around 6000 logic elements on a Xilinx FPGA. Sounds like a problem when the largest Mach XO2 has 7000 elements right? WRONG! I compiled it on the Mach XO2 and it only took up 200-250 LUTs depending on the implementation. The reason is these babies have built in 'User Flash Memory' which is great for things like the tables in the 8910/2149. So where the Xilinx FPGA sucks up a TON of logic just for ROM, the Mach XO2 puts that data in Flash leaving plenty of room to spare for actual logic use. I've got it compiled on my current CPLD and the 2149 takes up about (EDIT 30-40%) of available logic. Which is pretty awesome when you consider it's only a $5-8 CPLD There is still plenty of room for a MMC5 with extras on my current device. But I kind of already decided to step up to a larger device since it doesn't cost much more. So on that device It would only use about 10% leaving room for MMC5ish capabilities along with other boards on the same configuration.

Tepples: I like your delta-sigma DAC idea especially since it wouldn't take up much for CPLD pins and only add discrete components. I've had plans to run your DEC $4011 from when I was designing it as well. My thought was to have circuitry to support both the DEC $4011 option and the EXP2/6 method for those modding the NES/exp jumper/or FC.

80sFREAK: Sorry the RCA cable hanging off it isn't artistic enough for this cheeseburger.

That's very cool ^^

Now I'm thinking shouldn't the tables and stuff end up in SRAM cells of the FPGAs ...? You can easily use them to store LUTs with minimal extra cost...?

It's my understanding that the FPGA would be storing the tables in SRAM cells but there are only a few cells per logic element. The Xilinx FPGAs are very homogenous as I understand it, they don't have a separate area for SRAM it's distributed throughout the logic elements. So when you use that distributed SRAM (in the logic elements) your taking up the entire element for a few bits of SRAM. So the cost isn't minimal and the 64Kb of tables sucks up lots of cells in the xilinx FPGA.

I haven't researched the details of the Xilinx architecture, so take what I'm saying with a grain of salt. But if the YM2149 really does utilize 10% of the XC2S300 like the wiki says I'm not sure what else could explain why the Lattice devices have such a huge advantage.

I am more familiar with Altera FPGAs and they got nice chunks of SRAM to use in your stuff with minimal extra cost. Optimized for storing LUTs and ROM etc. At least so datasheets say ^^

The YM2149 is only around 200 PLD macrocells and the chip itself doesn't have any ROM unlike the FM chips. The cheeseburger cores online use ROM for a 3D volume LUT since you'd have to think outside the bun (R) to calculate logarithmic attenuation, average 3 channels, scale to 16-bit and normalize in hardware.

Edit: Of course Xilinx devices have block RAM, nobody in their right mind would use distributed RAM (or ROM in Altera's case) to hold 64 KiB, I don't think even the latest chips have that much.

Yeah that's what I've come to realize kyuusaku. I tried compiling it on a smaller Mach XO2 that didn't have much flash memory and when I used the larger tables the thing exploded because it filled up the flash and started using logic cells. It wanted to consume several thousand logic units that weren't available. It was okay with the smaller table or a device with more flash.

kyuusaku wrote:you'd have to think outside the bun (R) to calculate logarithmic attenuation, average 3 channels, scale to 16-bit and normalize in hardware.

As I understand the logarithmic output of an AY-3-8910 or SN76489A, we'll need a 3-cycle sequencer, a mux, a 16-entry log to linear table, and a pair of registers.

Cycle 1: Latch previous accumulator value into DAC output, look up channel 1's volume in 16-entry table, and load it into an accumulator.
Cycle 2: Look up channel 2's volume in 16-entry table and add it to the accumulator.
Cycle 3: Look up channel 3's volume in 16-entry table and add it to the accumulator.

I can has free french fryz nao? Or what did I get wrong in the above pseudo-HDL?