chipmusic.org is an online community in respect and relation to chip music, art and its parallels.
You are not logged in. Please login or register.
Jarek got back with me. I asked about the CPLD code which the website claims to offer to those who ask:
Hey sorry for the delay, not ignoring you I'm opening boxes to find the backup I had of the source (it's been a while...)
If you go to my site and look up the TSUNDERE project, the CPLD code is really just a block diagram of that
So thats a good start.
Jarek emailed me again.
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...
He also attached the cpld code.
I'm gonna reread your post yogi. I somehow missedit
Can you explain more why the atmega in the chipmaestro is so limiting, while an arduinoboy works so well?
Can you explain more why the atmega in the chipmaestro is so limiting, while an arduinoboy works so well?
The gameboy is receiving native serial data from the arduino while in CM, the serial data is converted to parallel and then sent to the NES. I also think it may have to do with the gameboy running a little faster than the NES does and MIDI cannot be sped up or slowed down.
Another reason I can think of is that the GB has a dedicated ROM running at all times and the CM for NES has a psudo-ROM which can only support so much code.
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=trueIn 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
I'll keep an eye on your project for sure. And yeah, I switched the Teensy for a 3.1 like you mentioned because it is 5v tolerant and runs much faster. I feel like the extra memory and speed could be used to store samples, without the use of teh CHR space.
[
I'll keep an eye on your project for sure. And yeah, I switched the Teensy for a 3.1 like you mentioned because it is 5v tolerant and runs much faster. I feel like the extra memory and speed could be used to store samples, without the use of teh CHR space.
Yea, the Teensy 3.1 will beat the pants off the ATMega168! At it's speed, won't have to worry too much about a stripped down synth engine. And should be able to do raw PCM samples from SD maybe.
There was another thread about the CM, with some info about the CPLD logic. It's a very simple 'program' loop, and in theory should allow very fast access. If I recall, about 15 instructions(EDIT:cycles) long. Here is the nesdev.org thread with Kevtris' design
http://forums.nesdev.com/viewtopic.php?t=3836
He explains the loop and the interface to the uC. Beyond this hardware, the uC does everything else - process Midi messages, convert Midi messages to 2A03 register values, manage sound FX like arps or slides or whatever and then sends data to interface.
Yogi
Last edited by yogi (Feb 7, 2016 1:40 am)
Here is more from Jarek. Apparently the CPLD just has 8bytes of 'code' so this is a TIGHT loop.
I tried purposely to stay away from NES stuff like CHR ROM and RAMs to keep the latency between MIDI to NES as low as possible and make it easier to 'patch' things into the Chip Maestro without worrying about the NES side, hence the 8 byte ROM inside the CPLD locking the NES in a loop being fed by an arbitrary microcontroller. If you're going to store sample data, I suggest looking at the TSUNDERE code where I implemented a simple DMC transfer routine which you can use for playing samples through the NES's DMC (http://wiki.nesdev.com/w/index.php/APU_DMC), and keeping the sample stuff on the Teensy side. Putting it on the NES side severely limits the amount of sample storage you have (only like, 2 seconds of sound?). The CPLD is fast enough to play samples as fast as a native NES program, as long as the Teensy can keep it fed....
Also been reading everything I can on the nes ext port. There might be something to it...
Last edited by Jazzmarazz (Feb 7, 2016 1:35 am)
Oops
Last edited by Jazzmarazz (Feb 7, 2016 1:35 am)
The thing to remember with the CM design is the 2A03 is not running a proper NES kernel. The CPLD state machine is kind of jamming this simple loop into the 2A03. The PPU is not started and has no need for CHR data, no NMIs are generated; the ports aren't read, nothing is done but load bytes into the PSG registers. Now the lack of a video screen may be off putting to some, but it would just complicate the system and leads to Midi lag. There is very little difference between the naked 2A03 on the TSUNDERE and the cart based Chip Maestro. If anything the CM cart is inferior because of the smaller ATMega 168.
Yogi
