flipacholas / architecture-of-consoles Goto Github PK

The Sound Integrated Circuit or ‘IC’: A set of modules (Synthesiser, DSP and Mixer) that generates the audio signal and applies effects on it. It supports up to 64 PCM channels with a resolution of 16 or 8 bits and a sampling rate of 44.1MHz

A sampling rate in the house of Megahertz seems astronomical. 44.1 KHz would be the correct rate as found in CDs.

Hi!
A small correction for this wonderful article:
IEEE 1394, or 'Fireware' in Apple world
Surely you meant FireWire?

Best regards!

Article is full of short and difficult-to-follow sentences. It was the first article written for the website and so much changed since then.

Extensions like 'Read Aloud' are not reading hidden tabs.

In the Unused Power subsection of Backwards compatibility, the following paragraph misspelled 'word' as 'world'.

Thus, whenever any CPU needs to fetch a word (32-bit wide) from memory, the interface stalls the CPU, using up to 3 ‘wait’ cycles, until a full *world* is reconstructed.

Hello! I finished translation of dreamcast article started by https://crowdin.com/profile/Spreit.
I'm not sure how I should put multiple authors to authors log and if it's fine to keep nicknames here instead of real names

https://www.copetti.org/writings/consoles/playstation-3/#bib:cpu-7-0
https://www.copetti.org/writings/consoles/playstation-3/#bibref:12

It's the one that talks about an opcode for fp square roots.

Some technical informations about how the Xbox Live 1.0 works. Can be great addition.

https://channel9.msdn.com/Blogs/TheChannel9Team/Boyd-Multerer-How-was-Xbox-Live-developed?term=xbox%20live&lang-en=true

https://channel9.msdn.com/Blogs/TheChannel9Team/Boyd-Multerer-Development-and-Security-lessons-from-the-Xbox-Live-team?term=xbox%20live&lang-en=true&pageSize=15&skip=15

i didn't see this mentioned in the PS1 article, but i thought it was worth pointing out: the PS1 was the first major console that required developers to program in a high-level way, using the Sony libraries and C, etc. it was explicitly forbidden to write programs entirely in assembly language. the developer contract with Sony stipulated that the official libraries must be used for game development. this is of course in sharp contrast to the 8-bit/16-bit era where nearly all games were coded in assembly for speed and efficiency.

at the beginning of the PS1 era, it's clear simply by reading the SCEE BBS archive from 1995-1996 that many developers had trouble adjusting to this. the Saturn, by comparison, let developers program the "old" way, directly to the hardware, with full documentation provided by Sega. meanwhile, you can see the devs begging Sony repeatedly for low-level documentation for the GTE in these old posts. (Andy Gavin in his Ars Technica interview recalls doing exactly the same thing; he claims he succeeded.) these are all new problems that game devs had to face at the time, and it foreshadowed the future: it's safe to say that game devs generally no longer worry about hardware registers or program in assembly, and this method of programming started with the PS1.

none of this is mentioned in the article but i believe it's an important historical detail.

Interesting source: http://gendev.spritesmind.net/forum/viewtopic.php?t=1203

Hi! Just discovered your site and I'm loving it so far.

Just noticed that on the Game Boy article, on the caption of the model image it says that the console was released in 1999 in Japan.

Hello, great series!

Looking at the section Interesting hardware to get under Contributing here https://www.copetti.org/writings/consoles/sega-saturn/#contributing
it is rendered as a raw code block instead of a section with title and list.

Changelog at the end of articles is similar.

I haven’t found what generates these sections (github search still splits queries!)

This is regarding the article https://www.copetti.org/writings/consoles/game-boy-advance/

Diagram

In the Diagram, it shows the GBC cartridge having a mapper, and the GBA cartridge not having a mapper.

This is true for the vast majority of games, but a few games on the GBA were 64MB in size (such as GBA Video cartridges), and needed a mapper to address the whole 64MB cartridge. Flash cartridges also used mappers.

Memory locations

4 locations are listed there. IWRAM, EWRAM, PAK ROM, and CART RAM.

"IWRAM (Internal WRAM) → 32-bit with 32 KB: Useful for storing ARM instructions and data in big chunks."

