OK, I've found where the trouble lies. ?STACK is supposed to issue an error message if the stack is out of bounds. But 6502 FIG Forth's ?STACK is coded incorrectly. Here is the FIG version compared to a debugged version.

There's an empty-stack test and a full-stack test. For the empty-stack test, FIG's ?STACK begins by placing $9E on stack... and then attempts to decide whether the stack is empty! That's why (as shown by whartung's screen dialog) the stack can actually underflow by one item and yet go unflagged.

The new, corrected version calls SP@ first, so as to get the true picture. The other parameter and the test are coded subsequently.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Aha! Yes, thank you Jeff.

The last time I worked on a 6502 Forth was valForth on my Atari 800, and that was *cough* 30ish years ago(!!). And I don't recall . having this behavior. So I go on the assumption that the Fig source is "correct", and any anomalies are of my own creation.

But, yea, looking at ?STACK, your point is well made. I cleaned that up and it's much better now. At least it's consistent.

I'm moving forward with disk I/O. I have the primitives coded in the simulator. Working on R/W now. For a moment I was confused between the distinction, if any, between what a "block" is vs what a "screen" is.

Again, back in the valForth days, a screen was 512 bytes, 32 x 16, rather than 1024, 64 x 16, notably because the Atari had a 40 character screen. I have no memory what a block was, though I imagine it was the same. My recent spelunkings seem to intermix block and screen, or more specifically a screen is a unit of source code, and each screen is a block. In contrast, a block is simply a unit of arbitrary data, typically of 1024 bytes, but not necessarily. Not all blocks are screens.

That makes R/W a little more clear on how to get that written. Hopefully today, we'll see.

Thanks again, Jeff.

For anyone reading this in future, a few points regarding TOS and BOS:

In my post above I used their literal values 9Eh and 20h, but TOS and BOS are the symblic names declared in the 6502 FIG assembly source.Puzzling over ?STACK I began to wonder if BOS and TOS are intended to represent "limit" or "limit+1". In other words, are $20 and $9E legal and usable values for X, or are they the threshold at which an error message ought to result? I quickly determined that TOS is a legal value because that's what gets loaded into X during a cold or warm start. As for BOS, this is a value used only by ?STACK, and ?STACK issues no error if X equals BOS. Forth itself (at least the 6502 FIG version) has no names for BOS and TOS. That's why ?STACK uses hard-coded literal values (based on BOS and TOS as declared in the assembly source).

On a related note, 6502 FIG Forth has two "silent" (ie, nameless) USER variables known as S0 and R0. These are quite different from TOS (and have no relation at all to BOS), but S0 is initially set to TOS. The Glossary and Screen 36 mention S0 and R0. Each has 16 bits of space allocated in the user area but the names S0 and R0 appear nowhere. They are referenced simply according to an offset from the User Pointer. See the assembly source for SP! and RP!.


Block size is usually set to represent the smallest chunk your disk subsystem can read/write. A screen, as you say, is a unit of source code (comprised of multiple blocks).

Have fun.... and remember to EMPTY-BUFFERS at the beginning of your session before attempting to LOAD any Forth source code!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

It's all quite confusing, I don't think they're consistent in their usage.

First of, Fig as B/BUF, "Bytes per Buffer".

The install guide says:

Then, we have B/SCR, which Fig defines as "Blocks per Screen". Yet, that actual definition is:

So, in fact B/SCR is really more "buffers" per screen. It's also clear that "screen" means 1024 bytes, which is constant with the 64x16 text block.

Next, we have the definition of LOAD, which is "Begin interpretation of screen n.". Along with LOAD we have BLOCK which is "Leave the memory address of the block buffer containing block n.", along with BUFFER "Obtain the next memory buffer, assigning it to block n.". It's pretty clear that the arguments for LOAD, BLOCK, and BUFFER are the same -- a block number. So, in this case a Screen is one in the same as a Block, which is loaded in to a Buffer.

