Currently the code expects us to handle all PI read and write requests. If we don't, the state machine ends up in a bad state.

Example: User has a physical N64DD connected which will respond to certain memory accesses. If we also respond, there will be a bus conflict.

Solve this by e.g. resetting the state machine in the else case in the big while/if chain in n64_pi.c

How to test? Not sure, don't have a N64DD,

From korgeaux:

user presses reset
PIF sends command 3 and keeps CLK down
~500 ms delay
CIC pulls DQ down
PIF sets CLK up
CIC pulls DQ up
PIF asserts and releases NMI

See https://github.com/Polprzewodnikowy/SummerCollection/blob/lcmxo2/sw/controller/src/cic.c#L282-L291

First, just implement something that can write and read the PSRAM.

Write test code that fills whole PSRAM with pseudo-random numbers, then verify.

Measure performance, latency.

Investigate how to tie it in to the n64 bus PIO.

Can we use this to run arbitrary code from closed source ROMs without patching?

What do we need to patch in order to jump to our memory area?

Can we extract screenshots from the frame buffer directly?

Possible to debug?

Read/write memory, and continue?

Investigate if it's possible and practical to let one RP2040 (pico1) boot from a second RP2040 (pico2) by connecting the Flash pins to the gpios of the second.

Might need to use PIO to emulate flash in the second RP2040.

Will probably need to lower the flash speed configuration

Implementation idea:

pico2 loads the image it wants to emulate into RAM first.
pico2 sets up PIO to quickly serve QSPI read requests.
Could borrow code/ideas from the PicoCart64 code.

In the v2 concepts we need pico1 (connected to the n64 bus) to load/send:

• sram data
• wifi data
• sdcard data
• debug data
• etc...

via MCU2.

Start prototyping on a communication solution for this.

Let the cart connect to the user's wifi, then connect to a server (either local or on the internet maybe?), then let the user control the server to push out a ROM file on demand.

Prepare some kind of firmware for the ESP32-C3 so it can be used as a WiFi peripheral.

Most promising path seems to be to run https://github.com/adafruit/nina-fw on the ESP32-C3, and https://github.com/adafruit/WiFiNINA on the RP2040.

Ensure that it can be programmed by #4

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.

This is mostly useful for tiny homebrew ROMs, but might be useful for users who use the Pico which only has 2MB of flash.

Idea:

Python script that chops up the file into 4k blocks, generate a table that points to the right block, write the mapping in c code done

How fast can we go?

Once the ROM is in PSRAM, with our own probably faster QPI controller, we might have really low latency and might be able to go below 200ns on a constant basis.

Patch the PI configuration word to lower values.

Write a stress test ROM.

Update:

Not going for a custom QSPI controller. But by doing prefetching, data could be served quite fast.

A stress test ROM is still something we should do.

Hi Sir

built one lite ,can boot to the menu but can't run testROM(there has one fail item)

pressed all button and no action

My step as below, please help me for improve it, many thanks Sir

1. programmed picocart64-v1-ntsc.uf2
2. Created testrom.uf2
3. programmed testrom.uf2

Currently we can't meet the timing of 0x1240 and need to patch it to something higher (0x1280 works).

Curious.

Are there any plans to add the ability to stream data straight to the cartridge over the USB port while everything is plugged in and the console is running?

Would be a boon for homebrew devs looking for a cheap USB devcart.

I was wondering, if you run the code from RAM, could you connect more flash or an SD-card to the QSPI pins? You won't have the execute-in-place available, but could store data?
Or is there a hardware/software limitation?

That would free up a few pins for the N64 bus.

Sorry for the silly issue but the discord invite link in the Readme is expired. Thanks! Great project here.

After #12 is done, look into how to backup the SRAM after the system has been running. Some solutions seem to trigger SRAM saving by holding the reset button on the N64 (N64_COLD_RESET is held low during this time I think).

Write code that saves the SRAM to external flash.

Write code that can load an initial SRAM image before booting the software.

For now, let's focus on using the external flash, and SDCard/WiFi later on. Let's worry about the trigger later (N64_CR or something else).

Do this after we have EEPROM support as it shares the same interface.

I was thinking, right now we have only three free gpios remaining, which could be used for Savegames or for SD Card, but not both at the same time/cartridge, so, what about using a MCP23017 (GPIO expansion module) in not-crucial timing I/O?

