Single Chip Cartridge

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

bitcores
Posts: 35
Joined: Thu Apr 20, 2023 3:09 am
Location: Japan

Re: Single Chip Cartridge

Post by bitcores »

So it seems there's just enough time to deal with 6000-7FFF access without having to reshape M2 or anything like that.
DSC_1968.JPG
But when I do access 6000-7FFF, it has this weird effect that persists until the Pico is power cycled and it's driving me up the wall :lol:
You can see when I read from 6000 there's no response, and then after that the first character of the address disappears and when I write to the 6000 range the first time the first byte disappeared, but the writes to 8000 are perfectly fine. There's something weird going on in this code.

--edit--
Ok, apparently the build option for the Pico code to "copy to ram" didn't put everything in RAM, and finding the correct way of doing that has fixed the problem.

--extra edit--
Further information.
It seems that the problem really comes down to the compiled size of the Pico program, perhaps due to the banked nature of the RAM in the Pico, if the program takes up too much space in memory there is added delay in accessing portions of it.
Using the no_flash option does solve this, but the program isn't persistent on the Pico with it, you have to upload it every time you power cycle the Pico. This option remains available and if you want to pre-load data into the PRG_RAM, this is the approach to take.
If you want to use the PRG_RAM just as RAM, I managed to squeeze down the program just enough that it seems to work fine.
The code for this revision is in this branch of my gihub project https://github.com/bitcores/one_chip_pi ... /v2+writes
I should probably do a wiring diagram at some point. I should probably also look at ways to compress and decompress the PRG data/ram, but the final compiled size, including decompression code, needs to be under 87kB.
khari
Posts: 11
Joined: Sat Feb 17, 2024 10:45 pm
Location: USA - Eastern Time

Re: Single Chip Cartridge

Post by khari »

It looks like you have wozmon running from the picture of your screen. I have a few questions.

How did you get keyboard input to the NES? Do you have a family basic keyboard or did you build the PS/2 to famicom adapter? update: I dug through your source code and the characters cycle with controller inputs.

It seems like you have your rp2040 only wired to the CPU address lines/data bus. Is there another ROM chip for the PPU or do some programs run properly even when the PPU data/address lines are left floating?
bitcores
Posts: 35
Joined: Thu Apr 20, 2023 3:09 am
Location: Japan

Re: Single Chip Cartridge

Post by bitcores »

khari wrote: Sat Feb 17, 2024 11:01 pm It seems like you have your rp2040 only wired to the CPU address lines/data bus. Is there another ROM chip for the PPU or do some programs run properly even when the PPU data/address lines are left floating?
I have my cart configured the same way nocash does in the opening posts of this thread, using Mapper 218.
The PPU RAM is permanently enabled, so a CHR-ROM/RAM on the cartridge isn't used and the lines are left floating. This lets you use the PPU RAM as CHR-RAM, but it is also very limited.
Programs pretty much need to be designed around this Mapper because of the very limited CHR-RAM available.

When I found out that Family Basic existed, I started thinking about if I could connect a keyboard to make Wozmon easier to use and perhaps even build MS Basic for this cart. It's unfortunate if it can only work on the Famicom and not the NES, though.

I may as well plug the PCB I designed for this cart. There's instructions for what options to use when ordering them in the repo readme file https://github.com/bitcores/one_chip_pi ... 2%2Bwrites
pcb-front.JPG
I've thought about making a second that is NES compatible, but the need for a CIC (I think?) but this one should be able to be used in a Famicom -> NES adapter cartridge so that's probably the better path.
khari
Posts: 11
Joined: Sat Feb 17, 2024 10:45 pm
Location: USA - Eastern Time

Re: Single Chip Cartridge

Post by khari »

bitcores wrote: Wed Feb 21, 2024 1:17 am Programs pretty much need to be designed around this Mapper because of the very limited CHR-RAM available.

When I found out that Family Basic existed, I started thinking about if I could connect a keyboard to make Wozmon easier to use and perhaps even build MS Basic for this cart. It's unfortunate if it can only work on the Famicom and not the NES, though.
I originally didn't consider the mappers very much. I know that $4020 to $FFFF is free for the cartridge to use however it pleases. If the cartridge is all writable, we can kind of ignore any of the mapper restrictions the console originally had and make it turn as much address space as needed into RAM. I then realized the main purpose of the mapper scheme was to keep homebrew stuff compatible with emulation.

