ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/20/90)
Date: 01-17-90 (23:46) Number: 1715 (Echo)
To: MARK SMILEY Refer#: 1709
From: MIKE SPERL Read: NO
Subj: SCRNSAV.SEQ Status: PUBLIC MESSAGE
Mark,
>how about a faster version of CLIP_FILL_ELLIPSE ?
Here's the first step: smart ellipse with automatic clipping.
What about drawing segments of ellipses on the display? Would
this be useful? All the tools are already available (with minor
mods).
: CLIP4PIXELS ( -- ) \ uses values of: x y xc yc
inline \ XC @ X + YC @ Y +
mov ax, xc add ax, ' x 3 + #) push ax
mov ax, yc add ax, ' y 3 + #) 1push
end-inline
clip-dot
inline \ XC @ X - YC @ Y +
mov ax, xc sub ax, ' x 3 + #) push ax
mov ax, yc add ax, ' y 3 + #) 1push
end-inline
clip-dot
inline \ XC @ X + YC @ Y -
mov ax, xc add ax, ' x 3 + #) push ax
mov ax, yc sub ax, ' y 3 + #) 1push
end-inline
clip-dot
inline \ XC @ X - YC @ Y -
mov ax, xc sub ax, ' x 3 + #) push ax
mov ax, yc sub ax, ' y 3 + #) 1push
end-inline
clip-dot ;
: ELLIPSE ( xc yc a0 b0 -- ) \ smart ellipse
inline \ clip?
mov bx, sp
mov ax, 6 [bx] \ xc
cmp ax, 2 [bx] \ xc - a0 check left edge
js 1 $
mov dx, 4 [bx] \ yc
cmp dx, 0 [bx] \ yc - b0 check top edge
js 1 $
add ax, 2 [bx] \ xc + a0 check right edge
cmp ax, hres
jge 1 $
add dx, 0 [bx] \ yc + b0 check bottom edge
cmp dx, vres
jge 1 $
xor ax, ax \ false
1push \ false -> don't clip
1 $: mov ax, # -1
1push \ true -> clip
end-inline \ clip?
if ['] CLIP4PIXELS IS ELLIPSE_PIXELS
else ['] SET4PIXELS IS ELLIPSE_PIXELS
then (ELLIPSE) ;
commment:
\ If you use smart ellipse, these words are redundant
: CLIPELLIPSE ( xc yc a0 b0 -- )
['] CLIP4PIXELS IS ELLIPSE_PIXELS (ELLIPSE) ;
: CLIPELLIPSE? ( xc yc a0 b0 -- )
clip? \ substitute the inline code from ellipse here
if ['] SET4PIXELS IS ELLIPSE_PIXELS
else ['] CLIP4PIXELS IS ELLIPSE_PIXELS
then (ELLIPSE) ;
comment;
Another suggestion: add
ASSEMBLER INLINEON
to tthe beginning af files containing assembler words (inluding
high level words with inline code), and
ASSEMBLER INLINEOFF
ONLY FORTH ( optional )
at the end. This makes a big difference in the dot and line words
particularly.
I've got BARNEX running with the new words, now. Nice. If
you want to send me something, I'd love a copy of your new book,
615 E. 68th St., Richfield, MN 55423. ;-)
- Mike -
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/20/90)
Date: 01-17-90 (23:48) Number: 1716 (Echo) To: MARK SMILEY Refer#: 1710 From: MIKE SPERL Read: NO Subj: GRAPHICS Status: PUBLIC MESSAGE Mark, > LABEL DODEFER ( addr -- ) <-- expects a number on TOS old diagram; should be ( -- ) if my suggestion is adopted. > MOV BX, AX <-- what's in AX? see discussion below > MOV AX,3 [BX] > JMP AX END-CODE <-- how was addr used? it wasn't there to be used, actually. My one track mind neglected to change the stack diagram when pasting it into the last message; the new one is just ( -- ). Lets look at the senario of a word calling a deferred word. defer mark : t1 ." I'm Mark." cr ; ' t1 is mark : t2 ." I'm testing mark, and " mark ; \ run T2 then ' mark 1 dump (dump cfa's in code space) 81fa = mark 81ff = t1 8204 = t2 UMMMMMMMMMQMMMMMMMMMMMMMMMQMMMMMMMMMMMMMMMQMMMMMMMMMMMMMMMM 3 SEG:OFF 3 A B C D E3 F 0 1 2 33 4 5 6 7 8 FMMMMMMMMMXMMMMMMMMMMMMMMMXMMMMMMMMMMMMMMMXMMMMMMMMMMMMMMMM 34BDF:81FA3 E8 7B 81 FF 813 E9 57 80 C9 143 E9 52 80 CA 14 TMMMMMMMMMOMMMMMMMMMMMMMMMOMMMMMMMMMMMMMMMOMMMMMMMMMMMMMMMM cfa of mark cfa of t1 cfa of t2 E8 7B 81 == CALL DODEFER (call $0398, you can set a breakpoint at 081fa in D86 to see it work) 81FF is placed on the stack by CALL as the "return address", explaining the PRESENT stack diagram. Notice that it is the address of T1, the word that will be run by DODEFER. This is the same trick used in F-PC by VARIABLE to push the address of its body. Now, to NEXT. NEXT does ES: LODSW to get the cfa from list space into ax, and jumps to the code with JMP AX. In the deferred word, the code jumped to is CALL DODEFER, compiled in MARK by DEFER. The CALL places the address of the calling word's body on the stack (it thinks we'll return, and that's where the next instruction should be). AX isn't changed, so the cfa of the deferred word is still in ax when DODEFER runs; my suggestion is simply to move it to bx and MOV AX, 3 [BX] (which takes the same number of clocks as the present MOV AX, 0 [BX]) thus saving the overhead of a CALL and POP, which will make the whole process twice as fast. For this to work properly DEFER also must be modified as was indicated previously to change the CALL compiled in the deferred word by DEFER to JMP (or the stack will accumulate all those return addresses!). Clear as mud? Use D86 to step through it. Setting a breakpoint at $0398 reveals the remarkable number of deferred words in the keyboard input loop - almost twenty in F-PC. - Mike - ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/21/90)
Date: 01-21-90 (02:15) Number: 1718 (Echo)
To: MARK SMILEY Refer#: 1710
From: MIKE SPERL Read: NO
Subj: GRAPHICS Status: PUBLIC MESSAGE
Mark,
Thank you for the upload. My suggestions are being uploaded
as the file brecall.zip for your testing and use. We were on the
same track regarding our ideas and methods, so much of what is in
the file is just another approach to what you've done; thought you
might like to see it, anyway. It seems to work with test screens
and with the landscape program.
I tried to make a large buffer unsuccessfully, so then I made
small buffers, but only had memory enough for two. No good. The
compression will have to solve the buffer problem, I guess. If
you can figure out a way to make a buffer large enough to hold
four bit planes, then we can address the buffer in the same manner
that F-PC addresses lists, which would not require the time for
compression, and the latter could be postponed to file writing
time.
In landscape I used a file temp.$$$ to hold the screen image
for recall. It could be renamed for permanent saving. Most users
can supply disk space; I used my 2Mbyte ramdisk, which makes it
very fast. I'd hate to wait for a floppy! You might consider
oonly compressing files for saving; that way the program runs
faster.
Re: forth faster than C? That would seem to depend on
programming sstyle. Nest is the big bottleneck in forth, so
decomposing words into smaller words is to be avoided. This is a
good technique for development and debugging, but after code is
running it's a good idea to combine words that fit well into a
single process, just as we did in the case of the lines. It's
been said that forth is made up of lots of small words, and that's
fine for the kernel, where most of them are called by next rather
than nest because they're in assembler, and those that aren't are
so valuable and general there's no choice. But any small word
should stand on its own, and not be simply a part of another.
I feel that the main object in optimizing forth is the elimination
of next, and assembler words should be written for that purpose
as well as eliminating the numerous pushes and pops and >r's in
stack manipulations.
The inline code in (bsave) and (brecall) in the upload is an
example of this philosophy. ;-)
- Mike -
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'dwp@willett.UUCP (Doug Philips) (01/23/90)
Category 3, Topic 15
Message 32 Sun Jan 21, 1990
R.GILLIES at 22:58 PST
There seems to be a lack of graphics utilities advertised in the in magazines
in comparison to the other languages. Is there a listing of Forth written
graphic utility vendors?
---
Preferred: willett!dwp@gateway.sei.cmu.edu OR ...!sei!willett!dwp
Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/24/90)
Category 3, Topic 15
Message 34 Mon Jan 22, 1990
D.RUFFER [Dennis] at 23:25 EST
> Is there a listing of Forth written graphic utility vendors?
Without a graphics standard it would be pretty hard to write utilities that
will work on more than one Forth system. I know that F-PC, LMI and PolyForth
all have built in graphics support and I'm sure all the Forths for the Mac do
also. However, I don't know of any of them that can share graphics code with
any of the others. If you don't care about sharing, check out what any of the
above Forths have to offer.
DaR
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/07/90)
Category 3, Topic 15 Message 40 Sun Feb 04, 1990 R.NEWHALL at 12:20 EST I would like to know if there are any public domain routines for doing geometry calculations in MacForth. I work closely with a software firm that is expanding their CAD program on the Mac. Types of routines that I would be interested in are placing elements such as a circle tangent to two lines with the radius of the circle given, etc. I am sure that someone has hashed all of this out and do not care to re-invent the wheel. Also interested in possibly purchasing the code if not available in public domain. Anyone with information on this subject please drop me a letter on Genie mail (address- R.NEWHALL) Thank you! ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
wlee@csd4.csd.uwm.edu (Wan Ngai Wayne Lee) (02/07/90)
!HELP NEEDED! I am taking a graphics course. The professor let the students pick their own environment for the programming works. I decided to use FORTH on my AT, so I can learn graphics and practice my FORTH skills at the same time. PROBLEM: Graphics involves a lot of matrix maths. REQUEST: Does anyone has algorithms or source for FORTH to deal with matrix efficiently? Or better yet, does anyone has an APL in FORTH? Thanks for any input in advance. ---------------------------------- Wayne Lee Internet: wlee@csd4.csd.uwm.edu CompuServe: 73230,772 GEnie: W.LEE7
ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/16/90)
Date: 02-15-90 (02:29) Number: 1592 (Echo) To: ALL Refer#: NONE From: GENE LEFAVE Read: (N/A) Subj: X-WINDOWS Status: PUBLIC MESSAGE I was wondering what would be required to run an X-window terminal from a FORTH system. Does anyone have an idea as to where one could get the specs for the beast. . I would think that since most UNIX terminals are connected via ASCII serial lines that the X-window protocol must be serial, so that one could make a nice FORTH front end. . Gene --- ~ EZ-Reader 1.13 ~ ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/24/90)
Date: 02-23-90 (00:51) Number: 2945 (Echo) To: DOUG SCHIFFER Refer#: 2867 From: JERRY SHIFRIN Read: NO Subj: GRAPHICS Status: PUBLIC MESSAGE >information on Paintbrush's file format. Let me know if there is inter >I will post the file. DS>POST! (please??!!). I'm also looking for information on TIFF image DS>files, if anyone has any info on them. It's downloadable from the ECFB (703-442-8695) as PBFORMAT.ZIP. A small number of downloads are permitted on the first call. --- * QDeLuxe 1.10 #214s ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/03/90)
Date: 03-02-90 (01:47) Number: 1768 (Echo) To: DEE KNIGHT Refer#: 1751 From: MARK SMILEY Read: NO Subj: HERCULES WORDS Status: PUBLIC MESSAGE Dee, Thanks for uploading VIEWEDIT.ZIP. I am eager to try it out. I'll let you know how it goes. > Have enjoyed uusingg your graphics package, tho it has been a little > rough keeping my kludges for the herc mono board upp to date with > your version changes (I'm still on Smiley31). J. Bilderbackk didd > hdot routines for tthe hherc board that work with FPC35. Should I send > it to you? Please send me (or upload to ECFB) any hercules stuff you have. Currently, as you know, there is no hercules support in my routines. I don't have access to a hercules card, so I can't debug such routines. Let me know if I may include the routines you send in my graphics package (with appropriate credit, of course). I am sending a new version of my graphics routines to ECFB soon, so don't get the version on the board yet. Get the 2-27-90 version soon to appear. Mark --- ~ EZ-Reader 1.13 ~ ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/03/90)
Date: 03-02-90 (01:47) Number: 1769 (Echo)
To: MIKE SPERL Refer#: 1754
From: MARK SMILEY Read: NO
Subj: DGIF1.ZIP Status: PUBLIC MESSAGE
Mike,
Glad to see you're back. Your system sounds excellent, and at an
unbelievably low price, too! I am currently seeking a job, but once I
get settled in, I'll consider upgrading my system.
I had trouble with SHOWGIFINFO on two .GIF files that are viewable
with other gif viewers. One was a 320x200 256-color file, and the other
was a 640x480 256-color file. In both cases, SHOWGIFINFO gave the
message:
Not a gif file.
If it would help you, I could send you one of these gif files.
SHOWGIFINFO did work on a 640x350 16-color .GIF file, though.
By the way, pay no attention to the actual structure of the header in
BRECALL -- that was for a particular program I wrote.
I'm sending a new copy of the graphics routines to ECFB soon. It
includes your EGA/VGA screen saving routines.
> New-expect even workss with Tom's editor now without forcing you to do
> a warm boot to get bacck to forth.
Is this a new version of New-expect? I'd like to use it, but I gave
it up due to incompatibilities with F-PC v. 3.50.
> ... but miss the editor's help screens
> that accompanied previous veersions (I don'tt use it enough to be
> fully conversant with aall the keystrokes).
Neither do I. I use QEDIT v. 2.08.
> Hope I didn't cause you any trouble suggesting a change in DEFER.
No trouble. I wisely (it seems with hindsight) decided to wait a bit
before fooling with it.
> DEFER ...
> Maybe someone more familiar with the metacompiler would be interested
> to help?
Perhaps Tim Smith might be able to help, since he was re-writing the
meta-compiler last I heard.
> Meanwhile, I thought consideration might be given to a more efficient
> jump table mechanism to direct a program to the correct code,
> eliminating the use of defer if possible. What do you think?
Sounds good to me. Any speed is helpful with graphics routines, and
we are currently using tons of deferred words for nearly everything
(dots, lines, etc.). So it could be quite an improvement.
Mark
---
~ EZ-Reader 1.13 ~
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/03/90)
Date: 03-02-90 (01:47) Number: 1770 (Echo)
To: DEE KNIGHT Refer#: NONE
From: MARK SMILEY Read: NO
Subj: VIEWEDIT Status: PUBLIC MESSAGE
Dee,
VIEWEDIT is great! Thanks, it's just what I wanted.
I discovered that there are some more files (not mentioned in
HELPFILE.TXT) that it doesn't need:
printing.seq newfile.seq editerr.seq
But it needs fwords.seq.
One comment: H doesn't do what I'd like it to -- namely go to the
help file at the line where the word in question is listed. Currently
it does what you say it does:
H (word) loads help file to line # in editor
But VIEW and the others work flawlessly.
Thanks again,
Mark
---
~ EZ-Reader 1.13 ~
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/11/91)
Date: 04-08-91 (05:46) Number: 1789 of 1790 (Echo) To: ALL Refer#: NONE From: DONNIE COLEMAN Read: (N/A) Subj: FPC: GRAPHICS AND FP Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) I've been exploring FPC and am currently trying to sort out the various problems associated with using floating point with the graphics routines of Mark Smiley. I have been using VPSFLOAT v.1.00 and have been having some difficulties... I understand that there is a revision to VPSFLOAT, though I have not seen it yet. Does anyone know where I can find it?? FFLOAT appears to have some similar compatability problems, but considerably improved over the old HFLOAT. In reading some of the messages on the boards, there is some contraversy regarding the use of floating point in FORTH. My stance is, if the '87 is available why not use it? NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for Forth! <<<>>> ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/26/91)
Date: 04-22-91 (07:11) Number: 1965 of 1988 (Echo) To: ALL Refer#: NONE From: BILL TEEGARDEN Read: HAS REPLIES Subj: EGA SCREEN UTILITIES Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) I am looking for a Forth utility program that will allow me to throw EGA screens up quickly and remove them quickly. I wrote a similar utility in Pascal for CGA, but I have drawn a blank in Forth. Does anyone know of such an animal? Bill Teegarden NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 <<<>>> Date: 04-22-91 (07:46) Number: 1966 of 1988 (Echo) To: BILL TEEGARDEN Refer#: NONE From: RAY DUNCAN Read: NO Subj: EGA SCREEN UTILITIES Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) The problem is that the higher-resolution graphics modes are more complex to handle. The memory is organized as bit planes, so you have to select each bit plane and then read out all its memory, select the next and read its memory, and so on. This is the way @BLOCK and !BLOCK work, and their code is quite efficient, so you might want to just build your screen save/restore logic on top of @BLOCK/!BLOCK. NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 <<<>>> ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp