Single Chip Cartridge
Moderator: Moderators
- krzysiobal
- Posts: 1036
- Joined: Sun Jun 12, 2011 12:06 pm
- Location: Poland
- Contact:
Re: Single Chip Cartridge
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.
Re: Single Chip Cartridge
Chris Covell's TapeDump utility does something like this, but you have to disable the CIC to get it working on a frontloader.
Re: Single Chip Cartridge
This has been done on the Atari 2600 a while ago (link), which is pretty impressive considering it has only 128 bytes of RAM.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.
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...
Re: Single Chip Cartridge
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?
Re: Single Chip Cartridge
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: 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.
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
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.
Re: Single Chip Cartridge
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
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
Re: Single Chip Cartridge
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.
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!
Re: Single Chip Cartridge
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:Magic Floor is now using DMA for OAM access, that should fix the NTSC drawing issues.
Certainly.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).
Re: Single Chip Cartridge
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.
I just got it working today, so code still needs work (preferably by someone skilled) but it does seem to run Magic Floor fine.
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.
Re: Single Chip Cartridge
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!
Re: Single Chip Cartridge
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.
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.
-
- Posts: 53
- Joined: Wed Sep 09, 2020 3:08 am
Re: Single Chip Cartridge
I'm not so sure if rp2040 is so bad of a choice then. How are 5V microcontrollers options on the market?
Re: Single Chip Cartridge
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...
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...
Re: Single Chip Cartridge
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.
Re: Single Chip Cartridge
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
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.
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.