Jump to content

Question regarding creating objects in Belboz's Hello World Example


SamBushman

Recommended Posts

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 :P 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

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

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 :P 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

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

  • 2 years later...
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

Guest
This topic is now closed to further replies.
×
×
  • Create New...