Search options (Page 13 of 87)

Hi Jazz. Good idea
   I really believe that the CM is kind of a dead end, design wise. The main idea is to tightly control the 2A03 in a very limited loop. In theory the super simple loop that the CPLD does is the lowest latency way to push bytes into the PSG and the AVR code is the 'make or break' of the design, which is where the CM kind of went wrong.  With a faster/ larger uC a better synth engine could have been designed.
  The Teensy2 is good but consider moving up to the Teensy3 ARM based board. This seems like the best 'Bang for the Buck'  and a larger CPLD not so much. There is just so much you can do without a more complicated main loop on the 2A03. In allot of way, this design mirrors Little Scale's interfaces; a simple loop running on the console and a uC sending raw register data, but in this case we are on the bus and not the pad ports.
  Trying to add more features on the 2A03 side, you would end up with a PRG/CHR full on mapper, with the uC memory mapped. This is the basic design of the Midines: the PIC's parallel slave port is mapped in the NES's memory. A synth kernel running on the 2A03 checks the PIC address for changes, (I'm kind of guessing based on the hardware, so...) With this design, PRG ROM based DMA sample playback is do-able via the kernel. With the CM you need to send raw PCM samples to the DAC at the sample rate, so you end up needing a fast processor and a large storage for the samples. Which is a challenge for most uCs that don't have a native parallel bus, reads and writes are bit banged.
   For a redesign of the TSUNDERE/CM take a look at this project-
https://github.com/Jaffe-/NESizer2
and the main board-
https://github.com/Jaffe-/NESizer2/blob … g?raw=true

In this design, the AVR is better synced to the 2A03 (they share the same 20 MHz CLK, AVR overclocked) and not dependent on a 'Gate' based CPLD loop. The ATMega 328 handles the 2A03 opcodes for the loop as well as the sample playback. The interface between the two is only an 8 bit latch, the majority of the other logic in the schema is to support the sample RAM busses.
  For a cart, maybe scale back the amount of sample storage and use a EPROM. A 50~70 macrocell CPLD would be needed for the 30~50 register bits needed for the Data/Adr latches and decoder logic in a >40 Pin package. Perhaps a Xilinx XC9572xl cause it's +5 tolerant and breakout boards are cheap.
   The uC would have to be synced to the system clock to cycle count for the state the 2A03; the Nesizer2 design shares the 20 MHz clock, which can't be done on the cart port. So maybe some sort of PLL locked on the Phi2?
  Anyways, There's a ton of ideas and allot of work involved. I'm in the middle of building a beta of the Nesizer so will definitely  share insights. I can also help a bit with the CPLD, currently getting my feet wet with VHDL so still a noob, but can get some basic logic going.
Yogi

P.S. the midi capabilities were constrained by the Atmega, the 3032 is plenty for holding what it needs to be, but the Atmega side could def use a new approach...