Jump to content

SebRmv

Level1
  • Posts

    1,553
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by SebRmv

  1. I don't have linux nor any idea of how to port the zerosquare's routines on linux ^^

    it seems that it doesn't work on win98, does any one can test it and tell me if it's working for him ? (on xp or 98 ?)

    because if the pack only work on my computer, that's a bit useless :/

     

    Maybe I can try to hack it myself.

    I guess an ATARI version would be cool also.

  2. Hello there !

     

    I just got a JagCD from someone and the first think I tried to do was trying to encrypt a CD using the BJL version of Matthias Domin Encryption program.

    But this need a serial cable that you plug in the dsp port and this need a jaglink, and I don't have this hardware.

     

    So I tried to save some money and soldering pain, and used the "mini debugger" source of Zerosquare that allowed me to dump the Jaguar memory to a file on my PC. I then patched the program of matthias to disable uart and xmodem transfer, as well as joypad reading that was disturbing BJL transfer, and added the BJL transfer routines from Zerosquare instead of the uart/xmodem routines.

     

    and here is the result, a really easy to use "one-double-click-encryption" pack

    which allow you to encrypt a cd using your jagcd and the BJL only just by double clicking on a batch file that does the job for you.

     

    I would like to thanks Zerosquare and Matthias Domin for their great job that allowed me to do this pack.

     

    Enjoy !

    JagCD.zip

     

    ps: This works only with a parallel port at $378, on XP or 98

     

    Great job!

    And what about a linux version :D?

     

     

  3. About division, how do you emulate 16.16 division?

    What is a 16.16 division?

    Do you also emulate that the G_REMAIN does not

    necessary contain the remainder but a value

    that permits to compute the remainder?

     

    I know I can hack myself the code ;)

     

    Anyway, it seems that you can emulate the division unit of the GPU/DSP

    by doing

     

    q = a/b
    REMAIN = a%b
    if (q & 1) == 0 then REMAIN-=b;

     

    For the 16.16 division, it is simply the result of dividing

    (a << 16) by b

    (48 bits integer for (a << 16))

     

     

  4. [edit : "The data registers may only be

    written to while the Blitter is idle." page 70/141 of the Jag_v8 documentation]

     

    Yes, I have seen that also in the doc.

    So this could mean that some of the registers are double buffered

    (in particular, almost all of the address registers)

     

    Does anybody have tested this?

     

     

  5. I was playing a bit with the blitter today and I tried to do a line routine using the blitter (in 68k, but just for blitter-understanding purpose)

    and I came up with this nice little screen that can be used as a screensaver ;)

    200 lines, redrawn each time (the VBL is almost full :D but the code is over-VBL-jump proof so it will only be slower in 60Hz I suppose)

     

    http://onori.free.fr/jag/lines.zip

     

    cool :)

     

  6. Ok, not really related but I have a question about the blitter:

     

    do the registers are double buffered?

    (this would mean that we can prepare the next blit

    while the current one is being completed)

    if yes, which ones exactly?

     

     

  7. This is used by the OP to render scaled sprites (the Atari documentation is your friend) :)

    After each line is processed, the corresponding 68k program (to what the OP do) is

     

    ;; d0.b = REMAINDER
    ;; d1.b = VSCALE
    ;; d2.w = HEIGHT
    ;; d3.w = DWIDTH
    ;; a0 = DATA
            sub.b   #1<<5,d0; subtract 1 to REMAINDER
            bcc.s   .done; if positive then that's all
    .adjust:
            add.w   d3,a0; next line in DATA
            subq.w #1,d2; decrement height by one 
            beq.s    .done; if height becomes 0 then stop
            add.b   d1,d0; add VSCALE to REMAINDER
            bcc.s    .adjust; until it becomes positive
    .done:
    ;; update values (REMAINDER, HEIGHT, DATA)

     

    so, after examination of the NET files, it is not exactly what is implemented.

    The correct program is rather:

     

    ;; d0.b = REMAINDER
    ;; d1.b = VSCALE
    ;; d2.w = HEIGHT
    ;; d3.w = DWIDTH
    ;; a0 = DATA
            sub.b   #1<<5,d0; subtract 1 to REMAINDER
    .adjust:
            cmp.b  #1<<5,d0; compare to 1 (instead of 0)!!
            bpl.s  .done
            add.w  d3,a0; next line
            add.b  d1,d0; REMAINDER += VSCALE
            subq.w #1,d2; height--
            bpl.s   .adjust
    .done:
    ;; update values (REMAINDER, HEIGHT, DATA)

     

    This explains why it does not work correctly when VSCALE >= (7<<5).

    (since in this case, overflow can occur)

     

    Also, I believe the ideal initial value for the REMAINDER is

     

    1<<5 + VSCALE - 1

  8. Thanks for this.

     

    Do you emulate the GPU pipeline also?

     

    About division, how do you emulate 16.16 division?

    What is a 16.16 division?

    Do you also emulate that the G_REMAIN does not

    necessary contain the remainder but a value

    that permits to compute the remainder?

  9. Don't be sorry for using your own language! -- I need the practice to retain my Canadianism. If you could say more phrases like "no sugar added!" and "free toy inside!", it would help me remember my childhood reading the French side of cereal boxes. ;)

     

    I believe I worked it out on paper once myself - if you do the math about when the scanlines draw I think it works out. I can't give an example right now because I'm at work, but draw it out on paper and I think it makes sense.

     

    I haven't had a look at the library yet, but the specs sounded nice. Do you have some videos on the page? (I will go look now.)

     

    Yes, there are some examples (with videos) on the page.

    Since the API has not changed, I have not updated the examples though.

     

    Cheers

  10. I'm not sure I fully understand the question, but remember how the sprite scaling works - it's just a simple counter per scanline.

     

    IIRC, decrementing by 1 at the beginning makes the first scanline appear on a sprite that is scaled down -- otherwise it usually skips the first scanline. Typically it looks better to have the first scanline present and let it skip the next one.

     

    Does that help? :)

     

    Sorry Tursi for the french :P

     

    My question was about the "height" field of scaled sprites.

     

    I believe I read somewhere that height of scaled sprites has to be decremented by one.

    But I can't remember where I have seen that and just asked if anyone also read that.

     

    From my experiment, if height is not decremented, then the last line seems to be corrupted.

     

    I even believe that the fix proposed was to add an empty (black) line at the end of each

    scaled sprites.

     

    Anyway, thanks for your help.

    Have you seen the new release of my library?

    I am pretty proud of the way the OP list is built now ;)

  11. Well, I have to find some time to spend on this (I am playing a bit too much during these holydays...)

    but I hope the new sprite manager will be ready for january 2008

     

    I'll give more details when it will be about to be released.

    (but I really hope this will work as I expect)

     

    Hello,

     

    finally, I finished the work I wanted to do on the sprite manager.

    I have just released the source code (v 1.1.4).

     

    The changes are transparent for users but internally the display manager has been entirely rewritten.

    Now, the OP list is divided in 8 lists and branch objects are used to optimise bus access.

    I have made some quick tests and managed to reach about 480 sprites at 60 Hz and 570 sprites at 50 Hz.

    In practice, I think that 350-400 sprites is more reasonable.

  12. I think a lot of commercial Jag games were done in C -- Doom had a lot of C (custom GPU compiler notwithstanding). C code on the 68k purely is never going to be anywhere near the Jag's top performance, but that doesn't mean it can't do a game. Seb's library is a good step in that direction since it accelerates low level details for you, reducing the impact.

     

    I'm curious about your plans for the lib, Seb? :)

     

    Well, I have to find some time to spend on this (I am playing a bit too much during these holydays...)

    but I hope the new sprite manager will be ready for january 2008

     

    I'll give more details when it will be about to be released.

    (but I really hope this will work as I expect)

  13. Yes, that's a very good idea. I think the better the dev environment, the more people might want to use it.

    And it's especially important to get rid of the "C is too slow" rumor. Afterall there are plenty of game ideas where C is probably fast enough.

     

    I'll try it out as soon as I can.

     

    Regards, Lars.

     

    Exactly. I also think that C is sufficient for many games.

    The trick is that the goary stuff is made in assembler (GPU/DSP/68k) and is part of the lib.

    Thus this is still sufficiently efficient.

     

    Note also that assembler's addicts may also use my lib. It is not a "C only" thing.

     

    Cheers & Merry Christmas :)

  14. Hi Lars!

     

    That's very cool news if you consider using my own library :)

     

    Concerning your questions about Visual Studio, I cannot really answer to these since I develop mainly with my linux distro.

     

    With linux, you can simply download my shell script that builds a gcc cross compiler to generate 68k code.

    ie download and run:

    http://removers.free.fr/softs/archives/mk_xgcc.sh

     

    then you can get a source distrib of my libs, ie download

    http://removers.free.fr/softs/archives/jlibc-0.5.1.tar.gz

    http://removers.free.fr/softs/archives/rmvlib-1.1.2.tar.gz

     

    and build them (in this order)

    I assume the path you will use are the same as mine

    (I know there is an issue in the Doxyfiles that states explicitly an absolut path on my system :D)

     

    To build, simply run ./build.sh (that are in the archives)

     

    Then, you can start using my library.

    I have already coded some small examples to illustrate how to use it.

    The sources are downloadable at my website:

     

    http://removers.free.fr/softs/download.php

     

    About a documentation of the library, I have started to document the code

    and use doxygen to generate an HTML doc. This is browsable at the following

    urls:

    http://removers.atari.org/doc/jlibc/

    http://removers.atari.org/doc/rmvlib/

     

    I know this documentation is not perfect (far from that), but I hope it can already

    help programmers to become familiar with the library.

     

    I am currently writing a more technical document to explain the internals

    of the library (and in particular the sprite manager that is going to evolve

    quite a bit soon [i hope Christmas vacation will be sufficient to implement all my ideas])

     

    Anyway, I would be pleased to answer all your questions and hear your suggestions.

     

    Maybe it is a good idea to open a new part in this forum (or elsewhere) so that users

    can discuss about the library.

     

    Cheers

     

    Seb

×
×
  • Create New...