[Coco] CoCo f83 -- Questions on .bin file format and disk layout for non SSSD disks.

[Brett Heath]

Hello all,

Before begging for help here's an update on the status of f83 for the CoCo.

In the process of researching CRC implementations it became clear that the
CRC was designed to detect relatively small differences between almost identical
data blocks and is therefore probably not reliable as a fingerprint to
distinguish
blocks that are completely different. In other words, FAT's are short enough and
probably similar enought that a CRC could probably be used to distinguish them
but the potential variability in the corresponding (and somewhat longer)
directory tracks is so large as to make CRC's unreliable at best and in general
worse than useless as an identification hash.

So after translating the forth CRC code to 6809 assembler I set it aside and
took a break from slogging through the DOS emulation and spent some time working
on fun stuff.

Fun stuff in this case includes:
   Converting the kernel source from the Chromium assembler
   to the Flex assembler.
   Adapting WORDS and the VOCABULARY management to work with the
   position independent dictionary.
   Getting the Flex assembler to load (this was almost trivial).
   Modifying the Multitasker for the CoCo (the DOS-CP/M version relies on
   software restarts)
   Rewriting the Debugger low-level (this was non-trivial).

The Multitasker is untested  but everything else is working, coolest
of all are the
debugger and the assembler.

Which brings me back to the DOS stuff.

The nice thing about using an assembler and metacompiler written in
forth for forth
is that I can generate any ouput format I care to implement.

The not so nice thing is that it doesn't automatically know what output format
is appropriate for an executable .bin file that will load from Disk Basic.

By examining the first few bytes in other .bin files and playing around with
the options on VCC2's import utilities I've come up with;

00 <size> <load-adr>

for the first five bytes, but this didn't seem to work and it's apparent
from the conversation in the Assembler thread that it's more complicated
than that.

The Assembler thread gave me some more hints, but there are still some
murky spots.

  1. Can a large (~16k) executable  be put in a single segment .bin file?
  2. If not what are the size restrictions and format requirements for
each segment?
  3. If so, what's the format of the postamble (and preamble for that matter)?
  4. Is there someplace where this is documented so I don't have to
pester people
      with questions?
  5. What is the largest executable that can be loaded and run from Basic?
       (64k CoCo 2)
I would actually prefer to finish development without relying on the
disk system beyond
using it to test my file interface, but until I can get a serial
interface working on an
emulator I'm stuck with it.

There are drivers available for either the bit-banger or an ACIA that
would be easy to
incorporate into f83 as a replacement for disk I/O but the bit-banger
in both VCC2 and
xmess are apparently only usable as printers. Is there ACIA emulation in xmess?
Can it be attached to a virtual or physical serial port?

Yeah, I've asked this before but serial I/O from an emulator would
_really_ help a lot.


As to the other questions mentioned in the subject line. Playing
around with the fun
stuff had the side benefit of testing the file-read implementation. It
seems reliable but
 the performance could be better, probably due to the rather mindless
logical record
to physical sector conversion calculation. In any case, before
rewriting that and
cleaning up the open-file management it would be nice to know something about
the layout of disk sizes other than the 35 track 18 sector/track default so f83
can deal with them too.

Specifically, where are the additional FAT and directory entries
stored on the 40 and
80 track disks. What other disk sizes/formats are common in the CoCo world and
where might I find documantation on their layout?

For my own purposes I'm targeting a CoCo tethered to another system
through a serial
port, but as long as I'm porting the thing I'd like to make it useful
for as many Coconuts
as possible, so the more disk formats it knows how to handle the better.


My Internet connection is a bit on the flakey side right now so if I
don't acknowledge
replies right away please bear with me (this is it's first day back up
since December 2).

Brett K. Heath