[Coco] f83 for the 6809 -- It'a Alive!

[Brett Heath]

Hello All

I've been away for a couple of years but some may remember that i
occasionally made noises about a port of Laxen & Perry's f83 to the CoCo.

A few weeks ago I noticed that I once again had the necessary tools
(and the time!) to
resurrect the project. After som debugging  the f83 kernel is running
on Jeff Vavasour's CoCo 2 emulator under dosemu at one of my linux
consoles.

I haven't torture tested all the components yet, but the interpreter,
compiler, and defining
words all work which in itself is a pretty thorough test of the rest
of the dictionary (The exception being some of the more obscure logic
and math ops).

I'm currently working on the Disk I/O, which is the last component of
a complete kernel that
can then load all the goodies included in the full f83 distribution
(Assembler, Block editor, Multitasker, Decompiler, Forth debugger,
Memory dump, etc...).

Which brings me to why I rejoined the list now. f83 was different from
most other small forth systems available at the time in that while it
used the forth standard 1k sequential blocks for disk I/O it kept them
in files managed by the local DOS rather than writing them directly to
a
directoryless disk as most of it's contemporaries did.

The unravelled books and various other documentation have given me
what I need to design
a low-level interface that will work. The problem is I have never
owned a floppy interface for my CoCo's (a I and a II). Don't get me
wrong, I have few qualms about using the emulator with a downloaded
copy of the disk rom for testing (Microsoft owes me dammit), but the
fact that I have no familiarity with BDOS means it's gonna be pure
reverse engineering. A bit of insight from people familiar with the
tools would undoubtedly improve the design.

So here's my initial question.

At first blush it looks like there's no simple way to get BDOS to take
care of translating from logical file position to track/granule/sector
from outside of Basic. Which means I'm gonna have to read and parse
the directory (and probably the FAT) to keep track of where things
are. If this is the case, there doesn't seem to be much point in going
through Basic at all beyond the simple functions provided by DSKCON,
since I'll have to maintain my own copies of most things anyway, and
it's a Bad Idea to have two unrelated pieces of software running at
the same time when they both think they're in charge of a particular
piece of storage space, particularly directory and FAT storage space.

Is this right or didi I miss something(s)

If the above is a fair assesment, then there are undoubtedly some
subtleties in the way BDOS
handles the directory that I will have to address if I want f83
generated files to be readable by
Basic (particularly the full f83 executable). Any well known gotchas
to tell me about before
I start reading modifying and writing directories and FAT's. I'ts all
gonna be on virtual copies of
virtual disks of course so everythings recoverable, but any hints
which come to mind would be appreciated.

For those who are interested, my development system is f83 running
under dosemu in a terminal. As configured now it compiles the source
into a disk file in .pak format which is then
loaded into Vavasour's CoCo 2 emulator running on a console session of
dosemu in the same dos directory (gad I Love Linux!) for testing.  The
kernel runs in a footprint of just under 12k plus disk and stack
buffers. The full f83 will have a footprint of around 24k.

This is a straight port of f83, but it has been modified to be
position independent and I've added
functions to the metacompiler which allow it to compile directly to
disk rather than to a memory image which must then be saved.

One last question, has anybody managed to get the Keil emulator
running under dosemu?

Brett K. Heath