Single Chip Cartridge

[lidnariq]

Based on https://hackaday.com/2023/04/05/rp2040- ... -confirms/ looks like all but the ADC pins would be 5v capable for input, so if I were to do another one I'd to the address pins from GPIO 0-14, ROM CE 15 and then use level converters for the data pins from 16 onwards because at least one of the ADC pins needs to be used unless you stick with 16k ROM sizes.

But it's not truly 5v tolerant, so while it might work it may also reduce the life of the RP2040.

OEM NESes and Famicoms are NMOS, and the 2A03 and 2C02 don't manage to drive anything above 4V. Only because of this do I say that it should be safe.

Note this is only true for:
CPU A0-A14
M2
R/W
PPU A8-A13
PPU /RD, /WR

It is not true for:
/ROMSEL (from 74'139)
PPU /A13 (from 74'04 or 40'368 depending)
PPU A0-A7 (from 74'373)
CPU D0-D7 (SRAM is CMOS)
PPU D0-D7 (SRAM is CMOS)
Any famiclone-on-a-chip

I don't know if this is relevant or not but I found a Japanese Site the other day that is selling a homebrew Mapper 218 PCB of some sort I think it may even be flash-able, you can order it through Buyee if you are willing to pay the additional International Shipping cost. They also have a Kazzo script for it..

Oh that's amazing. Makes me really unreasonably happy.

[bitcores]

OEM NESes and Famicoms are NMOS, and the 2A03 and 2C02 don't manage to drive anything above 4V. Only because of this do I say that it should be safe.

This makes me a little surprised that using the logic level converters on the address lines even worked properly, considering the reference voltage is 5V.
It also makes me wonder if this causes some added latency that required the higher clock speed I have the Pico running at.

And that Mapper 218 PCB is nice. Looks like someone bought up all the stock, though.

[lidnariq]

This makes me a little surprised that using the logic level converters on the address lines even worked properly, considering the reference voltage is 5V.
It also makes me wonder if this causes some added latency that required the higher clock speed I have the Pico running at.

Since you're using boards with resistors and discrete MOSFETs, it should be possible to figure out depending on the specific MOSFETs and rest of circuit...

[bitcores]

I've put up the code running my cartridge.
https://github.com/bitcores/one_chip_pico

I think I will make a v2 with LLCs only for the data lines soon and see how that goes.

[bitcores]

So I made another cartridge only using LLCs for the data lines. I probably didn't need to swap the address and data pins around on the Pico but I think it is a little bit neater (ha!) this way considering where the data pins are on the ROM. ROMSEL is done through a voltage divider, to make sure it's around 3v so the ADC doesn't get damaged or anything. However, this did require a small change in the PIO code because the LLC causes pins to be HIGH before the Famicom is powered on while with the voltage divider the pin is in a LOW state.

This donor PCB was also configured differently than the last I used, wired to be permanently vertically mirrored (don't worry, I didn't destroy a Donkey Kong Jr. cart, it was one of many Mahjong variants) and required some trace cutting to set up the nametable jumpers.

Now I'm currently using FCEUX to test the code I'm writing for the Famicom (also looked at no$nes a little) but while I'm using the same NES headers as MagicFloor, there are some "differences" between rendering of the emulator and the hardware. My guess would be the emulator not strictly adhering to the 2kB memory limit (in fact, looking in the PPU memory it has still loaded the tiles into the Pattern table range and has the standard Nametable layout), but is there a way to configure the emulator to accurately represent mapping nametable RAM as CHR-RAM?

[lidnariq]

Mapper 218 support in FCEUX only was added in August 2022. Is your copy of FCEUX new enough? (2.6.5 was just released in February)

Historically I've used mapper 7, which at least limits the nametable usefully. You might also have good luck with Mesen2.

[bitcores]

I do have FCEUX 2.6.5, but trying Mesen2 seems to more closely replicate what my console is doing, thanks.

--edit--
My suspicions were right. VRAM was filled with garbage and the demo code I was learning from didn't have any example of zeroing it. FCEUX starts with a clean memory but Mesen2 had the option of filling it with random data, which helped.

[bitcores]

So I'm thinking about my cart again and whether I can actually write data to it by adding another connection to the CPU R/W pin on the slot. Emulators at least seem to block writing to the 8000-FFFF ROM space (at least in my NES port of WozMon I can't store values there), but I'm curious as to whether the actual hardware will allow it (looking at the schematic I don't see any reason why it wouldn't, unless it just didn't pull R/W low).
This has also made me curious about the 6000-7FFF address range that is usually used by PRG-RAM, and whether I could get access to that as well. What I'm thinking is that I can use couple of transistors or logic gate on A13 and A14 to open a path from ROMSEL to ground to forcibly "enable" my cart when the address is in the 6000-7FFF range.
Would it work? Is there some danger in doing this?

