12 ms·
Inside the Super Nintendo cartridges
- SEXMCNIGGA48766 3y ago[dead]
- 2genders30551 3y ago[dead]
- 2genders31285 3y ago[flagged]
- sexmc28373 3y ago[flagged]
- sexmc25061 3y ago[flagged]
- sexmc11078 3y ago[flagged]
- sexmc45161 3y ago[flagged]
- plugin-baby 3y ago> The author of DOOM for SNES, Randy Linden, did not have access to any documentation about the GSU chip or even DOOM source code. He reverse engineered all of it Technically this is impressive, but why was it necessary?
- MenhirMike 3y agoSome Details on the Doom Wiki (https://doomwiki.org/wiki/Super_NES https://doomwiki.org/wiki/Super_NES): Randy Linden, the port's sole programmer, initiated the port of Doom for the Super NES on his own initially, as he was fascinated by the game. Since Doom's source code was not yet released at the time, Linden referred to the Unofficial Doom Specs as a means of understanding the game's lump layout in detail. The resources were extracted from the IWAD, with some (notably sprites such as the player's sprites and the original status bar face sprites) unused due to technical limitations. According to an interview, due to lack of development systems for the Super FX, Linden wrote a set of tools consisting of an assembler, linker, debugger, dubbed the ACCESS, on his own Amiga before beginning development of the port proper. For the hardware kit, he utilized a hacked Star Fox cartridge and a pair of modified Super NES controllers plugged into the console and connected to the Amiga's parallel port. A serial protocol was used to further link the two devices. After developing a full prototype, he later showcased it to his employer, Sculptured Software, which helped him finish the development. In the interview, Linden expressed a wish that he could have added the missing levels; however, the game, already the largest possible size for a Super FX 2 game at 16 megabits (approximately 2 megabytes), only has roughly 16 bytes of free space. Linden also added support for the Super Scope light gun device, the Super NES mouse, and the XBAND modem for multiplayer. Fellow programmer John Coffey, himself a fan of the Doom series, made modifications to the levels, but some of those modifications were rejected by id Software.
- devbent 3y agoI was lucky enough to work with Randy for quite a few years at Microsoft. Incredible developer. He also made the Bleem! PlayStation emulator. Funny enough none of his coworkers ever bothered to look him up online until after we all stopped working together at which point we all learned we'd been working with programming royalty.
- Dwedit 3y agoAlso it was recently figured out that using the SNES's mosaic feature in an unconventional way could have nearly doubled the game's framerate.
- eru 3y agoDo you have more information on that?
- JohnBooty 3y agoInteresting, please do tell more! I know that Wolf3D on the SNES uses Mode 7. Not for the walls or sprites, but for the entire screen. The graphics are rendered into a background tiles with a resolution of like 175x100 or something, then scaled up with Mode7 to fill the 224x192 screen. (those aren't the exact numbers, but you get the idea)
- Dwedit 3y agoThe "mosaic trick" is a way to perform horizontal pixel doubling in hardware rather than software. And to do this trick, you turn on the SNES's Mosaic feature, scroll 1 pixel to the left every other scanline, and scroll upward one pixel after each two scanlines have been drawn. Normally the SNES mosaic feature just the top-left pixel of a 2x2 square into that entire square. But the trick makes a different set of pixels get doubled horizontally on the next scanline. It requires a different arrangement of pixels than the normal way of drawing tiles. A tile containing these pixels: 01234567 becomes this when viewed on two scanlines: 00224466 11335577 Actually performing these scroll writes does not require any CPU intervention because you use the SNES's HDMA feature to do those scroll writes. User "93143" on Nesdev describes the Mosaic trick in this post: https://forums.nesdev.org/viewtopic.php?p=205633#p205633 https://forums.nesdev.org/viewtopic.php?p=205633#p205633, other discussion here: https://forums.nesdev.org/viewtopic.php?t=20393&start=135 https://forums.nesdev.org/viewtopic.php?t=20393&start=135 --- So now that you've done this, you need half as much video memory as before, which effectively doubles your bandwidth for rendering and transfers.
- superfamicom 3y agoA similar thing happened with the Wolfenstein 3D port as well, where John Carmack gave Rebecca Heineman kudos for learning Japanese to read the patents to get the technical documentation, always cool history around these things, some more in my post about it here: https://eludevisibility.org/super-noahs-ark-3d-source-code https://eludevisibility.org/super-noahs-ark-3d-source-code
- burnte 3y agoI can't speak to this case, but dev kits and SDK/documentation are often two separate SKUs and the latter has a higher price. If I remember the Crash Bandicoot guys found a hardware bug with memory card saving because they rolled their own code rather than using the SDK they didn't have.
- MenhirMike 3y agoI do really like how cartridges on the old systems were essentially equivalent to a PCI Expansion Card in a PC. It was directly connected to the Bus and could do essentially anything. Sadly, that practice ended after the GameBoy Advance, and everything since the Nintendo DS has been purely data storage. This leads to crazy modern enhancements like a Raytracing chip[1], or the MSU1 enhancement chip that is AFAIK not available as an actual physical chip, but only in software emulators. But it would be theoretically possible to manufacture, so you could have an actual physical SNES Cartridge of Road Blaster[2]. On the article itself, I noticed that his list has "Street Fighter Zero 2" as a USA ROM - that should be incorrect, since Street Fighter Zero is what Street Fighter Alpha was called in Japan. So Zero 2 should just be the Japanese version of Alpha 2. (Also, thanks for linking to the MVG video that debunks the myth that the delay before each round is caused by decompression) [1] https://www.youtube.com/watch?v=2jee4tlakqo https://www.youtube.com/watch?v=2jee4tlakqo [2] https://www.youtube.com/watch?v=BvIXUOr4yxU https://www.youtube.com/watch?v=BvIXUOr4yxU
- hollow-moe 3y agoNow I am curious to know how some games could have an IR transmsmitter inside the cartridge like Pokemon Soulsilver, did they plan this specific usecase or a whole channel for limited cartridge expansion components ?
- dwattttt 3y agoThe interface to the gaming system might be strictly data, but you've got power supplied to the cartridge; you can put whatever hardware you can fit inside that cartridge still
- MenhirMike 3y agoThat's actually a pretty good question. The NTR-031 IR cartridges were used for a few games, and there was also one for Motion Sensors and a TV Antenna. From what I can see, it looks like even though they can't extend the functionality directly, they do still interface with the system in some way. Perhaps they are more like a device connected to a serial port would be? So far less capable than the full extension cart, but still possible to communicate with through a standardized protocol? (The DS Cartridge slot has 8 data pins rather than the full address/data bus, but seems to have a protocol: http://problemkaputt.de/gbatek.htm#dscartridgeprotocol http://problemkaputt.de/gbatek.htm#dscartridgeprotocol) So, I need to correct myself, they nerfed it first with the DS, before then switching to being pure flash chips with the 3DS when they switched to XtraROM (which has potential lifespan issues: https://gbatemp.net/threads/nintendo-switch-3ds-cartridge-lifespan.591607/ https://gbatemp.net/threads/nintendo-switch-3ds-cartridge-li...) - and that seems to not allow much custom functionality: https://www.3dbrew.org/wiki/Gamecards#Protocol https://www.3dbrew.org/wiki/Gamecards#Protocol (Though if someone with more knowledge can correct me, please do so. I thought that DS/3DS/Switch are pure flash chips, but was wrong at least about the DS)
- solarized 3y agoI hope developers still love to blog details with article mode like this, rather than vlogging it on YouTube. A lot of detail packed into a few kilobytes only. "Super Mario World" is still the masterpiece game ever. It has amazing characters, sprites, and stages packed into only 360 KB.
- Dwedit 3y agoThe file sizes given by the site are wrong. Super Mario World is 512KB, or 508KB if you discard the padding at the end. Only compressing it to ZIP format gives you a file size around 360KB.
- fabiensanglard 3y agoYea, after writing this I regretted using zip to estimate usage. Probably would get better number by extracting each zip and look how much zero padding is at the end of the file. WDYT?
- Dwedit 3y agoI think applying RLE to the file might give a better estimate, because files have blank space throughout, not just at the end. Just tried it on Super Mario World and the estimated size was 479,154 (468K) bytes. If you don't have an RLE tool handy, you can force Pucrunch to act as an RLE-only compressor by using the -r 0 switch which disables the LZ compression feature.
- justsomehnguy 3y agoJust query each archive for the total uncompressed data. While the 'real' code+data is less than the size of the banks, the banks are always ^2.
- Dwedit 3y agoThe goal here isn't to tell the real file sizes, the goal here is to estimate the "effective" file size without any padding. Padding can be at places other than the end of the file.
- AdamH12113 3y agoIt’s impressive that developers could afford to make custom ICs for only one or two games. I wouldn’t have thought the revenue would be enough to justify that.
- rvense 3y agoGames on cartridge were quite expensive, I think.
- CTDOCodebases 3y agoYes for reference Street Fighter 2 was sold for AUD $120 then which works out to be about AUD $270 when adjusted for inflation. It was priced more than the other games but you get the idea. For reference a typical Nintendo Switch game will sell for AUD $79 on release.
- sharpneli 3y agoThey were around $60 or your regional equivalent. This means $140+ today assuming 1990 dollar.
- RetroTechie 3y ago$60 doesn't justify the expense of custom ICs. It's that some consoles like the (S)NES were extremely popular, sold in the millions. And some games sold in similar numbers. Or were expected to. Or custom IC was (expected to be) used in a # of games. Or some of these publishers were just awash with cash + crazy high expectations for their products. Or some combination of the above. Iirc for custom ICs, you're usually talking about production runs in the many-thousands. Say, 10k+. But in the above example: if $60 provides a $10/sale budget, 10k sales gives you a $100k budget to work with. 100k sales -> a cool 1M budget. Numbers add up quickly if it's mass-produced and 'everyone' buys one.
- jccalhoun 3y agoMy assumption was always that they went into the design of it assuming they would use the chips for more games. Then either the game didn't sell well or the SNES was at the end of its life or something happened to prevent them from using it again.
- wk_end 3y agoWhere do the byte counts for the various games come from? The games came on ROM chips that were, as ROM chip are wont to, sized to powers-of-two. For instance, Super Mario World was shipped on a 512kb ROM - where does 346,330 bytes come from? Are these compressed sizes?
- anthk 3y agoData padding.
- TapamN 3y agoIt looks like they're compressed sizes. If I gzip SMW.SMC, I get a 347 KB file. It's very misleading. There are other issues in there. The writer makes it sound like MVG was the one who discovered that the pause in SFA2 was from loading audio data, when it was already known LONG before his video. https://forums.nesdev.org/viewtopic.php?p=70474#p70474 https://forums.nesdev.org/viewtopic.php?p=70474#p70474 He also seems very confused about the RTC. It's obviously so that the clock keeps going even when the console is off and the cartridge is unplugged, like in the GBC/GBA Pokemon games, but he says something about how it might be because of the NTSC clock drifting? ??? What?
- fabiensanglard 3y agoThe numbers are estimates based on zipped size. But it is a bad idea. I should write a program to extract each zip, and count zero bytes padding at the end of the file. Too late for today, I will write that tomorrow and update the article.
- modeless 3y agoI'm wondering why the console CPU wasn't running at 4x the clock rate to begin with, if the cartridges could easily and cheaply include one so much better. I guess that's just how fast CPUs were improving back then. A CPU from just a few years prior was that obsolete. Crazy!
- VS1999 3y agoNintendo likes to sell its consoles at a profit, so they might have just decided that even an extra $10 per console wasn't worth it.
- andrekandre 3y agosort of yea, it seems originally they wanted to use a 68000 but late 1980s chip shortages and other costs made it difficult so they went with a 6502 derivative [1] [1] https://retrocomputing.stackexchange.com/questions/9373/did-nintendo-change-its-mind-about-68000-snes https://retrocomputing.stackexchange.com/questions/9373/did-... * there nay be others but this is the best link i could find (my info came from elsewhere but i cant find it now)
- wk_end 3y agoUnlike modern chips with cache hierarchies and the like, the 65816 is designed to run in lock step with the memory it’s accessing. A faster CPU would have necessitated faster RAM in the system and faster ROMs on the carts too. Games were expensive enough as it was, then.
- Dwedit 3y agoN64 would be the first Nintendo home console to use a cache. Then Nintendo DS was the first Nintendo handheld to use a cache.
- amlib 3y agoI also wonder why they couldn't provide a second cartridge slot for the enhancements. Sell enhancement carts separately or bundled with some of the games that require it (mostly the first game to feature such enhancement) and then all other developers could consider using them too, without worrying about the cost of their own cart. I imagine this would add to much cost or complexity to the console, making it simpler to just bundle the chips in a single cart anyway.
- silisili 3y agoI love any and all research on these systems. It completely blows my mind that something as complex and fun as Mario Kart was only 350KB in size. You can't even get a 'hello world' binary that small for most languages today. Yeah, it's custom and tuned, but that's a lot of fun packed with at the time 'good graphics' in the size of a single low quality jpeg of today.
- WilTimSon 3y agoWell, we have to account for the fact that modern system simply don't require that much optimization and compression. Working with stricter limits meant that dev teams had to get creative and minimize file size, while nowadays a single game update can be around 20 GB.
- HeckFeck 3y ago> nowadays a single game update can be around 20 GB Irrespective of the abundance of storage we now enjoy, and even though I could rationally understand the reasons, this will always make me raise an eyebrow or sigh.
- eru 3y agoYou are just getting old. People used to have the same reaction to games that filled up an entire CD (or even multiple).
- sgarland 3y agoEh, not the same. All the games I remember spanning multiple discs (Emperor: Battle for Dune took four, for example) were that large due to FMV cutscenes. I understand that 3D textures are large files, but surely there is some hideous bloat occurring to cause the explosion in size. And outside of games, the same bloat occurs, so it’s not just textures. “Let’s ship an entire browser rendering engine with our app” hasn’t exactly helped.
- 3y ago
- qalmakka 3y ago> One of the exceptional characteristics of the Super Nintendo was the ability for game cartridges (cart) to pack more than instructions and assets into ROM chips Wasn't this true even on other Nintendo consoles? Gameboy and Gameboy Color cartridges did similar if not even more outlandish things, like the GameBoy Camera
- hnlmorg 3y agoIt was basically true for all 16 and 8bit era consoles
- masklinn 3y agoIt would probably be more precise to say that it was true for cart-based consoles: likely due to backwards compatibility with the GB port Nintendo supported enhancement carts until the DS (though by then it’d become very uncommon). And the N64 technically supported cart enhancements though only a small handful of japanese games used it (Morita Shogi 64 had a modem and rj11 adapter in the cart… and RCEs so you can use it as a homebrew vector). Once cart were replaced with optical drives there was no way to have anything but data shipped with the game, so enhancements was limited to whatever the console designer had specced expansion slots or even just controller ports for. Then again, as hardware became more complex an expensive, the ROI on bespoke chips got lower and lower. SETA released 3 single-game chips, there’s no way that’s justifiable nowadays.
- hnlmorg 3y agoIndeed. And well put too
- ThatPlayer 3y agoGameboy Advance could do it too. Yoshi Topsy-Turvey and WarioWare: Twisted had gyro sensors. Boktai had a light sensor. Also the Nintendo e-Reader for scanning cards. Even the Nintendo DS could do it, though I'm not sure it was used outside of flashcarts like the SuperCard that included an additional CPU.
- icodestuff 3y ago> Even Super Mario World[10] got the treatment (I can't remember slowdowns but I was only twelve can then). Yoshi’s Island 4 has a slowdown in some circumstances (have Yoshi, get Starman and hit P-Switch), as does another level I can’t recall, exactly… it has a bunch of Monty Moles that explode all at once. I think it’s on Chocolate Island. I think there might be a third with two Sumo Bros. and an Amazing Flying Hammer Bro. onscreen.
- skhr0680 3y agoI remember a ton of lag in Outrageous
- hooby 3y agoI wonder what you could do with modern tech, exploiting that ability of having "enhancement chips" in the cartridge. The SuperFX is mentioned to have it's own framebuffer and copy the whole thing over to VRAM. Does that mean, it would technically be possible to put some ridiculously overpowered SoC into an cartridge, and use that to render modern graphics (at SNES resolutions), copying the resulting frames back into the SNES VRAM? What are the limitations there?
- chpatrick 3y agohttps://youtu.be/ar9WRwCiSr0?si=LArQqOoH2bLtTXCQ https://youtu.be/ar9WRwCiSr0?si=LArQqOoH2bLtTXCQ
- eru 3y agoHa, exactly the same video I had in mind when I read that question. It's a good one.
- hooby 3y agonoice but apparently the NES is a lot more limited, in that it wasn't really designed to accept enhancement chips. still absolutely amazing that he can run emulated SNES games on real NES hardware! but the SNES actually had that ability to accept enhancement chips - as seen in the SuperFX and others... I feel that should allow for doing drastically more!
- JohnBooty 3y agoDifferent set of challenges on the SNES. The NES was a little unusual in that it basically had no video ram. The PPU (the graphics chip) rendered sprites and background tiles straight off of the cartridge at 60fps as if the cartridge was an extension of the CPU's address space. So there are almost no limits to what you could do with expansion hardware, other than the fact that everything would have to ultimately be rendered thru the NES' limited color palette. You could make a cart that provides an interface to let a monster PC with multiple 4090s treating the cartridges' tile data as a "dumb" framebuffer and run Cyberpunk 2077 through an NES... although, again, in 4-bit color hahaha. In contrast, for the Genesis and SNES, you need to copy graphics data from cartidge to VRAM. Then it gets rendered. This was presumably done because ROM of the area was not fast enough to feed the graphics chips of the 16-bit systems, thus the need for local VRAM as sort of a cache. So on a SNES you'd have to do some more work, you'd have to DMA a whole screen's worth of data from the custom cart into VRAM 60 times per second, which I think exceeds the data rates the SNES can achieve. My understanding may be wrong, somebody correct me
- a1o 3y ago> There were three versions of the DSP-1 named DSP-1, DSP-1a, and DSP-1b. While introducing bug fixing and improving the process, the chip behavior was slightly altered which resulted in planes in Pilot Wings demo crashing into the ground OK, I will use that excuse if someone asks me why I am so bad at it.
- Mizza 3y agoReally specific question, but can anybody explain what looks like a bodge resistor on the Star Fox cart (on the missing 74HCT04 chip in the bottom right)? Everything else is SMD, so it looks to me like they realized some mistake after production and had to manually fix every cart. Or maybe this is just a scan of a hacked/prototype cart.
- goosedragons 3y agoI just opened my Japanese Starfox cart. It must be a later revision because it's a half height board with the 4 chips covered in black epoxy. It still has that resistor, although I'm not sure if it's connecting the same traces because the board is completely different.
- Rychard 3y agoThis Reddit thread seems to suggest that it's from an early production run of the game. (though that seems strange to me as normally the glob top chips come as a cost-cutting measure on later revisions of a chip.) https://old.reddit.com/r/gamecollecting/comments/5ddcse/anyone_ever_come_across_a_snes_board_like_this/ https://old.reddit.com/r/gamecollecting/comments/5ddcse/anyo... One of the comments links to this page which shows a picture you can use for comparison: https://snescentral.com/pcbboards.php?chip=SHVC-1C0N https://snescentral.com/pcbboards.php?chip=SHVC-1C0N
- jsheard 3y agoAnother detail not mentioned here is that even carts which didn't contain enhancement chips had different levels of performance - the SNES CPU nominally ran at 3.58mhz, but it would only actually run at that speed with a "FastROM" cart inserted. Nintendo also offered publishers a "SlowROM" cart format, which was cheaper, but would downclock the CPU to just 2.68mhz. There is a community of modders developing patches to turn SlowROM games into FastROM games to alleviate slowdown. I read somewhere that some SlowROM games appear to have been developed for FastROM in the first place, but were converted to SlowROM at the last minute due to penny-pinching demands by the publisher.
- easyThrowaway 3y agoAlways wondered if that was just an arbitrary licensing distinction made up by nintendo or there were actual differences between carts data reading speeds. At the end of the day, all SNES carts sported mask roms.
- MBCook 3y agoAt various points it was very hard to get ROM made due to shortages. It may have been an attempted solution to that, can’t get fast but you could have slow.
- GaggiX 3y agoThe article does mention LoRom and HiRom, I imagine you're talking about the same thing.
- jsheard 3y agoNo that's something else, LoROM and HiROM differ in how the ROM data is mapped into memory, while FastROM and SlowROM differ in the bus speed. You can have Lo/Slow, Lo/Fast, Hi/Slow or Hi/Fast carts.
- deleted 3y ago[deleted]
- donatj 3y agoThere's not a lot of physical space for it, but I have wondered aloud before if the Switch cartridge slot could be used for enhancements?
- nullsmack 3y agoIs there even anything that would make sense? A lot of the older enhancements were because of the limited compute ability of older consoles, or adding sensors like the already mentioned gyro sensors and light sensors in GBA games. The Switch is already more powerful than anything you could reasonably add in a cart, and probably already has any sensors you'd reasonably add too. If there's anything else that could be done, that'd be interesting to find out.
- MisterTea 3y agoSince these carts pull out the CPU bus I would like to know if anyone ever did anything unusual with a classic gaming console. Like controlling motors for a robot or wiring in an FPGA to add functionality like Ethernet/USB, running a terminal emulator, trying to write an OS, etc.
- Covalence_ 3y agoHere's someone using the (officially unused) NES expansion port to send a Tweet from the console: https://www.trapzz.com/?page_id=292 https://www.trapzz.com/?page_id=292
- MisterTea 3y agoThanks! this is the weird stuff I like to see.
- fmy105 3y ago[flagged]
- deleted 3y ago[deleted]
- cdchn 3y agoThe lengths manufacturers of unlicensed cartridges would go to circumvent the CIC were pretty interesting. These carts and early Famicom adapters (which didn't have a CIC) would 'zap' the CIC to keep it resetting. Then Tengen made their own CIC knockoff for their games (they made unique plastic cases for their cartidges too)
- bityard 3y ago> It's wild that the Super 3D Noah's Ark unlicensed game didn't have its own CIC chip and required plugging an official cartridge on top to pass the copy protection check. Goes to show the lengths publishers had to go to bypass Nintendo's strict licensing. I wonder how many other unlicensed carts used similar CIC workarounds. Super 3D Noah's Ark is the only game that seems to have survived to modern times, but I remember there were quite a few more. Nintendo wasn't happy about the religious-themed games but knew it would be extremely bad press to go after the developers, so they strong-armed the major retailers instead. I used to see the games developed by Wisdom Tree in Christmas stores, book stores, and small regional retailers. In non-western countries, there were pirated games that used the same "piggyback" technique to avoid the CIC, but this was less common since PCBs were pretty expensive to manufacture in smallish quantities at the time. Console game piracy didn't _really_ take off until CDs became the dominant format. Arcade game piracy actually had a pretty robust underground market, though.
- SEXMCNIGGA12759 3y ago[flagged]
- SEXMCNIGGA2800 3y ago[flagged]
- r0bbbo 3y agoSomething I've never been able to wrap my head around is how ROMs are dumped for emulators from cartridges? Dumping instructions and assets makes total sense to me, and packaging that up in a data file that can be interpreted by an emulator too, but how does an emulator model the hardware of every 'expansion' chip in a cartridge? How is that dumped from an original cartridge?
- cdchn 3y agoThey're not dumped. The emulator implementation recreates the expansion chip functionality in software. There are only so many expansion chips, so its not intractable.
- RiverCrochet 3y agoExpansion chips aren't ROMs; they need to be emulated as well. The situation was IMHO a bit worse with the SNESs precedessor, the NES. There were quite a few expansion chips--called mappers--even though their general function was expanding the NES's memory space instead of adding additional processors or capabiliies - and they were in most games because without them the NES is limited to 32KB of PRG ROM and I think 4KB or 8KB of CHR (graphic) ROM. Most games after the year the NES came out had them. These all had to be reverse engineered along with the console itself - fortunately much simpler than reverse engineering an add-on CPU or accelerator though. Some are common and in many games (MMC1, MMC3) and others are pretty much for a specific game only (MMC2 is for Punch-Out only).
- SEXMCNIGGA42692 3y ago[flagged]
- SEXMCNIGGA7830 3y ago[flagged]
- SEXMCNIGGA16188 3y ago[flagged]
- nuancebydefault 3y agoCoin cell powered SRAM as an alternative to proper non volatile memory. I find it funny but probably any other solutions were plenty more expensive.
- SEXMCNIGGA10407 3y ago[flagged]
- ApolloFortyNine 3y agoWhen I first learned about how complicated cartridges were it blew my mind. Each cartridge cost $10-25 to make, and N64 was even more expensive. For years now though the cost of delivering the game itself has been essentially 0. It's just wild to me that a huge percentage of the price of a game went to 'nobody' in a way, and just to buying the chips it took to make the cartridge. It likely made up a bigger cut then actually went to the developer of the game.
- SEXMCNIGGA42966 3y ago[flagged]
- SEXMCNIGGA36294 3y ago[dead]
- SEXMCNIGGA19934 3y ago[flagged]
- SEXMCNIGGA21933 3y ago[flagged]
- SEXMCNIGGA23367 3y ago[dead]
- SEXMCNIGGA2049 3y ago[flagged]
- SEXMCNIGGA6721 3y ago[flagged]
- SEXMCNIGGA41352 3y ago[flagged]
- SEXMCNIGGA35334 3y ago[flagged]
- SEXMCNIGGA18538 3y ago[flagged]
- SEXMCNIGGA22619 3y ago[flagged]
- SEXMCNIGGA49193 3y ago[flagged]
- SEXMCNIGGA37477 3y ago[flagged]
- SEXMCNIGGA10770 3y ago[flagged]
- SEXMCNIGGA29847 3y ago[flagged]
- SEXMCNIGGA34036 3y ago[flagged]
- SEXMCNIGGA24579 3y ago[dead]
- SEXMCNIGGA36328 3y ago[flagged]
- SEXMCNIGGA20803 3y ago[flagged]
- SEXMCNIGGA30049 3y ago[flagged]
- SEXMCNIGGA49859 3y ago[dead]
- SEXMCNIGGA8629 3y ago[dead]
- SEXMCNIGGA8128 3y ago[dead]
- SEXMCNIGGA42584 3y ago[dead]
- SEXMCNIGGA47700 3y ago[dead]
- SEXMCNIGGA47246 3y ago[dead]
- SEXMCNIGGA12879 3y ago[dead]
- SEXMCNIGGA38139 3y ago[dead]
- SEXMCNIGGA44946 3y ago[dead]
- SEXMCNIGGA48517 3y ago[dead]
- SEXMCNIGGA11334 3y ago[dead]
- SEXMCNIGGA38002 3y ago[dead]
- SEXMCNIGGA16327 3y ago[flagged]
- SEXMCNIGGA18548 3y ago[dead]
- SEXMCNIGGA28119 3y ago[dead]
- SEXMCNIGGA8425 3y ago[dead]
- SEXMCNIGGA13134 3y ago[dead]
- SEXMCNIGGA6120 3y ago[flagged]
- SEXMCNIGGA17039 3y ago[dead]
- SEXMCNIGGA20090 3y ago[dead]
- SEXMCNIGGA37939 3y ago[dead]
- SEXMCNIGGA24960 3y ago[dead]
- SEXMCNIGGA32629 3y ago[dead]
- SEXMCNIGGA47158 3y ago[dead]
- SEXMCNIGGA31696 3y ago[dead]
- 2genders30488 3y ago[dead]
- 2genders21470 3y ago[dead]
- 2genders31406 3y ago[dead]
- 2genders19192 3y ago[dead]
- 2genders23174 3y ago[dead]
- 2genders27281 3y ago[dead]
- 2genders46095 3y ago[dead]
- 2genders47493 3y ago[dead]
- 2genders20299 3y ago[flagged]
- 2genders15781 3y ago[flagged]
- 2genders39950 3y ago[flagged]
- 2genders7097 3y ago[dead]
- 2genders21396 3y ago[flagged]
- 2genders41257 3y ago[dead]
- 2genders3799 3y ago[dead]
- 2genders4161 3y ago[flagged]
- SEXMCNIGGA47685 3y ago[dead]
- SEXMCNIGGA37282 3y ago[flagged]
- 2genders1206 3y ago[flagged]
- 2genders5690 3y ago[flagged]
- 2genders14192 3y ago[flagged]
- 2genders9299 3y ago[flagged]
- 2genders48014 3y ago[flagged]
- 2genders12521 3y ago[flagged]
- SEXMCNIGGA28175 3y ago[dead]
- 2genders6 3y ago[flagged]
- 2genders25899 3y ago[flagged]
- SEXMCNIGGA30937 3y ago[dead]
- 2genders47148 3y ago[flagged]
- 2genders48344 3y ago[flagged]
- 2genders17397 3y ago[flagged]
- 2genders28563 3y ago[flagged]
- 2genders35499 3y ago[flagged]
- 2genders26746 3y ago[flagged]
- 2genders48393 3y ago[flagged]
- 2genders12597 3y ago[flagged]
- 2genders38654 3y ago[flagged]
- 2genders24716 3y ago[flagged]
- SEXMCNIGGA7832 3y ago[flagged]
- SEXMCNIGGA44355 3y ago[flagged]
- SEXMCNIGGA35084 3y ago[flagged]
- SEXMCNIGGA36471 3y ago[dead]
- SEXMCNIGGA43966 3y ago[dead]
- SEXMCNIGGA27575 3y ago[dead]
- SEXMCNIGGA19833 3y ago[dead]
- SEXMCNIGGA42549 3y ago[dead]
- SEXMCNIGGA19398 3y ago[dead]
- SEXMCNIGGA1806 3y ago[dead]
- SEXMCNIGGA11411 3y ago[dead]
- SEXMCNIGGA31756 3y ago[dead]
- SEXMCNIGGA41250 3y ago[dead]
- SEXMCNIGGA17692 3y ago[dead]
- indianmilf9732 3y ago[dead]
- indianmilf36932 3y ago[dead]
- indianmilf12812 3y ago[dead]
- indianmilf2543 3y ago[dead]
- indianmilf24902 3y ago[flagged]
- sexmc9884 3y ago[flagged]
- sexmc12896 3y ago[flagged]
- sexmc30431 3y ago[flagged]
- TacticalCoder 3y ago> The copy-protection mechanism of the SNES is something I already dig into in my 10NES article. It works by having two chips talking in lockstep. One chip is in the console, the other in the cart. If the console CIC sees something it does not like, it resets every processor. It was easily defeated for consumers though (but probably not for game producers/editors)... Back then we all had a "backup device" for our SNES: a device you'd plug into the SNES and which had a floppy drive. So we'd "backup" all our games on very cheap 3"1/2 floppies. All that was needed for the system to work was to have one original cartdridge, which you'd plug into the copier, and the device would reuse that cartdridge's CIC chip. https://en.wikipedia.org/wiki/Game_backup_device https://en.wikipedia.org/wiki/Game_backup_device