N64 Questions
- Thread starter cufunha
- Start date
BGNG
New member
Cache is, in its simplest form, memory on the processor. Instructions from programs can be stored in this memory and the processor can read from it directly instead of making a call to the system memory, which takes time and must transfer through the bus. Caching, to my understanding, serves little more purpose than to make execution of code faster by making it more accessible by the processor than it normally would with the program stored in memory.
for any PC CPUs :
The Cache is using the SRAM (Static Random Access Memory) memory type, the most expensive and fastest memory. That type of RAM work with a simply open/close fonction , like a switch , open = 0 (no contact) , closed = 1 (contact). The L1 cache is on the CPU , it is used, as BGNG said, to store the commands in queue for the Processing unit to execute. It is the fastest one since it's on the CPU, so it demands less time to get the information. On another side, the L2 cache isn't really on the CPU, it's the same type of SRAM but a bit slower and located on the motherboard. It's used when the L1 cache is full or to put instructions that are less important then the other ones.
The Cache is using the SRAM (Static Random Access Memory) memory type, the most expensive and fastest memory. That type of RAM work with a simply open/close fonction , like a switch , open = 0 (no contact) , closed = 1 (contact). The L1 cache is on the CPU , it is used, as BGNG said, to store the commands in queue for the Processing unit to execute. It is the fastest one since it's on the CPU, so it demands less time to get the information. On another side, the L2 cache isn't really on the CPU, it's the same type of SRAM but a bit slower and located on the motherboard. It's used when the L1 cache is full or to put instructions that are less important then the other ones.
Last edited:
zenogais
New member
I just wanted to add one thing, there is something called a cache miss that occurs when some data the CPU needs is not in the cache. When this occrus the CPU must wait several cycles (or more depending mostly on the gap between CPU and system memory speed) while the data is fetched from main system memory. The CPU will only read data that is aligned from an x byte boundary, lets say 32 bytes. So if the data you want it to read is at 0x1FC01024 then it will read the data from 0x1FC01020 to 0x1FC0103F. This is why a programs memory alignment can be crucial to its speed.
Last edited:
- Thread Starter
- #7
simple question bout country codes and manfacturer id (n64)
N64 Roms have in the header somethings I wonder to know why... but for now, I'm focusing on country id codes and the manufacturer id. From anarko docs 1.1, we have:
003Eh - 003Fh (1 word): Country code
0x4400 = Germany ('D')
0x4500 = USA ('E')
0x4A00 = Japan ('J')
0x5000 = Europe ('P')
0x5500 = Australia ('U')
Is there anymore country code that can appear in a N64 Rom? if so, what are they and what countries they're assigned to?
0038h - 003Bh (1 dword): Manufacturer ID
0x0000004E = Nintendo ('N')
Is this the only manufacturer id possible?
N64 Roms have in the header somethings I wonder to know why... but for now, I'm focusing on country id codes and the manufacturer id. From anarko docs 1.1, we have:
003Eh - 003Fh (1 word): Country code
0x4400 = Germany ('D')
0x4500 = USA ('E')
0x4A00 = Japan ('J')
0x5000 = Europe ('P')
0x5500 = Australia ('U')
Is there anymore country code that can appear in a N64 Rom? if so, what are they and what countries they're assigned to?
0038h - 003Bh (1 dword): Manufacturer ID
0x0000004E = Nintendo ('N')
Is this the only manufacturer id possible?
BGNG
New member
I cannot find more information on the country codes.
[Previously posted list does not apply to N64]
The CRC header entries are checksums implemented into the header in order to verify that the ROM is compliant with the header code and that it is not corrupt. They are calculated with bytes in the file and must match the checksum performed by the emulator/console via the real bytes and the algorithm at bootup or the game will not run. I do not know what the algorithm for N64 CRCs is.
[Previously posted list does not apply to N64]
The CRC header entries are checksums implemented into the header in order to verify that the ROM is compliant with the header code and that it is not corrupt. They are calculated with bytes in the file and must match the checksum performed by the emulator/console via the real bytes and the algorithm at bootup or the game will not run. I do not know what the algorithm for N64 CRCs is.
FYI, L2 cache has been on-die since the Athlon T-Bird and P3 Coppermine.Knuckles said:
- Thread Starter
- #15
emulate 64bit opcodes under n64 cpu?
N64 main processor (r4300i) works both on 64bit and 32bit mode. I know that n64 runs only on 32bit mode, so GPR registers are 32bit wide (right?). My question is: do I have to emulate 64bit-only opcodes (LDL, LDR, LD, etc...); if so, they have some kind of special format under n64 CPU?
ANOTHER QUESTION: some opcodes are not documented by anarko docs (LDCz, LWCz, ...). It means that I don't need to emulate them and to raise a reserved instruction exception if they are called from the rom?
N64 main processor (r4300i) works both on 64bit and 32bit mode. I know that n64 runs only on 32bit mode, so GPR registers are 32bit wide (right?). My question is: do I have to emulate 64bit-only opcodes (LDL, LDR, LD, etc...); if so, they have some kind of special format under n64 CPU?
ANOTHER QUESTION: some opcodes are not documented by anarko docs (LDCz, LWCz, ...). It means that I don't need to emulate them and to raise a reserved instruction exception if they are called from the rom?
- Thread Starter
- #19
There is something wrong. If n64 runs in 64bit mode, everything should be like the r4300i manual describes for 64bit mode, and that's not what's happenning: addressing uses 32bit mode addressing. Are only the registers 64bit wide or there are another things on the 64bit mode, like tlb entries?