87

How does the Sonic & Knuckles cart detect another cartridge? It checks the serial numbers of games; they can be found in the ROM's header. It probably detects all preceding Sonic the Hedgehog games since they all result in specific effects when locked-on. Are the game ROMs merged in some way when connected? It seems both games are simply mapped onto ...


72

The main point to understand is that the console is limited. RAM on the console itself is faster than memory on the cartridge (and the cartridge memory was usually read only, with a little non volatile for user data). So the game designers had to carefully consider how to use the precious, but faster, ram on the console, vs the slower rom on the cartridge....


64

Theoretically it could take 25 minutes (or more), in practice it never did. Theoretically it could, because the C-64's built-in tape handling routines had a data rate of about 300 bit/s. That's 37.5 bytes per second, or almost 30 minutes for a full 64K. In practice, it never did, because the tape handling / decoding was done almost entirely in software, ...


55

The 8 bit 6502 family doesn't have any stack-relative addressing modes that would make it easy to use the stack for variable storage. One can access values on the stack with a sequence such as TSX; LDA &102, X, but that's slower, clobbers X, and uses more memory (both in code size and stack usage) than a global variable. The 65C816 adds stack-relative ...


52

Time to market was another factor. I worked in the games industry in the 1980s and when we were getting the final game from the developer, mastering to cassette and disk took just hours before they went into production and (typically leading up to Christmas) they were in the shops just 48 hours later. Often there would be a bug found and disks would be re-...


50

I wouldn't say "It's a very specific and subtle kind of behavior." I really think this is the case of undefined behavior that has been reproduced so many times from N64 launch to now that users have seen repeat behavior. In fact, sometimes cartridge tilting can actually delete your game save (Donkey Kong 64), and not just mess with the graphics (Goldeneye'...


48

Off the top of my head I can think of two reasons, there are probably more. The first reason is that these variables may be set by a routine each frame, and then a lot of code uses them during the time of the whole frame. Every interrupt routine that fires during that frame may want to read out the current direction. The second reason is that, in a real-...


37

A cartridge was limited to 16 kbytes ROM, and some were only 8k. There would be plenty of RAM to use, but the code and data must fit into the 16 kbytes. As programs became more sophisticated, the desire to make full use of the C64's sound, graphics, and sprites, ROM size would often be a limiting factor. OTOH, a program loaded from disk (or for the ...


34

Game Boy games do not always need a manual save operation. There's no hardware reason that would prevent Game Boy games from saving in the way you describe. For the Game Boy hardware, RAM present on the cart can be used by games for whatever it needs. SRAM is RAM on the cartridge; most of the time, it's backed up by a battery and used to store save data, ...


33

To understand what was going on with licensed and unlicensed ports of popular arcade games in the 1980s, you have to understand two critical factors. The video gaming culture of the time, and the preeminence of coin-op arcade games. The role of trademarks and legal trademark protections, which was the more crucial law pertaining to arcade game ports at the ...


32

Microprocessors have a minimum operating voltage spec, but that generally doesn't mark a threshold where they stop executing code. Instead, it specifies level below which they aren't guaranteed to execute instructions correctly. When a game is powered off, a processor may execute a few hundred or a few thousand instructions between the time the voltage ...


29

This is the pinout of a Nintendo 64 cartridge (from here). The Nintendo 64 used a multiplexed address/data bus with a three-stage access protocol: write the high word of the address you want to access, write the low word, then read the data, all going across the same 16 pins. This indirect access method means that program code needs to be run from the ...


27

I'd guess a lot of the systems used for development didn't clean the memory down in between usages. It's also likely that for games "gaps" got left between binary chunks. So if for a hypothetical system redefined characters had to start on a multiple of 256 (0x100) byte boundaries the memory layout might have looked like this: 0x0000 - 0x1789 - Compiled ...


23

As mentioned previously the timing issue is the cause not to waste time in pushing up parameters, access them with cost-intensive addressing modes and pull them finally from stack. Too much action if this occurs in a tight, time-critical frame building routine. In a games of a certain size usually all could be handled with global variables. Some state of the ...


23

