diff --git a/course/en/18-other-representations.md b/course/en/18-other-representations.md
new file mode 100644
index 0000000..511d6b9
--- /dev/null
+++ b/course/en/18-other-representations.md
@@ -0,0 +1,41 @@
+# Other representations
+
+Bit patterns represent much more than ordinary integers. This chapter introduces Gray code, biased/excess notation, character codes and packed data.
+
+## PREDICT
+
+Must the bit pattern `01000001` always mean the number 65?
+
+## STEP — Gray code
+
+In binary-reflected Gray code, neighboring values differ in exactly one bit. This is useful when multiple bits should not transition simultaneously, such as in some position encoders.
+
+A binary value `b` can be converted with `g = b XOR (b >> 1)`.
+
+## STEP — biased/excess notation
+
+An exponent can be stored as an unsigned field plus an agreed bias. With bias 127, stored value 130 represents exponent (130-127=3).
+
+IEEE 754 binary32 uses this principle for its exponent field, with reserved field values receiving special meanings.
+
+## STEP — characters as numbers
+
+ASCII assigns `A` the code value 65, or `0x41`. Unicode defines **code points**, such as U+0041 for A. An encoding such as UTF-8 then determines the actual stored bytes.
+
+A code point and its byte encoding are not the same concept.
+
+## STEP — packed data
+
+One byte can contain several bit fields. A hypothetical status register might use bit 7 for ready, bit 6 for error, bits 5–4 for a mode and bits 3–0 for a counter.
+
+## OBSERVE
+
+`0x41` may be unsigned 65, signed 65, ASCII A, part of an instruction or a field inside a larger structure. Context supplies meaning.
+
+## EXPLAIN
+
+Computers store bits. Types, protocols, instruction sets and file formats supply their semantics.
+
+## Check yourself
+
+Compute the Gray code for binary `1010`. What exponent does stored value 124 represent with excess-127?
diff --git a/course/no/18-andre-representasjoner.md b/course/no/18-andre-representasjoner.md
new file mode 100644
index 0000000..0548bbd
--- /dev/null
+++ b/course/no/18-andre-representasjoner.md
@@ -0,0 +1,58 @@
+# Andre representasjoner
+
+Bitmønstre brukes til langt mer enn vanlige heltall. Dette kapitlet viser fire viktige eksempler: Gray-kode, biased/excess-notasjon, tegnkoder og packed data.
+
+## PREDICT
+
+Må bitmønsteret `01000001` alltid bety tallet 65?
+
+## STEP — Gray-kode
+
+I binær-reflektert Gray-kode skiller naboverdier seg med nøyaktig én bit. Dette er nyttig når flere bit ikke bør endre seg samtidig, for eksempel i enkelte posisjonssensorer og enkodere.
+
+De første 3-bit Gray-kodene er:
+
+| Desimal | Binær | Gray |
+|---:|---:|---:|
+| 0 | 000 | 000 |
+| 1 | 001 | 001 |
+| 2 | 010 | 011 |
+| 3 | 011 | 010 |
+| 4 | 100 | 110 |
+
+Fra binær verdi `b` kan Gray-koden beregnes som `g = b XOR (b >> 1)`.
+
+## STEP — biased/excess
+
+En eksponent kan lagres som et unsigned felt med en fast bias. Hvis bias er 127, representerer lagret felt 130 eksponenten (130-127=3).
+
+Dette er prinsippet som brukes for eksponentfeltet i IEEE 754 binary32, selv om spesielle feltverdier har egne betydninger.
+
+## STEP — tegn som tall
+
+ASCII gir bokstaven `A` kodeverdien 65, altså `0x41`. Unicode definerer **code points**, for eksempel U+0041 for A. En encoding som UTF-8 bestemmer deretter hvilke byte som faktisk lagres.
+
+Code point og byteencoding er derfor ikke det samme.
+
+## STEP — packed data
+
+En byte kan deles i bitfelt. Et tenkt statusregister kan bruke:
+
+- bit 7: ready
+- bit 6: error
+- bit 5–4: mode
+- bit 3–0: counter
+
+Da er byten ikke «ett tall» i vanlig forstand, men flere felt pakket sammen.
+
+## OBSERVE
+
+`0x41` kan tolkes som unsigned 65, signed 65, ASCII-tegnet A, deler av en instruksjon eller et felt i en struktur. Konteksten bestemmer betydningen.
+
+## EXPLAIN
+
+Datamaskinen lagrer bit. Typer, protokoller, instruksjonssett og filformater gir bitene semantikk.
+
+## Sjekk deg selv
+
+Beregn Gray-koden for binær `1010`. Hva er den virkelige eksponenten når et excess-127-felt inneholder 124?
diff --git a/exercises/no/07-representasjoner.md b/exercises/no/07-representasjoner.md
new file mode 100644
index 0000000..bba5278
--- /dev/null
+++ b/exercises/no/07-representasjoner.md
@@ -0,0 +1,10 @@
+# Øvelser: andre representasjoner
+
+1. Bruk `g = b XOR (b >> 1)` på binærverdien `0110`.
+2. Hvorfor kan én-bit-overganger være nyttige i en mekanisk posisjonsenkoder?
+3. Med excess-127: hvilken virkelig eksponent representerer feltverdien 140?
+4. Med excess-15: hvilken feltverdi lagrer eksponenten −4?
+5. Hva er ASCII-kodeverdien til `A` i desimal og hex?
+6. Forklar forskjellen mellom et Unicode code point og UTF-8-byte.
+7. Et register bruker bit 7 som READY og bit 0 som ENABLE. Hvilken maske tester begge bitene samtidig?
+8. Gi tre forskjellige plausible tolkninger av byte `0x41`.
diff --git a/solutions/no/07-representasjoner.md b/solutions/no/07-representasjoner.md
new file mode 100644
index 0000000..71590bb
--- /dev/null
+++ b/solutions/no/07-representasjoner.md
@@ -0,0 +1,10 @@
+# Løsninger: andre representasjoner
+
+1. `0110 XOR 0011 = 0101`.
+2. Når bare én bit endres mellom naboposisjoner reduseres risikoen for tvetydige mellomtilstander dersom bitene ikke skifter helt samtidig.
+3. (140-127=13).
+4. (-4+15=11), altså feltverdien 11.
+5. 65 desimalt, `0x41`.
+6. Code point er Unicode-identiteten til tegnet; UTF-8 er en konkret variabel-lengde byteencoding av code pointet.
+7. `10000001₂ = 0x81`.
+8. For eksempel unsigned heltall 65, ASCII-tegnet A eller et rått bytefelt i en instruksjon/protokoll/filstruktur.