Well, lets ask some questions first...

Quote:

It is a long time since someone mentioned ASM coding on MRC. Can this code be optimized ? framex1: db 0,2,18,19 ; X offset of line 0, length of line 0, data, data ect db 0,2,20,21; X offset of line 1, length of line 1, data, data ect db 127 ; end of the frame (...) _frames: dw framex1,frame0,frame1,frame2,frame3,frame4,frame5, etc etc

Is it possible to have offsets bigger than 127? (is there a reason for using exactly 127 as a terminator?)
Is there a limit for the number of frames?
Is there a limit for the amount of data in each frame line?
Must the data be in the same structure as frame lines definitions?
Can I mess with auxiliary registers (like AF', BC', DE' and HL')?

With those answers I will be able to answer you with more property.

Quote:

Well, lets ask some questions first... Is it possible to have offsets bigger than 127? (is there a reason for using exactly 127 as a terminator?)

no, and I think that a max length of 16 would fit any real situation of use.
The reason for 127 is that it is a large number that probably will never be used, so no real reason.

Quote:

Is there a limit for the number of frames?

We could limit the number of frames to 256, this would meet any reasonable use of the code.

Quote:

Is there a limit for the amount of data in each line frame?

As I told before, no, but if we pose this limit to 16, it would fit any practical use.

Quote:

Must the data be in the same structure as frame lines definitions?

No, we can arrange offset/lengths in a different data structure, adding a pointer to the line

Quote:

Can I mess with auxiliary registers (like AF', BC', DE' and HL')?

Sure !

Quote:

With those answers I will be able to answer you with more property.

Thanks in advance for the time you will be able to dedicate !!

Quote:

push de ; 10 T states pop IX ; 14 T states total 24

according to my docs, it would be 11+15=26,


And I was about to ask very similar questions to those by Fudeba.

If len <=253, we can replace:

    inc ix
    inc ix
    add ix,bc

with

  inc c
  inc c
  add ix,bc
  dec c
  dec c

and storing len+2 instead of len, we can also remove the first 2 incs.

Quote:

And I was about to ask very similar questions to those by Fudeba. If len <=253, we can replace: inc ix inc ix add ix,bc with inc c inc c add ix,bc dec c dec c and storing len+2 instead of len, we can also remove the first 2 incs.

Nice one!! Thanks

Quote:

according to my docs, it would be 11+15=26,

Probably my info do not count the msx M state

Quote:

Quote: according to my docs, it would be 11+15=26, Probably my info do not count the msx M state

Or maybe my info is tied to the Spectrum, but I'm not aware of the possible timing differences other than the extra wait states in Spectrum while accesing the contended memory.

Quote:

Quote: Well, lets ask some questions first... Is it possible to have offsets bigger than 127? (is there a reason for using exactly 127 as a terminator?) no, and I think that a max length of 16 would fit any real situation of use. The reason for 127 is that it is a large number that probably will never be used, so no real reason. Quote: Is there a limit for the number of frames? We could limit the number of frames to 256, this would meet any reasonable use of the code. Quote: Is there a limit for the amount of data in each line frame? As I told before, no, but if we pose this limit to 16, it would fit any practical use. Quote: Must the data be in the same structure as frame lines definitions? No, we can arrange offset/lengths in a different data structure, adding a pointer to the line

Another question... can frames be void? (ie: pointing to a 127, no lines to transfer)

If they can't, we can replace:

1:  ld  a,(ix+0)      ; 127 == fine

    cp 127
    jp z,3f

[...]

    jp  1b

with

    ld  a,(ix+0)      ; 128 == fine
    and 127
1:  
[...]

    ld  a,(ix+0)      ; 128 == fine
    and a
    jp  p, 1b

and the first byte of each frame will have a +128 to mark the end of data of the previous one (for the last one, just put a 128 as an ending mark), saving all but 1 end of frame markers.

---

If a frame can be void, we can always use 128 as the end ending mark, and use


1: ld a,(ix+0) ; 128 == fine

and a
jp m,3f

[...]

ARTRAG: maybe you can take advantage of using the alternate register set and changing the ix ptrs to a hl' or bc' or de'?

[edit]
ops I misunderstood

Quote:

Can this code be optimized ?

Absolutely. At least 30% faster, probably more.

Good ! How ?

Thanks to Metalbrain I've already replaced

1:  ld  a,(ix+0)      ; 127 == fine

    cp 127
    jp z,3f
    ld  c,a