In addition to RichF's answer, tapes were a lot cheaper than cartridges to manufacture. Tape duplication in the 80s was very low cost due to the high volumes involved, not least thanks to music distribution on the format.


19

The NES can be damaged by software, so removing the cartridge at just the wrong timing could theoretically damage the console. The 2CO2 PPU in the NES normally reads the background color from palette index 0, but this isn't hard-wired into the chip -- it actually reads the palette index of the background from four EXT pins. These pins are grounded on the ...


18

You can, provided that you have a cartridge reader that you can plug to the computer that runs the emulator. One such reader is Retrode; if you google "nes cartridge reader" you will find references to more similar products, even DIY kits.


18

Yes, cassettes were common, they took ages, and they were error prone. In Europe, disk drives for the ZX Spectrum and Commodore 64 were uncommon. It's the same for cartridge games for the C64. The market for the 8-bit micros in the 80s in the UK was driven by price, so the cassette interfaces were the majority here. (BBC Micros with floppy drives were common ...


18

I don't know if this is correct, but it seems to fit. The SNES sound chip is a full processor. It can run its own program and play sounds independently of the main processor. It is also possible for a Game Boy ROM to load a sound program into the SNES sound chip via the Super Game Boy. Animaniacs is one those games. While the way the SNES sound chip is ...


17

I know you specifically asked about cartridge "games". But another important factor in the market forces surrounding this was that the cartridge slot was ALSO the one "expansion" slot - A very limited resource on the C64. As users and the market became more mature, there were many other uses for the cartridge/expansion slot, and these became competition for ...


16

I don't know if this applies in every case, but, on the Commodore PET and by extension C64, an executable program file on disk/tape consisted of a load address (normally $0401 on the PET) and then literally a memory dump of the the region of RAM containing the program. The normal save routine would save all the memory until it got to the end of the BASIC ...


15

As a personal project I had the idea to create a custom cartridge for my Commodore 64 and use an ATmega 1284p microcontroller to emulate eproms and/or custom chips. I doubt that this will work! The reason is simply the time needed by the microcontroller to react on a signal change: As far as I know, you have about 0.25µs to react on some edge on the C64 ...


15

You're asking us to speculate about something that hasn't been released yet. However, looking at the FAQ, it's clear that this is just a fancy Linux box with some emulators on it. Processor: Intel Coffee Lake S Series Processor Memory: 2GB DDR4 RAM Polymega’s Modules use top tier emulators with low latency controller inputs. Emulators: Legally licensed ...


14

It's also worth pointing out that the intricacies of maintaining variables on the stack can result in slower code. And of course there are limits to how big the stack can be; even with the more expansive stack on the 65816, you're still limited to a fraction of bank $00 (so 64K minus the direct page(s) minus any other stacks you have around minus any I/O ...


13

Hardware No damage to the hardware should occur (unless by chance removing the cartridge physically damages the hardware contacts). The reason for this is is that loading a cart basically completes a big circuit the the system hardware. There is no internal storage (at least not on the NES/SNES/N64 and Game Boy), so there is no persistent memory to ...


13

Simple Answer: Unlimited and Many Ofc, every system can only reserve a certain amount of real address space for cartridges, but then there is Bank Switching. Just take the original Atari 2600. Address space for ROM was 4 KiB, and many early games only used 2 KiB ROMs. But already in 1982 Burger Time came in a cartridge with 16 KiB ROM and some sort of bank ...


12

I used to use a clean rubber eraser to clean golden contacts in general, not only cartridges but that can also leave residues if you don't clean it properly after. There is a comprehensive article on Arstechnica website that recommends using Q-Tips, Brass polish, high-concentrated alcohol, and lint-free cloths. Based on the instructions and the companion ...


12

The Gist Games on the N64 typically did not have a lot of memory to use. Instead of keeping all code and data loaded onto the cartridge at one time, it would typically keep some necessary game code loaded into memory, and would only load temporary game code or data when needed. This is seen with cartridge tilting on "The Legend of Zelda: Ocarina of Time" ...


Only top voted, non community-wiki answers of a minimum length are eligible