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

[Michael Furman]

Please have a look at http://www.ocs.net/~n6il/bindecode.c (apologise  
for there being no comments) as an example.  This program will display  
all of the information contained in the record headers of .bin files.

Further comments inline:

On Dec 19, 2008, at 5:41 AM, Robert Gault wrote:

> Brett Heath wrote:
>>
>>  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.

  This is indeed documented in Disk-Basic Unravelled under "Machine  
Language File Input/Output" on page 17.

>
>>  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.

 From playing with the gcc6809 port I have some additional  
information.  Since I am creating disk images and then LOADM'ing the  
BIN files onto the system I had to play around with the program  
segments (text, bss, data, etc) quite a bit to keep from writing on  
top of basic variables.  I had issues with both causing problems to  
DECB and DECB causing problems to my program.  Here's what I wound up  
with that seems to keep me out of trouble (These are options being  
given to ASLINK to tell it where the segments are going)

options="-b .text=0x2000 -b .data=0x7000 -b .bss=0x7C00 - 
b .ctors=0x7F40 -b .dtors=0x7F80 -b vector=0x7FC0"

I found that writing anything below $2000 is trouble - DECB has a lot  
of variables and buffers stored before the VDG display buffer.  At one  
time the BSS segment was loading on top of the DECB buffers causing  
the loaded program to corrupt itself.  I used $1800 for a while and  
ran into some trouble with that, I don't remember what it was offhand.

On the other end the basic roms spend some amount of time to find the  
end of ram.  On a 32/64k system TOPRAM ($0074) is $7FFE. It seems to  
place the stack around $7F35 and works its way down towards $7F00 (and  
farther if a complex basic program is run), so I had to move segments  
out of this range of memory as well.  You will note that I stuck the  
infrequently used ctors, dtors and vector segments (used for things  
like stdio initialization and  atexit(3)) after the stack, knowing  
that this could be dangerous and I might have to move them again in  
the future.

In general anything between $2000 and $7EFF is very safe.    This is  
around 24k of usable space.  You can still do LOADM and EXEC as well  
as most simple BASIC commands without any trouble.