Shonumi wrote:
It's an entire 16MB, so it is tempting to put more data there if you can spare it.
Why in the world wouldn't you?
It's funny, because talking about something like the XBone or the PS4 and having way too much ram, (I actually say a $1000 computer, i7 processor and whatnot, with 8GB of ram, and this is a computer) I don't see how people were able to deal with as little ram as this if all the textures had to fit here. Would DMA be fast enough to realistically swap textures from main ram to this special audio ram and then back again in one frame at 60fps so that you're rendering a scene with both textures? I mean, 24MB really isn't that much when you have program, "actual ram", and graphics all at once. What do you think would be the average texture size from the time period? On the GameCube (I don't know why it's on my mind now), are the textures using lossy compression? And not related, do larger textures generally take longer to render? I wouldn't think so, because the video hardware looks at the pixels of where the polygon is being drawn and than at the texture instead of the other way around? What always amazed me is the kind of fractional accuracy there must be when finding the pixels of a texture to draw so that the texture is smooth instead of blocky. (I guess if say a pixel that is going to be drawn in a polygon corresponds to "pixel 1 and 3/4" on the actual texture, it does Pixel1 + Pixel2 + Pixel 2 + Pixel2 / 4 to find the color that gets sent to the certain spot on the framebuffer.)
Anyway, before I completely derail my own topic...
tepples wrote:
boot0 in a ROM on the GPU die loads boot1, hashes it, and compares its hash to that stored in a small PROM on the GPU. It freezes if they differ.
It just looks at a specific place in flash memory, and compares the value there to a certain value on the system? What does "hash" mean? Read a certain value? Also, I'm not really sure, is boot(whatever number) a step, or a location where a value is held, or both? What's even the point in boot0 and boot1?
Anyway, I feel like looking at the GameCube:
Quote:
copies the Bootstrap 2 code (BS2) from Bootrom to 0x81300000
• disables the IPL decryption logic by clearing bit 17 of 0xcc006800
• sets IP of Machine State Register so exception vectors are pointing to lower memory
• jumps to BS2 code
("BS2 code" is apparently just the code that handles the GameCube logo and the limited menu you can access.)
This makes more sense to me. It copies the Bootstrap 2 code into ram, so it can be read like a program. Then, it does other stuff that I actually have no clue what they mean, but I assume it's for running the menu properly in some way. Then, it actually runs the code for Bootstrap 2, which is the menu, so there are two roms found in the system: One for setting up the menu, and the actual menu itself. Bootstrap 1 is the only one that actually gets read through like a program directly though, as Bootstrap 2 is read in ram just like a game after it has been copied. You know, this is ridiculous, but could a regular game actually copy information from Bootstap 2 into ram? I mean, like if you just wanted to copy the model for the GameCube logo from the rom in the system. There'd be very little purpose, but I'm just wondering if it would be possible. I suppose you could make a "never ending loop" by making a game that essentially behaves exactly like Bootstrap 1. There'd be no point, but it'd be something.
So, we have our question answered in how the menu gets loaded, but how does the actual game get loaded? Is there program in the menu, Bootstrap 2, that copies data from the game to ram, and then makes it jump to that specific location in ram? Actually, I guess that's kind of how Action Replay works? It copies part of the game into ram, and then it overwrites some of the information before jumping to actually mess with the data? It seems you could only manipulate data that's first being loaded into ram though. You know one weird thing I just thought of? In loading the data from the game into ram, it would have to ensure that it doesn't overwrite the program that is actually loading the data. I know the page lists the C code for Bootstrap 1, but because I don't know it and I'm curious, does anyone know where on the disk the data is being copied, how much data is being copied, and where the data is being sent to in ram? I assume it starts running though the program at the beginning of where it was copied in ram?
I just realized I asked about 50 questions...