These blocks and buffers are not the same as B/BUF and B/SCR blocks and buffers. That's where it gets confusing.

It's also not helpful that they define a Fig disk primitive, R/W. They say that it "This colon-definition is the standard linkage to your disc. It requests the read or write of a disc sector.". A disk sector is represented as being B/BUF long. Later, however, they define R/W:

Are we talking Big B BLOCKs and BUFFERs or Little b blocks and buffers. Looking at the sample implementation of a RAM disk R/W:

And with the associated other chatter, they mean Little b blocks and buffers. The fact that this moves only B/BUF data at a time suggests that.

So it seems I need to implement R/W, to read/write one sector at a time, and properly define B/BUF and B/SCR to match. Once I get that done, everything else should "just work".

But was confusing to decipher.

I added the disk interface code to my implementation, but I found I had a catastrophic failure in BLOCK. It would take forever to run and came back with odd results. I tracked this down to the fact that I changed the Sector Size from 128 to 256, and missed a hard coded constant that was based on that number. (Curse you hard coded constants!) I implemented that RAM Disk R/W, and BLOCK seems to now work correctly.

So, I'll go and uncomment out my original R/W and see if I can get that to work.

Nice little detail, I was able to right the R/W with regular Forth rather than having to drop in to assembly. It's just pushing memory to special addresses that respond "instantly", so, no more than some stack gymnastics and some stores.

So, "disk" I/O appears to work. I guess BLOCK and BUFFER are interchangeable, screens are simply as many blocks/buffers as necessary based on size to fit in to 1K. That was still really confusing.

I typed in the editor found in the Fig install manual. First, I typed in the few words I need to simply insert lines, then I typed the entire editor suite in. I have not tested it completely, but the I/O part works, screens are saving, etc. So that's all good.

At a minimum I've turned the disk "on" in the raw assembly, so now I have actual error messages.

But found another odd behavior.

If I do this:

I quickly get an EMPTY STACK error, as expected.

However, if I do this:

It prints a) too many numbers (clearly overshooting the stack), and b) goes out to lunch. Curious that the compiled behavior of . is (that) different from the immediate behavior, different enough to crash the interpreter.

Have to track that down, very strange.

I haven't used actual fig-Forth (which is why I haven't been contributing on this topic), but in the Forth-83 I've been using, the stack only gets checked (by INTERPRETER) when interpreting from the input stream, not when executing compiled code, which explains why you don't get the error message when you execute the colon definition. It know you're just playing with it and you know not to do that in real applications. It would slow it down a lot if it had to keep checking those things needlessly during program running.

_________________
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?

Ah HA! Yes, THAT makes complete sense to me. At one point I actually had a stack check in ., but I removed it after fixing ?STACK. But you're right, only INTERPRET has an actual stack check in it, and that's not run with compiled words.

As I mentioned earlier, I haven't used a Forth in a gazillion years. I imagine were this to have happened back in the day on my Atari, I would have hit the RESET button without a second thought, and just moved on. My simulator doesn't really have a RESET button per se at the moment (of all things, I can't enter a start address and start running right now, just haven't needed it, everything simply starts at $0200).

I'm thinking of perhaps adding in SuperMon and a simple boot protocol for my disk, so that I have something I can BRK and RESET in to. It's one of those weird balance things -- what do you do in the simulator tooling vs within the processor itself. For example, the simulator looks for BRK now and simply stops it. But to load my Forth currently, it loads from an Intel HEX file generated by the assembler off of the file system, rather than the little disk thing I have. No big deal, just debating on whether to try and make the Forth more self-hosting or not.

Speaking of F83, I have been debating if I want to do more with my Fig in place or should I consider moving up to F83. It seems like a reasonable upgrade (as with all things, it has its detractors), but it's not as severe as ANSI. I'm considering it sooner than later simply so I don't have to rewrite other code after words.

Do you (or anyone) have any thoughts one way or the other?

