On Saturday, June 25, 2016 at 6:28:28 PM UTC-7, Cecil - k5nwa wrote:
> On 6/25/2016 6:53 PM,
hughag...@gmail.com wrote:
> > On Saturday, June 25, 2016 at 7:55:26 AM UTC-7, Anton Ertl wrote:
> >> Rob Sciuk <
r...@controlq.com> writes:
> >>> If I read this correctly, you are implying that you cannot write a
> >>> "breakout" program in ANS Forth because the language lacks a timer "in
> >>> order to have consistent speed".
> >>
> >> I doubt that this is an issue for Breakout, but sure, if a game
> >> consumes a significant and varying amount of CPU, then standard Forth
> >> lacks support for allowing consistent sub-second timing.
> >
> > Elizabeth Rather surrounds herself with pocket-boys who support her faithfully. Not long ago she spoke out against having a code-library support full-duplex in a UART and immediately Andrew Haley (an employee of Forth Inc.) sprang to her defense claiming that using a UART for only half-duplex is the "Forth Spirit." Now we have Anton Ertl (appointed by Elizabeth Rather to be the Forth-200x chair-person) claim that ANS-Forth (written by Elizabeth Rather) would be adequate for my BreakOut game.
> >
> > The paddle is over 30 character rows away from the wall, so if TIME&DATE is used for timing (accurate to one second), the ball will move one character row per second and so it would take over one minute for the ball to travel from the paddle to the wall and back to the paddle again --- it is a good thing that TIME&DATE provides hours and days, because this will be needed to keep track of how long the game takes to play (mostly a matter of the player's ability to stay awake) --- but Anton has to support Elizabeth Rather no matter what, so he won't admit that ANS-Forth is unable to support even the most rudimentary arcade game.
Actually, I said this wrong. The paddle has to move at least 3 times faster than the ball so the nimble-fingered player has time to move it under the ball after the ball has already bounced and begun to descend (especially true if there are multiple balls in the air simultaneously, which any decent BreakOut game would have). So, using ANS-Forth, it would take 3 to 6 minutes for the ball to travel from the paddle up to the wall and back down to the paddle again --- you need a period of 1/100 seconds or faster --- using TIME&DATE is over 2 orders of magnitude too slow.
I remember that the Commodore-64 had a "jiffy clock" meaning that you got an interrupt 60 times per second. IIRC the Vic-20 had the same thing. Those early computers didn't actually have a timer chip; they just used the 60Hz house-current AC cycle to generate their interrupt. This was okay for most games, but it was somewhat slow --- 100 times per second (as done on the Radio-Shack Color Computer) would have been better.
I haven't actually been interested in arcade games since the days of the Commodore-64 --- every teenager is interested in arcade games, and I was no exception --- I only brought up the subject of BreakOut here because I was trying to encourage Gavino to write a fun program, but he said "fuk u" so the project is pretty much dead (I might write it myself just so it could be yet another example program in the novice package, but this is not a high priority for me).
Most programmers get started in programming by writing arcade games when they are teenagers --- the fact that ANS-Forth doesn't support arcade games is just one of the many reasons why ANS-Forth is not popular --- teenagers go to college having never heard of Forth, and they eventually graduate from college still having never heard of Forth.
> > I think that ANS-Forth was purposely sabotaged by the corporations to prevent the common Forth programmers from competing against them --- anybody who does gets denounced for being non-standard --- but they themselves ignore the Standard routinely because they know it is useless (they purposely made it useless).
> >
> > Anybody who has written an arcade game on any computer, from the Commodore Vic-20 on up, knows that millisecond timing is necessary to provide consistent speed --- claiming that this is not true, is blatantly dishonest and unbelievable.
> >
> I'm not much into games, but in embedded programming for which Forth can
> be a very useful tool due to it's interactive nature, timing to
> milliseconds is very important.
Actually, timing to milliseconds is pretty pedestrian for motion-control. Timing to micro-seconds is much more common.
The problem with motion-control is harmonic resonance, which can result in vibration. If the machine begins vibrating when you make one change in direction, and then you make another change in direction while it is still vibrating, the new vibration will likely be in sync with the previous vibration and you will get amplified vibration. This happens often when drawing a curved line because the curve is actually a sequence of straight lines of only a few milli-inches each, so the changes in direction occur at a constant frequency.
The typical solution is to stop the movement at each change in direction for a long period of time (like 20 milliseconds) to let the vibration settle down, so you never get feedback.
The MiniForth processor was used in the motion-control board of a laser-etcher. This can't be stopped for even a short period of time because the laser will burn a blotch in the material. The laser has to move at a consistent speed, whether it is making a straight line or a curved line. Also, the laser has to move fast because the images are often large and intricate, and you don't want to take hours to etch each image. This is why we needed a custom micro-processor that was very fast --- the program was sending new commands to the stepper motors on a very high frequency (I don't know exactly, but the period was maybe 5 or 10 micro-seconds).
This was over 20 years ago --- it seems unlikely that there is anybody on the Forth-200x committee today who would be capable of building a processor like this or writing the program for it --- this is why I was kicked out!
> Both VFX, and SwiftForth have words to read a millisecond timer, and to
> time events but ANS Forth doesn't seem to have those features, but it
> does have a word to wait x milliseconds which is not useful to time
> things while one continues executing code.
If you read the documentation for MS in the ANS-Forth document (section 10.6.2.1905), you will see that it says this:
"Wait at least u milliseconds."
The time spent waiting could be significantly longer than the specified time and still fulfill the "at least" requirement.
I think MS was primarily put in ANS-Forth to support multi-tasking. You would have this function.
: pause 1 ms ;
PAUSE would be inserted at the top of every colon word and also at the top of every loop. The pause would be at least 1 millisecond --- as much as 100 milliseconds if there was a task-switch done inside of MS --- only 1 millisecond if no task-switch is needed.
Elizabeth Rather is fascinated with multi-tasking and highly impressed by the fact that Charles Moore provided Forth with multi-tasking way back in the 1970s. Multi-tasking is not actually useful in embedded controllers however --- multi-tasking can be used in soft real-time --- multi-tasking can't be used in hard real-time, but this is interrupt-driven. Charles Moore actually wrote the multi-tasking stuff in Forth to support multi-user systems because the PDP11 was so expensive in the 1970s that a company would typically own one and have everybody in the building using it with a dumb-terminal --- multi-user systems haven't been used since the 1980s though just because the price went down and it became feasible for every employee to have his own computer on his desk (actually, under his desk, as they were still somewhat bulky).
As I have said many times, ANS-Forth represents the state of the art for desktop-computer Forth circa about 1974 --- ANS-Forth was already 20 years obsolete in 1994 when it came out --- now, of course, ANS-Forth is over 40 years obsolete.