Jump to content
Jagware

SebRmv

Level1
 View Profile  See their activity

  • Content count

    1,553

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by SebRmv

  7. Posted · Report reply

    I didn't even know about this flag :D

    Thanks for pointing that thus.

     

    While reading the description, I also read the following warning (in Jag_v8)

     

    WARNING - writing a value to the flag bits and making use of those flag bits in the following instruction will

    not work properly due to pipe-lining effects. If it is necessary to use flags set by a STORE instruction, then

    ensure that at least one other instruction lies between the STORE and the flags dependent instruction.

     

    So let's deviate from the original subject :P

    Does it mean that for leaving an interruption handler, the sample code

    given by Atari does not always work?

     

    Remember that the sample code (given by Atari) is:

    int_serv:
  movei GPU_FLAGS,r30; point R30 at flags register
  load (r30),r29; get flags
  bclr 3,r29; clear IMASK
  bset 11,r29; and interrupt 2 latch
  load (r31),r28; get last instruction address
  addq 2,r28; point at next to be executed
  addq 4,r31; updating the stack pointer
  jump (r28); and return
  store r29,(r30); restore flags

     

    Is the restore flags instruction is at the good place?

    If I understand correctly the warning, they say that

    is is not safe to put the last store after the jump.

     

    This theory is consistent with the following remark (found in bug sections)

    · We've found that you can't put the IMASK clear in the delay slot of the jump out of the interrupt, because

    the instruction that was interrupted may not get the correct register bank (TWI - Brian McKee)

     

    Does anybody have experienced such things?

    I may have a (random) bug related to this.

  12. Posted · Report reply

    I will make bench this night.

     

    But, don't forget that you can not read at GPU_RAM+$8000, it's a write only access. ;) (To allow faster transfers into the GPU space, all the registers are also available as thirty-two bit memory, at an offset of 8000 hex from their normal addresses. At this address, the internal memory is write only. p43/141)

     

    Thanks, I forgot this point.

     

    So basically, I would like to compare

     

    DRAM->DRAM in PIXEL mode (DEPTH16)

     

    to

     

    DRAM -> GPU in PIXEL mode (still DEPTH16)

    GPU -> DRAM in PHRASE mode

    (which is 39 cycles/phrase if I have understood correcly)

  13. Posted · Report reply

    Assuming that resolution is DEPTH16

     

    What about DRAM->DRAM in PIXEL mode

     

    In particular, I wonder whether

     

    DRAM->DRAM in PIXEL mode

     

    is faster or slower than

     

    DRAM->GPU (fast access) in PIXEL mode

    (assuming that it is correcly aligned to work: edit: by the way, does fast access work in pixel mode with DEPTH16)

    GPU (fast access) -> DRAM in PHRASE mode

     

    ie we blit in two times, using the GPU RAM as intermediate buffer

     

    Thanks

     

    edit:

     

    and thus, what about normal (slow) access

     

    DRAM -> GPU in PIXEL mode : 7 * 4 = 28 cycles/phrase if I have understood correctly what precedes

    GPU -> DRAM in PHRASE mode : 11 cycles/phrase according to the benchmark above

    so, that would be 39 cycles/phrase

     

    and, depending on the answer to the question,

     

    DRAM -> GPU in PIXEL mode : 7 * 4 = 28 cycles/phrase if I have understood correctly what precedes

    GPU (fast access) -> DRAM in PHRASE mode

  14. Posted · Report reply

    thanks, I will take a look at ADDC :)

    I think you can compile it directly for linux because lazarus is multiplatform

    maybe you could add a linux version to the distribution :)

     

    I just quickly tested this morning and I was too lazy to recompile it ;)

    but I'll try that.

    If I manage to get lazarus working on my PC, I will even try to fix the

    problem of ADDC (and probably SUBC too)

     

     

  15. Posted · Report reply

    I have just tested it. It works even with wine under linux!!

     

    This is really a cool app, thank you Orion!

     

    I found a bug: ADDC is not correctly emulated.

     

    Looking at the source, I think you update the Carry FLAG too early.

    (ie before doing the addition !)

     

     

     

  21. Posted · Report reply

    The next thing to think about is the case of sprite that is between 2 band, and for that there is 2 solution :

    - cut the sprite and add it to both band

    or

    - the OP read 2 band by line so it can finish to draw previous sprite.

     

    I have chosen the 2nd one, because it's the one that take less CPU time.

     

    Interesting. But this works just because you know that any sprite is at most on two strips, doesn't it?

     

  24. Posted · Report reply

    Well, I told RaZ about it when it happened, in January. I must admit I've not done any testing since.

     

    Try to archive your personal messages (without checking "Delete messages after archiving" !) and see if you receive them.

    If you don't, tell me and I'll bugger RaZ again to fix it.

     

    In the meantime, I've bumped the capacity of the PM boxes to 200 messages, so we'll have a little time before us.

     

    It does not seem to work.

  25. Posted · Report reply

    It seems that the forum software currently is temporarily unable to send email messages.

     

    Consequently, do not use the "Archive Messages" in the Messenger area. You will not receive your messages, and if the "Delete messages after archiving" option was checked, they will be lost !

     

    We're sorry for the inconvenience, and we'll try to resolve this issue as soon as possible.

     

    Is this resolved?

     

     

×