I was introduced to Forth in 1988 or 89 through the Forth module on my Hewlett-Packard HP-71 hand-held computer which had basically Forth-79 but a little strange because of its 4-bit data bus and 20-bit address bus. Bytes were of course two nybbles, but a cell was two and a half bytes, five nybbles, so a complete address would fit in a cell. It's strange, but did not present any problems. The BASIC in that computer was by far the best BASIC I've ever seen (when you include the Math module and user group language extensions), but the Forth implementation was very poor. I was able to dramatically speed up many words just by re-writing them even as secondaries, not resorting to assembly language for its even stranger Saturn processor with 64-bit registers. I never did learn its assembler.

Then I went to Forth-83 for the 6502-controlled test equipment at my last place of work about 1990. It seemed considerably better. Forth was popular and apparently making big strides in acceptance and standardization in that time period, and it showed in the difference between the two standards ('79 and '83), it seemed to me. (Fig-Forth was before Forth-79.) ANS Forth came later after much debate of the X3J14 committee; but although it has some good things, there are also various things I don't like about it, so I'm glad I don't have to be locked entirely into one standard or another.

There are of course many words in common usage that are not part of any official standard; so when I found that various words I wrote were in common usage but had different names, I changed my names to match common usage. One example is RANGE , which tells if n1 is in the range of n2 to n3, which of course I used a lot in the automated production test equipment, to see if a test result was within acceptable limits. I found that others did the same thing and called it BETWEEN , and that it almost made it into ANS Forth under that name; so I changed the name of mine to match. So in a way, common usage itself becomes a standard.

There are some parts of ANS Forth that present extra overhead in order to make it more portable across a wide range of processors. My personal opinion is that they may have taken this a little too far. At some point, we need to acknowledge that no language that lets you get so close to the heart of the computer will be 100% portable. We must consider the programmer(s) and platform(s) involved, and decide on a good balance between portability and optimization. I personally prefer a little more optimization at the expense of some portability. Greater optimization means a particular processor can be used for a wider range of jobs anyway, which would in itself reduce the need for portability.

Jack Woehr of Vesta Technology who was on the X3J14 committee says in his book "Forth: The New Model", "When Forth, which some hold to be inextricably wedded to hardware, takes responsibility for cross-platform portability, a certain light-footedness and grace will be surrendered." He admits that optimum portability and optimum efficiency don't come at the same point. Fortunately he also says it's not the committee's intention to force anyone to comply with the standard. What I have is basically Forth-83 with a lot of extensions from my own experience, the books "Starting Forth" and "Thinking Forth," Forth Dimensions magazine, ANS, and common usage.

Edit: Jeff Fox has a great article entitled "ANSI Forth is ANTI Forth" at http://www.ultratechnology.com/antiansi.htm, and Chuck Moore, the inventor of Forth agrees. See why.

Changing the subject-- I worked with screens very little, and found them extremely limiting, with too many disadvantages to justify keeping them for their few advantages. I have mostly used text files for my source code, with a full-featured programmer's text editor (MultiEdit, for DOS in my case) which I've had as many as 32 files open at once on. The computers I've run the Forth on had very little in the way of human I/O, so I have been using the PC (with its full keyboard, hi-res monitor, and disc drives) to write and save the source code, and send that to the target for on-the-fly compilation, assembly, or execution, as appropriate, when needed. Turn-around time for writing and testing a little piece of code is instant, without having to exit or suspend or background the editor or re-compile the whole application. The text editor was not only convenient for the obvious reasons, but also allows marking any size of block down to as little as single "." and sending that out as if printing it (but it doesn't have to know that the target computer is not a printer). For the automated test equipment, I would get things going this way and periodically add the newly developed material to EPROM. When finished, the whole application was in EPROM, so it was no longer dependent on the PC.

_________________
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 for an interesting post, Garth. I apologize for not contributing to this thread lately myself. whartung, I don't have any experience with F83 so I'm afraid I have no opinion to offer. If you do end up in F83 territory, drop us a line and let us know your impressions!

