nesdev.org

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.

Chris Covell's TapeDump utility does something like this, but you have to disable the CIC to get it working on a frontloader.

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

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?

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.

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

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.

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.