How does Game Boy / Sharp LR35902 HRAM work?

Question

The Nintendo Game Boy has RAM called "HRAM" (meaning "high ram") decoded at locations $ff80 through $fffe. (All other decoded locations in the $ffxx page appear to be I/O device and system control mappings.)

The CPU also has a special "high page" load instruction that works like the 6800/6502 zero page or 6809 direct page addressing modes. This apparently uses mnemonic LDH ("load from high page") and the opcode is follwed by only the low byte of the address; the high byte $ff is implicitly assumed (i.e., LDH A,$a0 loads from $ffa0). This makes it one byte shorter (and thus faster to read and execute) than a standard direct address LD load instruction.

My questions related to this are:

1. Where is this HRAM, physically? Is it on the CPU die? Outside of the clock cycles saved by the new high-page instructions, is it any faster than any other RAM? Does it have any other special properties? (E.g., there seems to be a DMA system which when running blocks access to external RAM and ROM but not HRAM. I don't know if the DMA system can itself access HRAM.)

2. When HRAM is accessed, what appears on the external address/data/control buses and cartridge port? Bonus points if you have further interesting information about this when accessing other parts of the high page.

3. What's the full list of additional instructions/addressing modes added to the CPU that relate to HRAM and/or high-page access? Do any other 8080-like CPUs provide this, or is this unique to the Sharp LR35902? What assemblers understand extra mnemonics like LDH? Do any assemblers automatically choose the shorter addressing mode when assembling instructions like LD A,$ff80?

4. The boot ROM sets up the stack in HRAM (the first instruction is LD SP,$fffe). What's the advantage of doing this over just putting the stack in regular work RAM?

5. What are typical uses of HRAM, if any, that use its special characteristics beyond just "I saved a byte on a load or store instruction"?

If you feel any of these questions are big enough to warrant being extracted to a separate question on this site, mention this in your answer or a comment and I'll look at doing that.

Answer 1

The Game Boy is an SoC; with the exception of the on-board work RAM and video RAM (8 KB each), the CPU and all on-board peripherals are contained on a single chip. (The cartridge adds external ROM and optionally a memory bank controller, RAM and other peripherals.)

Thus, the HRAM is on the CPU die. Is not inherently faster than external memory: all accesses to it take the same number of cycles as accesses to external memory.

You may be able to save some cycles when accessing any address in the $FF00-$FFFF range (whether HRAM or not) by using one of four new instructions added for this purpose, each adding either an 8-bit constant or the contents of register C to $FF00 to generate the effective address:

E0 nn       ldh (nn),A      ; 12 cycles
F0 nn       ldh A,(nn)      ; 12 cycles
E2          ld (C),A        ; 8 cycles
F2          ld A,(C)        ; 8 cycles

These are understood by all assemblers targeting Game Boy. Optimizations vary from assembler to assembler. RGBDS does optimize ld a,($FFnn) to an ldh opcode (and the same for stores) unless the -L option is given to disable that. WLA DX does not, though it does assemble LD A,($FF00+nn) to the shorter opcodes.

But standard 8080/Z80 instructions of the same length are just as fast. For example, the one-byte instruction ld A,(HL) (opcode $7E) is also only 8 cycles, whether HL is loaded with an $FFnn address or not.

The only special property or use of the HRAM visible to the programmer, besides that it's in the $FF00-$FFFF address range and thus accessible using the additional instructions above, is that the DMA controller, when operating, does not cut off access to it as it does for external memory. When you trigger a DMA transfer the CPU cannot access external memory for 160 microseconds, so the code the CPU runs during this period must be read from HRAM. (I have no idea what happens if you try to read code from or otherwise access external memory during this period.) More details and an example of how this is handled can be found at "Gameboy DMA Transfers", though be warned that that page appears to have a few errors/typos.

Whether or not the DMA can use HRAM as a source (the DMA destination is fixed to the object attribute memory or OAM—the sprite table), it would never make sense to use it in a real program because it always copies $9F bytes, 32 more than the entire size of HRAM, and peripheral registers are adjacent to HRAM on both ends.

The bus mentioned in the question is the external bus; there are several internal buses as well. GameBoy Memory Access Paterns has logic analyzer traces of this bus for various kinds of accesses. In the section "Boot ROM external bus access" we can see a detailed trace for writes to two IO ports (line 13's ldd (hl),a with HL=$FF26 and line 14's ldh (c),a with C=$11). It appears to me that, as per the explanation given in the text, C̅S̅ remains high (as it must) and the address lines are correct, but neither the other control (R̅D̅ and W̅R̅) nor data lines reflect what's on the internal buses. The text says that HRAM is the same, though the next trace including a program running from HRAM isn't detailed enough in that section for me to confirm that.

I see no particular reason for the boot ROM to use HRAM rather than work RAM for the stack in normal operation. However, it might make it easier to test systems with defective internal RAM as you'd still be able to boot a cartridge (presumably one containing a diagnostic program).

Answer 2

The CPU also has a special "high page" load instruction that works like the 6800/6502 zero page or 6809 direct page addressing modes.

Looks like that's where the Nintendo guys came from, doesn't it? It couldn't be at zero, as thats where the vectors are stored (basically the reverse layout of a 6502, isn't it?)

