|QA1||How do I use an EEPROM?|
|QA2||How do I develop software for PAL with the PARTNER N64?|
|QA3||What is "overhead" in the map output for ld in exeGCC?|
|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)|
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?
.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
A3 The 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.