Jazzmarazz
Offline
Michigan

There is an old thread in which a few members toyed with the idea of improving Chip Maestro. The topic didn't end up being very constructive. Who "really" wants to do that?
The Schematic, and codes are readily available for download.

What would you improve? --

Sample playback?
-- lets add CHR-ROM to store samples.
MIDI-OUT?
-- the TX pin on the atmega is unused.
Other (non MIDI) control inputs?
-- ADC6, ADC7 and PB2 are unused on the atmega.
USB-MIDI?
-- The Atmega168 is slow, whereas a teensy has native USB midi and is much much faster. Is an extra $10 worth the power?
New CPLD?
-- The EPM3032 is cheap, but what about the EMP3064? Its twice as powerful so it can address more "virtual" ROM and even control the CHR ROM.

Currently the virtual PRG ROM is a measly 32 bytes if I understand that correctly. For only a few cents more per part, it could be 64 or even 128 bytes.

I can't do this alone though, I am just a hardware guy. I have interest in learning to program for CPLD's though.
One more thing worth noting is that the Chip Maestro isn't all that far off from MIDINES internally. More PRG_ROM in that case, but the MCU inside is actually not nearly as powerful as a Teensy. This could really turn into something if we got community input.

Here is my initial rendition/suggestion.
Teensy instead of Atmega168
Added CHR_ROM for samples
Maybe switch to EMP3064 for the CPLD
MIDI Thru from Teensy
USB-MIDI
Use on-board 3v3 reg from teensy
All CIC chip footprints available for use
NOT FIXED TO NTSC! .....

Second update:

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Running list of Suggestions:

Ability to send CC commands (no presets) - 2PLAYER
vibrato function - PROTODOME
DPCM resampling - PROTODOME
MIDI-channel-select jumpers - Jazzmarazz
NTSC/PAL jumper - Jazzmarazz
Audio-in/through - MaxDolensky

Last edited by Jazzmarazz (Jan 22, 2016 4:55 am)

2PLAYER
Offline
Rhode Island

Having the ability to send CC commands rather than cycling through presets via note data would be a great start.
I probably couldn't help developing it but I am good at breaking stuff if you need a tester

Jazzmarazz
Offline
Michigan

Good one.
I did some more looking at replacements parts and the Teensy LC is not 5v tolerant. Thats no big deal. The Teensy 2.0 is for only a few dollars more.

Jazzmarazz
Offline
Michigan

What I think. Added to first post.

PROTODOME
Offline
UK

Decent vibrato function would be ace. Actually, built-in envelopes would save a huge amount of time. There are a bunch of cool DAW automation tools for this purpose (FL's Fruity Envelope Controller is brilliant), but having it native would really helpful.

Also, would it be possible to have MIDI control over DPCM pitches (with some rad sampled orchestra hits / basses)? I know some games utilised re-pitching of samples to melodic effect, but I'm sure I read somewhere that there's a limit to the pitches possible.

Jazzmarazz
Offline
Michigan
PROTODOME wrote:

Decent vibrato function would be ace. Actually, built-in envelopes would save a huge amount of time. There are a bunch of cool DAW automation tools for this purpose (FL's Fruity Envelope Controller is brilliant), but having it native would really helpful.

Also, would it be possible to have MIDI control over DPCM pitches (with some rad sampled orchestra hits / basses)? I know some games utilised re-pitching of samples to melodic effect, but I'm sure I read somewhere that there's a limit to the pitches possible.

I have read about re-sampling too and it seemed to be reliant on one of the blanking periods. I know nothing about coding though. Seeing as the Teensy has built in timers and the CPLD is controlled to some extent via an interrupt, it could be possible.

Jazzmarazz
Offline
Michigan

I suggest some jumpers on the cart to determine which MIDI channels it responds to. 
This way, with one MIDI stream you could control 3 NES's independently.

One cart dedicated to channels 1-5, one for 6-10 and one for 11-15.
Maybe channel 16 could be global controls that all NES's respond to.

Illustration:

This would be convenient for people with limited MIDI cables/controllers. Of course with USB-MIDI, running out of USB ports is pretty difficult.

Last edited by Jazzmarazz (Jan 22, 2016 1:16 am)

MaxDolensky
Offline
Alabama

Would be cool if it was reflashable and maybe we could also use the audio-through pin for *something*. Not quite sure what though.

Jazzmarazz
Offline
Michigan
MaxDolensky wrote:

Would be cool if it was reflashable and maybe we could also use the audio-through pin for *something*. Not quite sure what though.

At least two of the components need "flashed" separately, but it is definitely reflashable if there were alternate code revisions.
The teensy is flashable over USB and the CPLD is programmable via the JTAG breakout. The CPLD is nothing more than a slave to the microcontroller, so a lot of the heavy work can be done with the teensy alone as long as the CPLD understands that is. Lets say that the CPLD is programmed to do everything it possibly can do in respect to updating sound registers; you would never have to touch it again. Now the Teensy on the other hand can be flashed with all sort of creative sketches, controlling timers, envelopes, vibrato, etc. What I mean to say is that the teensy could be the only thing you need to change, granted you want to change anything at all.

If you're talking about the CHR-ROM, well it could be reflashed if you pulled it out and set it in an eprom programmer. It is not utilized at this time however, so it can be ignored altogether.

What do you mean Audio-through? Do you mean the expansion pins? People would need to modify their console to use that and not all end-users are up for it.

second update to a new board. Fully routed

Now we just need some programming ideas and a way to address the CHR-ROM.

EDIT: Some changes to make...
I don't think the Teensy has an on-board 3v3 regulator. It has a footprint, but nothing is there. I'll have to add the LM1117 back on.
Jarek seems to really like port manipulation, so I might have to rearrange some of the teensy GPIO to accomodate the teesny-equivalent of ports. (or lack-there-of)

EDIT2: K, I slapped an LM1117 vreg on the back.

Last edited by Jazzmarazz (Jan 22, 2016 6:10 am)

dustfilledhobo
Offline
Salt Lake City, UT, USA

I don't really have the tech skills to help with this, but I'm very excited about this project.  Any estimates on the price of a cart once this is finished?

Jazzmarazz
Offline
Michigan

The only justifiable way to produce a revised cart is through at-cost group-printings as open source. Jarek still sells the original.

herr_prof
Offline
Unsubscribe

better idea: get batsly to finish FaMi
https://code.google.com/p/pcnestool/wiki/FaMI

way closer to being usable than this alpha level product.

herr_prof
Offline
Unsubscribe

better idea: get batsly to finish FaMi
https://code.google.com/p/pcnestool/wiki/FaMI

way closer to being usable than this alpha level product.

Jazzmarazz
Offline
Michigan
herr_prof wrote:

better idea: get batsly to finish FaMi
https://code.google.com/p/pcnestool/wiki/FaMI

way closer to being usable than this alpha level product.

The problem is, there is nothing I can offer to Batsly in terms of help. So unless I kidnap the guy and force his hand, he'll get it done when he gets it done. He is fully capable of completing that project on his own.

yogi
Offline
Jelly Stone park, MD USA

Sorry, some weird double post happened

Last edited by yogi (Jan 24, 2016 12:32 am)

yogi
Offline
Jelly Stone park, MD USA

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

Last edited by yogi (Jan 24, 2016 12:39 am)