It is currently Tue Nov 13, 2018 10:46 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 150 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9, 10  Next
Author Message
PostPosted: Sun Oct 21, 2018 4:39 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 114
Location: Minnesota
Rahsennor wrote:
Wait, so the MMC5 DAC is linear? That means it's not just a repackaged APU.

Do you have any plans to measure the pulse channels? I'm not hardware-savvy enough to tell if that's feasible with your setup.

I could try that. I am thinking that the M2 reset detection would probably stop the pulse channels, so as to prevent stuck notes when you reset the Nintendo, so that might be a problem with my setup. I might try using a function generator into M2 to get around this.


Top
 Profile  
 
PostPosted: Tue Oct 23, 2018 11:36 am 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 114
Location: Minnesota
I am not quite set up for fast M2 yet, I have to think about it a little bit more and get that going before I can look at the pulse channels. In the meantime, I tried writing to the MMC5's built-in RAM. Something isn't working right. I always read back all 00s from the RAM. Could you guys review my test code and let me know anything you notice? Especially consider how I am handling M2 and R/W edges - I don't have a good handle on the correct sequence of those yet. Are there more modes I need to set or unlocks that I need to do? Or could my slow M2 be screwing this up somehow? Hopefully not.

Code:
        private void testFillRam()
        {
            byte data_to_write = 0x10;

            string s = "";

            readAndRefreshGraphics();

            // Set CPU R/W, /ROMSEL, and M2 as outputs:
            sendDataDirection(0xF8, 0x4A, 0);
            // Set these outputs to high:
            setCpuRW(true);
            setRomSel(true);
            setM2(false);
            // Send
            sendOutput(logicData[5][0], 0x4A, 0);

            // Set CPU address bus as output:
            sendDataDirection(0x00, 0x42, 0);
            sendDataDirection(0x00, 0x42, 1);

            setCpuRW(false);
            sendOutput(logicData[5][0], 0x4A, 0);

            // Set CPU data bus as output:
            sendDataDirection(0x00, 0x46, 0);


            // Write value $02 to register $5102:
            setCpuAddress(0x5102);
            sendOutput(logicData[1][0], 0x42, 0);  // LSB
            sendOutput(logicData[1][1], 0x42, 1);  // MSB

            logicData[3][0] = 0x02;  // Data to write
            sendOutput(logicData[3][0], 0x46, 0);

            setM2(true);  // Register the data
            sendOutput(logicData[5][0], 0x4A, 0);
            setM2(false);
            sendOutput(logicData[5][0], 0x4A, 0);
            // End set $5102 to unlock value $02:


            // Write value $01 to register $5103:
            setCpuAddress(0x5103);
            sendOutput(logicData[1][0], 0x42, 0);  // LSB
            sendOutput(logicData[1][1], 0x42, 1);  // MSB

            logicData[3][0] = 0x01;  // Data to write
            sendOutput(logicData[3][0], 0x46, 0);

            setM2(true);  // Register the data
            sendOutput(logicData[5][0], 0x4A, 0);
            setM2(false);
            sendOutput(logicData[5][0], 0x4A, 0);
            // End set $5103 to unlock value $01:


            // Write mode value $02 to register $5104:
            setCpuAddress(0x5104);
            sendOutput(logicData[1][0], 0x42, 0);  // LSB
            sendOutput(logicData[1][1], 0x42, 1);  // MSB

            logicData[3][0] = 0x02;  // Data to write
            sendOutput(logicData[3][0], 0x46, 0);

            setM2(true);  // Register the data
            sendOutput(logicData[5][0], 0x4A, 0);
            setM2(false);
            sendOutput(logicData[5][0], 0x4A, 0);
            // End set $5104 to mode 02 (normal RAM)


            // Start: write non-zero, non-FF, non-negative data to entire expansion RAM:
            for (int i = 0x5C00; i < 0x6000; i++)
            {
                setCpuAddress((UInt16)i);
                sendOutput(logicData[1][0], 0x42, 0);  // LSB
                sendOutput(logicData[1][1], 0x42, 1);  // MSB

                logicData[3][0] = data_to_write;  // Data to write
                sendOutput(logicData[3][0], 0x46, 0);

                setM2(true);  // Register the data
                sendOutput(logicData[5][0], 0x4A, 0);
                setM2(false);
                sendOutput(logicData[5][0], 0x4A, 0);

                data_to_write++;
                if (data_to_write > 0x7F)
                {
                    data_to_write = 0x10;
                }

                // Update progress bar in GUI:
                double progress = (double)(i - 0x5C00) / (double)(0x6000 - 0x5C00);
                SetProgressThreadable((int)(progress * 50.0));
            }

            // Set CPU data bus as input:
            sendDataDirection(0xFF, 0x46, 0);

            setCpuRW(true);  // Read mode
            setM2(true);
            sendOutput(logicData[5][0], 0x4A, 0);

            // Read back entire expansion RAM
            for (int i = 0x5C00; i < 0x6000; i++)
            {
                s += i.ToString("X4") + ",";

                s += readFromPRGAddress((UInt16)i).ToString("X2") + "\r\n";

                // Update progress bar in GUI:
                double progress = (double)(i - 0x5C00) / (double)(0x6000 - 0x5C00);
                SetProgressThreadable(50 + (int)(progress * 50.0));
            }

            // Log to File:
            filename = "MMC5 Expansion RAM Fill " + DateTime.Now.ToString("MM.dd.yy hh.mm.ss tt");
            using (StreamWriter outfile = new StreamWriter(folderName + filename + ".csv", true))
            {
                outfile.WriteLine(s);
            }

            SetProgressThreadable(0);

        }


