Eicar wrote:
I don't understand how cycles 65-256 are performed. The evaluation is done on all 64 OAMs meaning it would take (256-64)/64 = 3 cycles per sprite evaluation.
Each access takes 2 cycles, and there are one access per sprite and three additional accesses per in-range sprite.
Quote:
The wiki states that odd cycles are read operations from the OAM, and even are writes to secondary OAM. However, there are two loops happening within this time.
First is the evaluation to find out what gets copied to the secondary OAM, and then there's the other loop for the (broken) overflow flag update.
How is this done? Are the loops done in parallel or sequentially?
It's a state machine. For each cycle of the pixel loop, the loop to evaluate sprites for the next line runs one step. So it's done in parallel with the background and sprite rendering.
Quote:
Does anyone have a more detailed description on how this is done per cycle?
What other programming languages do you know? If you know C or C++, the following may make sense:
Code:
size_t soam_index, i;
for (soam_index = 0; soam_index < 32; ++soam_index) {
rest_1_cycle(); // 1 cycle
secondary_oam[soam_index] = 0xFF; // 1 cycle
}
for (i = 0, soam_index = 0; i < 256 && soam_index < 32; i += 4) {
unsigned char y = oam[i]; // 1 cycle
if (soam_index < 32) { // 1 cycle
secondary_oam[soam_index] = y;
if (y_in_range(y)) {
unsigned char tmp = oam[i + 1]; // 1 cycle
secondary_oam[++soam_index] = tmp; // 1 cycle
tmp = oam[i + 2]; // 1 cycle
secondary_oam[++soam_index] = tmp; // 1 cycle
tmp = oam[i + 3]; // 1 cycle
secondary_oam[++soam_index] = tmp; // 1 cycle
++soam_index;
}
}
}
// Broken overflow flag stuff omitted; this stuff can be
// addressed later when getting Codemasters games working
FAQ
Search
Register
Login
