| QA1 | How do I use an EEPROM?(199810) |
| QA2 | How do I develop software for PAL with the PARTNER N64?(199811) |
| QA3 | What is "overhead" in the map output for ld in exeGCC?(199905) |
| QA4 | Can "after max" be used for mild? (199906) |
| QA5 | I do not need to describe wave for mild? (199906) |
| QA6 | How can I use the object file for various purposes? (199906) |
| QA7 | How can I prevent osSyncPrintf from hanging up with the actual hardware with 2.0K? (199910) |
| QA8 | Where is greset located?(200003) |
| QA9 | Performance is worsened due to the compiler option.(200002) |
Q1 I currently use the PARTNER N64 for development. If I use an EEPROM, what other hardware is necessary besides PARTNER?
A1 You must purchase an EEPROM chip. These come in either 4K or 16K models.
When you open the PARTNER cartridge you will find an 8-pin socket. Insert the EEPROM chip there.
To purchase EEPROM chips, please contact NOA at the following numbers.
NOA Parts Department Phone: (800) 531-4048 FAX: (800) 447-8362.
International Orders Phone: (425) 861-2038 FAX: (800) 558-7100
Q2 Are any modifications to the PARTNER necessary when developing PAL version software with PARTNER N64?
A2 Please refer to the "Software Submissions Checklist" included in the "N64 Software Submission Requirements" document.
For PAL requirements, please refer to the "PAL Software Submission Requirements" in the same document.
Q3 I currently check the map file that is output by the linker in order to decrease the ROM size, but the word "overhead" appears after the object name, as shown below. What is this "overhead?" Is some kind of waste being created in the ROM image?
from c:\Ultra/usr/lib/PR/gspF3DEX2.Rej.fifo.o(.text)
.text 8003cf80 1190 1190 2**4 elf32-bigmips c:\Ultra/usr/lib/PR/gspF3DEX2.Rej.fifo.o(overhead
4056 bytes)
8003cf80 gspF3DEX2_Rej_fifoTextStart
8003e110 gspF3DEX2_Rej_fifoTextEnd
A3The word "overhead," as it appears in the MAP that to which you refer is not overhead in the target ROM program, but refers to overhead in the memory inside the PC. Therefore, it has no significance as information for decreasing the ROM size.
Q4 I have a question regarding how to place OBJECT for mild.
I would like to place one OBJECT after more than 2 segments. I think it is possible to specify it by "after max" , "after min" for makerom; however these cannot be used for mild. To place it by specifying ADDRESS directly is the only way for mild?
A4 As you pointed out, mild does not have "after max" function.
Other than using ADDRESS, you can only check the output of the section address for mild, find the largest segment address, and place it using "after" (segment name).
Q5 It seems that wave is not used for mild. Do I not need to describe it?
A5 The description of wave is not used for mild.
Still, writing down the placement of segment as above may be helpful for future references.
Q6 I made a ROM image by placing the same object file to more than one segment for mild; however, it does not work properly.
A6 For mild, if more than one segment has the same object, segments other than the one used first do not accept codes.
Even if they accept codes, the ROM will be used wastefully because the object will be taken up by the ROM image repeatedly.
Memory efficiency would improve if the object is divided into segments and loaded when the overlay has common portions.
Q7
With 2.0K, when I burned ROM made with libultra.a and started the cartridge with the actual hardware, the program hung up when osSyncPrintf was executed.
There was no problem with 2.0J+libultra_rom.a+is_debug.c. Can you do something about it?
Is 2.0K+libultra_rom.a+is_debug.c possible as before?
A7 If you define ISV64 when compiling, you can use it.
2.0K+libultra_rom.a+is_debug.c is possible.
Q8 I cannot find the sample, greset, which is mentioned in the programming manual, in demos. Where is it?
A8 Because this is a sample for the emulator board for SGI INDY, it is not included in the OS for PC. As the emulator board does not have anything similar to a Reset Button, it is necessary to execute the greset command to simulate pressing the Reset Button.
Q9 If "-g" option is used for exegcc, performance is clearly worse. Depending on whether the "-g" option is used or not, do codes created change? For the optimization option, "-03" is used.
A9 If -g is used, the codes created will change slightly even with the same optimization option. If -g is used, optimization which make source debuggin impossible (e.g., an extended slot is no longer used) will not be carried out. Therefore, it should be faster and the size should be smaller without -g.
However, since N64 CPU uses a direct mapping method of cache, performance changes very much with a slight change of code locations. As described above, if -g is used, the object size will change and cache hits may increase accidentally, and the final speed might increase. (Refer to the R4300 manual for the direct mapping method.)
Since there is no tool to judge the optimal code location, you need to go through a trial and error process when seeking optimization.
For example, you might want to try "-02" and "-03" (without "-g" for both) with object unit to compare execute speed and code size.