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

User avatar
krzysiobal
Posts: 1036
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: Single Chip Cartridge

Post by krzysiobal »

What about making a 0 chip cartridge (or half chip) - the game would have just one prg-rom chip, but quickly after running, it would copy itself into internal nes ram and start executing itself from here. The cart could be then removed and the game wouldn't break. Ook, removing the cart would break the graphics as the vrom !cs line wouldnt be any longer connected to gnd, but then you could insert specially prepared pcb that contains only two jumpers - one that connects vrom !cs to gnd and the second that connects vram a10 to pa13. :D
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Single Chip Cartridge

Post by tepples »

Chris Covell's TapeDump utility does something like this, but you have to disable the CIC to get it working on a frontloader.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Single Chip Cartridge

Post by tokumaru »

krzysiobal wrote:What about making a 0 chip cartridge (or half chip) - the game would have just one prg-rom chip, but quickly after running, it would copy itself into internal nes ram and start executing itself from here. The cart could be then removed and the game wouldn't break.
This has been done on the Atari 2600 a while ago (link), which is pretty impressive considering it has only 128 bytes of RAM.

Now, looking at this thread again... We never had a compo of games for the single-chip cartridge, did we? That would've been a fun one...
JRoatch
Formerly 43110
Posts: 422
Joined: Wed Feb 05, 2014 7:01 am
Contact:

Re: Single Chip Cartridge

Post by JRoatch »

I'm curious, how would a single chip cartridge behave on a SOAC clones? I know that those clones have problems with 4-screen because the system fails to select cart RAM for nametables, but will they fail the other way and fail to select the internal ram for CHR?
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Single Chip Cartridge

Post by lidnariq »

Yeah. Those particular Famiclones short CIRAM /CE to PPU /A13, so the 2KiB of RAM is always enabled for nametable fetches and always disabled for pattern fetches, meaning that this CHR-less design won't work on them.

On Famiclones that retain the NES's multiplexing of the PPU data bus, all the tiles will be the open bus pattern:

Code: Select all

abcd2000
abcd2003
abcd2030
abcd2033
abcd2300
abcd2303
abcd2330
abcd2333
where abcd = the low four bits of the tile that's being fetched (in colors 0 and 3)

On famiclones that don't, all the tiles would be a repeat of the fetched attribute table byte, so each 32x32 pixel zone would be the same 8 wide x1 high pattern, and it would be a function of the colors chosen for each 16x16 zone.


On the other hand, I don't actually know just how widespread this particular famiclone bug is. Clearly enough that it's well documented, like the reversed duty cycles bug.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Single Chip Cartridge

Post by nocash »

I've update Magic Floor, and released another single-chip game: Starfight.

Magic Floor is now using DMA for OAM access, that should fix the NTSC drawing issues. The random generator does now start with smaller floors which is making the game a bit easier. The boulder is now a bit larger (the old 8x8 pixel boulder looked a bit lost on the 32x32pixel floor cells). And, with that minor changes, the ROM image grew to about 1020h bytes : / not so much a problem, but I was troubled by the idea of releasing something that's missing the 4K boundary by only 20h bytes, so I've added the decompression function from Starfight in there, too.
http://problemkaputt.de/magicflr.htm
I've also added two gif's and a link to tepples' Magic Floor gameboy version on the above webpage (hope that's okay). That version comes up with several nice additions (which, no, I don't have them adopted in the NES update - maybe I'll do so someday).

