20240330 release doesn't work on PAL N64

[michalderkacz]

Have two N64s: Europe/PAL model and Japan/NTSC model.

The Japan/NTSC model works great with picocart64-v1-ntsc.uf2. Testroom and any game I've flashed so far work fine. Have only a problem with 240pSuite-newer test suite that doesn't work.

The Europe/PAL version doesn't work at all with picocart64-v1-pal.uf2 + testrom (nothing on the screen). It works fine with PAL cartridges.

[kbeckmann]

That’s odd. I’m developing on a PAL console primarily and this works for me. Potentially there could be a problem with the pico you used for that unit? How’s the soldering etc?

Regarding 240p, this should also work. I have my own test rom but could you let me know where to find yours?

[michalderkacz]

I use WeAct 16 MB Pico attached to the broken Supper64 cartridge:

Test works fine with it:

The N64 240p Suite is from here.

If the last release works on your PAL N64 it's probably a problem with my one. Maybe the connector is slightly misaligned and works with the original cartridges but it doesn't with Super64 one. Will try to check all connections from the Pico to the N64 motherboard.

[michalderkacz]

The pico definitely works in both consoles:

NTSC

PicoCart64 Boot (git rev 2d88074a)
cic_task_entry
second_task_entry
Hello from the N64!

PAL

PicoCart64 Boot (git rev 2d88074a)
cic_task_entry
second_task_entry

I've to disassemble the PAL one...

[michalderkacz]

So I've disassembled my PAL N64 and started checking the PIF-NUS signals (1996 PIF(P)-NUS 9703 D).

When N64 works (with the original game cartridge) the NMI signal is high. The CIC-DCLK and CIC-DIO signals are as below:

