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

[N8WQ]

Hi Brett,
How is your F83 project coming?
I got up early this week and was reading up on the history of Forth.
Charles Moore was an ingenious programmer.
A couple of years ago I was interested in writing my own version of 
Forth for the CoCo but got sidetracked.
If there is something I can do to help please let me know.

Alan Jones

-- 
N8WQ - Canal Winchester, Ohio
http://exwn8jef.googlepages.com/home
http://n8wq.blogspot.com



Brett Heath wrote:
> 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
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>