Jump to content
Jagware

rush6432

Members
  • Content count

    36
  • Joined

  • Last visited

Posts posted by rush6432


  1. After one attempt here at integrating this tool into an existing program ive had no good results. Unsure why, but it seems that it crashes even when setting up the stack 12k away from the end of ram and calling it as the directions say while including the .s file.

     

    I havnt used mode 4, just the mode 7 example.

     

    Am i missing something?? Could always benefit from a little better compression :) allows for more stuff in programs.


  2. Just curious if someone can give me the break down on using sinewaves for object position.

     

    Usually it's not very practical to store the object's position using polar coordinates AKA rho,theta (ρ,θ) or at a stretch of the definition, sine waves. What is rather useful though is to use polar coordinates for expressing the movement vector or speed for X and Y axes in layman's terms.

     

    Let's assume that you have an object at (100,200) and you want it to move with a speed of 5 pixels/frame 30 degrees north-east. The pair (5 pix/frame,30°) is exactly a representation of the movement vector in polar coordinates. If we were to add this every frame to the coordinates of the object (which are expressed in the Cartesian system), we'd get the desired motion. Since our object's position is expressed in Cartesian coordinates and we can't change the way the hardware stores coordinates, it follows that we have to convert the movement vector to the Cartesian system as well. We can do this relatively easy using the 2 following formulas:

     

    Δx = r * cos(θ) = 5 * cos(30°)

    Δy = r * sin(θ) = 5 * sin(30°)

     

    If we were to add this pair of equations to our coordinates we'd get the coordinates of the object for the new frame, thus:

     

    new_x= Δx + 100 = 5 * cos(30°) + 100

    new_y= Δy + 100 = 5 * sin(30°) + 200

     

    One final thing to notice is that actual Cartesian coordinates have the x axis pointing right and the y pointing up, but screen coordinates have the y axis pointing down (the pair of coordinates (0,0) is at the top left corner instead of the bottom left because of this), so if we were to add the above, the object would head to the bottom right instead of top right. So we have to adjust the 2nd equation like so:

     

    new_y= -5 * sin(30°) + 200

     

    And all will be well.

     

     

    Apologies if that wasn't what you asked for and it's common knowledge for you, but this is what I understood you were asking in the first sentence of your question. Of course, if this is what you asked for and something's not clear in my answer, feel free to ask further :).

     

    No that sums it up. i somewhat knew this already but was more inquiring about the process of creating the tables themselves so that i could write a routine to call to read the tables for x/y positions and have an object follow a pattern per say.


  3. Or there's a sine table already hardcoded into the DSP. It's not the most precise in the world, but you can interpolate between samples if you need higher precision.

     

     

    ahh thats right...... i totally forgot about that...

     

    Thanks for the replies. ill have to mess around with it a bit and see what i come up with.

     


  4. Just curious if someone can give me the break down on using sinewaves for object position.

     

    Mainly what im curious about is how to go about generating the sinewave table that code can be written to pull information from. (x and y axis).

     

    Is there such a tool that makes it easy to create a pattern or wave and then output the coordinates easily?


  5. Congrats on this new release!

    It's especially nice to see new cart based games, looks nice!

    I agree with Orion, but then again it's good to see that the binary will be available for people to play.

    However I wonder why 50/60 Hz compatibility wasn't added? Except for Dragon's Lair a 50/60 Hz switch wasn't really necessary on any Jaguar.

     

    i thought raiden had issues with pal as well?!?

     

     


  6. As for price - they've said they've allowed enough to cover the cost of their Alpines, EPROM burner and other stuff, and they've still come in at the same price as the last homebrew on cart, so it seems they did quite well (especially considering the quality of the physical production). So potentially, later releases will be cheaper.

     

    The PAL/NTSC problem is an object displacement issue (as I understand it), the kind of thing you get quite often before you get a good skeleton framework set up to work with. It's not present in stuff they've worked on after this, so shouldn't be an issue in future. Can't blame rush for not wanting to go back and work on this further, he's pretty much drawn a line under this game and wants to get on with other things - know the feeling.

     

     

    Yeah, cost of alpines + eprom burner and parts is just downright expensive...

     

    As for the pal/ntsc issue, yes its more due to the fact that i developed on an ntsc console and didnt really bother until about 75-80 percent or more through to look into pal :( (Stupid on my part)

     

    Unfortunately at that point ive hard coded alot of screen positions for sprites and while i COULD fix this, i feel since a first run is out already it would be unfair to fix it for the next run and leave the original 23 buyers with a semi crippled version.

     

    We plan on doing some more carts and some CDs here soon hopefully. Binary should be out after these so everyone can play it.

     

    As for fixing though, sh3 you're right. im drawing a line under it and calling it done. we have advanced on to other jag projects that are sharper and more advanced/improved.

     

    Honestly i dont see us trying to charge anymore than the $80usd + shipping for a hard copy full cartridge release. I can say thats the most expensive it will probably get..

     

    Hell madbodies charged 80 and used a dvd/vhs style case with foam.... no manual...


  7. I use RMW bit for "shadows" in CRY mode. I make a simple picture in low colors. I then convert it to an .S file using tga2cry (in 1/2/4bit/pixel) mode.

    Next step is to edit this .S file to alter the colormap information and remove the "color" component C and R...

    And finaly I make some test using different Y value depending of the background (to avoid saturation effects).

     

     

    Thanks guys for the information. very informative. Ill have to tinker with it when i get some more free time.

     

    The jag dev manual mentions a mixed mode rgb/cry video mode?? $6C7 when pushed into VMODE seems to be 16bit rgb 320x240ish and $4C7 seems to be cry

    cry 16bit 320x240 is there a mixed mode like the manual states where you can have cry objects and rgb objects in the same list and display properly or is it just one or the other? I havent looked at the manual in some time so i may have to sometime soon, but figured someone might know off hand.


  8. I havn't found many examples and or much documentation on this topic. I have searched and found a thread or two here but it ends up partially in french through the thread. Seems i missed the boat on this topic completely...

     

    Anyhow, can anyone fill me in a little on how the transparency feature works using RMW and or what the rules might be when creating images that use this function or bit set in the object on the obj list? my guess is that getting transparency is only really achieved through RMW bit and CRY coloring or can the RMW bit be used with RGB successfully?

     

    Ive seen the Blobs.bin example which i think zerosquare?! or someone else has created (correct me if im wrong on the author) looks to be using several bitmaps overlayed using this feature...


  9. Hello, just popping in with a small warning:

     

                      move.l a0,usp

     

    If you assemble using smac, this will get wrongly assembled as

     

                      move.l a0,sp

     

    which means your stack will point at $0, and your program might crash if you're not setting the stack afterwards! I found this the hard way a couple of years back :).

     

    im using the older linker/compiler at the moment.

     

    Looks like the code matthias posted from bastian schick helped alleviate a few problems. Using this prior to everything in my program and then setting up the stack again and initializing video and other basics it works with no problems finally. I was able to test burn this to some chips and try it on a stub jag. It seems to boot properly every time now and even through the jag cd, but then again its still a stub jag. Id like to continue testing it on a full production system to make 100 % sure everything is still ok.

     

    For now, i wont say its solved as i may speak too soon heh..

     

     

    Looks as if this has solved the issue. Many thanks to those who have made suggestions and helped along the way.

     

    I have made a few successfull eprom burns that boot flawlessly over 50 times in a row on a production un-modified NTSC console :)

     


  10. Hello, just popping in with a small warning:

     

                      move.l a0,usp

     

    If you assemble using smac, this will get wrongly assembled as

     

                      move.l a0,sp

     

    which means your stack will point at $0, and your program might crash if you're not setting the stack afterwards! I found this the hard way a couple of years back :).

     

    im using the older linker/compiler at the moment.

     

    Looks like the code matthias posted from bastian schick helped alleviate a few problems. Using this prior to everything in my program and then setting up the stack again and initializing video and other basics it works with no problems finally. I was able to test burn this to some chips and try it on a stub jag. It seems to boot properly every time now and even through the jag cd, but then again its still a stub jag. Id like to continue testing it on a full production system to make 100 % sure everything is still ok.

     

    For now, i wont say its solved as i may speak too soon heh..

     

     


  11. Because we don't know where the OP list is so we can accidentaly erased it when copying ROM to DRAM ?

     

     

    Very good point ^^^

     

    I personally did not know that the system upon boot up set itself to a stop object already.... I was under the impression you had to set the hw and put it on a stop obj to keep the system happy or else when the VI/Interrupts are enabled the olp would have nothing to process and crash/lock the system....

     

    If i were to copy my binary file after bootup its a possibility that the stock rom is putting the stop obj in the middle of ram and im just overwriting it when copying to ram then which would explain my problems ive been having...


  12. Matthias and Matmook, thanks for the replies.

     

    I have tried the supplied code you suggested with it "shutting down" the jaguar esentially and setting the OP to a stop object at location $0

     

    This seems to work very well and my loader loop loads my binary to ram which and executes. Seems my program startup is a little screwy because ive tried the same thing using just the atari startup.s file as its own binary to just display the licensed to or by logo and this loads perfectly fine, however when swapping the binary loaded to ram it seems my program is not initializing something right.... Sound plays but garbled scaled graphics appear.

     

    Atleast im in the right direction now though :) Thanks to all.


  13. Yop ! Hum, quick idea... Is the stop object of your loader program in RAM ?

     

    it isnt actually.... its defined within the cart loader program...

     

    i can however relocate this..

     

    Do you think it may hve to do with the transition from a stop obj to a real list by chance? waiting until an interrupt completes now prior to loading in the list is how ive got it setup at the moment, but this is within the program thats loaded to ram. one the loader program dumps the binary file to ram it that program in ram takes over and finishes setting up a few system settings.

     

    Another thing i thought might be holding it back is the possibility of writing the stop obj with the 68k or the gpu... ive heard the 68k will do it in two writes where as the gpu can do it in a single write and be done. Any real issues with using the 68k to set the OLP to a stop specifically? Ive seen quite a few other programs do this as well which makes me think its not a huge deal but others swear the gpu is the only way to set the OLP to a stop upon system startup (ie atari startup routine)

     

     

    Ill see if i can post a snip of code of how i have it setup at the moment when i get home.


  14.  

    Quest continues....

     

    Boots, but intermittently.....

     

    im not quite sure what the issue is here. On a stub jag it boots literally every time...The loader program sets the disables the VI and sets the OLP to a stop object. tried to set it with the gpu (like atari does) and even with the 68k. no dice

     

    not quite 100 percent sure what im missing here but my best guess would be a transition from the list with a stop object in the loader program to a fully populated list when the program in ram takes over.

     

    Anyone care to shed some light onto this with their own experiences in "loader" programs loading ram based games? Am i missing something obvious? if so please point a fellow hobbyist in the right direction :)


  15. Just burned eproms again here, this time i used the atari video startup sequence/system init file supplied with the SDK. Didnt work (suprise :rolleyes: ) this was however just in the program that is transfered to ram by the wrapper program.

     

    I used my wrapper program to encapsulate the binary file into a file that loads from cart and directly to ram. However i literally have the wrapper just doing the copy right away and nothing else. im guessing this could be my problem??? im assuming i should throw atleast something to the effect of this....

     

    move.l #$70007,G_END

    move.w #$FFFF,VI ; disable video interrupts

     

    move.l #STOPOBJ,d0 ; stop the obj processor.

    swap d0

    move.l d0,OLP

     

    in the wrapper program? should disable video and set obj processor to a stop object so the system wont crash... that would be my best guess as to why its doing nothing afterwards...... could be crashing before it even starts the copy of the program to ram??

     

    Or i could possibly use the startup.s (atari sys startup file) AS the wrapper program to setup the system and then throw in some copy code to load the binary to ram and jump to the ram location.... the binary file would just not have the sys init stuff and would perform the normal functions of what its designed to do.

     

    Anyone see any issues with either method?

     

     

    Well.... i feel like a fool.....

     

    the above theory was correct....

     

    I jumped directly to copying the binary instead of disabling the VI and stoping the obj processor which caused it to crash and lock the system and never really either complete the copy of the binary file to ram or even start copying....

     

    All fixed though, the above code when added with a basic copy loop for the binary file works like a charm!

     


  16. Just burned eproms again here, this time i used the atari video startup sequence/system init file supplied with the SDK. Didnt work (suprise :rolleyes: ) this was however just in the program that is transfered to ram by the wrapper program.

     

    I used my wrapper program to encapsulate the binary file into a file that loads from cart and directly to ram. However i literally have the wrapper just doing the copy right away and nothing else. im guessing this could be my problem??? im assuming i should throw atleast something to the effect of this....

     

    move.l #$70007,G_END

    move.w #$FFFF,VI ; disable video interrupts

     

    move.l #STOPOBJ,d0 ; stop the obj processor.

    swap d0

    move.l d0,OLP

     

    in the wrapper program? should disable video and set obj processor to a stop object so the system wont crash... that would be my best guess as to why its doing nothing afterwards...... could be crashing before it even starts the copy of the program to ram??

     

    Or i could possibly use the startup.s (atari sys startup file) AS the wrapper program to setup the system and then throw in some copy code to load the binary to ram and jump to the ram location.... the binary file would just not have the sys init stuff and would perform the normal functions of what its designed to do.

     

    Anyone see any issues with either method?


  17. The fact that a normal game runs fine is pretty strange... if the endianness or the bus width had been wrong, it wouldn't run... (note for Matthias : the universal header is set for 32-bit bus width).

     

    There's the possibility that your program doesn't initialize a register that happens to be set correctly when running on a Skunkboard, but not on a Stubulator BIOS. Try checking that you're initializing the video registers properly, especially VI.

     

     

    I was setting the VI register early on in the code but.. ive eliminated my startup code all together now and just used the atari startup.s file instead to get the system up and running. seems to work fine so far when testing.

     

    As for the eeproms

     

    Can anyone shed some light on which method would be better suited for encrypting/splitting the roms??

     

    Should i just use the jagcrypt.exe program which splits and encrypts or just use the manual copy of the univ.k3y file onto the binary and then use the atari romsplit.exe file?? does it really matter??

     

    Is there a preferred method here to use?


  18. ...but all i get is a black screen afterwards (this is on a stub jag)

     

    ...

    ..

    .

    I then use the following on a windows machine to put the 8k universal header on the file.

    copy univ.k3y/b + program.bin/b ENCRYPTED.ROM/b

     

    Is the bit for showing the spinning cube set in that universal header?

    If so: Does the screen go black immediatelly after booting the Jaguar or does the cube show up and the screen wents black after it?

     

    Bye!

    Matthias

     

    I am unsure if the bit is set for the spinning cube in the header. Im not quite sure how to check this other than a hex editor and even them im not sure what id be looking for really.

     

    The spinning jaguar cube does come up but thats due to it being a stub jag i think.

     

    I really probably need a normal jaguar to test this stuff out on.

     

    Ill try a copy of a 2mb game here and see what i come up with using the same process i listed above.

     

     

    Edit: i was able to burn iron solder. all i did was split the rom file with the romsplit program and burned each portion to a chip.

     

    It did show the jaguar logo here but then went to a red screen for 2 seconds and then started the game. my only guess is that it didnt pass encryption and the stub jag bios let it pass anyway. It didnt help that one of my chips on that burn didnt pass the verify stage but still worked.

     

    Another update, ran the binary file through the Jiffi program to make a rom file and then used a windows hex editor to strip out the padding. testing the rom file after stripping out the padding and worked just fine. then used romsplit and split the rom and burned on to respectiv chips, still a black screen.. unsure what the deal is here. i am not using the official atari video startup (udg one) so this may play a role im guessing?

     

    Even though, why would it work on the skunkboard and alpine board and then throw issues when burned to a cartridge?

     


  19. ...but all i get is a black screen afterwards (this is on a stub jag)

     

    ...

    ..

    .

    I then use the following on a windows machine to put the 8k universal header on the file.

    copy univ.k3y/b + program.bin/b ENCRYPTED.ROM/b

     

    Is the bit for showing the spinning cube set in that universal header?

    If so: Does the screen go black immediatelly after booting the Jaguar or does the cube show up and the screen wents black after it?

     

    Bye!

    Matthias

     

    I am unsure if the bit is set for the spinning cube in the header. Im not quite sure how to check this other than a hex editor and even them im not sure what id be looking for really.

     

    The spinning jaguar cube does come up but thats due to it being a stub jag i think.

     

    I really probably need a normal jaguar to test this stuff out on.

     

    Ill try a copy of a 2mb game here and see what i come up with using the same process i listed above.

     

     

    Edit: i was able to burn iron solder. all i did was split the rom file with the romsplit program and burned each portion to a chip.

     

    It did show the jaguar logo here but then went to a red screen for 2 seconds and then started the game. my only guess is that it didnt pass encryption and the stub jag bios let it pass anyway. It didnt help that one of my chips on that burn didnt pass the verify stage but still worked.


  20. Hey guys, ive been having a bit of trouble getting my binary programs burned to a cartridge.

    Ive got a programmer that will burn the chips with whatever i want and verify ok after burning but all i get is a black screen afterwards (this is on a stub jag)

     

    Here is the breakdown of how the binary is prepped before burning..

     

     

    I take a binary file that links and compiles at 4000 (ram) and has no header. i use a wrapper program i wrote that compiles and includes this binary file and immediately copys the file to ram an then jumps to the execution point. This wrapper program starts at 802000 and has no header either.

     

    I then use the following on a windows machine to put the 8k universal header on the file.

    copy univ.k3y/b + program.bin/b ENCRYPTED.ROM/b

     

    I have verified with a hex editor that the 8k univseral header is added at this point.

     

    I am able to load this file into project tempest emulator and virtual jaguar and run it without issues. It also runs perfectly fine like this on the skunkboard.

     

    I then use romsplit.exe (supplied atari tool) to split the rom using the following command

     

    romsplit -w encrypted.rom which gives me a .HI and .LO file.

     

    Now from everything ive seen the hi file goes on the top eprom spot on the cartridge and low in the other.

     

    When i burn each chip the program and chip offset are both 000000. I just get a black screen after following this.

     

     

    Any suggestions? do i need to byteswap the .hi and .lo files? am i missing a step here?


  21. So ive been playing with the skunk console features (read/write to files and console) but was trying to find out if there was any way that you could test to see if opening a file failed on the jaguar side. I know the pc throws a "code 2" error when a file that the jaguar requests to open doesnt exist but is there a way to obtain this back on the jaguar so that it knows how to react or do other condition based code? i havnt skimmed through the skunk library too much just yet but was curious if i was missing something here.

     

    The skunk manual doesnt really go into depth other than explaining some basic read write functions.


  22. Hello,

     

    here is what i do when i blitt the char-set letters into the canvas:

     

     ; set up for transparent blit!!!
        moveq.l  #0,d0
        move.l  d0,B_PATD; Isn't B_PATD a WORD-register? Or a PHRASE?
        move.l  #0,d0
        move.l  d0,B_PATD+4; Isn't B_PATD a WORD-register? Or a PHRASE?
       
       move.l   #SRCEN|UPDA1|UPDA2|LFU_REPLACE|DCOMPEN,B_CMD

     

    For complete overwritting, i simply leave out the setting of B_PATD and the DCOMPEN-flag.

     

     

    Kind regards

    Matthias

     

    Matthias,

     

    Thank you very much for the information. i knew there were a few simple flags i had been missing for the transparent blit.

     

    Thanks again for such a prompt response. :)

     


  23. Hello,

     

    here is what i do when i blitt the char-set letters into the canvas:

     

     ; set up for transparent blit!!!
        moveq.l  #0,d0
        move.l  d0,B_PATD; Isn't B_PATD a WORD-register? Or a PHRASE?
        move.l  #0,d0
        move.l  d0,B_PATD+4; Isn't B_PATD a WORD-register? Or a PHRASE?
       
       move.l   #SRCEN|UPDA1|UPDA2|LFU_REPLACE|DCOMPEN,B_CMD

     

    For complete overwritting, i simply leave out the setting of B_PATD and the DCOMPEN-flag.

     

     

    Kind regards

    Matthias

     

    Matthias,

     

    Thank you very much for the information. i knew there were a few simple flags i had been missing for the transparent blit. Thanks again for such a prompt response. :)

     

×