[...]

    jp  1b

with

    jp 2f

1:  ld c,a
[...]


2:  ld  a,(ix+0)      ; 127 == fine

    cp 127
    jp nz,1b

Quote:

Good ! How ?

Do you have the original c code?

No the code is hand made,
I have just adapted it in order to be called by a C function, so parameter
passing have to be trough DE, BC and the stack

Ok, you're using ix and sp kindof like the compiler so I guessed it was c code.

It is just to access to I/O parameters on the stack

I was exploring alternative possibilities adopting, e.g. a different data structure where tile data are
not stored with the offset/length information. This is what I get, actually it does not seem really better...

framex0:
    db 0,2
    dw p0
    db 0,2
    dw p1
    db 127
    
frame0:
    db 5,1
    dw p2
    db 4,1
    dw p2
    db 3,1
    dw p2
    db 2,1
    dw p2
    db 1,1
    dw p2
    db 127
    
p0:
    db 18,19
p1:
    db 20,21
p2:
    db 147

_frames:
    dw framex0,frame0, etc etc


    global _map_w
    global _frames


;de   source_addr;
;bc   dest_addr;
;ix+4 e ix+5 nframe
    global _npctgrab
_npctgrab:
    push    ix
    ld  ix,0
    add ix,sp

    push    de
    ld  e,(ix+4)
    ld  d,(ix+5)
    ld  hl,_frames
    add hl,de
    add hl,de
    ld  e,(hl)
    inc hl
    ld  d,(hl)  ; de punta alla frame corrente

    db  0xdd    
    ld  l,e
    db  0xdd
    ld  h,d     ; ora ix punta alla frame corrente

    pop hl      ; hl punta alla source in room

    ld d,b  ; bc puntava alla destination in frame buffer
    ld e,c  ; ora de punta alla destination in frame buffer

    jp 2f
 
1:  ld  c,a
    ld  b,0
    push hl
    add hl,bc       ; source

    ld  c,(ix+1)    ; len
    ldir
    ld bc,4
    add ix,bc    

    pop hl
    ld  bc,(_map_w)
    add hl,bc

2:  ld  a,(ix+0)      ; 127 == fine
    cp 127
    jp nz,1b

    pop ix
    pop hl
    pop af
    jp  (hl)



;de   source_addr;
;bc   dest_addr;
;ix+4 e ix+5 nframe
    global _npctrest
_npctrest:
    push ix
    ld  ix,0
    add ix,sp

    push    de
    ld  e,(ix+4)
    ld  d,(ix+5)
    ld  hl,_frames
    add hl,de
    add hl,de
    ld  e,(hl)
    inc hl
    ld  d,(hl)  ; de punta alla frame corrente

    db  0xdd    
    ld  l,e
    db  0xdd
    ld  h,d     ; ora ix punta alla frame corrente

    pop de      ; de punta alla source in buffer

    ld h,b  
    ld l,c      ; ora hl punta alla destination in room

    jp  2f

1:  ld  c,a
    ld  b,0
    push hl
    add hl,bc       ; source

    ld  c,(ix+1)    ; len
    ex de,hl
    ldir
    ex de,hl    
    ld  bc,4
    add ix,bc
    
    pop hl
    ld  bc,(_map_w)
    add hl,bc

2:  ld  a,(ix+0)      ; 127 == fine
    cp 127
    jp z,1b

3:  pop ix
    pop hl
    pop af
    jp  (hl)

;de   source_addr;
;bc   nframe;
    global _npctplot
_npctplot:    
    push    ix
    push    de
    ld  hl,_frames
    add hl,bc
    add hl,bc
    ld  e,(hl)
    inc hl
    ld  d,(hl)

    db  0xdd    
    ld  l,e
    db  0xdd
    ld  h,d     ; ora ix punta alla frame corrente    
    
    pop hl      ; hl punta alla destinazione in room

    jp  2f

1:  ld  c,a
    ld  b,0
    push hl
    add hl,bc       ; dest

    ld  a,(ix+1)
    ld  c,a         ; len

    ld  e,(ix+2)
    ld  d,(ix+3)
    
    ex de,hl
    ldir
    ex  de,hl
    
    ld  bc,4
    add ix,bc

    pop hl

    ld  bc,(_map_w)
    add hl,bc

2:  ld  a,(ix+0)      ; 127 == fine
    cp 127
    jp  nz,1b
    pop ix
    ret