Top
 Profile  
 
PostPosted: Tue Oct 23, 2018 11:48 am 
Online

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 417
Location: Poland
When MMC5 detects reset condition (no M2 toggling), EXRAM access is disabled and returns 00s for $5c00-$5fff.

To enable it, start toggling M2 and choose EXRAM mode by writing to $5204.

You cannot just connect external signal generator to force M2 clocking because that would interfere with what you drive address/data/r_w lines and will make MMC5 think that you are making read or write cycles.

You must modifity your testing device to drive M2 with proper clock speed and when there is USB communication in progress, it still need to be driven (so probably some hardware PWM will be necessary)


Top
 Profile  
 
PostPosted: Tue Oct 23, 2018 12:05 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 114
Location: Minnesota
krzysiobal wrote:
When MMC5 detects reset condition (no M2 toggling), EXRAM access is disabled and returns 00s for $5c00-$5fff.

To enable it, start toggling M2 and choose EXRAM mode by writing to $5204.

You cannot just connect external signal generator to force M2 clocking because that would interfere with what you drive address/data/r_w lines and will make MMC5 think that you are making read or write cycles.

You must modifity your testing device to drive M2 with proper clock speed and when there is USB communication in progress, it still need to be driven (so probably some hardware PWM will be necessary)

Okay, bummer, that makes sense though. I was thinking that I would use a function generator, connected through a 10k resistor to M2, then my setup would still be able to override the function generator by driving M2 high or low, but I still think that would be too long of a delay on M2... So I might be facing a redesign of my test setup... But honestly though, my setup leaves a lot to be desired as it is. It will be good to rethink some things.

Edit:
My current setup works like this:
Computer with GUI
V
USB
V
USB to I2C adapter
V
8x 16 bit I2C IO expander chips, each a different address

The problem is that this setup is very slow compared to a real Nintendo.

I started working on a "buffer" microcontroller to put between the computer and the I/O expanders:

Computer with GUI
V
serial port
V
Buffer Microcontroller
V
8x 16 bit I2C IO expander chips, each a different address, also direct connections for M2, CPU R/W, etc.

The microcontroller can be smart enough to keep toggling M2 and operating the IO expanders at the right times. I have attached the beginning of this project. It currently operates a timer but is not yet talking with the computer or with the IO expanders. I want this part to be pretty much dumb and do what it is told by the computer. So the computer needs to be the one to know what io expanders/pins connect to which MMC5 pins, what sequence to do things, etc. Feel free to have a look at the source code so far and let me know if you notice any big design flaws. That would be very appreciated.


