In case anyone's playing around with 6502 FIG Forth, I thought it'd be good to gather together info regarding its quirks... and a couple of outright bugs.

BUG #1: In this topic Garth explains a subtle but fundamental flaw in the 6502 FIG Forth multiply routine U* (aka UM*). This manifests as incorrect multiplication results in a tiny minority of cases.

BUG #2: Below I will explain a much less subtle problem with the unsigned "less-than" test, U<. As most of you know, the desired behavior for U< is n1 n2 --- flag where the boolean flag is true if, based on unsigned comparison, n1 is less than n2.

FIG Forth defines U< as but that logic is incorrect. The - (subtraction) makes sense, but following it with 0< does not. The boolean left on stack should be determined by whether the subtraction produces a borrow -- not by whether the subtraction produces a 0< (negative) result.

U< could be correctly coded in high level by extending n1 and n2 to double precision. D- SWAP DROP 0< could then be used to produce a reliable result. But, tallying up the memory cost, I decided I might as well code U< in assembler instead:

Thanks go to whartung for helping with the U< testing; also to Bill Ragsdale, who created 6502 FIG Forth -- a venerable classic! -- in the first place.

-- Jeff

ps: a slightly smaller and faster version begins as follows:

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

Thanks for pointing that out. I never used FIG-Forth exactly, but much of what I started with came from FIG-Forth. My U< says (after forming the header):
I don't remember if that's what it came with or if it's my own fix.

What I have in my '816 Forth is:


