3

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.

  • 1
    The large number of subquestions makes it hard answering them. They are extrem broad and do not realy show why a certan (additional) topic is targeted, making answering to the point even harder. Some upfront research to narrow it down might have improved focusing. – Raffzahn Jul 24 '19 at 9:13
  • @Raffzahn I am thinking that taking the questions as a whole and producing an answer with a different organization, rather than trying to go through point by point, may produce a better answer. (This is one reason I didn't split this up into lots of small questions.) If there are no good examples of this in a few days, I can try to produce an example of what I mean based on information in answers here and any further external information to which they lead. (If it turns out I can't do this, I'd agree that the question is probably poorly formulated.) – Curt J. Sampson Jul 24 '19 at 9:20
  • It's just an experience I got here, that rather broad questions, as above is, when taking all the subquestions into account (basically asking 'tell me all about HRAM'), are extreme hard to answer and, more important, they usually lead to unsatisfying answers, as it's a poking in the dark. More than once I spend several hours (yes, that's common time needed for a seriosu reply), just to learn that the information needed was not the one the question asked for. In general, as wider a topic is/has to be, as more important is to specify why and for what an information is requested. – Raffzahn Jul 24 '19 at 9:43
  • I understand. I have a pretty strong feeling for what I'm looking for, but it seems to be hard to explain, so let's just let this run for a bit and see if I or someone else comes up with a good example of what type of answer I'm looking for for a question like this. (I don't actually think it's hugely broad, since HRAM is a pretty small and not terribly complex part of the system.) – Curt J. Sampson Jul 24 '19 at 10:34
  • Formulating some text down to the core is always a challenge, isn't it? I got the feeling you focus too much onto the RAM part when it's really about High Page and its benefits, don't you? – Raffzahn Jul 24 '19 at 10:51
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.

  • Looks like part of your sentence is missing, starting with "Of course, as the first half of the high page contains all I/O registers. thus making the" – Wilson Jul 24 '19 at 9:31
  • @Wilson Done :)) – Raffzahn Jul 24 '19 at 9:54
  • 1
    "Or is this about access time in general?" Yes; I meant is there any additional speed due to the RAM being on-chip, independent of the savings by having shorter opcodes. (I've tweaked the question slightly to try to make this more clear.) Your answer makes it clear that there isn't. – Curt J. Sampson Jul 24 '19 at 10:51
  • Do you have more details about what appears on the buses when HRAM is accessed? I'm not clear on what "Yes" means. Can I expect to see both the address and the data read/written on the address/data pins on the cartridge port (with C̅S̅ presumably high)? Is the same true for all I/O reads and writes in FF00-FF7F? – Curt J. Sampson Jul 24 '19 at 12:33
  • "That's the way the TV adaptors work. Listening to what is done and repeating that for their video circuit." Do you have a reference to anything that works like this? I've done some searching and can't find anything like this. – Curt J. Sampson Jul 24 '19 at 13:18
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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.