IWRAM is the fastest memory available on the system. It has a full 32-bit bus, and executes 32-bit ARM instructions at full speed, and reads or writes 32-bit data words at full speed.
But it's only 32KB, so "Big Chunks" doesn't sound like the correct term to describe it. I understand that "big chunks" means 4-byte words here, but the term seems a little misleading. You can't hold that much data into the tiny 32K of IWRAM.

Also, Video RAM is missing here. Unlike the NES, SNES, or GB/GBC, the CPU has full access to video memory whenever it wants it, it's not just for the PPU.
While it is on a 16-bit bus, it still has an extremely fast connection to the CPU. It only takes 2 cycles to execute a 32-bit ARM instruction from Video RAM, and takes 1 cycle to Read/Write a 16-bit word, or 2 cycles to Read/Write a 32-bit word. This means that Video RAM can be used as "More IWRAM" if you really need the space for running more fast code, or storing more fast data.

The speed comparison is like this:

• IWRAM (fastest)
• VRAM (1x-2x slower than IWRAM)
• EWRAM (3x-6x slower than IWRAM)
• Cartridge (5x-8x slower than IWRAM)

"Cart RAM -> 16-bit with variable size: This is the place where the cartridge RAM is accessed."

The bus size is incorrect here. It's an 8-bit bus, not a 16-bit bus. Furthermore, it's the only bus where you can't read or write more than 8 bits at a time. Attempting to read more than 8 bits will only give useful data in the low 8 bits of the word read back.

"Critical Sections"

Only critical sections should use the ARM instruction set. (Memory locations section)

Games are mostly written in C with critical sections in assembly (Games section)

The term "critical section" refers to concurrent programming, or multiple threads. When code is placed in a critical section, it can only be executed by one thread at a time, other threads need to wait to get in.

Perhaps change "critical sections" into "High-speed 32-bit code in fast memory".

How do they maintain compatibility?

It turns out that the GBA BIOS does see the cartridge slot switch get pressed, and it reacts by switching the system into GBC mode.
The GB Micro can also be swtiched into GBC mode by software, but it is unable to read GBC cartridges.

Constructing the frame

The caption on the background says;

"Affine background layers in use, Layer 3 will be scaled to simulate water effects"

The "Affine" background layers refer to the "Mode-7" like scaling and rotation effects used by games like Mario Kart or F-Zero.
The three background layers seen here are plain background layers, not affine-transformed layers.

"Raster effects" (scrolling changes performed at each scanline) can be used to perform some distortions that keep the scanlines whole. This includes effects such as horizontal skewing, simulated multi-plane parallax, wavy scrolling, vertical scaling, or other vertical wavy effects. Raster effects can be performed on plain background layers, the actual Affine layers aren't needed for those.

Tiles are grouped into charblocks. Each block is reserved for a specific type of layer.

It's not quite three 32KB independent blocks.