Attachments:
File comment: Source Code
main.c [7.95 KiB]
Downloaded 21 times
Top
 Profile  
 
PostPosted: Wed Oct 24, 2018 3:00 am 
Online

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 417
Location: Poland
Yea, it is good to have whole logic on the PC side and use the device just as a executor, but in many cases, device under test will not wait forever for a command. So putting microcontroller between is neccesary.

If you want to stay with your current design, you still should add microcontroller and make at least a modification that would let the PC send commands the microcontroller as a batch querry (with specified delay between commands) and receive batch result.


Top
 Profile  
 
PostPosted: Wed Oct 24, 2018 6:37 am 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 114
Location: Minnesota
I don't need to stay with my current design -- I am open to ideas. I wish I had a 100 pin, 5 Volt microcontroller and skip these stupid IO expanders, they are so slow. I am actually not sure if I can write to them in less than the MMC5 reset time even with this new setup. I think it will work but I haven't tried and measured it yet. I think that I will probably have to toggle M2 between each 8 pins read or written

I like the idea of batch operations in the micro. A problem that I will probably run into with that is RAM. I have something like 32k in this micro. Some of the tests I have done earlier in this thread had megabytes of results. But I am thinking that in these cases there is typically a short test that is repeated many times with slight variations. If I queue up each short test, take my time to gather the result, then start over with the next test, that should be okay.


Top
 Profile  
 
PostPosted: Wed Oct 24, 2018 7:00 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20763
Location: NE Indiana, USA (NTSC)
Could you build your test bench around a 3.3 volt MCU with sufficient I/O and put level shifters in front of the MMC5? Then you could tell the MCU to treat the NES cart bus as an external SRAM. It could push test results to a different board with more RAM over a serial port or whatever. I'd say build the test bench around an NES Control Deck, but you want to know what happens in less than the 4 cycles it takes to run STA or what happens with nonstandard PPU bus sequences.


Top
 Profile  
 
PostPosted: Wed Oct 24, 2018 7:20 am 
Offline
User avatar

Joined: Sat May 04, 2013 6:44 am
Posts: 33
Ben Boldt wrote:
I don't need to stay with my current design -- I am open to ideas. I wish I had a 100 pin, 5 Volt microcontroller and skip these stupid IO expanders, they are so slow.
It's not 100 pins, but the Arduino Mega 2560 rev 3 has 54 I/Os at 5V. (The ATmega2560 chip it uses has 86 I/Os, but the Arduino is using a bunch of those for USB and such.)

If you're comfortable building your own board around a microcontroller, you might consider the STMicro ST10F276Z5. It's 5V tolerant on most I/O pins and has up to 111 general purpose I/O lines. It's hard to find now and a bit expensive, but Mouser will sell you a single chip for $36 USD.

The dev board for that MCU, the STEVAL-IFN001V2, is also hard to find, but allegedly there is a seller in Hong Kong who has over 1000 of them. It does not have a USB interface - it has CAN and RS232. (Targeted at automotive applications, I think).

NXP / Freescale also used to have some 5V options, also targeted at cars, but I think they are now similarly hard to find. Other than that, I think you are stuck with more modern MCUs and level translators.


Top
 Profile  
 
PostPosted: Wed Oct 24, 2018 11:19 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7714
Location: Seattle
One complicating factor: we don't yet know whether the MMC5's voltage thresholds are "TTL" or "CMOS", so it's conceivable that a 3.3V design with protection but not up-translation won't work.

Given my hunch that the MMC5 is NMOS, they're probably TTL voltage thresholds, but it's the sort of thing you want to test before you spend money.


Top
 Profile  
 
PostPosted: Thu Oct 25, 2018 9:18 am 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 114
Location: Minnesota
Let me know if this is enough info for you gurus to figure out how this chip is made. Rising edge measurements attached.


