I got a 6502 Forth metacompiler from a supplier in about 1990 for a work project,
the last set of automated test equipment I did at the company I was working for. The metacompiler supplier started with fig-Forth and modified it to be Forth-83, but did not fix the division and multiplication bugs and had some others (whether original or not I do not know) like the D< which had an underflow bug. The metacompiler itself which ran on a PC had some serious bugs which showed up exponentially more and more as the size of my code grew as I added more functions and developed the project. It was leaving out whole random lines of code, and picking through the Intel Hex file output was my only way to troubleshoot it. I had to manually write lines of code as data bytes in the source code to get it to put those in. What a pain. It resembled sink holes more than pot holes. I mentioned this in an article I had published in the Forth Dimensions magazine (May/Jun '94), and even though I didn't mention the supplier's name, I guess they thought it was obvious enough who it was from the fact that no one else was supplying a 6502 Forth metacompiler, and they very suddenly quit selling it.
Since I wanted the high-level Forth interrupt support, without overhead, I started working on that right from the beginning of the project. They, among others, said it couldn't be done. After I did it, I got it published in the Jul/Aug '94 issue of Forth Dimensions and it got a very good reception. It is also
here on this site.
I added a lot of functions, some being from ANS. I want to publish it, but I need to convert it to an assembly source (so you don't need the metacompiler), and I need to re-write the few portions left that came from this supplier's conversion of fig-Forth to Forth-83 so they can't claim any copyright infringement. There are still things that should be made more efficient too, like the fact that they made branch and 0branch to be relative which requires the additional step of adding the 16-bit offset to the current address before the jump.
When I wrote my '816 Forth assembly source code basically from scratch soon after, I made it mostly Forth-83, with additions from common usage, and from ANS, and from the books "Starting Forth" and "Thinking Forth," and from my own experience.
Since all of this was to have Forth in ROM, and I didn't even use a ROM emulator, then before the kernel itself was working, it took a lot of ROM erasing and re-programming. It wasn't too bad as the next EPROM from the UV eraser was ready every four minutes which gave just enough time to figure out what to change in the code to try next and let the fast PC's assembler or metacompiler run. My debugging technique is basically what I have written up in the
debugging page of the 6502 primer. It gets better after the kernels were working so they could do their own compiling into RAM and give the instant turnaround time you come to expect from Forth. That lets you develop additions much more quickly and have them bug-free before putting them in ROM.
I never did make a comprehensive list of the differences between fig-Forth and Forth 83, but ones that come to mind are the floored division (which never seemed to be an issue for me), VLIST versus WORDS, how strings are put on the stack (sometimes counted, sometimes not), and I think there are differences in how disc access is handled. You'll probably want to check me on all of this. My HP-71 Forth ROM module has (more or less) Forth-79 but with 20-bit words, and although the differences are minor, I do like the '83 more.
I did not have a full user interface in mind for either of these 65xx Forth systems, as my focus in not on desktop computing but on embedded and workbench, but rather, I used the PC for its monitor, keyboard, disc drives, and full-featured programmer's text editor in the development of programs used on the target computers. Screen files are something I used only in the early work with the metacompiler. I can see why they were used back when computers were far less powerful and disc drives were much smaller and slower, but I found them extremely limiting, and I converted to all text files for source code after that. The 65xx computers boot up with Forth in ROM and can do their own compilation and assembly of applications, but from ASCII source code coming over the RS-232 line from the PC. I would eventually like to completely cut their dependence on the PC though.
One of the big projects I want to do when I get another slowdown in my work is to finish these up for publication on my website.