Quote:

About "jp po": I simply avoid to disable interrupts if they are already disabled, it can be a waste of time but, for personal experience, I try to avoid useless instructions.

The "jp po" after the ex af,af'?

Quote:

The "jp po" after the ex af,af'?

Ok... let'say I wanted to test your attention level
Thank you Sjoerd!
This is the corrected version:


.comment %
IN
OUT HL = system timer value
%
STGet@::

ld c,STL
ld a,i
jp po,?1
di
?1:
ex af,af' ; save interrupt enable flag and disable ints

; this must be the quickest possible
in a,(STH)
in l,(c)
in h,(c)

ex af,af' ; restore interrupt if previously enabled
jp po,?2
ei
?2:

; now evaluate results
ld a,l
cp h
jr nz,?3

; (STL) not changed
ex af,af'
ld h,a
ret

?3:
; presume H = L + 1
; check if L = 0FFh, so H = 0
inc l
jr nz,?4

; L was 0FFh
ex af,af'
ld h,a
inc h
ld l,0
ret

?4:
; L was not 0FFh
ld l,h
ex af,af'
ld h,a
ret


About G9K library: I've downloaded vers. 0.51, I need some time to study/adapt to use with M80/L80, as soon as I've something ready I'll let you know.

MicroTech

MicroTech: You can use an export file with labels that you can generate with sjasm. assemble the lib on a fixed adress and simply load into ram in runtime.. This whay you don't have to convert anything

Quote:

About "jp po": I simply avoid to disable interrupts if they are already disabled, it can be a waste of time but, for personal experience, I try to avoid useless instructions.

Thinks about that...

you are using a "JP" for avoid to waste time, avoiding executing DI if already it is.
BUT, that doesn't matter, Because you are wasting MORE time executing the "JP PO," to test than just executing an redundant function like "DI". After all, then the interrupt status will be restores at the end of the routine.

... I try to avoid useless instructions. ... - the first jp po, is already useless..



SAVE THE BYTES !!!! SAVE THE BYTES!!!!.

and about checking if the reading is coherent, it have some bugs.

...
; now evaluate results
ld a,l
cp h
jr nz,?3
...

in this part!. you are evaluating the low byte of the counter, and checking if is or not equal... letme says!.... if it is one tick per 3.xxx ms, it will be always different. Instead of that you needs to evaluate if the low byte passes from $FF to $00.

so

that part is

ld a,l
xor h
and $80
jr nz,?3

; NO CHANGES, the readed value is ok.
ret

; changes, increase MSB
?3: inc MSB

ret

so, final editing.

.comment %
IN
OUT HL = system timer value
%
STGet@::

ld c,STL
ld a,i
di
ex af,af' ; save interrupt enable flag and disable ints

; this must be the quickest possible
in h,(c) ; OTHER BUG CORRECTED.
in a,(STH) ; reading MSB in the middle is important.
in l,(c)
ld e,a ; E = MSB (temporaly).

ld a,l
xor h
and $80
jr z,?1

inc e

?1:

ld h, e

ex af,af' ; restore interrupt if previously enabled move at the end.
ret po ; realy FASTER.
ei
ret

Quote:

in this part!. you are evaluating the low byte of the counter, and checking if is or not equal... letme says!.... if it is one tick per 3.xxx ms, it will be always different. Instead of that you needs to evaluate if the low byte passes from $FF to $00.

Why would it always be different? Not that an INC A | JR Z instead would hurt, of course...

ah, rite... fly's thinking in good-old MSX2 terms... An IN r,(C) takes 0.42 ms on an R800 fly... (eat your heart out Z80! )

well, you're right Sonic_aka_T.... but always my way is short and can be use in z80 or R800. And my way don't care about which is the mhz of the CPU.

dunno, don't really see what's wrong with:

	LD C,$E7
	IN H,(C)
	IN A,($E6)
	LD L,A
	OR A
	JR NZ,DONE
	IN H,(C)
