1. Thanx
I just want to thank everyone for responding to my inquiry
about my silly scrolltext routine 
A few comments though:
Robert Craig says:
> As for your smooth scrolling program, it spends over 95%
> of it's time doing mem_copy() of 64000 bytes. Euphoria's
> mem_copy() calls C's memcpy(). I don't think you could
> run your program more than about 1% faster in C. I believe
> that writes to screen memory are much slower than writes
> to general DRAM addresses, because of the lack of caching.
Then the memcpy() command is probably assembled, right?
Does this mean it wouldn't even be much faster in pure
machine code? I mean; copying 64000 bytes from one place
to another should not be any challenge for a modern processor,
even in high-level language, so is the caching problems simply an
unavoidable hardware bottle-neck?
Afterbeat says:
> I tested out that program, and I found that it goes faster,
> and the text doesn't shake, when you take out the
> vertical retrace routine.
Yes, but then it's not smooth at all !
Afterbeat also helped me find the standard charset, thanx!
Lucius L. Hilley III also answered some of my questions,
but perhaps the most helpful and enlightening answer came
from Jiri Babor:
> In recent years I really had to use a wait_retrace routine
> only when I was messing around with page switching.
> Otherwise the 'modern' hardware does not seem to need it.
> I ran your scroller and it was reasonably smooth at the
> lowest speed setting after I commented out the line with
> the wait_retrace call.
Exactly. 'Reasonably smooth'.
I have mentioned the Commodore 64 earlier. This is a machine
people now-a-days use as a standardized symbol of old fashion,
out classed, stone age computer technology.
But among game and demo programmers on the 64 one rule was
crystal clear: If it wasn't perfectly smooth, it wasn't worth watching.
Those days, 'Reasonably smooth' was just not smooth enough...
> BTW, you should never rely on the hardware to dictate the
> top speed. Everybody's machine will be ten times faster
> in three years time.
I'd say about 4 times faster, wanna bet ?
> maximum speed, even if you never get anywhere near it
> with your present gear. In a decade or so software
> archeologists will praise you for it...
I guess you are right, but calling the time() function also
steal raster. With the time delayer (even when set to zero
delay, but still calling time(), it seems impossible to get
anything smooth...
( Then Jiri guides me through some font problems, thanks again
> You also mentioned drawing lines, circles, etc. on virtual
> screens. Have a look at my vgraph.e in the Archives.
> It is pretty old and neglected, but it does lines, ellipses
> and polygons reasonably fast.
Just what I was looking for !
Anyway, since I'm a natural quitter, I'm gonna give
up the silly "smooth scrolling project" for now.
I'm never gonna quit Euphoria, though...
Tor Bernhard Gausen
2. Re: Thanx
- Posted by C & K L <candk at TICNET.COM>
Jan 22, 1999
-
Last edited Jan 23, 1999
I hate to be off topic, but I grew up with Commodore... 
Have you seen the new Commodore 64 they've released? I forgot the exact
specs, but the chip is 100MHz. I think it was on cnet's site. It's now
in a sleek black case. The computer is still the keyboard... hehe
Anyway, maybe somebody could port EUPHORIA... woo hoo!
Or maybe it was a joke. I don't know. See ya!
Tor Bernhard Gausen wrote:
>
> I have mentioned the Commodore 64 earlier. This is a machine
> people now-a-days use as a standardized symbol of old fashion,
> out classed, stone age computer technology.
>
> But among game and demo programmers on the 64 one rule was
> crystal clear: If it wasn't perfectly smooth, it wasn't worth watching.
3. Re: Thanx
You're welcome! :)
When I commented out the line that waited for the vertical retrace, it
still went smooth for me, but that's probably because I got a pretty fast
cpu (PII-400MHz).. Heh.
Oh yeah, and if I ever find the location for the characters 128 thru 255,
I'll tell ya. *Goes and downloads ASMEdit, hoping he can find it again*
The AfterBeat
Tor Bernhard Gausen wrote:
> I just want to thank everyone for responding to my inquiry
> about my silly scrolltext routine
>
> A few comments though:
>
> Robert Craig says:
> > As for your smooth scrolling program, it spends over 95%
> > of it's time doing mem_copy() of 64000 bytes. Euphoria's
> > mem_copy() calls C's memcpy(). I don't think you could
> > run your program more than about 1% faster in C. I believe
> > that writes to screen memory are much slower than writes
> > to general DRAM addresses, because of the lack of caching.
>
> Then the memcpy() command is probably assembled, right?
> Does this mean it wouldn't even be much faster in pure
> machine code? I mean; copying 64000 bytes from one place
> to another should not be any challenge for a modern processor,
> even in high-level language, so is the caching problems simply an
> unavoidable hardware bottle-neck?
>
> Afterbeat says:
> > I tested out that program, and I found that it goes faster,
> > and the text doesn't shake, when you take out the
> > vertical retrace routine.
>
> Yes, but then it's not smooth at all !
> Afterbeat also helped me find the standard charset, thanx!
>
> Lucius L. Hilley III also answered some of my questions,
> but perhaps the most helpful and enlightening answer came
> from Jiri Babor:
>
> > In recent years I really had to use a wait_retrace routine
> > only when I was messing around with page switching.
> > Otherwise the 'modern' hardware does not seem to need it.
> > I ran your scroller and it was reasonably smooth at the
> > lowest speed setting after I commented out the line with
> > the wait_retrace call.
>
> Exactly. 'Reasonably smooth'.
>
> I have mentioned the Commodore 64 earlier. This is a machine
> people now-a-days use as a standardized symbol of old fashion,
> out classed, stone age computer technology.
>
> But among game and demo programmers on the 64 one rule was
> crystal clear: If it wasn't perfectly smooth, it wasn't worth watching.
>
> Those days, 'Reasonably smooth' was just not smooth enough...
>
> > BTW, you should never rely on the hardware to dictate the
> > top speed. Everybody's machine will be ten times faster
> > in three years time.
>
> I'd say about 4 times faster, wanna bet ?
>
> > maximum speed, even if you never get anywhere near it
> > with your present gear. In a decade or so software
> > archeologists will praise you for it...
>
> I guess you are right, but calling the time() function also
> steal raster. With the time delayer (even when set to zero
> delay, but still calling time(), it seems impossible to get
> anything smooth...
>
> ( Then Jiri guides me through some font problems, thanks again
>
> > You also mentioned drawing lines, circles, etc. on virtual
> > screens. Have a look at my vgraph.e in the Archives.
> > It is pretty old and neglected, but it does lines, ellipses
> > and polygons reasonably fast.
>
> Just what I was looking for !
>
> Anyway, since I'm a natural quitter, I'm gonna give
> up the silly "smooth scrolling project" for now.
>
> I'm never gonna quit Euphoria, though...
>
> Tor Bernhard Gausen
4. Thanx
--=====================_872896517==_
To the listserv:
Thanks to Bryan Watts, Pete Eberlein, and Robert Pilkington for suggesting
that I use 'wait_key' instead of 'get_key'.
I don't know why I didn't think of that. I combed the library with a
fine-tooth comb and couldn't find anything that I thought would do the
trick, when all the time it was right there in front of me.
--=====================_872896517==_
Michael Bolin apparently misunderstood my other question about
'restore'. He suggested 'seek' in the library. But 'seek' seems
to do exactly what I *don't* want. If I want to find something
in a file, when I know it is there, where it is, I have
previously hung something there to mark its location -- then I
use 'seek' to find that something. That's not what I want to do.
I want to find something that may be in the file, but I don't
know where it is or even for certain that it exists. The only
way to find it is to start at the beginning looking at each item
and saying, "No, that's not it ... that's not it ... that's not
it," and finally, "THAT'S IT!" or "Sorry, it's not here." (Yes,
I know about binary searches and other techniques, but for a file
of this size, about 200 items, a binary search program is more
trouble than a straight sequential search.)
Suppose, for example, that my file contains a list of all the
presidents of the United States, arranged in alphabetical order
by first name. Somebody calls out, "Benjamin," and the computer
replies, "Harrison;" or the call is "Warren," and the reply is
"Harding." For "Franklin," the reply would be "Pierce or
Roosevelt;" for a real workout, the request "James" would produce
"Buchanan, Carter, Garfield, Madison, Monroe, or Polk."
For every search of the file, the program has to start at the
beginning of the file. Having returned "Harrison" for the
request "Benjamin," it should not start with "Calvin" for the
next search when the request is "Abraham"; it will reply, "No
such president with that name," unless it wraps around at the end
of the file -- another trick that I don't want to bother with at
this point.
Without the 'restore' command I was asking about, subsequent
searches would begin in the middle of the file. The 'restore'
command would enable a new search to start over at the beginning.
Okay, Michael?
Wally Riley
wryly at mindspring.com
--=====================_872896517==_--
5. Re: Thanx
- Posted by Robert B Pilkington <bpilkington at JUNO.COM>
Aug 29, 1997
-
Last edited Aug 30, 1997
>Thanks to Bryan Watts, Pete Eberlein, and Robert Pilkington for
>suggesting
>that I use 'wait_key' instead of 'get_key'.
>
>I don't know why I didn't think of that. I combed the library with a
>fine-tooth comb and couldn't find anything that I thought would do the
>trick, when all the time it was right there in front of me.
Well, your welcome... :)
>Michael Bolin apparently misunderstood my other question about
>'restore'. He suggested 'seek' in the library. But 'seek' seems
>to do exactly what I *don't* want. If I want to find something
>in a file, when I know it is there, where it is, I have
>previously hung something there to mark its location -- then I
>use 'seek' to find that something. That's not what I want to do.
Um, yes it does....... Read on, trust me. :)
>I want to find something that may be in the file, but I don't
>know where it is or even for certain that it exists. The only
>way to find it is to start at the beginning looking at each item
>and saying, "No, that's not it ... that's not it ... that's not
>it," and finally, "THAT'S IT!" or "Sorry, it's not here." (Yes,
>I know about binary searches and other techniques, but for a file
>of this size, about 200 items, a binary search program is more
>trouble than a straight sequential search.)
Okay....
>Suppose, for example, that my file contains a list of all the
>presidents of the United States, arranged in alphabetical order
>by first name. Somebody calls out, "Benjamin," and the computer
>replies, "Harrison;" or the call is "Warren," and the reply is
>"Harding." For "Franklin," the reply would be "Pierce or
>Roosevelt;" for a real workout, the request "James" would produce
>"Buchanan, Carter, Garfield, Madison, Monroe, or Polk."
>
>For every search of the file, the program has to start at the
>beginning of the file. Having returned "Harrison" for the
>request "Benjamin," it should not start with "Calvin" for the
>next search when the request is "Abraham"; it will reply, "No
>such president with that name," unless it wraps around at the end
>of the file -- another trick that I don't want to bother with at
>this point.
>
>Without the 'restore' command I was asking about, subsequent
>searches would begin in the middle of the file. The 'restore'
>command would enable a new search to start over at the beginning.
Okay, assuming the filename variable is fn:
junk = seek(fn, 0)
Will reset to the beginning of the file. (junk will be 0, indicating
success)
6. Re: Thanx
- Posted by "Christopher K. Lester" <cklester at FLASH.NET>
Aug 29, 1997
-
Last edited Aug 30, 1997
>I want to find something that may be in the file, but I don't
>know where it is or even for certain that it exists.
Have you considered writing your data to the file using print(filenum,
database)?
Having saved the database, you just do sequential searches through an
index... say, the first element.
Right guys?
Later!
ck
P.S. This involves a lot more, but I'm just testing the waters of
appropriateness. :)
7. Re: Thanx
> Without the 'restore' command I was asking about, subsequent
> searches would begin in the middle of the file. The 'restore'
> command would enable a new search to start over at the beginning.
The answer is still 'seek()', you just use seek to position 0 of the
file to point (again) to the begining of the file.
Regards,
Daniel Berstein
danielberstein at usa.net
http://www.geocities.com/SiliconValley/Heights/9316
8. Re: Thanx
>Wallace B. Riley wrote
-- snip --
>searches would begin in the middle of the file. The 'restore'
>command would enable a new search to start over at the beginning.
Unless you are working with a very large database your purposes
would probably be better served reading the file into a sequence
then using find().
Graeme.
9. Re: Thanx
At 11:17 PM 8/29/97 +0700, you wrote:
>---------------------- Information from the mail header -----------------------
>Sender: Euphoria Programming for MS-DOS <EUPHORIA at
>MIAMIU.ACS.MUOHIO.EDU>
>Poster: "Christopher K. Lester" <cklester at FLASH.NET>
>Subject: Re: Thanx
>-------------------------------------------------------------------------------
>
>>I want to find something that may be in the file, but I don't
>>know where it is or even for certain that it exists.
>
>Have you considered writing your data to the file using print(filenum,
>database)?
>
>Having saved the database, you just do sequential searches through an
>index... say, the first element.
>
>Right guys?
>
>Later!
>ck
>
>P.S. This involves a lot more, but I'm just testing the waters of
>appropriateness. :)
>
Thanks to you, but your suggestion isn't practical. I don't write to the
file, it just exists. I made it up a long time ago and it just sits there,
waiting for me to refer to it. That bit about not knowing whether something
is in it or not is a bit strong -- if I as a human were looking up
something, I'd know ahead of time whether what I was looking for would be
there; but the computer isn't human. You give it bad info, it goes ahead
and tries to find it. That is unfortunately all too easy in the project I'm
working on. I've found that out the hard way more than once.
But thanks again.
Wally Riley
wryly at mindspring.com
10. Re: Thanx
>Thanks to you, but your suggestion isn't practical. I don't write to the
>file, it just exists. I made it up a long time ago and it just sits there,
>waiting for me to refer to it. That bit about not knowing whether something
>is in it or not is a bit strong -- if I as a human were looking up
>something, I'd know ahead of time whether what I was looking for would be
>there; but the computer isn't human. You give it bad info, it goes ahead
>and tries to find it. That is unfortunately all too easy in the project I'm
>working on. I've found that out the hard way more than once.
I created a lotto pick tracker for a lotto club I manage. At first, I had
data in a sequential file like the following:
"date, numbers, prize, etc."
I had to read the file, then parse it out finding each comma, etc. etc. It
was the kind of file I think you are talking about-- one that just exists
and is needed for data.
I got wise and realized I could save a lot of time if I just read the
database into a sequence then saved it to a NEW file with print(filenum,
database).
In other words, I simply created a new database- SAME DATA, just different
format. Now it is much easier to read from, find from, manipulate, write
to, etc.
I don't think I'm too off base suggesting you take that old file and update
it to a better format.
Later!
ck
11. Re: Thanx
On Fri, 29 Aug 1997 19:16:39 -0400 "Wallace B. Riley"
<wryly at MINDSPRING.COM> writes:
>Michael Bolin apparently misunderstood my other question about
>'restore'. He suggested 'seek' in the library.
I think you are misunderstanding Euphoria's seek(). It allows you to
position yourself any place you want in a file.
Syntax: include file.e
i1 = seek(fn, i2)
Description: Seek (move) to any byte position in the file fn or to the
end of
file if i2 is -1. For each open file there is a current
byte
position that is updated as a result of I/O operations on
the
file. The initial file position is 0 for files opened for
read,
write or update. The initial position is the end of file
for
files opened for append. The value returned by seek() is
0 if the
seek was successful, and non-zero if it was unsuccessful.
It is
possible to seek past the end of a file. In this case
undefined
bytes will be added to the file to make it long enough
for the
seek.
>I want to find something that may be in the file, but I don't
>know where it is or even for certain that it exists. The only
>way to find it is to start at the beginning looking at each item
>and saying, "No, that's not it ... that's not it ... that's not
>it," and finally, "THAT'S IT!" or "Sorry, it's not here."
Just seek(fn,0) before each search and you will start searching at the
top of the file each time.
For the data in your example remember to handle the multiple names or
each time you search for "Ben*" you will get the first one in the list.
Larry D. Poos
-[USMC (Retar{bks}{bks}ired) Havelock, NC]-
- Programming and System Consultant, LTAD Enterprises -
