HN user
You're right: many of TecToy's Brazil-exclusive Master System games were tweaked versions of Game Gear releases. That includes games like Ecco 2, Mortal Kombat 3 and Sonic Blast, but not the aforementioned Street Fighter II which they developed independently.
I think the Master System version of Sonic Spinball came from Sega themselves though. It was sold in Europe as well as Brazil.
I don't know if they even had an emulator at the time - I don't think a 1980s PC could run a NES emulator at a reasonable speed.
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.
On execution, 16-bit Thumb instructions are transparently decompressed to full 32-bit ARM instructions in real time, without performance loss.
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.
Throughout the entire NES game library, almost no games use these illegal opcodes. Apparently as part of the licensing process, Nintendo would verify that games only used the official instructions.
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?
Link's Awakening feels like it shouldn't be possible in a single megabyte of mask ROM
Half a megabyte, even! (For the original monochrome game - the later color version is a full megabyte.)
220uF is correct. Along with the 75Ω terminating resistor inside the TV, that forms a high-pass filter with a cutoff frequency of ~10Hz.
Nice and compact! When I was writing a Z80 emulator I made heavy use of the tables in Sean Young's "The Undocumented Z80 Documented" [0] (chapters 8, 9 & 10). This 2-page reference card seems to contain just about everything in the document's 22 pages.
[0] https://www.smspower.org/uploads/Development/z80-documented....
no instruction timing chart?
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.
Sony’s part number suggests it has a 45 inch tube inside. But in a rare case of truth in advertising, Sony advertised it as a 43-inch model.
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.
According to [0], about 1.2 kg (2.6 lbs). Surprisingly this is mostly in the neck and funnel of the tube - the screen itself uses different metals because lead would affect its optical performance.
[0] https://www.sciencedirect.com/science/article/pii/S187802961...
Yes, the aperture grille (hundreds of wires and a metal frame holding them in tension) is itself heavier than a traditional shadow mask.
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.
AFAIK the French NES is just a PAL console with an added composite-to-RGB converter. Although it outputs RGB signals, the quality is no better than composite.
The Sega Genesis did something similar - its hardware is a strict superset of the Master System's, so it can run SMS games natively.
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.
A megabyte of ram on a machine with only a 16 bit address space gets a bit silly. Do you really want to manage 16 memory pages?
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.
It doesn't sound like they include the entire ROM, only the parts necessary to play back the recording. If you "take control", the game may try to access parts of the ROM which are missing, which causes the quote to reset. This happens frequently with the Metroid II example - the Tetris one seems much more robust.
Presumably this refers to Ricoh, who produced the CPUs and PPUs for both the NES and Super NES.
The Game Boy is much more similar to the Sega Master System & Game Gear than to the NES. Some games (e.g. Lemmings 2, Pinball Dreams, Spirou) were developed for both handhelds (or even for all 3 platforms) using a single assembly-language codebase.
In reality, every monitor was a CRT. They just drew what looked good on their development devices.
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.
a 32x20 array of tile indices
Oops, that should say 32x30.
The graphics chip can halt the CPU until it has reached the start of a new scanline.
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 didn't have a framebuffer either
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!
The other replies describe the lack of coprocessors, but there is one way in which Mega Drive cartridges got more sophisticated over time - increased ROM capacity.
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.
I assume the suggestion isn't that Nintendo should give the games away. Just that if you buy a game on the Switch you shouldn't have to buy it again when you upgrade to their next console.
It’s a shame that for most classic games, the source code will never be released. I wish that after a while, and things were no longer commercially viable, code would be released.
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.
I used a debugger - it looks like the function in the DMA registers is actually just 32 bits:
$4317 mvn src,dest
$431a rts
That's right. Sorry if it wasn't clear.
"The DMA registers [...] run the full CPU 3.6Mhz speed. [...] I put a 32 byte function that would draw a scanline of polygon data in there."
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.
This. The Super NES memory map is divided into 256 banks of 64KB each. The bottom 8KB of RAM is visible in 128 of these banks, but the remaining 120KB only appears once. The bottom 8KB of RAM is therefore faster to access (at any time, it's more likely to be visible in the "current" bank).
Of course, game developers tried to put as much data as possible into the part of RAM that is faster to access.
It's more like a cut-down Z80. Some registers are missing (note the list excludes IX and IY), as are some instructions (but a few others are added) and even some of the status flags.
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