This makes it one byte shorter (and thus faster to read and execute) than a standard direct address LD load instruction.

It basically replaces the standard IN/OUT instructions (plus adding an indexed version). Effectively moving I/O space into memory mapped, simplifying the memory design.

My questions related to this are:

Looks more like a dozend to me. Quite a broad pile, isn't it?

Where is this HRAM, physically? Is it on the CPU die?

Yes. In fact it's on what could be called the CPU-complex within the SoC.

Independent of using high page instructions, does that make it faster to access?

Of course, as the first half of the high page contains all I/O registers, it speeds up all hardware service - quite helpful on a system, which main job is to manipulate these registers. this feature is eventually more important for the existence of the high page than having RAM at that location.

Or is this about access time in general?

If yes, then no. There is no saving in time compared to an original 8080 IN/OUT instruction. Having the high page enables the usage of any kind of memory operation to read/write/modify the I/O registers as with memory mapped in general, while keeping the shorter encoding for simple load and store

Does it have any other special properties?

In general no - except during DMA, as it's the only memory region the CPU can access during DMA (*1), so DMA code has to reside there to keep the system running.

I don't know if the DMA system can itself access HRAM.

Interesting question. Never tried it, but I'd say rather not.

When HRAM is accessed, what appears on the external address/data/control buses and cartridge port?

Yes, except during DMA (AFAIK).

Bonus points if you have further interesting information about this when accessing other parts of the high page.

Above is true for the whole high page. That's the way the TV adaptors work. Listening to what is done and repeating that for their video circuit.

What's the full list of additional instructions/addressing modes added to the CPU that relate to HRAM and/or high-page access?

Only LoaD from/to HRAM with an 8 bit address (F0h/E0h) or address offseted by C (F2h/E2h)

Do any other 8080-like CPUs provide this, or is this unique to the Sharp LR35902?

None that I know of - then again, there have been countless implementation (much like with the 6502), so who knows.

What assemblers understand extra mnemonics like LDH?

Beside the original Devkit there are several.

Do any assemblers automatically choose the shorter addressing mode when assembling instructions like LD A,$ff80?

Depends on the assembler.

The boot ROM sets up the stack in HRAM (the first instruction is LD SP,$fffe). What's the advantage of doing this over just putting the stack in regular work RAM?

It'll works independent of any (other) RAM available. A boot ROM needs to be as conservative as possible with resources. Only use what's guaranteed, and only the least thereof.

What are typical uses of HRAM, if any, that use its special characteristics beyond just "I saved a byte on a load or store instruction"?

Again DMA. It's the only place can be executed when waiting for DMA to finish. And DMA is the way to update screen content.

---

*1 - Well there is as well the Boot-ROM within the CPU complex, but so far noone has come up with a good use for that during DMA.

Answer 3

Do any other 8080-like CPUs provide this, or is this unique to the Sharp LR35902?

The Sharp SM83 family (SM8311/83113/8314/8315) support the same instructions, documented in the Sharp Microcomputer Databook 1996 (page 186) as:

MNEMONIC	OPERATION
LD A, (C)	A ← (FF00ʜ + C)
LD A, (n)	A ← (FF00ʜ + n)
LD (C), A	(FF00ʜ + C) ← A
LD (n), A	(FF00ʜ + n) ← A