I thought I'd share some of the notes I have in my printout of the Jaguar TRM. Some of these things are known, some may be less obvious. Maybe having it all in one place will help someone out. In some places I've noted theories I've come across - some are proven, some disproven, some are still unproven to me. TRM = Technical Reference Manual Revsion 8.
System Clock: 26MHz
Jaguar cartridge startup: The system starts with the cart in 8-bit mode. The 68k reads address $800400 to determine the true cartridge width. Once set the boot begins. A single bit at $800408 indicates whether to display the boot screen (when cleared, the screen stays black). Next the cartridge verification code is loaded. The first byte is a negative value indicating how many encrypted 65-byte blocks to read - by default it's $F6 (-10) to read 10 blocks into memory. These blocks are decrypted via the GPU using the Jaguar's private key, then as long as that went well, the decrypted code is executed. (If it fails, you either get the red screen or a crash, depending on the exact failure). This decryption takes about 500ms per block, and is the main cause of the 5 second startup delay. The standard boot block then checksums the cartridge, verifies the checksum is valid, and prepared to enable the system. The "TYPEAB" universal header contains all the same code but skips the checksum. Finally, the GPU writes $03D0DEAD to address $F03000 and then halts - if any failures occurred a different value is written. When the GPU stops, the 68k resumes, and checks the value. If it's $03D0DEAD, then the 68k loads the cartridge boot address from $800404 (which is usually $802000), and jumps to it.
Theory: You can substantially speed the boot process by creating a new encrypted bootloader that only loads one block.
Status: Proven. Credit to KSkunk. A utility by Tursi to patch any existing cartridge is available on this forum at http://jaysmith2000.ipbhost.com/index.p ... opic=11703
OP - BitMapped Objects
Reinforcement: Negative Y coordinates are NOT supported, range is 0-2047. Negative X coordinates ARE supported, range is -2048 to 2047.
Reinforcement: Bitmapped objects are 2 phrases long and must be aligned to a 2 phrase boundary. Scaled bitmapped objects are 3 phrases long and must be aligned to a 4 phrase boundary.
OP - Graphics Processor Object
Theory: YPOS on the GPU Interrupt object is not honored.
OP - Stop Object
Theory: Bit 3, not documented in the TRM, generates a GPU interrupt if set when the stop object is processed.
GPU/DSP - Main RAM Jumps
Theory: Jumps can not be reliably used in main RAM.
Status: Disproven. Credit to Gorf and AtariOwl. There are specific circumstances under which main RAM jumps are completely reliable. The exact details are currently proprietary.
GPU - Potentially confusing term in Manual
Page 32 last paragraph says the GPU has 1k of 32-bit local RAM. This means it has 4KB of RAM arranged in 32-bit words.
GPU - STOREP Fails under DMAEN
Theory: STOREP to external RAM does not properly write the high data register when DMAEN is set
Status: Observed but not characterized. It appears a fixed pattern is written. Could use independent confirmation.
Blitter - Pixel Size
Theory: Pixel sizes of 2^6 and 2^7 do not work.
Status: Seems confirmed. 2^6 does SOMETHING but is not characterized. 2^7 does not appear to work.
Theory: Pixel size affects performance even when using Phrase Mode
Status: Confirmed. Copying the same data in 16-bit versus 32-bit mode made about a 4% difference in my tests. This may simply be pixel counting overhead. There is some thought required to run the blitter in a different pixel width than the data you are moving.
Blitter - Window Pointers
Theory: A1 Window Pixel Pointer and A2 Window pointer read from different addresses than they write
Status: Documented, accepted, but not personally confirmed. A1 Window Pixel Pointer writes to $F0220C and reads from $F02204, while the A2 Window pointer writes to $F02230 and reads from $F0222C.
Blitter - Y Add Control Bug
Theory: The A1 Y add control bit affects both A1 and A2
Status: Documented and confirmed. Page 135 of the TRM covers this.
Blitter - Outer Loop Performance
Theory: Each of the outer loop address updates induce a performance penalty.
Status: Confirmed. Unfortunately due to the Y add control bug sometimes you have no choice.
Blitter - Command/Status Register
Reinforcement: The command/status register, though documented separately, are in fact at the same address.
Blitter - A1 Clipping
Theory: A1 clipping is broken.
Status: Confirmed. Credit to Thunderbird. The TRM and his experience suggests it has some other bugs which further make it dangerous to rely on, which may cause it to write outside of your target memory area.
Blitter - Fractional Increment Performance
Theory: Fractional increment in the outer loop using phrase mode with single writes in the inner loop, is faster than fractional increment in the inner loop using 32-bit moves.
Status: Feasible. My code showed a 20% improvement in throughput despite the outer loop overhead, although of course the step of the increment is restricted to phrase boundaries (which is 4 pixels in 16-bit mode). It would be faster still if the inner loop supported phrase mode, but it does not appear to.
Sync Serial Interface/I2S
Theory: In Mode16, the Word strobe is reversed from the documentation.
Status: Unverified. Will update with the actual value for each channel upon testing.
Theory: In an underrun situation, the clock output stops and no futher data is emitted.
Status: Disproven. The last written word will repeat.
The port pinout is in the manual but the register breakdown is harder to come by. I don't have full details as yet.
Write (bit index, 0=lsb):
15 - Enable joystick outputs
8 - Enable audio (global system mute control)
7-0- Latched as JOY7-JOY0 (active low (when 0), rest should be high (1))
The inputs read depends on the row that is currently selected. Both sticks are read at the same time and the result stored in the high byte of the word (bits 8-15). I may have the numpad values wrong here:
Row 0: 369# RLDU
ROW 1: 2580 *741
Row 2: *741 2580
Row 3: RLDU 369#
(First group is JOY1, second is JOY0
For the low byte (bits 7-0):
0 - EEPROM Read Data
Joystick Button Register
Not 100% certain on these mappings. Again, they depend on the row selected (see above), and return both joysticks at once. I only have the 4 least significant bits (3-0) mapped:
Row 0: Ox AP
Row 1: Cx Bx
Row 2: Bx Cx
Row 3: AP Ox
(First group is JOY1, second is JOY0
Theory: GPIO pins strobe when read, emit data when written.
Status: Unproven. Based on studying the EEPROM access code. Not in the documentation is that GPIO0 appears to also be EEPROM Write Data/Clock, and GPIO1 appears to also be EEPROM Strobe.
DSP is attached as 16-bit
Theory: The DSP is wired into the Jaguar as a 16-bit device
Status: Accepted. It's of note only because the bug list in the TRM is potentially confusing. Bug 21 states that the 32-bit DSP is treated as 16-bit, and that this does not affect the Jaguar console. This is because the DSP is 16-bit anyway.
End of Interrupt
Theory: You cannot clear IMASK in the delay slot of the jump out of the interrupt, because the instruction that was interrupted may not get the correct register bank.
Status: Unproven. This is the documented way to exit and has worked fine in my code with heavy interrupt usage. However it's possible my code may mask transient errors like this.
Most of the bugs in the TRM not otherwise addressed are accepted, so they won't be repeated here. As regards the "Lies and Damned Lies" section on page 140, I've only got one that I've worked with, noted above, the rest I would also classify as unproven (except the obvious one about not putting an MMULT after a jump).
That's what I've got so far, anyway.