When you set up a background layer, you can pick one of Four different possibilities for which graphics to use. Each possibility is 32KB large, but they can start at any multiple of 16K. It could be 0K-32K, 16K-48K, 32K-64K, or 56K-64K (can't go past 64K for the background tiles, remaining 32K is for sprites only)

You also pick where the Tile Map goes. You can see some of the junk graphics sitting on "Block 2" (background 32K-64K) that look like vertical lines, those are the tile maps.

Only "Block 3" (Sprite 64K-96K) is reserved for a specific use in that video mode, and that is for sprites.

On the other side, in order to update the frame there are multiple options...

Not quite true anymore, the CPU has full access to Video RAM whenever it wants it, so there is no need to wait for Vblank time to perform DMA like on the other consoles. The only possible consequence is screen tearing due to the graphics changing the middle of the frame.

Cartridge space

SRAM: These need a battery to keep its content and can size up to 64 KB

The address space is 64K large, but Retail GBA cartridges did not exceed 32KB of SRAM. Flash cartridges did offer 64K of SRAM though.

Flashcards

Flashcards looked like ordinary Game Paks but had the addition of a card slot (SD, MiniSD, MicroSD or whatever) which enabled to run game ROMs.

The earlier flash cartridges did not have any memory card slots. Instead, the entire cartridge was NOR Flash memory, plus battery backed SRAM for saves. You booted a small program over the link cable which would rewrite the cartridge, using data received over the link cable.

The Master System, and possibly the Mega Drive too as they are architecturally similar, segregates the video memory from the CPU address space. Technically the video memory is on a 16-bit shared address+data bus with the VDP:

(Image from Sega service manual schematics)

The layout of memory used by the VDP and timings used in cycle-accurate emulators agree that it uses this 16-bit bus (AD0-AD15) to address video memory (A0 to A12) and read back 16 bits at a time. So technically this makes the Master System as 16-bit as a TurboGrafx-16...

This affects the diagram labelled "Memory architecture of the VDP" and the text just after it.

Also in that text it says "The CPU fills VRAM by writing on VDP’s registers, which will in turn forward the values to VRAM". It'd be better to say "The CPU writes data to VRAM by writing to the VDP, which will in turn forward the values to VRAM" - as this avoids confusion about the VDP's internal registers which are not part of the process.

Amazon's Send to Kindle function doesn't respect @media print {} css queries in the site, so some content is missing and badly formatted. The site still works for exporting to PDF though.

I don't know if I'll be able to find a fix for this, as there's very little documentation. I also tried amazon-only queries (amzn-mobi and amzn-kf8) to no avail, so this is just to note this bug down somewhere.

There is a missing word "million" after "16.7":
"The video signal outputs a resolution of up to 640x480 pixels (or 768×576 px in PAL) with up to 16.7 colours (24-bit depth)."

Noticed some issues and already sent in some pull requests but wanted to ask wether you preferred issues first or not. Planned to do a sweep through the articles to find mistakes and didn't know if I should make issues or just submit pulls

The article mentions floating-point math, however the PS2 is known to not follow the IEEE 754 standard, as infinity and NaN do not exist.
This page shows how this affected PCSX2's emulation.

I was curious because the PSP article has an explicit mention of the standard on the Coprocessors section, whilst the PS2 one does not, and it'd be best to clarify the difference. (I wonder if this affected developers porting from the PS2 to PSP?)

A Vector Floating Point Unit as ‘CP2’: A coprocessor designed for vector operations, similar to a traditional SIMD processor. It has 128 registers that store 32-bit floats (using the IEEE 754 standard) and a special instruction set with variable pipeline stages.

To sort out after finishing the Xbox 360 article,

I worked at a company (Accolade) who didn't license with SEGA and had to reverse engineer the console in order to make games for it.

Your claim: The sound chips are only accessible from the Z80. Correction, you can access the FM chip from the 68000. Before we figured out how to control the audio with the Z80 our first games only used the 68000 to make sound and music. Bubsy maybe? Therefore it is possible to control the YM2612 FM sound chip via the 68000 but IIRC the SN764898 was only available for control from the Z80. I can maybe find some references to back up this correction.

Clarification: the VDP native mode itself, it can be noted, was a descendent of the TMS9918 API. The Mode IV command structure was evolved from the 9918 architecture. We used the publicly available Texas Instruments 9918 data sheets to aid in reverse engineering the native mode Mega Drive VDP.

I've brought up playing fast and loose with IP before with regard to the NES but the 9918 used in the Master System and evolved into the Mega Drive was a "A “Z80-like” register file compatible superset clone of the 9918". (9918 designer Karl Guttag's blog linked below). As a side note, in this blog post he even claims that the NES PPU was a derivative work of the 9918 but not so directly as in the Master System / Mega Drive. When you look into it, and given my own familiarity with reverse engineering the Mega Drive, it does hold up.

Mention of Sega's implementation being a clone
https://kguttag.com/2017/06/28/texas-instruments-994a-and-tms9918-history/

And more specifically, see the comments here from Mickael Petit and admin (Guttag) response for much more insight.
"Strangely in spite of all the patent litigation that TI was pursuing at the time, I don’t remember them ever litigating the 9918 Patent "
https://kguttag.com/2013/08/10/if-you-havent-tested-it-it-doesnt-work/

"At the same time Yamaha did a register level clone and superset that was similar to the AVDP. Yamaha was apparently doing the chip for Nintendo and being in Japan they had the inside track on that design (I don’t know why TI never sued Yamaha based on our sprite patent, maybe we had a cross license, I don’t know). I’m that their chip was register level compatible with the 9918 and suspect that Nintendo, which developed Donkey Kong for Colecovision, use the 9918 in there early game system development."
http://spatula-city.org/~im14u2c/vdp-99xx/e1/99-4_History_By_KG_in_answers_to_Matthews_Questions.doc

