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

[Brett Heath]

Thanks Robert!

There are still some unclear details however (questions interspersed below).

On 12/19/08, Robert Gault <robert.gault at worldnet.att.net> wrote:
> Brett Heath wrote:

<snip>

> The postamble is $FF $00 $00 $MM $NN indicating that the end of the file
> has been reached $FF0000 and the execution (starting) address is $MMNN
>
Ok, how picky is Basic about the length (in the preamble) and the position of
the post-bytes.

The reason I'm asking is that currently the meta/cross compiler saves files
in sizes that are mutliples of 1K with a zero fill from the end-of-image to the
next 1K boundary. The value currently being stored in the length field reflects
reflects this. So, if I just tack the post-amble on at end-of-image
and zero fill till
the next 1K boundary should I expect that to work or does the post-amble
have to be in the last sector of the file or perhaps even at the end of the
last sector?

It's not that difficult to change things around so it saves only till
the next sector
boundary but I'd just as soon have a few hundred bytes after the image that
are cleared by loading the file (since they're going to be used as soon as
the kernel is extended anyway).

In some ways the 1K boundaries are more "natural" for forth but it's not a
big issue, I just have to know so I can implement it properly.

>>   4. Is there someplace where this is documented so I don't have to
>> pester people
>>       with questions?
>
> Probably lots of places, certainly in the disk chapter of the Unravelled
> series by Spectral Associates.

I didn't see that (probably looking for something else at the time).
There's also
a bit about it in the Disk EDTASM manual but that was less than clear,
and didn't
mention the post-amble at all IIRC.


>>   5. What is the largest executable that can be loaded and run from Basic?
>>        (64k CoCo 2)

> Assuming you are not going to use the trick of moving all code to RAM,
> you can load slightly under 32k. You must leave room in low RAM for the
> Basic OS. Tape only $600-$7FFF, Disk $E00-$7FFF.
> If Basic is to still operate, then room must be left for variables and
> stack space. You would need to CLEAR some space but not much.
> If you are going to use all RAM, then you might put a loader program
> into the text window $400-$5FF, load bytes from tape or disk, move the
> bytes into RAM, and then start the program. That will give you access to
> $600-$FEFF.
> The amount of memory available depends on how much of the ROM code you
> want to use in your programs.

At the moment the kernel disables interrupts (except NMI) by stuffing RTI's in
the ram vectors and turns off the ROMs during init. It then re-enables the ROMs
just before I/O calls (POLCAT, CHAROUT and DSKCON) then shuts them off
again. I haven't yet used the hi ram though.

What I'm contemplating is copying the bare minimum from basic
(Interrupt routines,
Char I/O and DSKCON) and possibly relocating them to an area just below the
hardware page and then putting forth's Block and Terminal buffers and
stacks just
below that. The kernel itself would load strictly below 7FFF, copy what it needs
from the Basic ROMs then move it's buffers and stacks up.

There's some problems with this though. What I've seen of the Basic ROMs
(while single stepping through the char routines) didn't look
relocatable. Different
versions of Basic are going to need different areas moved. Including a position
independent and "generic" version of the necessary Basic routines in the kernel
binary itself would not only bloat the kernel, it would be a blatant copyright
violation.

Ah well, that's a problem for later.

>><snip>
>> Specifically, where are the additional FAT and directory entries
>> stored on the 40 and
>> 80 track disks.
>
> As this is not sanctioned by Tandy for Disk Basic, there is no universal
> format for these larger disks. The few third party DOS that work with
> Basic disks larger than 42 tracks just extend the FAT region on the disk
> in T17S2. There is no change in the directory structure which is still
> T17S3 through T17S18.
> The real problem is the low RAM used by Disk Basic. There is no more
> room in RAM to extend FAT copies, so something has to give. You can't
> work simultaneously with 4 drives.

The f83 RSDOS emulator (for lack of a better term) doesn't use Basics buffers
at all. It allocates additional internal FAT buffers as needed when
new drives are
first acessed (that's a large part of what made it grow from 12K to almost 15K).
Guess I'll have to make them a little larger.

>
>> What other disk sizes/formats are common in the CoCo world and
>> where might I find documantation on their layout?
>
> OS-9 and FLEX. The OS-9 info can be found at
> http://www.rtsi.com/ftparchive.html You will have to search the Internet
> for info on FLEX.

I'm using FLEX's forth assembler (slightly modified) so there's probably not
a burning need to port forth to FLEX right now;-). OS9 is a goal (as well as
a 6309 extension to the assembler) but not till after there's a native CoCo
development environment.


Thanks again Robert.

Brett K. Heath