I had the same idea for running Wozmon with the basic keyboard and went looking to see if it was possible. There was a PS/2 keyboard to Family Basic keyboard adapter posted by emerson the forums about 4 years ago. It should be compatible with the NES since the original keyboard plugged into the Famicom Expansion port, which has 15 of the 48 pins in the NES Expansion port: https://www.nesdev.org/wiki/Expansion_port.
bitcores wrote: Wed Feb 21, 2024 1:17 am I've thought about making a second that is NES compatible, but the need for a CIC (I think?)
I dug into this too. There's now a clone chip to emulate the CIC in a cartridge with an 8-bit ATTiny13A microcontroller: https://moddingfridays.bleu255.com/Mult ... _CIC_Clone. I think most DIY NES cartridge PCBs use this AVR CIC chip. The cheapest DIY NES cartridge board seems like a mapper zero NROM cartridge which I think has all of its pins broken out for anyone to solder two EEPROMs to it. I was thinking that maybe the next revision should use two Pico boards to emulate both CPU ROM/RAM and PPU ROM/RAM to make it easy to switch whatever mapper it wants to imitate.
lidnariq
Site Admin
Posts: 11524
Joined: Sun Apr 13, 2008 11:12 am

Re: Single Chip Cartridge

Post by lidnariq »

khari wrote: Wed Feb 21, 2024 1:18 pm I was thinking that maybe the next revision should use two Pico boards to emulate both CPU ROM/RAM and PPU ROM/RAM to make it easy to switch whatever mapper it wants to imitate.
A few mappers rely on extremely precise synchronization between the PPU and CPU, especially MMC3 and MMC5 IRQs. Accuracy for this might be out of reach.

On the other hand, emulating MMC2 or VRC4 and their ROMs using two Picos should be easy.
bitcores
Posts: 35
Joined: Thu Apr 20, 2023 3:09 am
Location: Japan

Re: Single Chip Cartridge

Post by bitcores »

khari wrote: Wed Feb 21, 2024 1:18 pm I was thinking that maybe the next revision should use two Pico boards to emulate both CPU ROM/RAM and PPU ROM/RAM to make it easy to switch whatever mapper it wants to imitate.
I have no plans to make a version with two Picos. For starters, this is a "Single Chip Cartridge" thread so once you put two Picos in it you're back to two chips.
Theoretically it shouldn't be too difficult to modify the project to target two Picos but there are some disadvantages that would probably make buying a flash cart a better option.
Firstly, you have to break your project into two rom files. You need to build it targeting PRG and CHR separately (unless you run it as CHR-RAM). With flash carts you can just build it all into one rom file.
Secondly, you need to build for the Pico twice and flash twice. If wired up in the same way it might be able to use the same build file, but the build file might need to be tweaked for the PPU timing.
Thirdly, you need logic level converters for all the PPU lines, because according to lidnariq they're all nominally 5V unlike the CPU lines that are around 4V. You can get 8 input/output LLC chips, but this is going to more than double the size of a board running this (unless you make a multi-layer PCB).
And lastly, once you have the two Picos, all the LLC chips and boards, you've probably spent about as much as a flash cart. You might be able to do some weird stuff having these micro controllers that you can't do on a flash cart, but unless you have something like that in mind the flash cart seems just a better idea for writing homebrew.

Now currently I'm able to map all of $6000 to $FFFF on my cart, and it is all writeable, but I don't think that really helps with the limited PPU SRAM because the PPU can't directly get at it. You need to use the CPU to swap out data, which is something some games do with updating CHR-RAM mid frame, but you can't do that very often within one frame without causing slowdowns.

It's good to see there is a path to compatibility between Famicom and NES (I'm not familiar with NES hardware, I just have a Famicom here and only started this within the last year) but looking at emerson's solution it looks overbuilt for what I am thinking. I may just be able to use something like a Teensy to pretend it is a Family Basic keyboard.
khari
Posts: 11
Joined: Sat Feb 17, 2024 10:45 pm
Location: USA - Eastern Time

Re: Single Chip Cartridge

Post by khari »

bitcores wrote: Thu Feb 22, 2024 5:25 am looking at emerson's solution it looks overbuilt for what I am thinking. I may just be able to use something like a Teensy to pretend it is a Family Basic keyboard.
I think I could imitate a family basic keyboard with PIO from an RP2040 if I had a few hours and some good docs. need to look for more detailed specs on how the family basic communicates first.