9918 presentation by Karl Guttag
https://www.smspower.org/Development/TMS9918ArizonaTechnicalSymposiumDraft

Let me know if you need more details.

I enjoy reading your articles, thank you for your writing.
In your article on the Nintendo DS architecture, I saw that some of the channels could be used as PSGs.
Here's a testimony that you composed your music using only the hardware synthesizer of the DS.

A song I made once upon a time for the Nintendo DS PSG only.
https://www.youtube.com/watch?v=DT5Gsk7tSzE

https://twitter.com/yousukeyasui/status/29570250458533888

Yosuke Yasui was working on an educational game that was only released in Japan. The music played in the practice mode in the game "New Eitango Target 1900 DS" was apparently composed using DS PSG and the noise generator. I would be happy to help enrich your project as an example of how it was used in a real product. Sorry if you were already aware of this example. bye.

Same as #28

The text for the gameboy APU suggests that it can store 32 seperate waveforms for the wavechannel. In reality it can only store one waveform in the APU, which has 32 samples. https://gbdev.gg8.se/wiki/articles/Gameboy_sound_hardware
'fourth' in the next sentence is also incorrectly spelled 'forth'

In the Expansions subsection of Next-gen controllers, the following paragraph misspelled Nunchuck as Nunchuk.

Nintendo shipped this system with another controller to be used on the opposite hand, the *Nunchuk*, this one comes with its own accelerometer, joystick and two buttons.

Hi, excellent article, thank you! Knowing just a bit about sound synthesis, one detail caught my eye:

"Moreover, the second channel can act as a Low-frequency oscillator to modulate the first channel, much like FM synthesis."

Using an LFO to modulate the frequency of another oscillator is commonly referred to as vibrato. What usually (always :-) is meant by FM synthesis happens when the modulating signal has a frequency higher than LFO, high enough for the human ear to hear it as a pitch. Commonly referred to as audio rate frequency.

You probably know this, but because of the wording in the article, I don't know if it can actually do FM synthesis or just vibrato? And it would be super cool if it actually could to FM! (Only 2-op, but still very nice :-)

Cheers!

http://en64.shoutwiki.com/wiki/N64_CPU

Hi Rodrigo,

On the article NES Architecture, in the Scrapped functions section, it says "(whereas traditional binary can encode up to ‘255’ with a four-bit word)." I think it should be "with a eight-bit word".

I don't see any license file in the repository, so I'm not sure under which terms contributors are committing to this repository and how the content is distributed.

Is this expected?

Found this comment on Reddit.

In the megadrive/genesis article: the audio CPU is a Z80. However, the Z80 is based on the Intel 8080 and not on any motorola/MOS design.
https://en.wikipedia.org/wiki/Zilog_Z80.

Hi,

I enjoy reading your console series and I've just bumped into (seems to me) a discrepancy regarding the GBA device's VRAM. The article said that GBA has 96 KB VRAM on a 16-bit bus but the main 'Diagram' image shows a 64 KB VRAM on a 32-bit bus. Little bit further the 'Memory architecture of this system' picture is in agreement with the text but the 'Memory architecture of the PPU' diagram also have a 64 KB VRAM (but correctly on a 16-bit bus). Maybe this 64 KB come from the fact that only up to 64 KB can be used to store backgrounds and 32 KB to store sprites.

1. It is written that Odd pipeline has “a puny Fixed-Point Unit” but the figure is drawn a Floating-Point Unit.
2. I have a suggestion to change arrows between Ramps to the “Simplified diagram of the Element Interconnect Bus (EIB)” to arrows with two lines. So the total number of lines will be the same as the number of Rings.
   Example: https://images.app.goo.gl/MbaWxQYTocf6AFzT7

Thank you for your articles!

I'm starting to wonder if games with widescreen capabilities only alter the framebuffer (during rasterisation) and/or the viewport (during projection). Need more research to confirm this.

In your article on the Master System, your image shows the VDP data bus to the VRAM as 16-bit, but it's not. It's only 8-bit. It's designed to work with the old 1-bit DRAM chips which have a separate input and output data line, so the "16 bit" data bus is really an 8-bit input bus, and an 8-bit output bus. You can see this clearly in the VDP manuals where they show how to connect DRAM to the VDP.

