ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/06/90)
Date: 01-02-90 (05:48) Number: 1696
To: MIKE SPERL Refer#: NONE
From: MARK SMILEY Read: NO
Subj: GRAPHICS BUGS Status: PUBLIC MESSAGE
Mike,
Alas, FILL-ELLIPSE (renamed to FILL_ELLIPSE) didn't work
for me. In EGA or VGA640 mode, try:
: FF ( -- ) \ draws a centered filled ellipse
hres @ 2/ vres @ 2/ 2DUP SWAP 2/ SWAP 2/ ;
FILL_ELLIPSE ; FF
It only filled the horizontal line one away from the bottom
line of the ellipse.
On the other hand, EGA 300 200 20 30 FILL_ELLIPSE
filled only a thin vertical line to the left of center.
.
In checking out FILL_ELLIPSE, I discovered another bug in
GRAFKRNL.SEQ.
.
DOT ( x y color -- ) and CDOT didn't work properly, due to the
value of COLOR being used in set.res2. The change I made is
simple, though you may know a better way:
.
\ write mode 2 (assumes di=color)
label set.res2di \ load set/reset reg. w/ color
mov dx, # $3ce \ address graphics contrl. regs.
mov ax, # $0f01 \ al = enable set/res. reg. index = 1
out dx, ax \ ah = all 8 bits on, written to $3cf
xor ax, ax \ al = set/reset reg. index = 0
XCHG BX, DI \ save BX
MOV AH, BL \ send color (host data to vga)
\ Can't MOV AH, DI
out dx, ax
XCHG BX, DI \ restore BX (necessary for routines that
\ compute the pixel address before calling
\ this routine.). Restores DI just in case
\ it's needed by the calling routine.
ret c;
.
code ega.dot ( x y color -- )
POP DI \ color in di
pop cx pop dx \ dx = col, cx = row (dx=x, cx=y)
+code ega.d
push es \ save forth; color in di
call ega.pel.addr
call set.res2DI \ does: mov dx, # $3ce \THE ONLY CHANGE
not cl \ = 255 - cl
and cl, # 7 \ = 0 to 7
mov ax, # $108
rol ah, cl \ position our bit
out dx, ax \ mask to data reg
mov ax, di \ color in ega = 0..15
or es: 0 [bx], al \ write pixel
call restr.state
pop es
next c;
-----
This message came from GEnie via willett through a semi-automated program.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/06/90)
Date: 01-05-90 (01:54) Number: 1699 (Echo)
To: MARK SMILEY Refer#: 1696
From: MIKE SPERL Read: 01-05-90 (01:46)
Subj: GRAPHICS BUGS Status: PUBLIC MESSAGE
Mark,
It's interesting to look at next with tt. I've said that next
is faster than the subroutine call-ret mechanism. It turns out
thhat this is only true for forths with next inline, as F-PC.
Forths without inline next are slower than other languages! And
that's igoring nesting and un-nesting, which slows forth even
more!
The code:
DDDDDDDDD
Modifications to tt:
PUSH SI as the first instruction in tt, and POP SI just before
NEXT. The inner loop of tt to test NEXT is:
here
es: lodsw \ 18 + 11 + 15 = 44 (next not inline)
mov ax, # here 5 + \ instruction common to both tests
jmp ax \ these two inst. simulate next
\ next instruction simulates next NOT inline (omit for inline)
jmp here 2 + \ each word needs to jmp >next (like ret)
loop
The inner loop of tt to test CALL-RET is:
here
mov ax, # here 5 + \ filler, to equalize loops
call testing \ 23 clocks
loop
and, of course add:
label testing \ something to call
ret \ 20 clocks
c;
The results: (on 8088, with mss = 40)
DDDDDDDDDDDDDDDDDDDDDDDDDDDD
For ccaall - ret:
Elapsed time = 00:00:46.80
For next not inline:
Elapsed time = 00:00:48.11
result of testing:
48.11 / 46.80 = 1.028 (forth takes 3% more time)
predicted result, from manual:
44 / 43 = 1.02 (2% more time)
For inline next:
Elapsed time = 00:00:37.30
result of testing:
46.79 / 37.30 = 1.254 (call/ret take 25% more time)
predicted result, from manual:
43 / 29 = 1.48 (48% more)
It seems software timing can vary from predicted time by as much
as 18%; however, sometimes, as in the case of next not inline,
tt's result appears almost identical to that predicted. So,
what's going on? Is the INTEL manual inaccurate?
- Mike -
-----
This message came from GEnie via willett through a semi-automated program.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'