Starfight is an old Amstrad CPC 4Kbyte type-in shoot-em-up game made by Herve Couppe. I've released Gameboy and ZX81 ports of the game some many years ago. So, now there's also a NES port. It's using only 64 tiles, so it's working fine as mapper 218 (in fact it's barely using half the tiles at once, so there would be still room for more graphics). Sprites, colors, and sounds are more or less same as in the original CPC version. The game takes up about 1100h bytes, after adding a decompression function it grew to almost 1200h bytes - but after applying actual compression I got it down to less than 1000h bytes (no requirement for mapper 218, but I like 4Kbyte games). The problem about compression was that the NES has only 2K main RAM, so I had to split the game to three compressed 'overlay' snippets (tile data, title screen, and game engine).
http://problemkaputt.de/starfigh.htm
Apropos, does somebody know how to contact the original author in france? I've never found a contact address anywhere. Except, there's a video for the ZX81 Starfight version on youtube with a comment from somebody called Herve Couppe, so maybe that's him, but I don't have a youtube account, and don't even know if youtube has some sort of PM function(?)

Testing
Starfight and the Magic Floor update are both untested on real hardware (I've recently lost my home and my own PAL NES is now buried under tons of cardboard boxes, and I don't have a NTSC NES anyways). Would be nice if somebody could jump in and test the games on PAL and NTSC consoles. If you don't have mapper 218 hardware, anything with CHR-RAM should also work (eg. NROM mapper 0 with CHR-RAM, or AOROM mapper 7). The game source code allows to change "mapper_no" to that values (and can be then reassembled via Utility/Assemble File in no$nes.

Ah, yes, and I've released a new no$nes update today, see here: viewtopic.php?f=3&t=17959
User avatar
Dwedit
Posts: 4922
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Single Chip Cartridge

Post by Dwedit »

I still think that Mapper 218 should have been a NES 2.0 submapper of 7, so that every emulator in existence would already support it. Otherwise, I need to grab a hex editor and change the mapper to 7 myself.

edit: Trying to figure out what is breaking it on certain older emulators... Some emulators refuse to emulate mapper 7 without expanding the rom size to 32k. Some emulators are showing no nametables at all. Oddly enough, it works perfectly on Nesticle.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Single Chip Cartridge

Post by tepples »

nocash wrote:Magic Floor is now using DMA for OAM access, that should fix the NTSC drawing issues.
It does. I replaced the mapper number with 0 (NROM) + vertical mirroring, and it worked on my PowerPak the first time. I realized after completing a few floors that I had "got gud" since the first time I tried it. It must've been all the practice on the Game Boy port.
nocash wrote:And, with that minor changes, the ROM image grew to about 1020h bytes : / not so much a problem, but I was troubled by the idea of releasing something that's missing the 4K boundary by only 20h bytes, so I've added the decompression function from Starfight in there, too.
http://problemkaputt.de/magicflr.htm
I've also added two gif's and a link to tepples' Magic Floor gameboy version on the above webpage (hope that's okay).
Certainly.
bitcores
Posts: 18
Joined: Thu Apr 20, 2023 3:09 am
Location: Japan

Re: Single Chip Cartridge

Post by bitcores »

I'm very new to this but I drew inspiration from the PicoCart64 project and this Single Chip Cartridge thread to make a Pico driven Single Chip Cartridge.
DSC_1779.JPG
DSC_1780.JPG
Clearly a 5v microcontroller would have been a better choice to avoid all the level shifters. I also based it on a 16k ROM cart (not by design) so A14 is not connected (do that later).
I just got it working today, so code still needs work (preferably by someone skilled) but it does seem to run Magic Floor fine.
DSC_1786.JPG
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Single Chip Cartridge

Post by lidnariq »

I've been talking about wanting to do this for a while now, so it's awesome to see someone else beat me to it!
bitcores
Posts: 18
Joined: Thu Apr 20, 2023 3:09 am
Location: Japan

Re: Single Chip Cartridge

Post by bitcores »

Learn from my mistakes.
I'll make the code available soon, it uses the pio functionality of the Pico and written in C, so it should be easily ported to other microprocessors. Very simple at this point too.
Another random thought I had was that it should be possible to emulate, to some degree, MMC functionality if there is a framework for how to address the microprocessor to trigger swapping of data in the "ROM" space. I haven't attempted it but it is an idea. Perhaps one could also in that way load new tiles into the CHR-RAM.
But this would be making something completely focused on this hardware environment. Just some thoughts.
stan423321
Posts: 53
Joined: Wed Sep 09, 2020 3:08 am

Re: Single Chip Cartridge

Post by stan423321 »

I'm not so sure if rp2040 is so bad of a choice then. How are 5V microcontrollers options on the market?
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Single Chip Cartridge

Post by lidnariq »

RP2040 is a pretty good choice, given how both affordable and available it is right now.

High-speed 5V-native or 5V-tolerant micros with fast GPIO are fairly rare. And some of the pins on the RP2040 have a different overvoltage protection structure that renders them 4.5V-tolerant...
bitcores
Posts: 18
Joined: Thu Apr 20, 2023 3:09 am
Location: Japan

Re: Single Chip Cartridge

Post by bitcores »

lidnariq wrote: Sat Apr 22, 2023 10:35 am And some of the pins on the RP2040 have a different overvoltage protection structure that renders them 4.5V-tolerant...
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.
Zoldark
Posts: 72
Joined: Sat Oct 28, 2017 10:18 am
Contact:

Re: Single Chip Cartridge

Post by Zoldark »

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..

https://booth.pm/en/items/2824053
Don't buy FamicomNes games WillyNilly Check the Mapper first
https://www.nesdev.org/wiki/Mapper
https://nescartdb.com/
I feel like I said something wrong even if I didn't I don't know for sure and I always feel bad about it.
Post Reply