In case of the PicoCart I can observe only a short burst of activity on DCLK and DIO, just after power on (I can't catch it on my cheap scope). Next both signals are high and the NMI signal is as below:

I checked the continuity of DCLK and DIO directly between the PIF-NUS and Pico pins. It's OK. I also observe the same waveforms on the both sides.

It seems the next step is try to debug the communication in software using the UART as a debug output. Any advice?

[kbeckmann]

I tested the release again on real hardware and it works for me.

It is possible that the flash on the Pico you use for the PAL version is using a type of flash that doesn't handle 133 MHz. It has been seen in the wild that some 3rd party boards use the cheaper variant that only goes to 104 MHz or so, which is a problem.

What you can test with is the 133MHz variants from the unstable branch. The 133 MHz name is referring to the system clock, i.e. it is not overclocked. So the flash access is running at 133/2 MHz so it mitigates this issue. https://github.com/kbeckmann/PicoCart64/actions/runs/8156039367

[michalderkacz]

Just tested picocart64-v1-ntsc-133MHz.uf2 on the NTSC N64 and picocart64-v1-pal-133MHz.uf2 on the PAL one. The same result: NTSC works, PAL doesn't.

I think I've to try insert some debug prints here and there in the CIC code to see differences in both cases.

[kbeckmann]

How odd, I haven’t heard of anyone else having exactly this issue. Just for testing, could you try the ntsc firmware on the pal console?

[michalderkacz]

Tested all possible combinations (NTSC/PAL firmware, NTSC/PAL games).

I think there is something wrong with my PAL console that doesn't reveals in case of the original PAL games (unfortunately have only two of them). I've replaced all electrolytic capacitors on both consoles, so it shouldn't be a bad capacitor. If it's a problem with some voltage, it's on the edge, so the difference between the original cartridge and the PicoCart is enough to revel it.

As the communication between PIF and CIC seems to be affected, I want to see what Pico sees from the PIF and when the communication stops. If the problem is there a better scope will probably help to understand it.

The simplest way to handle this problem is probably to buy another PAL N64 but for now I still want to understand this problem instead sweep it under the rug.

[kbeckmann]

The CIC data transfer rate is very slow so even with a slow scope you should be able to capture this fine.

The related code is here https://github.com/kbeckmann/PicoCart64/blob/develop/sw/n64_cic/n64_cic.c

You can print using printf, but if you want to be sure it doesn't affect timing you can use uart_print_hex_u32 which is very fast. It's non-blocking and prepares the string in a relatively fast way.

Still I think it's odd that you are experiencing this issue, can't wrap my head around it. My gut feeling is that you might be getting bit errors over the wire which then causes the crc to be incorrect so the PIF rejects it.

Try to lower the bus speed. You can do so easily by editing the start of the ROM.

´´´

// SDK default, 0x80371240
//                  DCBBAA
// AA = LAT
// BB = PWD
//  C = PGS
//  D = RLS
//
// 1 cycle = 1/62.5 MHz = 16ns
// Time = (register+1)*16ns
// LAT = tL = 0x40 = 65 cycles
// PWM = tP = 0x12 = 19 cycles
// PGS      = 0x07 = 512 bytes page size
// RLS = tR = 0x03 = 4 cycles

´´´

Also, if you end up compiling your own pico firmware, you have to use at least gcc 12.x IIRC. Older versions will not optimize the code enough.

[michalderkacz]

Managed to compile the PicoCart using arm-gnu-toolchain-12.3.rel1.

Added some debug prints:

    cic_write_id(region);
    stdio_uart_out_chars("write_id\r\n", 10);

    // hw_tim_setup(TIM_ID_CIC, 500, cic_write_id_failed);

    cic_write_seed();
    stdio_uart_out_chars("write_seed\r\n", 12);
    // hw_tim_stop(TIM_ID_CIC);

    cic_write_checksum();
    stdio_uart_out_chars("write_checksum\r\n", 16);
    cic_init_ram(region);
    stdio_uart_out_chars("init_ram\r\n", 10);

    uint32_t iter = 0;
    while (1) {
        uint8_t cmd = 0;
        cmd |= (cic_read() << 1);
        cmd |= cic_read();
        uart_print_hex_u32(iter++);

        switch (cmd) {
        case 0:{
                stdio_uart_out_chars("compare_mode\r\n", 14);
                cic_compare_mode(region);
                break;
            }

        case 2:{
                stdio_uart_out_chars("x105_mode\r\n", 11);
                cic_x105_mode();
                break;
            }

        case 3:{
                stdio_uart_out_chars("reset_cb\r\n", 10);
                cic_soft_reset(cic_reset_cb);
                break;
            }

        case 1:
        default:{
                stdio_uart_out_chars("default\r\n", 9);
                while (1) {
                    vPortYield();
                }
                break;
            }
        }
    }

NTSC

PicoCart64 Boot (git rev 2d88074a)
cic_task_entry
second_task_entry
write_id
write_seed
write_checksum
init_ram
00000000
compare_mode
00000001
compare_mode
00000002
compare_mode
00000003
compare_mode
00000004
compare_mode
00000005
compare_mode
00000006
compare_mode
00000007
compare_mode
00000008
compare_mode
00000009
compare_mode
0000000A
compare_mode
0000000B
compare_mode
0000000C
compare_mode
0000000D
compare_mode
0000000E
compare_mode
0000000F
compare_mode
00000010
compare_mode
00000011
compare_mode
00000012
compare_mode
00000013
compare_mode
00000014
compare_mode
00000015
compare_mode
00000016
compare_mode
00000017
compare_mode
00000018
compare_mode
00000019
compare_mode
0000001A
compare_mode
0000001B
compare_mode
0000001C
compare_mode
0000001D
compare_mode
0000001E
compare_mode
0000001F
compare_mode
00000020
compare_mode
00000021
compare_mode
Hello from the N64!
00000022
compare_mode
00000023
compare_mode
...

PAL

PicoCart64 Boot (git rev 2d88074a)
cic_task_entry
second_task_entry
write_id
write_seed
write_checksum
init_ram

Both working PAL cartridges use the same PIF-NUS-7101.

[michalderkacz]

Before delving further into this issue, I wanted to be able to test with another PAL console.

Eventually tested my PicoCart with another two consoles PAL and NTSC, so for now it had the opportunity to work with two PAL ones and two NTSC ones.

My PicoCart works with both NTSC N64s and doesn't work with both PAL ones.

It seems that PAL consoles doesn't like my DIY cart. I think it's probably an electrical problem (noise, etc.). I'll keep investigate this further in my free time.

[kbeckmann]

I’m sorry I don’t know. It should work fine if you use a picocart v1 lite PCB with one of the supported pico boards and clones (weact 16MB is confirmed to work fine).

[kbeckmann]

Before I close this, did you try to lower the bus speed? It's easily done by increasing the values in the rom. E.g. changing 0x80371240 into 0x8037FF40 or something.

[michalderkacz]

After changing 12 to FF the testrom stared first time but reported an error (red bar, unfortunately restarted it too fast to see something more). Next three or more times didn't started at all and after that it stared starting every time. The RNG stress test runs noticeably slower.

Next I tested it with another PAL console. Didn't start at all.

Flashed the original testrom and now it also runs every time (RNG stress test runs fast) on one of PAL N64 and, of course itdoesn't start on another one. Now I've one PAL console that works with my Picocart and one that doesn't. There is definitely a progress ;-)

I think you can close this issue because it's probably an electrical problem with my DIY picocart (noise, unmatched impedances, etc.).

But can you check if the 240p test suite works for you: https://twitter.com/240pTest/status/1215673194461515778 (the 240pSuite-newer.z64 one). It's very useful tool and I can't run it on both NTSC and PAL consoles. If you are interested in its source code you can find it here: https://github.com/ArtemioUrbina/240pTestSuite/tree/master/240psuite/N64

[kbeckmann]

I'll have a look at the 240psuite, doesn't feel right that it doesn't work, so thanks for reporting that! 🙂

Yeah, it sounds like an electrical issue with your problems here. Recommend getting a PCB and soldering a pico onto it, as it improves the signal integrity.