Attachments:
rising edge - measuring PRG_CE output.png
rising edge - measuring PRG_CE output.png [ 21.53 KiB | Viewed 747 times ]
rising edge - measuring _ROMSEL input.png
rising edge - measuring _ROMSEL input.png [ 21.49 KiB | Viewed 747 times ]
Top
 Profile  
 
PostPosted: Thu Oct 25, 2018 9:19 am 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 114
Location: Minnesota
Falling Edge measurements attached.


Attachments:
falling edge - measuring PRG_CE output B.png
falling edge - measuring PRG_CE output B.png [ 24.07 KiB | Viewed 747 times ]
falling edge - measuring PRG_CE output A.png
falling edge - measuring PRG_CE output A.png [ 24.04 KiB | Viewed 747 times ]
falling edge - measuring _ROMSEL input B.png
falling edge - measuring _ROMSEL input B.png [ 23.63 KiB | Viewed 747 times ]
falling edge - measuring _ROMSEL input A.png
falling edge - measuring _ROMSEL input A.png [ 23.98 KiB | Viewed 747 times ]
Top
 Profile  
 
PostPosted: Thu Oct 25, 2018 10:20 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7714
Location: Seattle
Sure looks like TTL voltage thresholds to me. Using 3.3V as logic level high should be reliable.


Top
 Profile  
 
PostPosted: Thu Oct 25, 2018 11:26 am 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 114
Location: Minnesota
Would something like this work?
Code:
          3.4k          6.6k
MMC5 ---/\/\/\/---T---/\/\/\/--- GND
                  |
            3.3V PIC Micro

I have a couple of demo 100-pin dsPIC33FJ256GP710A. They have 87 IO pins, 2 of which will need to be used to communicate with the PC, so 85. It looks like I need at least 90 for the full MMC5...

I crunched some numbers on the IO expanders that I have. Each I2C message is 3 or 4 bytes:
Code:
Write:
[Start] [Addr][R/W][k] [data][k] [data][k] [Stop]
   1       7    1   1     8   1     8   1    1     = 29 bits

Read:
[Start] [Addr][R/W][k] [data][k] [Start] [Addr][R/W][k] [data][k] [Stop]
   1       7    1   1     8   1     1       7    1   1     8   1    1     = 39 bits

If everything was perfect, at 400kHz I2C, each bit takes 2.5 usec.
Write: 29 bits * 2.5 usec = 72.5 usec
Read: 39 bits * 2.5 usec = 97.5 usec

Realistically, let's say each operation takes 200 usec. If I want to get everything done in 5 msec before changing M2, that means I could do 25 IO Expander operations. This might actually be reasonable. I am very much more familiar with slave I2C mode on these PICs, but I will see what I can do getting master mode going, then make some measurements. This could be a free/easyish solution so I am going to look into it.


Top
 Profile  
 
PostPosted: Thu Oct 25, 2018 11:34 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7714
Location: Seattle
Ben Boldt wrote:
Would something like this work?
Code:
          3.4k          6.6k
MMC5 ---/\/\/\/---T---/\/\/\/--- GND
                  |
            3.3V PIC Micro
Ideally you'd use a 5V tolerant part, or translation, or protection, instead of a voltage divider, but at 10kΩ you're only talking about 500µA static per pin. And because speed isn't important in this case, you don't need to worry about RC delays making things not work—you can just slow everything down instead.


Top
 Profile  
 
PostPosted: Thu Oct 25, 2018 3:40 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 114
Location: Minnesota
I think I may end up doing a mixture of the IO expanders and the micro pins. It looks like I do have 48 5V tolerant pins on this micro.

I got master mode working with writes and with reads. The timing looks really good, in line with my predictions.


Attachments:
File comment: New Source File
main.c [11.86 KiB]
Downloaded 19 times
File comment: 2 write operations and 1 read operation
Fast I2C.png
Fast I2C.png [ 80.52 KiB | Viewed 700 times ]
Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 150 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9, 10  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: krzysiobal and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group