Some mods/hacks that I found:

• There are ODEs on the market that replace the disc drive for a microsd or even a 2.5" hard drive adapter.
• Action replay cartridges can be reflashed with a custom firmware to add more capabilities, including reading backups and disabling region lock. See Pseudo Saturn Kai.
• The Video-cd card that loads games is now called 'satiator'.

I'll be adding more once I get my hands on a modded Saturn console (I was so close to getting one but unfortunately the seller cancelled and gave it to someone else instead 😞).

This is just a reminder that the PS1's main diagram may need changes on the main bus layout. As LSI's docs show a different structure than Sony's docs.

In the exploits section, it might be interesting to mention FreeDVDBoot (a DVD player exploit that can run arbitrary software with a burned DVD-Video disc) and MechaPwn (persistent removal of certain region-lock/anti-piracy measures on late models).

I think both are interesting from historical and architectural perspectives (these are just my own speculations):

• FreeDVDBoot supports only a few fat models, but most of the late (slim) models. It seems that Sony was aiming for more software generality and fewer component SKUs, and on the other hand there was an organizational loss of interest in lockdown measures: exploit protections present in fat versions of the DVD player were apparently just left out in slims.
• MechaPwn relies on a writable patch area of the Mechacon disc access controller that was added when the original controller was replaced with an ARM-based one in late models. Apparently Sony was willing to put up with the risk of exploitation to cut down on mask ROM costs. MechaPwn enables bypassing region restrictions; how well depends on the device model and region. The regional differences in BIOS-side region-lock/anti-piracy functionalities seen in the MechaPwn README are a pretty interesting source for Sony Kremlinology in itself.

If you don't have time I can probably write a PR with a few words regarding these. I'm not sure what would be a suitable scope though. A few sentences for each?

In my research, there's no evidence that Ricoh licensed the chip designs from MOS. I've talked directly to Bill Mensch about this and IIRC he indicated that they just copied it. I also have heard Bill Herd weigh in as well that MOS looked at de-capped 2A03 and noted the 6502 core but declined to do anything about that. There was some 'speculation' in CBM hackers list in 2014 that the BCD disable was enough to avoid a patent infringement and perhaps they only hoped to get away with copying the 6502 gate for gate (as shown by Visual 6502) without too much notice. They tend to be very quiet on these things as it probably tarnishes their legacy in a similar way to how they (Nintendo) allegedly stole the Donkey Kong code in order to make Donkey Kong sequels in house. They lost a lawsuit in this regard and the story that they (Nintendo) didn't code Donkey Kong is swept under the rug. In any case, what I am saying is that I don't have any quotable evidence that they copied, only heresay , however unless you have documented proof that they licensed the core from MOS I don't think you should include that 'fact' because there is a strong suspicions that they merely copied.

Some facts:

• the 6502 portion of the 2A03 has an identical layout.
• chip masks were not copy-writable until 1984; 2A03 came out in 1982
• only 5 places in the polysilicon layer were cut to disable decimal mode ( SED CLD etc still work and show up in the flags register)
• "the 6502 <in the 2A03> databus drivers are reduced to remnants which drive an internal bus, eventually driving some logic which in turn drives the real databus drivers."

references:
https://en.wikipedia.org/wiki/Semiconductor_Chip_Protection_Act_of_1984
http://cbm-hackers.2304266.n4.nabble.com/R6502AP-td4659401.html
http://forums.nesdev.com/viewtopic.php?t=9813

Ten part series on the origin of the Famicom (in Japanese) archived
https://web.archive.org/web/20140920211721/http://trendy.nikkeibp.co.jp/article/special/20080922/1018969/

Part seven talks about why the 6502 was chosen (size)
https://web.archive.org/web/20141017171734/http://trendy.nikkeibp.co.jp/article/special/20081002/1019378/

This last part does say that Ricoh licensed the 6502 but from Rockwell (not MOS) which I also find strange since how can a Ricoh license the 6502 design from a 'second source'. I'm only speculating, but maybe Ricoh did have a relationship with Rockwell and acquired the 6502 IP through a back door deal but I don't know if they actually paid anyone at all per unit on the 2A03 in the Famicom/NES. Kind of like how you see a lot of cut/paste code showing up uncredited in other people's software.

