Can anyone lend a programmer a hand?

[Shamus]

Moderators: If this is the wrong forum, I apologize in advance.

 

Hi all,

 

I've been helping develop the portable Virtual Jaguar emulator (the one that grew out of David Raingeard's source code posting) and I've run up against something that is completely undocumented. Since I'm sure there's at least some of you out there that have access to a development Jaguar system, I was wondering if someone could help with the demystification.

 

What the deal is is this. There is a certain program that reads from the blitter's A1_FLAGS ($F02204) register (even though it's supposedly read only) after it does a blit and then uses it as A1_PIXEL ($F0220C) for a following blit. Here's the relevant GPU code:

 

F03824: MOVEFA R14, R02 [NCZ:010, R14(alt)=00F02200, R02=FFC070C7] -> [NCZ:010, R14(alt)=00F02200, R02=00F02200]

F03826: ADDQ   #4, R02 [NCZ:010, R02=00F02200] -> [NCZ:000, R02=00F02204]

F03828: LOAD   (R02), R01 [NCZ:000, R02=00F02204, R01=00F03840] -> [NCZ:000, R01=00073820]

F0382A: ADDQ   #8, R02 [NCZ:000, R02=00F02204] -> [NCZ:000, R02=00F0220C]

F0382C: SUB    R03, R01 [NCZ:000, R03=00000000, R01=00073820] -> [NCZ:000, R03=00000000, R01=00073820]

F0382E: STORE  R01, (R02) [NCZ:000, R01=00073820, R02=00F0220C]

F03830: MOVEFA R11, R01 [NCZ:000, R11(alt)=00F0223C, R01=00073820] -> [NCZ:000, R11(alt)=00F0223C, R01=00F0223C]

F03832: BSET   #16, R00 [NCZ:000, R00=00000028] -> [NCZ:000, R00=00010028]

F03834: STORE  R00, (R01) [NCZ:000, R00=00010028, R01=00F0223C]

F03836: MOVEFA R10, R00 [NCZ:000, R10(alt)=00F02238, R00=00010028] -> [NCZ:000, R10(alt)=00F02238, R00=00F02238]

F03838: MOVEI  #$41802801, R01 [NCZ:000, R01=00F0223C] -> [NCZ:000, R01=41802801]

F0383E: STORE  R01, (R00) [NCZ:000, R01=41802801, R00=00F02238]  ; BLIT #2

 

The value you see it getting from A1_FLAGS is pretty much what was stuffed in there previously, but it's definitely not (and I'm 99.999% sure about this) what you're supposed to get. I can't figure out why this particular program should be doing this, but there you go.

 

What would really help (please, please! ) is if someone with a development system could probe that location for me--do some blits and read the value in A1_FLAGS after the blitter is done.

 

This would really help not only in documenting the Jaguar hardware better, but it would be a shot in the arm for the Virtual Jaguar emulator as well (you will, of course, get credit for your discovery)!

 

-- Shamus

 

Yeah, I used to have a real live Jaguar, but gave it away long before I started working on VJ. D'oh!

[+Saturn]

Hi!

I can't help you with the code but I'm sure somebody will happen along who can.

 

Anyway, welcome

[Sinigord]

Just looking at the code section you posted, it doesn't seem to make much sense. According to the manual, F02204 is a write only address, however, when you read 32bits from that address you will get both the Flags Register and F02208 (which is A1 Clipping size and also write only). To then take these and write that to the A1 Pixel Pointer really doesn't make much sense. The next code then writes to the counter and then writes to the status register which is read only.

 

Are you sure the code is disassembled correctly ? Reading from write only registers and writing to read only just seems a bit strange to me.

 

If this is what's happening, you'll need to supply a larger section of code, preferably a binary that can be loaded to the specific address and executed. Debugging GPU code is a nightmare, even with the Alpine board, but not impossible

 

Regards,

 

Gordon

[Shamus]

Just looking at the code section you posted, it doesn't seem to make much sense. According to the manual, F02204 is a write only address, however, when you read 32bits from that address you will get both the Flags Register and F02208 (which is A1 Clipping size and also write only).

 

Err, the difference between $F02208 and $F02204 is 4 bytes which is 32 bits... How would it pick up A1_CLIP as well?

 

To then take these and write that to the A1 Pixel Pointer really doesn't make much sense. The next code then writes to the counter and then writes to the status register which is read only.

 

Are you sure the code is disassembled correctly ? Reading from write only registers and writing to read only just seems a bit strange to me.

 

The code is correct. What's in question here is not the GPU but the blitter. Apparently the JTRM wasn't telling the whole story about some of the locations in the blitter, since that GPU code was using the supposedly WO location $F02204 as a base address for another blit. I'm pretty sure whoever wrote that snippet of GPU code either stumbled on to something or was privy to some insider knowledge (my guess would be the former--I've seen a fair share of code that only works "by accident" because the developers misunderstood something)...

 

If this is what's happening, you'll need to supply a larger section of code, preferably a binary that can be loaded to the specific address and executed. Debugging GPU code is a nightmare, even with the Alpine board, but not impossible

 

You wouldn't have to debug any GPU code, you'd just have to write a little 68K code that set up the blitter (a few different cases) and then examine $F02204 afterward to see what the blitter is offering at that address (I could write a small routine for you if you'd like ). My suspicion is that the blitter pushes (or mirrors) something that keeps track of an internal address, and so we have the read from a supposedly "write only" register.

 

-- Shamus

[Shamus]

Problem solved.

 

It seems that by reading from $F02204 it was actually reading from $F0220C. My guess is that the blitter ignores the lower three bits on that address block ($F02200-F0220C) and simply returns the value at $F0220C.

random hypothesis>

 

I'm sure I'll have more questions in the near future... Thanks!

 

-- Shamus

[Guest]

helping hand needed?

 

ok. here you have one. free of charge. keep it