This is a slightly unrelated but just now, I was checking how much an RP2040-Plus board costed and stumbled upon a dev board with an RP2040 and an iCE40 FPGA: https://www.tindie.com/products/tinyvis ... up5k-fpga/ I know absolutely nothing about FPGA development, but it seems like it would be a more cost-effective way to emulate multiple ROMs for a cartridge with RAM/ROM for both the CPU and PPU. I have almost no idea how to write something like that, but it seems like a neat concept.
bitcores
Posts: 35
Joined: Thu Apr 20, 2023 3:09 am
Location: Japan

Re: Single Chip Cartridge

Post by bitcores »

khari wrote: Thu Feb 22, 2024 7:58 pm This is a slightly unrelated but just now, I was checking how much an RP2040-Plus board costed and stumbled upon a dev board with an RP2040 and an iCE40 FPGA: https://www.tindie.com/products/tinyvis ... up5k-fpga/ I know absolutely nothing about FPGA development, but it seems like it would be a more cost-effective way to emulate multiple ROMs for a cartridge with RAM/ROM for both the CPU and PPU. I have almost no idea how to write something like that, but it seems like a neat concept.
Looking at how they have broken out the GPIO on the RP2040 and iCE40, many of them share the same pins. They actually have a few GPIOs broken out that aren't available on the Pico, 23 - 25 and 27, so there might just be enough to have both PRG and CHR on that one package, but the way they are arranged would be tricky to organize.
khari wrote: Thu Feb 22, 2024 7:58 pm I think I could imitate a family basic keyboard with PIO from an RP2040 if I had a few hours and some good docs. need to look for more detailed specs on how the family basic communicates first.
The reason I mentioned using a Teensy was because again we are looking at 5V data lines (though OUT 0-2 from the CPU will be more like 4V) which means needing LLCs for a RP2040. We would need five data lines through an LLC or four plus a voltage divider for the clock signal on the Famicom side and two for data and clock on the keyboard side (though some keyboards will work on 3.3V input and so the data and clock will be 3.3 in that case).
Looking at the Famicom schematic and the wiki page on the Family BASIC Keyboard, I think the PIO code for that side would be much like I already have for my cart, and people have already written libraries for connecting a PS/2 keyboard to the Pico so we just have to glue it together.

As for how the communications works from what I gather, OUT2 should be high all the time for the keyboard to be enabled. OUT0 will go high and then low to signal reset of column and row to 0.
Then you'll read from $4017, which will enable read from the keyboard. The keyboard (Pico) will receive the M2 clock pulse to signal enabling the output and putting the 4 bits on the data bus D1 to D4, then the CPU will read the data on the falling edge of the clock signal and then disable read from the keyboard. (see below image)
Then you toggle OUT 1 to move to the next column or row. Then repeat the read from $4017 until you've read all the columns and rows.
6502controllerread.png
edit: actually it looks like OE0/OE1 should go low when M2 goes high, so probably at the time I have "Enabled controllers receive clock pulse"

I'm sure if I made mistake lidnariq will correct it. But I'm also thinking we should move the discussion of a keyboard adapter to a different thread, because it's not on topic.
lidnariq
Site Admin
Posts: 11524
Joined: Sun Apr 13, 2008 11:12 am

Re: Single Chip Cartridge

Post by lidnariq »

bitcores wrote: Thu Feb 22, 2024 5:25 am Thirdly, you need logic level converters for all the PPU lines, because according to lidnariq they're all nominally 5V unlike the CPU lines that are around 4V.
PPU A13-A8 should be 4V; PPU /RD and /WR should be 4V.

You're right that PPU A7-A0, D7-D0, /A13 should all be "real" 5V.
bitcores wrote: Thu Feb 22, 2024 11:26 pm Then you'll read from $4017, which will enable read from the keyboard.
Controllers are on their own bus, and you can't interfere safely from the cartridge port. (There's a 40H368 or 74HC368 driving the data bus when the CPU reads from $4016 or $4017).
The keyboard (Pico) will receive the M2 clock pulse to signal enabling the output and putting the 4 bits on the data bus D1 to D4, then the CPU will read the data on the falling edge of the clock signal and then disable read from the keyboard.
As a result from the above '368s, the Family Basic keyboard doesn't know or care about the read strobe (on OE2) - this is why it's clocked by toggling OUT1.
But I'm also thinking we should move the discussion of a keyboard adapter to a different thread, because it's not on topic.
I'd say this is early enough that you should make another thread, and I'll edit my post here to match, if you want.
bitcores
Posts: 35
Joined: Thu Apr 20, 2023 3:09 am
Location: Japan

