diff --git a/docs/cpuspecifications.md b/docs/cpuspecifications.md
index 5f09094..866228a 100644
--- a/docs/cpuspecifications.md
+++ b/docs/cpuspecifications.md
@@ -302,20 +302,20 @@ registers while the mul/div operation is busy will halt the CPU until the
mul/div has completed. For multiply, the execution time depends on rs (ie.
"small\*large" can be much faster than "large\*small").
```
- __umul_execution_time_____________________________________________________
+ __multu_execution_time_____________________________________________________
Fast (6 cycles) rs = 00000000h..000007FFh
Med (9 cycles) rs = 00000800h..000FFFFFh
Slow (13 cycles) rs = 00100000h..FFFFFFFFh
- __smul_execution_time_____________________________________________________
+ __mult_execution_time_____________________________________________________
Fast (6 cycles) rs = 00000000h..000007FFh, or rs = FFFFF800h..FFFFFFFFh
Med (9 cycles) rs = 00000800h..000FFFFFh, or rs = FFF00000h..FFFFF801h
Slow (13 cycles) rs = 00100000h..7FFFFFFFh, or rs = 80000000h..FFF00001h
- __udiv/sdiv_execution_time________________________________________________
+ __divu/div_execution_time________________________________________________
Fixed (36 cycles) no matter of rs and rt values
```
-For example, when executing "umul 123h,12345678h" and "mov r1,lo", one can
+For example, when executing "multu 123h,12345678h" and "mflo r1", one can
insert up to six (cached) ALU opcodes, or read one value from PSX Main RAM
-(which has 6 cycle access time) between the "umul" and "mov" opcodes without
+(which has 6 cycle access time) between the "multu" and "mflo" opcodes without
additional slowdown.
The hardware does NOT generate exceptions on divide overflows, instead, divide
errors are returning the following values:
@@ -326,8 +326,8 @@ errors are returning the following values:
div -80000000h..-1 0 --> Rs +1
div -80000000h -1 --> 0 -80000000h
```
-For udiv, the result is more or less correct (as close to infinite as
-possible). For sdiv, the results are total garbage (about farthest away from
+For divu, the result is more or less correct (as close to infinite as
+possible). For div, the results are total garbage (about furthest away from
the desired result as possible).
Note: After accessing the lo/hi registers, there seems to be a strange rule
that one should not touch the lo/hi registers in the next 2 cycles or so... not
diff --git a/docs/graphicsprocessingunitgpu.md b/docs/graphicsprocessingunitgpu.md
index 9a9034d..95be420 100644
--- a/docs/graphicsprocessingunitgpu.md
+++ b/docs/graphicsprocessingunitgpu.md
@@ -746,16 +746,16 @@ registers.
1-23 Unknown (seems to have no effect)
```
This feature seems to be intended for debugging purposes (most released games
-do contain program code for disabling textures, but do never execute it).
-GP1(09h) seems to be supported only on New GPUs. Old GPUs don't support it all,
-and there seem to be some Special/Prototype GPUs that use GP1(20h) instead of
+do contain program code for disabling textures, but never execute it).
+GP1(09h) seems to be supported only on New GPUs. Old GPUs don't support it at all,
+and there seem to be some special/prototype GPUs that use GP1(20h) instead of
GP1(09h).
#### GP1(20h) - Special/Prototype Texture Disable
```
0-23 Unknown (501h=Texture Enable, 504h=Texture Disable, or so?)
```
-Seems to be a used only on whatever arcade/prototype GPUs. New GPUs are using
+Seems to be used only on whatever arcade/prototype GPUs. New GPUs are using
GP1(09h) instead of GP1(20h).
#### GP1(0Bh) - Unknown/Internal?