Disk emulation in RAM is non-functional due to some obscure bug. RAM上のディスクエミュレーションは、不透明なバグのため、未だ不能です。
(Obscure because I can't find it.) （不透明と、ボクには未だ見つかりません。）
If you want a Forth that works on 6809, look at BIF-6809 (in the repositories): もし6809で動く Forth の方が良いなら、（レポジトリ内の） BIF-6809 を試みて下さい。 https://osdn.net/projects/bif-6809/
If you want to help me debug this conversion, I'd be happy for the help.
もし、これの移植途中の文のデバグを助けていただけるなら、よろしくお願いします。
At the end of 2018/beginning of 2019, I did some brute-force translating of the fig Forth model for the 6800 to the 6809. The results are in this repository, under several branches.
hand-translated
This branch contains the code, fig-forth_6809.asm, where I attempted to hand-translate the 6800 source and got bogged down in over-reach. That's a bad habit I have.
The source also contains some RAM disk screens from work I was doing on the 6800 version.
search-and-replace
This branch contains the results of using a text editor to search-and-replace the instructions that change. It also got bogged down. There is also a perl script, socialize6809.pl, which edits the source code of the model to be more sociable by converting the string arguments to a more standard form accepted by more assemblers. I settled on using lwtools, but some of the others I tried rejected the older count, comma, string argument for FCC.
auto
This branch contains the results of automatic conversion using a tool I wrote in perl, 6800to6809.pl, to blindly translate individual 6800 opcodes to individual 6809 opcode equivalents, or, in the cases of ABA and SBA and such, two.
In other words, one
INX
becomes one
LEAX 1,X
So it's rather inefficient and really offensive to read.
That result of the conversion is the file named fig6800to6809dumb.asm, and I think I got it to boot to the OK prompt on a CoCo emulator after making sure the differences between the 6800 stack (post-decrement push) and 6809 stack (pre-decrement push) were handled. XROAR was the emulater I used.
Then I got my hands into the results of the auto-conversion, doing such things as collecting sequences of "LEAX 1,X" into single LEAX, using auto-inc and auto-dec where appropriate and such, and allocating more of the VM machine registers to 6809 registers, but refraining from further attempts at optimization. The results of that are in the file fig-forth_6809.asm.
The disk image file figd6809.dsk, was used for transferring the object to the emulator.
auto-hand-optimized-offline
I really don't remember what all happened in here. Anyway, there are several parallel scratch conversions occurring at the same time, which is why there are
auto-hand-optimized-offline
fig-forth-auto6809halfopt.asm
fig-forth-auto6809opt.asm
in addition to the fig-forth_6809.asm source from the auto branch.
At some point I started doing a parallel conversion where one
version used the jmp back to the VM on leaf calls, and the other used
RTS leafs. That source is in fig-forth-auto6809opt.asm.
I think I like RTS leaf calls
because it should be more possible to mix code with subroutine leaf
calls with code from, say, compiled from C source. Theoretically. Maybe.
But the inner interpreter is still there, it just calls with a JSR
instead of a JMP. And you have to have the VM to activate if calling
from C object to Forth object.
auto-hand-optimized-detour
This all got mired down in bugs that showed up when trying to use the disk, and turned out to be there from back from some earlier point, in both the RTS and JMP NEXT versions.
The JMP NEXT version is in the file named fig-forth-auto6809.asm.
Another part of what was happening here was an attempt to use
"real" disk images instead of the assembled-in RAM disk emulation. I think that is what is in the file figao.asm.
Consider this branch a branch full of mini-branches.
auto-hand-optimized
When I hit the wall with the bugs, I reverted to this branch.
Then I got sidetracked checking the emulation on the 6800 model, then I ran out of time.
I'm not sure why the disk images ended up in the junkpile, instead of the dev directory.
My commit comments seem to say I cleared the disk emulation problems, but I don't think so.
Unless my memory is bad, there's an outstanding bug in the code to move data between the disk buffers and the RAM disk area, and I think the bug is a sign bug. In my attempts to debug, something keeps walking on something where the debug code can't catch it.
If not for this bug, I would have merged this branch with the HEAD branch and done a release.
It needs a slow walk-through from the beginning by someone who has time to spend a week or two on it.
If you are interested, git clone the repository, then git checkout the branch that looks most interesting.
Fork