[lidnariq]

Emulators block writes to $8000-$FFFF because that's mask ROM in normal carts, and by definition those can't have their contents changed after the fact. But if you want to emulate RAM in that region, you can, and Famicom Disk System is an example of that.

You can place writeable registers anywhere you want, including on top of other things. Indeed, the vast majority of NES games do: MMC3 places its ROM (when reading) in the same location it places its configuration registers (when writing). The only real constraint is that you mustn't get in a bus conflict, where two things are driving the data bus at the same time.

In practice, that means you can place readable registers anywhere from $4000-$4014 and $4018-$FFFF.

As far as detecting when the CPU is accessing memory below $8000:
You noticed that you don't have A15, but you do have a signal that's derived from A15.
But /ROMSEL arrives after M2, so you can't just say "M2 is high, /ROMSEL is high, so A15 was low". You'll have to wait around 30-40ns after M2 rises to check /ROMSEL and use that to determine what A15 was.

[bitcores]

Emulators block writes to $8000-$FFFF because that's mask ROM in normal carts, and by definition those can't have their contents changed after the fact. But if you want to emulate RAM in that region, you can, and Famicom Disk System is an example of that.

Right, of course. The iNES header is telling the emulator that it's a ROM so it goes read only, and there are other headers for Disk System which would allow writing in the PRG-ROM space. I'll have to look into that more.

As far as detecting when the CPU is accessing memory below $8000:
You noticed that you don't have A15, but you do have a signal that's derived from A15.
But /ROMSEL arrives after M2, so you can't just say "M2 is high, /ROMSEL is high, so A15 was low". You'll have to wait around 30-40ns after M2 rises to check /ROMSEL and use that to determine what A15 was.

I'm worried about how much logic I'd have to add in the C portions of the code to do this programmatically, I don't think there's much leeway available (dropping the Pico overclock by 10% or so will impair it). For writes that wouldn't be such an issue, but the read responses have to be out the door in as few cycles as possible.
That's why I'm thinking about either forcing the /ROMSEL, or I guess constructing a /RAMSEL signal like on https://www.nesdev.org/wiki/PRG_RAM_circuit
The /RAMSEL signal might actually be ideal, because then I could run it's code on the second PIO block and the second CPU core to minimize programmatically determining what is going on.
I guess I'll start with adding the R/W signal to the PRG-ROM access, to see if it is feasible, and then look at the /RAMSEL idea.

[lidnariq]

That's why I'm thinking about either forcing the /ROMSEL, or I guess constructing a /RAMSEL signal like on https://www.nesdev.org/wiki/PRG_RAM_circuit

If you're open to just solving this externally, the best approach is to make a re-shaped M2 that goes to its final state after /ROMSEL - and maybe the data bus - is valid.

[bitcores]

If you're open to just solving this externally, the best approach is to make a re-shaped M2 that goes to its final state after /ROMSEL - and maybe the data bus - is valid.

Would this be adding a resistor and capacitor to the circuit like in that Pirate Gradius 2 fix?
Ideally, I would like to keep whatever solution on the cart so that I can plug it into any original console (though I think that can be put on the cart?), but it might be worth considering just to have more options available.

Now I feel like I should rebuild my v1 cart so I can make some more carts from the LLCs and have more testing platforms.

[lidnariq]

Yes, exactly. Just an RC on M2.

One game - mapper 82 - has pins for both M2 and an RC-delayed copy of M2, and ANDs the two internally.

For your purposes, you can used the rising edge of delayed M2 for reads, and the falling edge of not-delayed M2 for writes - if you can capture the buses fast enough, at least.

[Joe]

If you're limited on pins, I think you could add a diode in parallel with the resistor to delay only one edge of M2.

The R/C circuit also delays the M2 rise/fall times, and your level shifters (if you put it on the 5V side) or Pico (if you put it on the 3.3v side) might be unhappy if it's too slow. I don't know exactly what qualifies as "too slow" but it came up in this thread.

[bitcores]

Now I feel like I need to fast track buying a scope so I can see how much leeway I actually have in the response times.
I'm going to keep these in mind, but I think the Pico is going to be limited in programmatically determining whether to act on addresses in time.