RetroSpark
I think the Master System version of Sonic Spinball came from Sega themselves though. It was sold in Europe as well as Brazil.
Another possibility is that they used a hardware device. Perhaps something that watches the 6502 `sync` pin to know when an opcode byte is being read, and verifies that the data bus contains a legal value.
That quote is from the ARM7TDMI manual - the CPU used in the Game Boy Advance, for example. I believe later processors contained entirely separate ARM and Thumb decoders.
I wonder how they tested that, though? I don't think developers had to submit their source code to Nintendo, so they would have had to analyse the binaries in some way?
Half a megabyte, even! (For the original monochrome game - the later color version is a full megabyte.)
[0] https://www.smspower.org/uploads/Development/z80-documented....
Instruction timings are in the pink table on the left-hand side. For example, `ADC HL, BC; ED4A; H15` means that the instruction affects the flags as in row H and takes 15 cycles to execute.
The overall tube size is 45”, the actual screen size is 43”. I believe it was mandatory in the USA to market TVs based on screen size, in most of the rest of the world they were sold based on tube size.
That’s why common sizes of 4:3 CRT TV in the US were 13/20/24/27/32” whereas in the rest of the world the same size TVs were sold as 14/21/25/29/34”. Interestingly the tubes’ internal part numbers are based on the screen size in centimeters: 34/51/59/68/80 cm.
[0] https://www.sciencedirect.com/science/article/pii/S187802961...
However, aperture grilles also use differently-shaped glass from shadow masks. The screens are only curved horizontally like a cylinder rather than on both axes like a sphere. This requires thicker, heavier glass to hold the vacuum.
Later flat-glass shadow-mask tubes were much closer in weight to flat Trinitrons.
However, unlike the Game Boy and GBA, the cartridge ports on the two systems are physically different (50 pins vs 64) so a cartridge adapter is still needed.
In that situation, I think an approach like the Super Game Boy's is probably better: include the old console's hardware in the adapter rather than in the new console, so that the new console's design need not be constrained by backward-compatibility.
The Game Boy Color has a 16-bit address space and almost all its games are 1MB or larger (although that's ROM rather than RAM). The largest game is 8MB in size - which is managed as 512 banks of 16KB each.
True, but there was a huge difference between a good-quality RGB monitor and a consumer TV connected via composite video or RF. Ideally designers would have been using development devices that took that difference into account.
For example, I've heard of artists at Sega drawing on PCs and using custom hardware so they could simultaneously view their work on a real Genesis connected to a typical TV.
Oops, that should say 32x30.
This seems similar to the horizontal-blank interrupt that's available on later machines, where it's widely used to change color palette or scroll values part-way down the screen. Because it’s an interrupt, though, the CPU doesn’t have to wait for it and can do other things during the active display period. As toast0 says, on the NES this interrupt is usually provided by hardware on the cartridge, but other 8-bit consoles (including the Game Boy and Master System) support it natively.
> Manipulating this setup on the fly as in "racing the beam" is really more exploit territory.
Even on the NES, "racing the beam" is not unheard of. For example, Marble Madness uses mid-scanline changes to draw text boxes in the middle of the level graphics. For part of the display it uses timed code to switch from the level nametable to text and back again within each scanline.
The NES does have two nametables that perform a similar role, though. Instead of storing a 256x240 array of pixels, they store a 32x20 array of tile indices, each describing an 8x8 pixel tile. Once the CPU has written to the nametables, it can do something else while the PPU draws an entire frame.
Whereas on the 2600, the CPU needs to step in every few scanlines or it can't draw a 2D image at all!
At launch, most games were around 512KB in size. By the end of the machine's lifespan 3MB was common and there were even some 4MB and 5MB games.
Unfortunately, many game companies lost the source code for their classic games years ago. They couldn't release it even if they wanted to.
One of the big surprises coming from this leak is simply the fact that Nintendo's source code still exists. The company seems to have been very thorough in archiving material related to its older games.
$4317 mvn src,dest
$431a rts
The SNES supports SlowROM and FastROM but, interestingly, its internal memory is "SlowRAM". This seems like it would significantly bottleneck the system's performance. I guess "FastRAM" was just too expensive.
Another World uses SlowROM, so almost everything in the system is slow. It's a clever trick to use the DMA registers as a tiny amount of "FastRAM" and run code from there.
Something similar has been done on the Game Boy Advance - it's faster to run code out of Video RAM than directly from ROM or (the majority of) normal RAM.
Of course, game developers tried to put as much data as possible into the part of RAM that is faster to access.
The official name of the CPU is unknown - there's some discussion of that here: https://forums.nesdev.com/viewtopic.php?f=20&t=18335