Tursi's notes

Let's get coding!

Moderator: a31chris

Post Reply
User avatar
a31chris
Jaguar MOD
Posts: 894
Joined: Mon Apr 01, 2013 7:09 am

Tursi's notes

Post by a31chris » Tue Feb 25, 2014 9:15 am

Tursi wrote: 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.
Status: Unproven

OP - Stop Object
Theory: Bit 3, not documented in the TRM, generates a GPU interrupt if set when the stop object is processed.
Status: Unproven

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.

Joystick Register
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
14 -
13 -
12 -
11 -
10 -
9 -
8 - Enable audio (global system mute control)
7-0- Latched as JOY7-JOY0 (active low (when 0), rest should be high (1))


Read:
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):
7 -
6 -
5 -
4 -
3 -
2 -
1 -
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

GPIO Decodes
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.

end
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.
What came after the Jaguar was the PS1 which for all it's greatness, ushered in corporate development and with it the bleached, repetitive, bland titles which for the most part we're still playing today. - David Wightman

User avatar
a31chris
Jaguar MOD
Posts: 894
Joined: Mon Apr 01, 2013 7:09 am

Re: Tursi's notes

Post by a31chris » Tue Feb 25, 2014 9:19 am

Thunderbird wrote:
Gorf wrote:
GPU - Typo in Manual
Page 32 last paragraph says the GPU has 1k of local RAM, it should read 4k.
This is not a typo.

The GPU does only have 1k...of 32 bit RAM. I beleive that is how the manual puts it.
The GPU has sixty-four internal 32-bit general purpose registers, of which thirty-two are visible at one time. It
also has 1K of local high-speed 32-bit RAM, which is where its instructions and working data are normally
stored. It also has access to external memory via the 64-bit co-processor bus, and can perform byte, word,
long-word and phrase data transfers on this bus. It can also execute its instructions from external RAM.



Also the DSP has 32 data lines. It does not connect the other upper 16.

Clipping does not work and is best left set to zero.

I can verify clipping does not work.

I have 3rd-hand evidence saying that it may actually write where you don't want it to!
What came after the Jaguar was the PS1 which for all it's greatness, ushered in corporate development and with it the bleached, repetitive, bland titles which for the most part we're still playing today. - David Wightman

Post Reply