API tools faq
paste
Advertisement
Zoinkity

N64 Test Cart on iQue

Zoinkity
Apr 11th, 2023
341
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 10.12 KB | None | 0 0
raw download clone embed print report
  1. .: N64 Test Cart on iQue :.
  2. The N64 Test Cart is a derivative of the go/no-go tool, itself derived from a test program used to develop the console and RDB boards. Source for an older variant was leaked in oman (gng), but this example is sourced from a partial dump made some years ago (it lacks some of the audio tests, version unknown).
  3. It runs a series of RSP/RDP tests and compares them to known good samples. If anything doesn't match up it displays an error on the screen alongside the major & minor test number blown. As of 4/2023, our best low-level video plugins still fail a number of these.
  4. Depending on the detected memory size--4MB, 6MB, or 8MB--there are some minor differences in certain test results.
  5.  
  6. There has been a bit of a question about what the iQue may or may not do, or at what level its video output differs from N64 (it clearly does after all). It is basically one big ASIC.
  7.  
  8. tl;dr: iQue passes all RSP/RDP tests, is fussy about certain address ranges, pattern-matches serial commands instead of parsing bytecode, doesn't like sudden video mode changes, and any video out differences are at final output.
  9.  
  10.  
  11. .: List of functions swapped with iQue support :.
  12. These functions were updated, mostly because they "just worked" and not necessarily because they needed to be. Note there are multiple copies of some of these, like osInitialize. Controller support normally needs to be adapted but it turns out it only uses the "normal" functions once, then completely ignores them >.<
  13. Essential:
  14. osInitialize
  15. __osViSwapContext
  16. osViSetMode
  17. osContStartReadData
  18. whatever 'copy result of SI status request to A1, setting presence flags to A0' is called
  19. Arguable:
  20. __osContRamRead
  21. __osContRamWrite
  22.  
  23. osInitialize detects iQue and initializes it. This particular lib version also works with N64. Without this you get very peculiar behavior.
  24.  
  25. __osViSwapContext & osViSetMode both ensure pixel advance in VI Status is set to 1, not 3, to prevent damage to hardware. One instance settings are manually written is also patched.
  26.  
  27. The controller libs are adapted so the "pak present" flag is tied to Controller Pak data allocations provided in the ticket. It also swaps status & input when __osBbHackFlags is set.
  28. The factory test version uses a tool called zaru that plugged into *every* port, using an interface on controller port 1 and mapping its data to controller slot addresses usually used by Controller Paks / GB64 data. This could tell you the state of power & grounds and provided a big yellow button, earpiece, DIP switches, and an LED. Detecting it is based on a read/write test to the LED register, so for our purposes it's mostly important that it's indistinguishable from a Controller Pak and needs to be hidden from iQue to prevent a lot of fatal tests tied to it.
  29.  
  30. The E/PI special cases are not necessary when access flag 0x20 is set, necessary for 8MB support. The MI hardware interrupts are not used. KeepAlive is removed by the patcher that allows unsigned content. Anything otherwise not mentioned apparently isn't very important either ;*)
  31.  
  32.  
  33. .: Patched Behavior :.
  34. * RAM tests are completely removed, as well as "rebooting".
  35. The bootloading sequence at 80200050 normally loaded code similar to an IPL to A4000000 on its first pass. This turned off rdram, then walked through the initialization and addressing portion again. The VI is manually initialized, then it walks through each word of rdram from 80000400 to detected maximum doing a read/write test. It then reloads the bootcode, resets the registers passed in from IPL1/2, and makes a second pass through 80200050.
  36. Problem #1 is that rdram registers are mapped--and initialized to zero. This test is guaranteed to fail. iQue has its own extended registers, and its own ram works in a fundamentally different way. (The normal rdram range might just be a special mapping of 81000000...)
  37. iQue
  38. 00000000 00000000 00000000 00000000
  39. 00000000 00000000 00000000 00000000
  40. 00000000 00000000 00000000 00000000
  41. 000011E0 000011E0 000011E0 000011E0
  42. 031111E4 031111E4 031111E4 031111E4
  43. 00000000 00000000 00000000 00000000
  44. 00000001 00000001 00000001 00000001
  45. 00000000 00000000 00000000 00000000
  46. 00000001 00000001 00000001 00000001
  47. Problem #2 is parts of the remainder also include init code skipped by iQue or requires adaptation (like VI regs). Plus it's long.
  48. Instead, the whole process is skipped: A0000320=0xDEADBEEF, A0000324=False if rdram isn't faulty.
  49.  
  50. * At 80001660, does a read/write test of B0900000. This address is above provided ROM, making it lethal.
  51. iQue latches all addresses between the end of provided cart data and PIFRAM. If you try to read or write from them it will softlock the system. That's true of a number of other address ranges: A5000000 through B0000000 all appear to lock as well. Open-bus responses are used in early titles to detect 64DD, replaced by IPL reads. Both are lethal to iQues.
  52. In this case the read & write are both NOP'd and the conditional forced so it doesn't try to throw a cart interrupt later using a write to BF000000.
  53.  
  54. * iQue uses pattern-matching for SI devices. It does not parse the bytecode!
  55. The normal libultra controller code is only used once, at boot. The rest of the serial input/status/reset/read/write code uses a hand-rolled library unique to dev programs.
  56. What this does is takes a list of five ints--one for each channel. It then copies into the buffer the corresponding bytecode for that command. There's eight of them, depending on how you count:
  57. 0 ignore channel; pushes a zero into the bytecode
  58. 1 byte: 00
  59. 1 device status; returns type of device or presence/error codes
  60. 6 bytes: 01 03 00 -- -- --
  61. 2 read controller input
  62. 7 bytes: 01 04 01 -- -- -- --
  63. 3 read controller slot
  64. 38 bytes: 03 21 02 {2 bytes addr|crc} {placeholder 32 bytes data} --
  65. 4 write controller slot
  66. 38 bytes: 23 01 03 {2 bytes addr|crc} {32 bytes data} {data crc}
  67. 5 read eeprom
  68. 12 bytes: 02 08 04 {addr} -- -- -- -- -- -- -- --
  69. 6 write eeprom
  70. 13 bytes: 0A 01 05 {addr} {8 bytes data} {crc}
  71. -1 reset; resets the device and returns status
  72. 6 bytes: 01 03 FF -- -- --
  73. else terminates with an error nothing checks for
  74. Basically, bytecode works like so: 0 ignores a channel, < 0 is special, > 0 is (count sent, count recieved, bytes sent, bytes received)
  75. PIF reads channels until it's out of them. -2 marks an explicit endpoint but with a "real" PIF the end is implied as well. Thankfully iQue also behaves this way. Also, commands don't have to be relevant. It simply encodes it, sends it along the port, and it's up to the device if it wants to respond. You can ask the cart eeprom line if it has any controller input (which it can, if you install a port there). iQue is forgiving on that front as well.
  76.  
  77. The difference is that the "normal" os variants pad commands so they align nicely at certain addresses. It makes reading results a smidge easier, and you can predict exactly where each channel's data will be found (the hand-rolled one uses a table of pointers). The padding byte is -1, effectively a NOP.
  78. iQue either doesn't parse the bytecode itself or somebody made a mistake and thought the 0xFF padding bytes were part of the command. *iQue ignores reads* that aren't written as:
  79. FF 01 04 01 -- -- -- --
  80. (Note: It's unknown which other commands, if any, are subject to the same bug.)
  81.  
  82. To get it to read input three functions were changed to account for aligned data:
  83. 8002E2FC V0 = p->end of pifram cmd to read input of SI device on channel index A1 using ctrl buffer A0
  84. This generates the bytecode sequence itself. It now adds the padding and advances 8 bytes instead of 7.
  85. 80001808 V0 = current buttons on controller 1
  86. 80035748 8006DE00 = current buttons, 8006DE04 = pressed buttons, 801914E0 = current buttons
  87. Both of these assumed the "unaligned" versions are in effect; aka. that the pointer to the command actually points at the command, not at a padding byte. In both, the address offset to the data was increased by 1.
  88.  
  89. None of the other various functions appear to be used so long as a zaru unit isn't detected.
  90.  
  91. * Commandline argument support is restored.
  92. The RDB version supports commandline arguments. This has been linked back in here by forcing the pointer to the string usually provided by the RDB to point to a copy of the internal ROM name at 0x20 in the header.
  93. There are two copies of osInitialize, one in the bootloader (80200000 range) and another in the main executable (80000400). The first of them has a short DMA tacked onto the end. It copies the internal name to 800001A0, usually reserved for 64DD disk gameIDs.
  94. Although not all are valid in this configuration, the available options are:
  95. -l lines
  96. -b use black
  97. -z no zclear
  98. -----------------------
  99. -f int frame count = int; default -1
  100. -m int run module number = int; default -1
  101. -d route RSP output to RDP through DRAM; default False
  102. -c calc checksum; default True
  103. -p print checksum values (allow mismatch); default False
  104. -s silent mode; default False
  105. -x show RDP images versus text output; default False
  106. -r maintain resolution (use with -x); default False
  107. -F flush RDP mspan? enables 1 primitive mode; default False
  108. -g using with debugger, dropping back to boostrap; default False
  109. -i dump images; default False
  110. -e dump bad frames; default False
  111. -a dump all frames; default False
  112. -S dump RSP; default False
  113. -D dump RDP; default False
  114. -o str board number; default "100"
  115.  
  116.  
  117. .: Test Results :.
  118. The ticket was generated with access flag 0x20 to ensure 8MB support. 4MB, 6MB, and 8MB modes were all tested with the same results.
  119.  
  120. All RSP & RDP tests passed. Any apparent differences in video output is not within the RCP but occurs when generating the output signal.
  121. Switching from interlaced mode to progressive causes several frames of color corruption. Switching video modes in general causes graphical errors (lines, flicker, etc.) over several frames. There's ghosting on the left edge of the output and during one test a stray pixel.
  122.  
  123. Observed controller range is (appoximately):
  124. ymax 85, ymin -86, xmax 81, xmin -89
  125. UR (71,72), UL (-74,72), LR (71,-74), LL (-74,-74)
  126.  
  127. -Zoinkity
  128.  
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement
Public Pastes
Advertisement
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!