I had a problem early on in the 6502 Forth I was working with which defined D< as:
My first encounter with the problem occurred with the numbers -70007FFF and FFF8002. D< said the negative number was not less than the positive number because -70007FFF (or 8FFF8001) minus FFF8002 gives 7FFFFFFF, which is positive. However, if we add 1 to the first number making it -70007FFE, the D- gives an answer of 80000000, and D< correctly says that yes, the first number is indeed less than the second. My own replacement (as a secondary, since I didn't use it often enough to warrant a primitive at the time), was:

What I have in my '816 Forth is:
BPL dult1 above is like a BPLlong to POP3_FALSE.

With a quick look, I did not find D< in my FIG-Forth book, but be careful.

Hopefully I copied all the code correctly. Although my '816 Forth was never finished to the point of being ready to publish, I am not aware of any bugs in it, and Wally Daniels used it for awhile in his work in the Pratt & Whitney turbine-engine plant in Nova Scotia.

_________________
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 Garth. It's maybe worth emphasizing that D< (and the latter portion of your post) are concerned with signed comparisons, as opposed to unsigned.

I like how this uses CMP rather than SBC to begin the subtraction -- no SEC is needed. (BTW the same approach could be used in your first example, U<. In other words set it up as a double-precision operation, and omit the superfluous BNE $1.)

-- Jeff

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

U/ BUG
U/ is the name used by FIG Forth for the integer division routine, known as UM/MOD in some other Forths. In this page of the 6502.org Source Code Repository Garth shows why some versions (including FIG) are improperly coded and can yield incorrect results. He lists several versions, new and old; for FIG you'd want to switch to the version 3/4 of the way down the page, "Corrected Forth UM/MOD primitive."

VLIST and ?STACK
The topic Firing up a FIG-Forth mentions two quirks. ?STACK fails to issue the Empty Stack ("Msg #0") when expected -- it tolerates a one-item underflow before alerting the user. The cause and fix are here. Also, some people notice that VLIST prints the last ASCII character of each name with bit 7 set. As discussed later in this thread, this minor issue really isn't a bug. It only occurs when the character-out routine you've installed fails to mask off bit 7 as required in the Fig spec.

Disk I/O
The FIG disk routines aren't broken but they sure can be dizzying to learn, partly due to an excess of words named B/ whatever -- where the B slash might mean either Byte, Block, or Buffer. Later in the same topic Firing up a FIG-Forth whartung remarks, "It's all quite confusing, I don't think they're consistent in their usage" and, a few posts later, offers some clarification of the terms. Also a reminder: after power-up but before you attempt to LOAD any Forth source you need to execute EMPTY-BUFFERS or else the result will be nonsensical/hilarious.

Running FIG in Native Mode on 65816
Few will be affected by this quirk. Zero-page,X and Zero-page,Y address modes on 65xx CPU's can usually be relied upon to wrap around, meaning that they always produce an address in Zero-page. FIG Forth exploits this with tricks such as LDA $FE,X where $FE is intended as a negative displacement; ie, LDA -2,X is intended. But the trick fails if the CPU is 65816 and you've moved the CPU from (default) Emulation Mode to Native Mode. Wraparound doesn't occur, and the trick unexpectedly produces an address in page $01. In the topic Getting started in Forth, Daryl aka 8BIT supplies the fixes necessary for FIG Forth to run on 65816 in Native Mode. (Thanks, Daryl!!) Two of the rewritten code snippets he lists are backward compatible and will also run correctly on earlier 65xx CPUs. But the third fix is trickier and pertains to the stack pointer. The solution listed will only work on 65816.

-- Jeff

Edit: clarify the issue of masking bit-7 on characters to be output

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

Thanks for grabbing these all in to one place.



The solution to the VLIST issue is that properly implemented, EMIT is 7-Bit only, with the 8th set to 0. This is documented, but with modern systems and expectations, I overlooked it. With that change, VLIST works properly.

I suspect there are more points that could be added, so if you notice anything, please speak up.

That's a reasonable solution -- and very easy to implement. It's great for someone just learning... but may be a tad shortsighted for an experienced user.

EMIT handles all characters output to the console, not just the output from VLIST. So, if EMIT masks off bit 7, then you're barred from ever using box-draw or other special, bit7-set characters. An alternative solution is to do the bit7-masking more selectively. It seems ID. would be a good place to do it. VLIST calls ID. which in turn calls EMIT. ID.'s sole purpose is to print the name of a Forth word, and names can't contain bit7-set characters anyway.

cheers

-- Jeff

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

Since you mention it, I seem to remember modifying my 6502 Forth to handle the 8-bit characters in names, as the special characters thus made available, including many Greek characters used in engineering, or even the degree symbol, are important to 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?

Well, that makes the most sense of all! A quirk of Fig Forth is that it uses bit 7 as a last-character marker when storing names in the dictionary. But that's redundant, since the length of the name is also stored. To eliminate this "feature" you'd have to alter name-searching and -scanning words such as (FIND) and TRAVERSE; possibly others..?

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

I should point out that when I say "properly implemented", I meant "properly according to the FIG specification". 7-Bit EMIT is by design for the FIG model. That's why this is not an issue with a compliant FIG implementation.

Now, is it optimal? Hardly, for all the reasons mentioned, especially today. But, Back In The Day(tm), 7-Bit was adequate (ASCII IS a 7-bit character set, after all), and they leveraged that in this specific case.

So, the point is that the 7-Bit EMIT is not just for the VLIST issue, it's by design for FIG. Whether ID. begot 7-Bit EMIT or vice-a-versa, I can't say.

You're right, Will -- the spec (mentioned in the Installation Manual) is for 7-bit. Sorry if I seemed to brush off your point. VLIST isn't broken as long as the spec is followed and EMIT masks off bit 7.

As for improving the spec and allowing 8-bit characters, even in word names, that's not trivially simple, given that we need to be able to TRAVERSE names in both directions. There's no problem when we know the start address of a name and need to find the end -- we just refer to the length byte that prepends the first character of the name. But, as for going the other direction, finding the start (the length byte) is problematic. (Fig dedicates bit 7 for marking the length-byte but we don't have that option.) We'd have to work backwards from the end, testing each byte individually. We stop when we find a byte which, treated as a length byte, "adds up" and correctly takes us to the end (the last character). Unfortunately, it's possible, although unlikely, for a false match to occur. A user could create a word name that contained a character in its midst which happened to equal the length from its own position to the end. Two examples: Ascii BEL is 07h, and mustn't appear 7 characters from the end. Ascii ! is 21h, and mustn't appear 21h characters from the end. Huh! Talk about quirks!! Word names would need to be screened at the time they're created, either to look for specific instances of a hazard or else to enforce blanket policies such as "Names must not contain characters below 20h" and "Names must be 1Fh or less in length."

-- Jeff

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

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

Sorry; I guess I got rambling there, exploring the reasons why there have to be restrictions on the names. But I didn't mean to imply the restrictions are onerous -- you're right; they're easy to accept. Still, when new names are created the compiler could/should check for violations.

J.

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

I have not looked at TRAVERSE, but I did wonder why FIG has both the 8th bit terminator AND a length byte. It didn't make sense to me that it would have both.

I guess it's all there to support NFA and PFA. Those are the only references to TRAVERSE I could find.

This version of the UM/MOD fix is faster and doesn't require a scratchpad byte:

http://6502org.wikidot.com/errata-software-figforth

Garth's version works fine, but rather than just checking the carry at the appropriate place, his version puts the carry in a zero page variable and uses what is, in effect, a 40-bit / 16-bit division routine.

The 65C816 version in Garth's article (in effect, a 48-bit / 16-bit division routine) is much, much simpler by just checking the carry at the appropriate place.

Some Forth's had what I consider an odd feature. I don't know if this was common to all Fig Forths, but 64Forth for the Commodore 64 had a variable, WIDTH . New words would have a count and no more than WIDTH letters in their name. I seem to recall that setting WIDTH to 3 was used to save memory. For example, a word might have a length of 11, but with WIDTH set to 3 only the count of 11 ( with the high bit set ) and the first three characters of that word's name would be saved as part of the header with the last letter's high bit set.
A Forth-83 Standard Forth even had this (mis)-feature. Blazin' Forth for the Commodore 64. At least Blazin' Forth would display something like this using WORDS .

64Forth's VLIST didn't display such names properly.
Although WIDTH was usually set to 31 ( in Blazin' Forth and 64Forth, at least ) it could be set to values other than 31 and 3. One gotcha. WIDTH must never be set to a value less than 1 or greater than 31.
I don't have this "feature" in my Forth because I don't like name collisions ( finding the wrong name ) because the length and first 'WIDTH' letters happen to be the same as in CONTEXT and CONVERT when WIDTH is set to 3.