Re: [M100] Does anyone actually use MFORTH?
"I’m not sure how that would work since .S has no idea what you think should be on the stack at any given time. It can only show you what is there now." It doesn't know, but it doesn't need to ... The stack has a fixed starting point. An underflowed stack's pointer has gone beyond that point, so the stack depth becomes negative. So what I suggested is .S could print a message if the stack depth has become negative. And the other thing it could do is correct the stack pointer back to it's initial value if it has become negative. Now since it underflowed it may have already corrupted something. So the last bit of the suggestion was to add a little unused space past the bottom of the stack so when you dip into it, nothing gets smacked up immediately. Ultimately of course the answer is: keep the stack balanced. And backup your ram to a REX bank while you're programming because everyone messes up.
Re: [M100] Does anyone actually use MFORTH?
Thanks for the instructional videos, Birt! The general Forth-y bits of it have been helpful and If I had a C=64 kicking around I'd definitely give DurexForth a try. The problem with .S is that if the stack has underflowed, it just keeps reading past the bottom until I assume it wraps all the way around memory and ends up back at the real bottom of the stack. Normally this means reset and you don't get a chance to see what you did wrong. Yesterday I was able to write a wrapper that checks DEPTH first and says something instead of spewing garbage: : .SS DEPTH 0 < IF ." YOU DUN GOOFED" ELSE .S THEN ; This has saved me a lot of resetting in the interim, but it'd be nice to not have to re-enter it every time, and I think it might be corrupting 4 bytes of memory just below MFORTH's stack with that DEPTH and subsequent 0 comparison. Maybe also for the error message string? Guess I'll find out eventually. :D Since DEPTH seems to know where the end of the stack is, and appropriately gives a negative number if you underflow, idk why .S couldn't do the same. If I can wrap my head around the assembly source for MFORTH, I might try to patch that in a sanity check and make a new ROM image. A project for another day I suppose. On Tue, Mar 30, 2021 at 8:49 AM Jeffrey Birt wrote: > The word .S prints out what is on the stack at that time without > disturbing it. It will never show you more or less than what is on the > stack. If what is on the stack does not make sense it is because of an > error in programming and this is very, very easy to do. > > > > One of the most helpful things for me was to write out each line of code > (each Word) on a different line and add a comment to the left as to what > the stack contents would be afterwards. While this is time consuming it has > the benefit of making it clear what is happening to the stack after each > step. > > > > One of the best parts of Forth is that it encourages you to create small > modules which are easier to debug. If you create a new word that is > supposed to take two values off the stack and manipulate them and return > the result you can check the functionality by clearing the stack, typing in > two test values and then executing your new Word. Then to a .S to check the > result. Remember though that .S leave the stack contents there so if you > want to run another such test you would want to clear the stack first. > > > > Jeff Birt > > > > *From:* M100 *On Behalf Of *Alex ... > *Sent:* Monday, March 29, 2021 1:25 PM > *To:* m...@bitchin100.com > *Subject:* Re: [M100] Does anyone actually use MFORTH? > > > > Cool, so newbie mistakes and ignorance. As long as my computer's working > properly. :) > > > > What threw me off is in the book, (pg.25) it talks about returning usually > 0 and printing STACK EMPTY, which is definitely not how the machine behaved > when trying it. > > > > I don't expect everything to have bounds checking, but I'm using .S a lot > to inspect the stack, so having to reset the machine all the time and start > over kind of sucks. If I knew more about the system maybe I could rewrite > .S to know if it's looking at the stack or what's underneath? > > > > About the editor: I skipped over the whole chapter on the arcane line > editor and page/block-based disk storage since this machine has none of > that. Using TEXT with .DO files works ok, as long as whatever I'm doing > doesn't trample the files in RAM. > > > > Thanks for the tutorial videos, Birt. They've been helpful! If I had a > C=64 kicking around here I would definitely give DurexForth a try. > > On Mon, Mar 29, 2021, 08:37 Jeffrey Birt wrote: > > This is the default behavior for most all vintage 8-bit Forth > implementations. To do a bounds check might take 6-10 machine cycles for > every word. This does not seem like a lot, but it would have a noticeable > impact on performance. > > > > When I ventured Forth a few years ago I found that Forth Inc has a PC > based Forth Dev system that is pretty forgiving and a good way to learn > without crashing a machine. https://www.forth.com/ . There is also a good > online Forth tutorial with a web based Forth implementation: > https://skilldrick.github.io/easyforth/ > > > > I got the most out of DurexForth which is a modern Forth implementation on > the C64. You still get the vintage goodness but with a good VI like editor > and actual file support rather than the super goofy and crude typical Forth > screens and blocks. I did a few cheesy Forth videos at the time too: > https://www.youtube.com/watch?v=TXIDqptXmiM (lots of links in the > description). > > > > Jeff Birt > > > > *From:* M100 *On Behalf Of *Alex ... > *Sent:* Sunday, March 28,
Re: [M100] Does anyone actually use MFORTH?
The word .S prints out what is on the stack at that time without disturbing it. It will never show you more or less than what is on the stack. If what is on the stack does not make sense it is because of an error in programming and this is very, very easy to do. One of the most helpful things for me was to write out each line of code (each Word) on a different line and add a comment to the left as to what the stack contents would be afterwards. While this is time consuming it has the benefit of making it clear what is happening to the stack after each step. One of the best parts of Forth is that it encourages you to create small modules which are easier to debug. If you create a new word that is supposed to take two values off the stack and manipulate them and return the result you can check the functionality by clearing the stack, typing in two test values and then executing your new Word. Then to a .S to check the result. Remember though that .S leave the stack contents there so if you want to run another such test you would want to clear the stack first. Jeff Birt From: M100 On Behalf Of Alex ... Sent: Monday, March 29, 2021 1:25 PM To: m...@bitchin100.com Subject: Re: [M100] Does anyone actually use MFORTH? Cool, so newbie mistakes and ignorance. As long as my computer's working properly. :) What threw me off is in the book, (pg.25) it talks about returning usually 0 and printing STACK EMPTY, which is definitely not how the machine behaved when trying it. I don't expect everything to have bounds checking, but I'm using .S a lot to inspect the stack, so having to reset the machine all the time and start over kind of sucks. If I knew more about the system maybe I could rewrite .S to know if it's looking at the stack or what's underneath? About the editor: I skipped over the whole chapter on the arcane line editor and page/block-based disk storage since this machine has none of that. Using TEXT with .DO files works ok, as long as whatever I'm doing doesn't trample the files in RAM. Thanks for the tutorial videos, Birt. They've been helpful! If I had a C=64 kicking around here I would definitely give DurexForth a try. On Mon, Mar 29, 2021, 08:37 Jeffrey Birt mailto:bir...@soigeneris.com> > wrote: This is the default behavior for most all vintage 8-bit Forth implementations. To do a bounds check might take 6-10 machine cycles for every word. This does not seem like a lot, but it would have a noticeable impact on performance. When I ventured Forth a few years ago I found that Forth Inc has a PC based Forth Dev system that is pretty forgiving and a good way to learn without crashing a machine. https://www.forth.com/ . There is also a good online Forth tutorial with a web based Forth implementation: https://skilldrick.github.io/easyforth/ I got the most out of DurexForth which is a modern Forth implementation on the C64. You still get the vintage goodness but with a good VI like editor and actual file support rather than the super goofy and crude typical Forth screens and blocks. I did a few cheesy Forth videos at the time too: https://www.youtube.com/watch?v=TXIDqptXmiM (lots of links in the description). Jeff Birt From: M100 mailto:m100-boun...@lists.bitchin100.com> > On Behalf Of Alex ... Sent: Sunday, March 28, 2021 9:39 PM To: Model 100 Discussion mailto:m100@lists.bitchin100.com> > Subject: [M100] Does anyone actually use MFORTH? Hello Tandy laptop nerds, So I've been reading Leo Brodie's "Starting Forth" and using my '102 as a playground / labrat. There's been a few inconsistencies I expected and can live with/work around, but I've noticed what seems like really bad bugs. It seems trivially easy to underflow the stack into la-la land. (For example: . . .S after a fresh boot will get it stuck spewing memory all over the screen) Has anyone actually used MFORTH for more than just simple tests? Is there maybe some hardware quirks involved here that don't exist on the Virtual-T emulator? Figured I'd cast this one out and see if anyone bites. -Alex -- Disclaimer: Any resemblance between the above views and those of my employer, my terminal, or the view out my window are purely coincidental. Any resemblance between the above and my own views is non-deterministic. The question of the existence of views in the absence of anyone to hold them is left as an exercise for the reader. The question of the existence of the reader is left as an exercise for the second god coefficient. (A discussion of non-orthogonal, non-integral polytheism is beyond the scope of this article.) Thanks /usr/games/fortune
Re: [M100] Does anyone actually use MFORTH?
| Modifying .S to indicate a stack underflow error would be reasonable. It's a debugging tool, and not used by programs so it doesn't impact performance. I’m not sure how that would work since .S has no idea what you think should be on the stack at any given time. It can only show you what is there now. Most of the issues I had getting started was forgetting the effect on the stack of operations I was carrying out, forgetting I needed to do DUP first, etc. I wound up doing a lot of ‘paper coding’, writing down each word on a different line and comment to the left of it was the stack contents would be after it was done. This was a great benefit to seeing what was happening. Jeff Birt From: M100 On Behalf Of John R. Hogerhuis Sent: Tuesday, March 30, 2021 2:54 AM To: m...@bitchin100.com Subject: Re: [M100] Does anyone actually use MFORTH?
Re: [M100] Does anyone actually use MFORTH?
On Mon, Mar 29, 2021 at 11:25 AM Alex ... wrote: > Cool, so newbie mistakes and ignorance. As long as my computer's working > properly. :) > > What threw me off is in the book, (pg.25) it talks about returning usually > 0 and printing STACK EMPTY, which is definitely not how the machine behaved > when trying it. > > I don't expect everything to have bounds checking, but I'm using .S a lot > to inspect the stack, so having to reset the machine all the time and start > over kind of sucks. If I knew more about the system maybe I could rewrite > .S to know if it's looking at the stack or what's underneath? > Modifying .S to indicate a stack underflow error would be reasonable. It's a debugging tool, and not used by programs so it doesn't impact performance. Modifying stack operations with underflow guards would be prohibitively expensive performance-wise given Forth is a "stack machine" language and our 80C85 isn't a speed demon by any stretch of the imagination. A compromise would be to add underflow checking/correction to .S, and add a few cells of space beyond the stack to allow it to underflow a little without causing damage. -- John.
Re: [M100] Does anyone actually use MFORTH?
Hi, That's sounds quite interesting. I learned vi when I was jumping between different Unix systems, and figured they would always have vi. Not always true, especially now, but my hit rate was better than with emacs. Jonathan >Ursprungligt meddelande >Från : petti...@gmail.com >Datum : 2021-03-29 - 23:08 (CEST) >Till : m100@lists.bitchin100.com >Ämne : Re: [M100] Does anyone actually use MFORTH? > >On 3/29/21 11:24 AM, Alex ... wrote: >> >> About the editor: I skipped over the whole chapter on the arcane line >> editor and page/block-based disk storage since this machine has none >> of that. Using TEXT with .DO files works ok, as long as whatever I'm >> doing doesn't trample the files in RAM. >> > >Makes me wish I had time to complete VIT, the vi editor I have for the >Model 100 that is about 75% complete. > >Ken >
Re: [M100] Does anyone actually use MFORTH?
"8)
Re: [M100] Does anyone actually use MFORTH?
A the memories. I used Forth heavily in the 80's, mostly being a FigForth person, on Z80 systems. What you describe is probably the single thing that killed Forth, the fundamental incompatibilities between versions. Some did simple stack checks before doing something silly, link the one referenced in the book, while others simply say "You're the boss - Lets DO THIS", and go off into execution never never. Standardisation was a big problem (as you have seen), We had the Forth-77 Standard, the interim Forth-78 Standard, the Forth-79 Standard, and finally the Forth Standards Team produced the Forth-83 Standard. Eventually, people decided that they wanted a better standard that everybody followed and that lead to the development of the American National Standard X3.215-1994, called the ANS standard. None of these looked like the FigForth reference implementation that spawned so many hobbyists Forths. Brodies editor was pretty standard for the time. Remember, you didn't need to consume a heap of valuable program space on complex editors when the focus was making a device that counted pedestrian traffic using an optical sensor, and your interface to the system was an ADM3a terminal, or a VT100, or a Hazletine (All of which had different cursor addressing methods). If you are interested, there are a group of us Forthers on the Book of Faces, in a group called Forth2020. We are all playing with a version of Forth for the ESP32 chip, which is a single cpu board the size of a big postage stamp that has WiFi, Bluetooth, hundreds of MB of Flash, and is fast... so very very fast. But to be honest, even that suffers from documentation issues as it is being developed - but we are getting there :-) Sadly the community remembers the days of the wild west, when particular sets of individuals on the comp.lang.forth newsgroups would have 'enthusiastic' discussions about some implementation issues associated with a standard That didn't help create the sense of community you need for a language. Hopefully this new Facebook group will help :-) Kindest regards, Doug Jackson em: d...@doughq.com ph: 0414 986878 Check out my awesome clocks at www.dougswordclocks.com Follow my amateur radio adventures at vk1zdj.net --- Just like an old fashioned letter, this email and any files transmitted with it should probably be treated as confidential and intended solely for your own use. Please note that any interesting spelling is usually my own and may have been caused by fat thumbs on a tiny tiny keyboard. Should any part of this message prove to be useful in the event of the imminent Zombie Apocalypse then the sender bears no personal, legal, or moral responsibility for any outcome resulting from its usage unless the result of said usage is the unlikely defeat of the Zombie Hordes in which case the sender takes full credit without any theoretical or actual legal liability. :-) Be nice to your parents. Go outside and do something awesome - Draw, paint, walk, setup a radio station, go fishing or sailing - just do something that makes you happy. ^G ^G ^G ^G ^G ^G ^G ^G- In more laid back days this line would literally sing ^G ^G ^G ^G ^G ^G ^G ^G On Tue, 30 Mar 2021 at 05:25, Alex ... wrote: > Cool, so newbie mistakes and ignorance. As long as my computer's working > properly. :) > > What threw me off is in the book, (pg.25) it talks about returning usually > 0 and printing STACK EMPTY, which is definitely not how the machine behaved > when trying it. > > I don't expect everything to have bounds checking, but I'm using .S a lot > to inspect the stack, so having to reset the machine all the time and start > over kind of sucks. If I knew more about the system maybe I could rewrite > .S to know if it's looking at the stack or what's underneath? > > About the editor: I skipped over the whole chapter on the arcane line > editor and page/block-based disk storage since this machine has none of > that. Using TEXT with .DO files works ok, as long as whatever I'm doing > doesn't trample the files in RAM. > > Thanks for the tutorial videos, Birt. They've been helpful! If I had a > C=64 kicking around here I would definitely give DurexForth a try. > > > On Mon, Mar 29, 2021, 08:37 Jeffrey Birt wrote: > >> This is the default behavior for most all vintage 8-bit Forth >> implementations. To do a bounds check might take 6-10 machine cycles for >> every word. This does not seem like a lot, but it would have a noticeable >> impact on performance. >> >> >> >> When I ventured Forth a few years ago I found that Forth Inc has a PC >> based Forth Dev system that is pretty forgiving and a good way to learn >> without crashing a machine. https://www.forth.com/ . There is also a >> good online Forth tutorial with a web based Forth implementation: >> https://skilldrick.github.io/easyforth/ >> >> >> >> I got the most out of DurexForth which is a modern Forth
Re: [M100] Does anyone actually use MFORTH?
On 3/29/21 11:24 AM, Alex ... wrote: About the editor: I skipped over the whole chapter on the arcane line editor and page/block-based disk storage since this machine has none of that. Using TEXT with .DO files works ok, as long as whatever I'm doing doesn't trample the files in RAM. Makes me wish I had time to complete VIT, the vi editor I have for the Model 100 that is about 75% complete. Ken
Re: [M100] Does anyone actually use MFORTH?
Cool, so newbie mistakes and ignorance. As long as my computer's working properly. :) What threw me off is in the book, (pg.25) it talks about returning usually 0 and printing STACK EMPTY, which is definitely not how the machine behaved when trying it. I don't expect everything to have bounds checking, but I'm using .S a lot to inspect the stack, so having to reset the machine all the time and start over kind of sucks. If I knew more about the system maybe I could rewrite .S to know if it's looking at the stack or what's underneath? About the editor: I skipped over the whole chapter on the arcane line editor and page/block-based disk storage since this machine has none of that. Using TEXT with .DO files works ok, as long as whatever I'm doing doesn't trample the files in RAM. Thanks for the tutorial videos, Birt. They've been helpful! If I had a C=64 kicking around here I would definitely give DurexForth a try. On Mon, Mar 29, 2021, 08:37 Jeffrey Birt wrote: > This is the default behavior for most all vintage 8-bit Forth > implementations. To do a bounds check might take 6-10 machine cycles for > every word. This does not seem like a lot, but it would have a noticeable > impact on performance. > > > > When I ventured Forth a few years ago I found that Forth Inc has a PC > based Forth Dev system that is pretty forgiving and a good way to learn > without crashing a machine. https://www.forth.com/ . There is also a good > online Forth tutorial with a web based Forth implementation: > https://skilldrick.github.io/easyforth/ > > > > I got the most out of DurexForth which is a modern Forth implementation on > the C64. You still get the vintage goodness but with a good VI like editor > and actual file support rather than the super goofy and crude typical Forth > screens and blocks. I did a few cheesy Forth videos at the time too: > https://www.youtube.com/watch?v=TXIDqptXmiM (lots of links in the > description). > > > > Jeff Birt > > > > *From:* M100 *On Behalf Of *Alex ... > *Sent:* Sunday, March 28, 2021 9:39 PM > *To:* Model 100 Discussion > *Subject:* [M100] Does anyone actually use MFORTH? > > > > Hello Tandy laptop nerds, > > So I've been reading Leo Brodie's "Starting Forth" and using my '102 as a > playground / labrat. There's been a few inconsistencies I expected and can > live with/work around, but I've noticed what seems like really bad bugs. It > seems trivially easy to underflow the stack into la-la land. (For example: > . . .S after a fresh boot will get it stuck spewing memory all over the > screen) > > Has anyone actually used MFORTH for more than just simple tests? Is there > maybe some hardware quirks involved here that don't exist on the Virtual-T > emulator? > > > > Figured I'd cast this one out and see if anyone bites. > > -Alex > > > -- > > Disclaimer: Any resemblance between the above views and those of my > employer, my terminal, or the view out my window are purely coincidental. > Any resemblance between the above and my own views is non-deterministic. > The question of the existence of views in the absence of anyone to hold > them is left as an exercise for the reader. > The question of the existence of the reader is left as an exercise for the > second god coefficient. (A discussion of non-orthogonal, non-integral > polytheism is beyond the scope of this article.) Thanks /usr/games/fortune >
Re: [M100] Does anyone actually use MFORTH?
This is the default behavior for most all vintage 8-bit Forth implementations. To do a bounds check might take 6-10 machine cycles for every word. This does not seem like a lot, but it would have a noticeable impact on performance. When I ventured Forth a few years ago I found that Forth Inc has a PC based Forth Dev system that is pretty forgiving and a good way to learn without crashing a machine. https://www.forth.com/ . There is also a good online Forth tutorial with a web based Forth implementation: https://skilldrick.github.io/easyforth/ I got the most out of DurexForth which is a modern Forth implementation on the C64. You still get the vintage goodness but with a good VI like editor and actual file support rather than the super goofy and crude typical Forth screens and blocks. I did a few cheesy Forth videos at the time too: https://www.youtube.com/watch?v=TXIDqptXmiM (lots of links in the description). Jeff Birt From: M100 On Behalf Of Alex ... Sent: Sunday, March 28, 2021 9:39 PM To: Model 100 Discussion Subject: [M100] Does anyone actually use MFORTH? Hello Tandy laptop nerds, So I've been reading Leo Brodie's "Starting Forth" and using my '102 as a playground / labrat. There's been a few inconsistencies I expected and can live with/work around, but I've noticed what seems like really bad bugs. It seems trivially easy to underflow the stack into la-la land. (For example: . . .S after a fresh boot will get it stuck spewing memory all over the screen) Has anyone actually used MFORTH for more than just simple tests? Is there maybe some hardware quirks involved here that don't exist on the Virtual-T emulator? Figured I'd cast this one out and see if anyone bites. -Alex -- Disclaimer: Any resemblance between the above views and those of my employer, my terminal, or the view out my window are purely coincidental. Any resemblance between the above and my own views is non-deterministic. The question of the existence of views in the absence of anyone to hold them is left as an exercise for the reader. The question of the existence of the reader is left as an exercise for the second god coefficient. (A discussion of non-orthogonal, non-integral polytheism is beyond the scope of this article.) Thanks /usr/games/fortune
Re: [M100] Does anyone actually use MFORTH?
On Sun, Mar 28, 2021 at 7:38 PM Alex ... wrote: > Hello Tandy laptop nerds, > > So I've been reading Leo Brodie's "Starting Forth" and using my '102 as a > playground / labrat. There's been a few inconsistencies I expected and can > live with/work around, but I've noticed what seems like really bad bugs. It > seems trivially easy to underflow the stack into la-la land. (For example: > . . .S after a fresh boot will get it stuck spewing memory all over the > screen) > I don't think that I'd call that a bug... Forths are pretty close to the metal languages. They tend not to have a lot of validity checks. You can crash it, no problem. If you underflow the stack, bad things happen. I'm actually not sure if parameter stack underflow = crash is typical of other 8-bit Forths. But I wouldn't be surprised. > > Has anyone actually used MFORTH for more than just simple tests? Is there > maybe some hardware quirks involved here that don't exist on the Virtual-T > emulator? > Your example crashes in CloudT too. It's not an emulation thing. I like MForth and have messed with it a few times. But the big thing that limits it is it offers no way to generate stand-alone CO files that can run from the regular environment (with or without the ROM). A metacompiler would be one way to do it. -- John. >
