Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by SamBushman

  1. As an update, I realized I was saving the address of the high 32 bits instead of the low 32 bits (oops). After correcting that mistake I got horizontal movement working fine. For whatever reason, the YPOS seems to be locked (any changes are reverted by the hardware). I will keep reading the Jaguar docs and see if I can figure it out. If anyone here can enlighten me to what I'm missing, I'd appreciate it.


    Cheers and thanks guys,



    --Another quick update

    Doh. I thought to take a look at the demo's level 0 interrupt and saw that when the bitmap object is created, a copy of the first phrase is saved to another part of memory for restoring (apparently the first phrase is destroyed by the object processor according to the comments). As such, I was in fact correctly changing the object header, but the interrupt was changing it back. I changed my C pointer to reference the stored copy of the header that was being restored. Now my coordinate manipulation is persistent. Sorry for the wasteful posts guys :P



  2. Hey guys,

    I am currently working on understanding the graphics pipeline of the Jaguar. I have monkeyed with Belboz's sample program a bit, altered the Bitmap object's header, and am now blitting an image defined by an external assembly file to the screen (hurray!). Now I wish to use controller input to move it around the screen. I have written a simple function to poll for the 1st player's controller and can successfully get input. My first attempt at moving the bitmap was to save the address of the object's headers to global variables, reference them from C, and alter them as needed. When I do this, the screen goes almost completely black and restores itself once the input key is released. Based on this, I figure I am going about it all wrong.


    My question therefore is "How do I manipulate the screen position of an image defined by a bitmap object in the Object Processor's List?"


    Thanks as always for your input. Cheers,


  3. 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,


  4. 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

  5. nm, I'm dumb :/

    I was messing with a version of the sdk software that I had just found online and chances are that it is incomplete. After looking into the files provided by Michael Hill's development tools I found working versions of all the examples.


    The only dangling issue now is how do I emulate aln's "-i fileName" flag (Includes the binary data contained in the file specified by "fileName" in the link. The contents of the file are placed verbatim into the DATA section. This is part of the jaguar doc's explanation of the option.) with vlink? The documentation pdf didn't seem to shed any light.


    Thanks and sorry for not double checking my software earlier :P,


  6. Hello,

    As an exercise (and resource for future reference) I wanted to assemble the examples provided with the official Atari Jaguar SDK (such as JAGMAND, the Mandelbrot set example). I have gotten the JAGMAND example to successfully assemble and run on Virtual Jaguar v299, but I am having trouble with some of the other examples. One common issue I am having is that directories referenced in the development documentation (such as the WORKSHOP directory) don't exist, others (such as the Mandelbrot example) are present, but some source files are named differently or are missing (such as Startup.s in the Mandelbrot example). The second issue I am having is in particular to the Joystick example (EXAMPLES\JOYPAD). The three dependency files: jaguar.inc, objlist.inc, and joypad.inc are all present, but it appears that joypad and objlist have been merged into jaguar.inc and thus just include jaguar.inc. This is fine, except that if this include structure is used with smac, then it throws a bunch of warnings about multiple equates for all the constants, as both DEMO.s (the original source file) and the dummy *.inc files include jaguar.inc. Furthermore, it appears some of the macro values are not defined in jaguar.inc.

    Examples of this are:

    CHRO_CLK on line 94 of DEMO.s

    O_YPOS on line 141 of DEMO.s

    O_XPOS on line 151 of DEMO.s


    I am able to prevent the multiple equate errors by simply commenting out the dummy includes, but I am still missing some of the macros. What I would like to know is:

    1. Is there a comprehensive version of the SDK that includes all of the code samples referenced in the documentation?

    2. Is there an option I can set on smac to prevent the multiple equate warnings so I may avoid having to patch every single code example included with the SDK?

    3. I am assuming that the lack of some macro values is due to the ever changing headers produced by Atari over the course of the Jaguar's lifetime. As such, some of the macros and utility headers may have been moved around. Has anyone gotten all these examples to assemble successfully, or does there exist at least a version of the Jaguar SDK that includes working copies of all these examples?


    Hopefully my explanation of my issues with the example programs doesn't come off as whining or complaining. I can understand that just getting official documentation and code is quite a feat. I would just like to be on the same page as the community regarding the state of these examples. Thanks for your time and patience with a Jag newbie.



    Sam Bushman

  7. -> Orion

    Where in the source files is the functionality to dump main memory (is it just a bool that needs flipped like "doGPUDis" in gpu.cpp? Also I noticed that when a rom runs (and doesn't crash :) ) it seems to already dump the contents of memory and the cpu registers. Any info on the modifications you made would be great. I have already followed your previous modifications of getting bjl roms running on revision 299 (the newest "stable" version on Shamus' SVN). Your comments in the packaged readme and the earlier post were very helpful. Thanks :)


    -> Tursi

    Sadly I'm horrible with a soldering iron, so the chip mod isn't feasible for me. The way I have scheduled my research, I will have just finished messing with the 68k assembly language and studying the processor itself and started looking into gamepad input by the time the skunkboards are set to ship (February 15th according to the old goatstore announcement), so I'm not too worried. The idea is solid though. I had messed with the JagCD based BJL tools a bit before my JagCD died :(, so I know the convenience :)


    Overall, thanks for the many responses guys. I've tooled around these forums for a while and have seen that between here, Atariage, and Sector II the Jaguar homebrew community tends to be friendly and active. This is partly what has given my the confidence to try such a project as teach myself to homebrew on the Jag.


    Cheers and thanks again,

    Sam Bushman

  8. Thanks for the info. I've downloaded the source for Virtual Jaguar (Along with its dependencies) and am running into some issues compiling it under minGW with GCC version 4.5.0.

    After downloading the development libraries/dlls for zlib and SDL and running "./compile" in the emulator's directory the program compiles for a bit and stops in the "src/sdlemu_config.cpp" source file with errors that the strcmp() and atoi() functions are not in the scope of the "sdlemu_getval_int" and "sldemu_getval_int" functions.

    Has anyone else had issues compiling Virtual Jaguar 1.0.7?


    Thanks and have a good one.

  9. Hello,

    my name is Sam Bushman. I am looking to learn to homebrew on the Atari Jaguar as an independent study project at college. While waiting for my Skunkboard v3 to come in the mail, I had hoped to get started by running compiled code on the PC via an emulator. I was wondering if there was a way to dump at least the current state of processor registers in either of the two major jaguar emulators (Virtual Jaguar or Project Tempest). If not, is there another way to develop strictly on a windows system and debug running code?


    Thanks for all the great resources offered on this site and have a good one.

  • Create New...