Re: Single Chip Cartridge

Post by bitcores »

lidnariq wrote: Fri Feb 23, 2024 1:39 am PPU A13-A8 should be 4V; PPU /RD and /WR should be 4V.

You're right that PPU A7-A0, D7-D0, /A13 should all be "real" 5V.
I should have realized that the PPU was NMOS as well, you even said so in that previous post.
lidnariq wrote: Fri Feb 23, 2024 1:39 am Controllers are on their own bus, and you can't interfere safely from the cartridge port. (There's a 40H368 or 74HC368 driving the data bus when the CPU reads from $4016 or $4017).
This is something I was thinking but wasn't sure of. So seeing the OE signals are being gates for the controllers to the data bus, we could constantly output the currently selected column/row without having to time it like I do with the cartridge. That would simplify the code a lot.
khari
Posts: 11
Joined: Sat Feb 17, 2024 10:45 pm
Location: USA - Eastern Time

Re: Single Chip Cartridge

Post by khari »

bitcores wrote: Fri Feb 23, 2024 2:51 am
lidnariq wrote: Fri Feb 23, 2024 1:39 am PPU A13-A8 should be 4V; PPU /RD and /WR should be 4V.

You're right that PPU A7-A0, D7-D0, /A13 should all be "real" 5V.
I should have realized that the PPU was NMOS as well, you even said so in that previous post.
When looking closely at the PCB on my NES from 1989, some of the chips mentioned are LS series rather than HC so some NES consoles wll require fewer logic converters than others. However, it is definitely better to be safe in case anybody reads this thread and builds a cartridge PCB that isn't compatible with the higher logic level in some consoles.
bitcores
Posts: 35
Joined: Thu Apr 20, 2023 3:09 am
Location: Japan

Re: Single Chip Cartridge

Post by bitcores »

khari wrote: Fri Feb 23, 2024 5:29 pm When looking closely at the PCB on my NES from 1989, some of the chips mentioned are LS series rather than HC so some NES consoles wll require fewer logic converters than others. However, it is definitely better to be safe in case anybody reads this thread and builds a cartridge PCB that isn't compatible with the higher logic level in some consoles.
It should also be noted that this all applies only to official consoles. All knockoff/offbrand compatible models need to be treated at nominal 5V everywhere.
Even my cartridge should not be put in an unofficial console. And I don't think I actually put a warning about that on my github.
khari
Posts: 11
Joined: Sat Feb 17, 2024 10:45 pm
Location: USA - Eastern Time

Re: Single Chip Cartridge

Post by khari »

bitcores wrote: Fri Feb 23, 2024 6:08 pm All knockoff/offbrand compatible models need to be treated at nominal 5V everywhere.
At that point, if 3 SN74AHCT245N logic translators are needed to be safe for all consoles, is it even a one chip cartridge anymore?
bitcores
Posts: 35
Joined: Thu Apr 20, 2023 3:09 am
Location: Japan

Re: Single Chip Cartridge

Post by bitcores »

khari wrote: Sat Feb 24, 2024 9:07 pm At that point, if 3 SN74AHCT245N logic translators are needed to be safe for all consoles, is it even a one chip cartridge anymore?
Technically the first prototype I made in viewtopic.php?p=287730#p287730 would be fully 5V safe because I used LLCs on all the lines and it has no other "chips". Using 8 channel rather than 4 channel would probably have saved some space, though.
khari
Posts: 11
Joined: Sat Feb 17, 2024 10:45 pm
Location: USA - Eastern Time

Re: Single Chip Cartridge

Post by khari »

bitcores wrote: Wed Feb 21, 2024 1:17 am When I found out that Family Basic existed, I started thinking about if I could connect a keyboard to make Wozmon easier to use and perhaps even build MS Basic for this cart. It's unfortunate if it can only work on the Famicom and not the NES, though.
My cartridge is currently WIP, and I've been thinking of testing some other stuff soon. Any idea whether the original family basic has been ported to mapper 218?
Post Reply