SamBushman Posted March 27, 2011 Report Share Posted March 27, 2011 Hey guys, recently I have been looking at the graphics pipeline for the Jag. In particular, I have been studying Belboz's popular "Hello World" example program (http://www.hillsoftware.com/files/atari/jaguar/jag_hello.zip) to better understand how to create a simple screen buffer. When looking at his Startup.s where he is creating the object list for the object processor he uses d2 and d3 as "link address overlays". He performs some operations on the values stored in d2 and d3 before creating the first branch object that don't make much sense to me. What in particular is throwing me off is the shifting and swapping. Below is the code in question: lea listbuf,a0 move.l a0,d2 ; Copy add.l #(LISTSIZE-1)*8,d2 ; Address of STOP object move.l d2,d3 ; Copy for low half lsr.l #8,d2 ; Shift high half into place lsr.l #3,d2 swap d3 ; Place low half correctly clr.w d3 lsl.l #5,d3 If someone could provide some explanation to what sort of data the LINK section of the object header is storing (a relative offset in bytes?) as well as shedding some light on the logic of the shifting and swapping done at the end of the above code sample I would appreciate it. Furthermore, if someone in the community has written a real rock solid article/tutorial on the graphics pipeline of the Jag I would love to read it The official docs have been helpful, but still leave me scratching my head a bit Thanks a bunch guys, Sam Bushman Link to comment Share on other sites More sharing options...
SCPCD Posted March 27, 2011 Report Share Posted March 27, 2011 lea listbuf,a0 copy address of listbuf to register a0 move.l a0,d2 ; Copy copy it to the d2 register to make some operation add.l #(LISTSIZE-1)*8,d2 ; Address of STOP object compute the address of the STOP object move.l d2,d3 ; Copy for low half copy it to the d3 register d2 = d3 = abcdefghijklmnopqrstuvwxyz012345 lsr.l #8,d2 ; Shift high half into place d2 = 00000000 abcdefghijklmnopqrstuvwx lsr.l #3,d2 d2 = 00000000000 abcdefghijklmnopqrstu swap d3 ; Place low half correctly d3 = qrstuvwxyz012345 abcdefghijklmnop clr.w d3 d3 = qrstuvwxyz012345 0000000000000000 lsl.l #5,d3 d3 = vwxyz012345 000000000000000000000 As 68k register is 32-bit you need 2 register to make a 64-bit phrase; you will have the LINK information onto 2 differents register : => the register d2 will be used for bit[42..32] of the phrase that represent bit[21..11] of absolute address of the next object => the register d3 will be used for bit[31..24] of the phrase that represent bit[10..3] of absolute address of the next object NB : it can have a bug if there is not masking bit for low bit[2..0] and high bit[31..22] of the address when the previous result is directly used to make the object : if not masked, it can have wrong bits in the final object fields HEIGHT and DATA for bitmapped object for example. final d2, d3 should be : (to avoid bugs) d2 = 000000000000000000000 nopqrstuvwx d3 = vwxyz012 000000000000000000000000 Link to comment Share on other sites More sharing options...
Matthias Posted March 27, 2011 Report Share Posted March 27, 2011 Hello! Hey guys, recently I have been looking at the graphics pipeline for the Jag. In particular, I have been studying Belboz's popular "Hello World" example program (http://www.hillsoftware.com/files/atari/jaguar/jag_hello.zip) to better understand how to create a simple screen buffer. When looking at his Startup.s where he is creating the object list for the object processor he uses d2 and d3 as "link address overlays". He performs some operations on the values stored in d2 and d3 before creating the first branch object that don't make much sense to me. What in particular is throwing me off is the shifting and swapping. Below is the code in question: lea listbuf,a0 move.l a0,d2 ; Copy add.l #(LISTSIZE-1)*8,d2 ; Address of STOP object move.l d2,d3 ; Copy for low half lsr.l #8,d2 ; Shift high half into place lsr.l #3,d2 swap d3 ; Place low half correctly clr.w d3 lsl.l #5,d3 If someone could provide some explanation to what sort of data the LINK section of the object header is storing (a relative offset in bytes?) as well as shedding some light on the logic of the shifting and swapping done at the end of the above code sample I would appreciate it. Furthermore, if someone in the community has written a real rock solid article/tutorial on the graphics pipeline of the Jag I would love to read it The official docs have been helpful, but still leave me scratching my head a bit Here is what a Branch-object looks like (ASCII-art taken from the Underground-docs): ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 10 This is what a branch object looks like: ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Phrase #0: 63 56 48 40 32 24 16 8 3 0 +--------^---------^-----+---^--------^--------+--------+--+-----^----+---+ | unused | Link-address | unused |CC| VCnt |011| +------------------------+---------------------+--------+--+----------+---+ 42..........24 23..16 15.14 13...3 2..0 19bits 8bit 2bit 11bits 3bits (11.8) Although a Branch-object is one of the more simpler object-types, creating it with a 68000 isn't quite easy, because the 68000 can only handle up to 32bits (a LONG-word), while all Jaguar-objects are layed out in 64bits (PHRASEs). That's the reason why the Link-address is spread over two registers (d2+d3) in the given 68000-assemblercode, additionally you need to consider that unlike the 68000, which can read a LONG-word from a WORD-adress, all PHRASE-variables need to be aligned on a PHRASE-boundary, so you can usually forget the lowest 3 bits when composing a Jaguar-graphicsobject. BTW: The Link-adress is not an offset, it's a real 22bit-address in the Jaguar's Objectprocessors addressspace. Looking at the object-layout the two used 68000-registers should be filled with portions of the link-address like this: d2 will be used for the bits 32 to 42 of the PHRASE, holding the upper 11 bits (11-21) of the 22bit-Link-address it its lower 11 bits, d3 will be used for the bits 24 to 31 of the PHRASE, holding bits 3-10 of the 22bit-Link-address in its upper 8 bits. For d3, SWAPing is just a fast way to move the desired link-adreessbits from the lower 16bit-half of the 32bit-register to the upper 16bit-half. Kind regards Matthias Link to comment Share on other sites More sharing options...
SamBushman Posted March 28, 2011 Author Report Share Posted March 28, 2011 Alrighty, that make sense. Thanks Looking farther down in the routine, I notice that whenever the phrase for a given object needs written to memory, the high 32-bits are written first, then the address is incremented and the low 32-bits of the phrase are written. Effectively, this is happening: Example Address Phrase Half ------------------------------------------------ $00000000 Phrase Bits [32:63] $00000004 Phrase Bits [0:31] Is this due to the 68k being a Big-Endian processor, or am I reading the code incorrectly? Thanks guys, Sam Link to comment Share on other sites More sharing options...
SCPCD Posted March 28, 2011 Report Share Posted March 28, 2011 Yes, it's because the jag is used in big-endian mode Link to comment Share on other sites More sharing options...
DerOtto Posted March 29, 2013 Report Share Posted March 29, 2013 Furthermore, if someone in the community has written a real rock solid article/tutorial on the graphics pipeline of the Jag I would love to read it tongue.gif The official docs have been helpful, but still leave me scratching my head a bit smile.gif yes... what i would love to see too ! simply explayn the startup.s in every detail.. why and what is done there i would be very thankfull for your help Link to comment Share on other sites More sharing options...
Recommended Posts