In addition to single cycle waveforms PC Engine also supports direct playback of 5-bit PCM samples. A good example would be batman with sampled bass, percussion and orchestra hits.

https://www.youtube.com/watch?v=KyqqX2DLtxw

I think it might also be worth emphasizing the full stereo panning per channel (4-bit volume for left and right output each). This is a nice advantage vs most of it's competition at the time.

Maybe not worth mentioning but in wave mode the wave buffer can be written to during playback to produce more complex sounds.

Surprisingly not many games that did this but it might've been because you would get an small, but audible click when the sample was changed.

https://www.youtube.com/watch?v=S7x6SUtF2Zo

https://www.youtube.com/watch?v=V845pHyaePk

EDO is "extended data out", not "external data out". It's "extended" because the RAM keeps outputting the data for the previous read even while the CPU starts sending the address for the next read or write — the overlapping lets the CPU send commands a little bit faster, leading to more effective bandwidth. With the previous gen (FPM) RAM, the data out would become invalid as soon as you started setting up the next address.

On the Costs sub-section of The strange end of terms, the date mentioned is 2017 instead of 2007 which is cited right after. Also, congratulations on releasing such a lengthy article!

In the section of the Sega Master System page titled "Emulation accuracy" that is referring to audio

We have a screenshot of a NES showing the wave "decaying", vs a Master System which has no "decay".
You see the square wave kind of "tilt" towards the center.

It turns out this "decay" is actually a simple highpass filter intentionally added to perform DC cancellation. It only uses additions, subtractions, and bit shifts, so it's really cheap and fast.

I don't quite remember what the formula was though.

Inspiration from Hackernews: https://pdf.math.dev/

Hi, I very much enjoyed your overview of the PS2 hardware. Just two things to note:

• As gsKit and Rick Gaiser/Maximus32's demos demonstrate, the PS2 does in fact support rendering and outputting 1920x1080; you mentioned the support for interlaced 1920x1080 and only up to 720x480 in progressive, but GS Mode Selector confirms that there is in fact an unused DTV 1080p mode (as well as 720p).

• It may be worth detailing the network section more. For instance, the PS2 supports 100mbps via ethernet at full/half duplex. (It may also be worth mentioning that the throughput of ethernet is typically bottlenecked by the slow IOP though!)

"The data cache also works as Scratchpad (fast RAM)" isn't correct. The PSX main processor had no data cache. The scratchpad was effectively mapping the actual data cache to a fixed address. This was a bit head on performance as every (non-instruction) memory read incurred a large penalty (something like 6 cycles)

In the The Leader sub-section of the CPU section, a Markdown link to the N64 article's CPU section was misspelled, therefore showing up as plain text.

Current:

• MIPS III ISA: A 64-bit RISC instruction set. Wait, is it me or this is the same ISA found on a [competitor’s console](https://www.copetti.org/projects/consoles/nintendo-64/#cpu?. (...)

Fix:

• MIPS III ISA: A 64-bit RISC instruction set. Wait, is it me or this is the same ISA found on a competitor’s console? (...)

https://twitter.com/unsafeptr/status/1396396250623365123

The article says that the pulse 3 channel was unused in the Green Hill example due to gameplay reserving it for sound effects. However, it's unused because the noise channel is using pulse 3's frequency.

The article states:

Any instruction followed by a ‘branch’ or ‘jump’ type opcode is executed unconditionally: Thus, developers have to manually fill the pipeline with modest instructions (such as ‘calculate 0 plus 0’) after the branch or jump to mitigate the hazard.

Related diagram (marked instructions are delay slots):

Based on my understanding, delay slots are instructions after a branching/jump instruction (emphasis mine):

Thus, developers have to manually fill the pipeline with modest instructions [...] after the branch or jump to mitigate the hazard.

But the statement immediately before, seems to reverse this logic (emphasis mine), as it implies that delay slots are instructions before the branch/jump:

Any instruction followed by a ‘branch’ or ‘jump’ type opcode is executed unconditionally

I think this should be "following", meaning "that follows"/"after" (emphasis mine):

Any instruction following a ‘branch’ or ‘jump’ type opcode is executed unconditionally

Sorry is this is my misunderstanding, but I find the statement obscure 😄