DONE:	.....
	RET

Quote:

LD C,$E7 IN H,(C) IN A,($E6) LD L,A OR A JR NZ,DONE IN H,(C) DONE: ..... RET

well, for R800 it is ok.... but my routine also work for timing on Z80 mode. But, offcourse, the timer is only available in a TURBO R.....

Congratz, you found one faster way

LD C,$E7
IN H,(C)
IN A,($E6)
LD L,A
AND $80
JR NZ,DONE
IN H,(C)
DONE: .....
RET

and this one will work ok, in z80 mode.

Quote:

... LD C,$E7 IN H,(C) IN A,($E6) LD L,A AND $80 JR NZ,DONE IN H,(C) DONE: ... RET

@ fly:

Ok, I think your method is better.
What is not so clear to me is the reasone to use

AND $80

instead of OR A (for example), you only need to test if L (A) is 0 or not,
why should you test "bit 7"?

Quote:

... I try to avoid useless instructions. ... - the first jp po, is already useless..

@ fly:
Now I remember why I avoid DI if ints are already disabled:
DI sets IFF1 = 0 and IFF2 = 0
which is not correct if your routine is called during a non-maskable interrupt service routine.
Once (working on onother z80 machine, not MSX) I had problems with this because
non-maskable interrupt service routine must preserve maskable interrupt enable flag (IFF1).
On MSX it makes no difference 'cause NMI is (actually) not used.

@ msd:

Quote:

MicroTech: You can use an export file with labels that you can generate with sjasm. assemble the lib on a fixed adress and simply load into ram in runtime.. This whay you don't have to convert anything

Good idea msd: I'll follow your suggestion: thanks!

MicroTech

This export file is already generated, you only have to set some defines.. But that will become clear when you look at it.

3D and MSX? A very difficult match! Your problem is the VDP of the MSX2. It is too slow to render at
reasonable frame rate a full page of 3D objects with filled polygons.
The only possibility you have for reaching a good frame rate is to resort to incremental algorithms for updating the screen. The limitation is that you cannot use shadows, but only flat colours.

To render a frame your 3D engine gives you a 2D projection of the scene on the screen, which is,
roughly speaking, a bulk of polygons.

Of course you need to use page swap, (let say page 0 and page 1 in sc5).

The idea is to store successive 3 frames in memory as bulks of polygons (let say frames (a), (b), (c) ).

While displaying frame (b) in page 0, you have frame (a) in page 1 (hidden) and you
need rendering frame (c).

Using the 2D representations of frames (a) and (c) as bulks of polygons you get the a new
list of polygons which is the difference of (c) with respect to (a). This new frame difference has
probably more complex 2D polygons, but has smaller surfaces to be filled you fill only
the areas not already filled by (a).

With large objects which move slowly, you can get very high frame-rates.
AR

3D and MSX? A very difficult match! Your problem is the VDP of the MSX2. It is too slow to render at
reasonable frame rate a full page of 3D objects with filled polygons.
The only possibility you have for reaching a good frame rate is to resort to incremental algorithms for updating the screen. The limitation is that you cannot use shadows, but only flat colours.

To render a frame your 3D engine gives you a 2D projection of the scene on the screen, which is,
roughly speaking, a bulk of polygons.

Of course you need to use page swap, (let say page 0 and page 1 in sc5).

The idea is to store 3 successive frames in memory as bulks of polygons (let say frames (a), (b), (c) ).

While displaying frame (b) in page 0, you have frame (a) in page 1 (hidden) and you
need rendering frame (c).

Using the 2D representations of frames (a) and (c) as bulks of polygons you get the a new
list of polygons which is the difference of (c) with respect to (a). This new frame "difference" has probably more complex 2D polygons, but has smaller surfaces to be filled as you fill only
the areas not already filled by (a).

With large objects which move slowly, you can get very high frame-rates.