But, before you move on...... would you be willing to post a clarification of these issues? I agree the terminology for disk IO is terribly confusing -- partly because of Fig's fondness for abbreviations beginning with the letter B (ambiguously representing BLOCK BUFFER BYTE etc). Another confusing aspect is the distinction between a buffer address (in ram) and the corresponding address on disk. While the subject is still fresh in your mind, perhaps you could share what you've unraveled.

Here again your efforts could be of benefit to others. Can you document the location of this constant for us please?

Annoying, to be sure! Can you direct us to where you found the error-message screens?

cheers,

Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

All of the (available) F83s I've seen are meta-compiled, so I would need to port one to assembly. I may still do this. F83 seems to be the last of the "screen" Forths. While ANS supports screens, etc., F83's heritage is still deep in it. I appreciate that folks prefer the files to screens, but my "machine" doesn't have a filesystem yet, so I'm more attracted to a screen based system at this juncture.

I think F83 is the most mature of the 16-bit, small machine Forths. Still deciding whether to take the porting effort on, but I think it would actually be valuable to have a "Fig style" assembly based F83, and that would be faster than trying to port the F83 meta-compiler to FIG in order to create a new F83. I understand the gist of the meta-compiler, but it's inner mechanics are still not quite clear to me.


BUFFER and BLOCK are the same thing. I should say they refer to the same unit, which is a Buffer. 1 Block is 1 Buffer in size. The argument to BUFFER and BLOCK is the same argument, typically the sector number (numbering 1 to # of sectors on the disk, which does not seem to have an "official" name).

Buffers are B/BUF bytes large. Screens are 1024 bytes large, and consist of B/SCR buffers.

The arguments to LIST and LOAD are Screen Numbers, not buffer numbers. Screens take multiple buffers.


The constant is named BMAG, and the text says it's defined as "total buffer magnitude, in bytes expressed by SSIZE+4*NBUF". The detail there is that it's actually (SSIZE+4)*NBUF, which is likely why it's not defined as an expression since most simple assemblers may not do operator precedence or offer parentheses. The value in the default Fig listing is 1056 ((128 + 4) * . In my listing I changed it to [SSIZE+4]*NBUF since I use [] in lieu of () in my expressions.


I found them in two places. One was in the PDP-11 User Guide, but the real find was the actual Fig Installation Manual. dclxvi linked to that: ftp://ftp.taygeta.com/pub/Forth/Archive ... IGINST.ZIP

This made much more sense since the assembly refers to screens of code and such, but I never knew what those screens referred to. In the past, my friends and I used to buy the machine listings from the legendary tech book store Op Amp Technical Books in Los Angeles, but even then I never saw the original Fig install guide. So, that link was really helpful.

The F83 standard ( http://forth.sourceforge.net/std/fst83/ ) is helpful as well, since it can trace its lineage back to the Fig systems. It's got reasonably clear definitions as well.

Just a matter of terminology: I know it's tempting to abbreviate, but according to http://www.angelfire.com/in/zydenbos/WhatisForth.html , F83 was a particular and popular public-domain implementation of Forth-83, written by Henry Laxen and Michael Perry. F83 could recompile itself (FIG-Forth required an external assembler), had multitasking capabilities, ran under a host operating system, and generally represented a quantum jump in power and sophistication over FIG-Forth. IOW, not all Forth-83's are F83.

_________________
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 forgot to mention this before, but for anyone interested, the Forth source for the assembler (used by the CODE words in the installation manual) is here:

ftp://ftp.taygeta.com/pub/Forth/Archive ... sm6502.txt

It appears to be OCR'd as there are some instances of things like uppercase Os that should be zeros, and lowercase Ls that should be ones.

A clean version of the Forth source for the assembler is here.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Somewhat related to the stack underflow issue mentioned before... On my system, underflowing the stack with a . results in the following output:

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut