I still haven't found the reason for the 68 byte gap between the DP and PAD. Can someone please enlighten me?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thanks.

I still am confused by WORD putting a whole line at HERE, as that would require a delimiter other than a space, and words are limited to 31 characters in Forth when finding them.

And I haven't come across enough numeric output to really study "those" words in depth, and didn't realize they built down. But there it is, <# starts at PAD, and #> builds down from PAD. The most common numeric output examples I have seen are with dates. But even they only take a dozen characters at the most.

I feel 68 bytes is overkill. 32 max would probably be enough.

Everyday use in Forth probably would never see that much space used, but maybe in a SEARCH/REPLACE function of a word processor. I know I have never done a SEARCH/REPLACE with over 12 characters, let alone 32 or 68.

I also don't think I have see both HERE and numeric output used at the same time. Couldn't they share the same space?

Maybe the space between HERE and PAD could have been made into an adjustable variable and used like virtual memory is used. If you need more space, then increase the variable.

I am basically speaking from a user with limited memory, like on a 64 kb machine. Users with larger memory access probably would not care one way or another as an extra 30 or so bytes is peanuts to them.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Your not steering me wrong. But you are also not giving me an answer that challenges me either.

When talking about screens, ENCLOSE will get the address of any line or multiple lines from a screen and does not copy it to HERE. I often use "; WORD" which will enclose a word definition and usually spans multiple lines much greater than 68 characters. And if anything was copied out of the buffer, it would be to PAD and not HERE.

When creating a colon definition, most of the interpretation is done in TIB and only -FIND searches for the word stored at HERE. And words have a limit of 31 characters.

The longest numeric output I have seen is a DATE/TIME string which has a max of about 22 characters, and is never used at the same time when Forth is searching for words.

So, all-in-all, looking through the Forth system code, I don't see a reason to have as large a gap as is given. Although it really doesn't make much difference from a programming standpoint, it is just more of a curiosity thing than a necessity.

I was just wondering if any one had a reason or ever felt the gap between HERE and PAD was big enough or was even necessary to be that large.

I didn't know it was a 68 byte gap until now, but I admit that the first inkling of a reason that flashed through my mind was a standard 64 char line plus a couple of delimiters at either end.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I know what the code does and posting code is not an answer. What I am asking is, why the need for such a large gap or should the gap be larger?

Let me give you an example. If I print a line with ." like this:

." This is a very long line to indicate that PAD and numeric output gets overwritten by any text that was just printed."

The text gets printed up to the 80 character limit set by QUERY and this test means that the text will over-write any pre-existing values in the numeric output area and anything at the start of PAD. Which also means they cannot hold data for future use. Which also means WORD does not know about the gap between HERE and PAD and is not restricted by the 68 byte limit. WORD is also not restricted by the 64 char limit of a screen line, otherwise it would have C/L MAX in WORD's definition.

My QUERY says 80 EXPECT and it interprets just fine. That should make the gap 80 characters, not 68. If WORD had anything to say about that, it would restrict the input basically to 64.

Since WORD is not restricted, can only mean one thing, that PAD is meant more as a starting point for numeric output to be calculated downwards. The longest numeric string I have seen so far is a Date/Time string that probably looks like this (hr:mn:ss Saturday DDth day of September, YYYY)( makes 45 characters, if text is allowed with numeric output )

I guess then, it is not unheard of to reach large numeric output strings.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Now I would like to know, why?
I thought I just proved that the numeric output area and PAD are just temporary position holders and it is ok if WORD over-writes text in those areas.

Were you getting corruption in PAD with something I haven't seen yet, or were you just being cautious?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I am still not sure what you are scared of overwriting at PAD since PAD is only temporary? Unless you are storing arrays starting at PAD?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?