For example (disclaimer: I'm not yet familiar with the code), it's obvious that we couldn't use it with AD* pins, but what about Cold Reset? Or maybe for CS pins on SPI modules)

It's just an idea btw, so don't take it as a solid solution

Depending on the ROM, the appropriate CIC chip needs to be emulated, as well as the correct region.

• Figure out the details around this
• Can we detect the CIC chip required from the ROM data? Look at cen64 perhaps?
• Adapt cic.c to handle dynamic selection during bootup
• For now, scan the ROM data during boot (too slow perhaps?) or do it compile time (write a script generate header files for this?)
• For later, use config area and set CIC emulation config through menu system

Currently it's too slow except for homebrew or patched roms.

First investigate what existing solutions there are.

Can we reuse? Build upon, extend?

Pico2 should be the controller, WiFi module the peripheral.

Maybe reuse protocol solution from #5 in order to have some code reuse.

• Run the NES emulator on the second core
• Write N64 homebrew that
  • reads the framebuffer and displays it
  • writes input states

I started to write this for ECPKart64 here: https://github.com/kbeckmann/n64fun/blob/main/streaming/streaming.c

https://github.com/pbatard/libwdi/wiki/WCID-Devices

So I just got the picon64 v1 lite cart off eBay and now everything I see on here says it needs to be flashed with the firmware. The link I found to it is https://nightly.link/kbeckmann/PicoCart64/workflows/20_build/develop/picocart64

I keep getting and error 404 when I click on it idk if anyone has this same issue or what but need help

Apparently this is how the N64Digital discovers which rom is being loaded during boot.

EverDrive OS broadcasts the ROM ID over Joybus port 1 before booting a game so that N64Digital can load the appropriate settings.

See https://gitlab.com/pixelfx-public/n64-game-id for more details

See https://www.marcrobledo.com/RomPatcher.js/ for a neat implementation in JS.

This is a big task, might need to break it down. But the gist is, add support for N64DD.

First step is to implement the protocol, serve data from external flash for convenience.

Later we might want to stream the disk contents from the SDCard.

The official Raspberry Pi Pico pinout has 3V3 on pin 36. 3V3_EN is on pin 37, and is connected to VSYS (5V/VUSB) through a 100K resistor.

On the WeAct RP2040 boards, Pin 36 is GPIO29, and 37 is 3V3. This means that the pins 36 and 37 need to be connected together. However, this must not be done on the official Pico boards.

Add a solder bridge jumper to do this easily, but add a clear warning/explanation so people don't bridge this by mistake.

I have no idea how this works but as long as it's rom patches and not ram patches it should be doable. We could patch the ROM while loading it into PSRAM.

We need an RTOS to run CIC emulation and EEPROM + FlashRAM emulation on the same core.

Investigate if there is a FreeRTOS port for RP2040 out there already, otherwise port it.

Since the Pico isn't an FPGA, it will be hard to latch data on a rising/falling edge of a clock, so we probably can't run it at system clock on the receiving side.

Investigate the limitations around this and what bandwidth we can reach using 4 data pins and 1 clock.

Map the SRAM area to physical SRAM on the RP2040.

Allocate 128kB for now. We might be able to use 256kB if we write our firmware carefully.

Use case:

• User downloads base firmware from github action artifact, flashes using UF2 mass storage
• User compresses ROM with a tool (python or online javascript thing), flashes it using picotool or UF2 mass storage

Let's start with the picotool approach, then build a javascript online tool that generates a uf2 file with a compressed ROM.

Write/port code that updates the ESP32-C3 WiFi module over UART and toggles the boot/reset pins, from an rp2040.

See https://github.com/espressif/esp-serial-flasher

Is the lite version of the board compatible with that pico 2040?

Look at https://github.com/pdaxrom/usb2n64-adapter

License is compatible.

Hello and thank you for this awesome project!

Have you got any plans to support other retro hardware? Having cheap flashcarts could definitely help the retro homebrew scene. Check out some of the awesome stuff that people are making: https://old.reddit.com/r/retrogamedev/

Hello there! I noticed that this repo has two licenses on it. Not sure if you knew, but GitHub made it so that you can upload several license files and it will show them without issue on the right hand side. Here is an example from one of my repos (https://github.com/MasonStooksbury/Hex-Clock)

The badges you see in my README can be added using this text. (They double as links to the license text as well):

[![License: CERN-OHL-P-2.0](https://img.shields.io/badge/Hardware_License-CERN--OHL--P--2.0-blue)](https://opensource.org/license/cern-ohl-p/)

[![License: MIT](https://img.shields.io/badge/Software_License-MIT-red.svg)](https://opensource.org/licenses/MIT)

I want to have physical boards when my vacation starts.