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

[Brett Heath]

On 12/19/08, Michael Furman <n6il at ocs.net> wrote:
> 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.

Thanks for the reference.

<snip>
>  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"

At the moment f83 isn't using seperate segments. It can be reorganized
to fit into a segmented model but that' a fair amount of work and until it
becomes necessary (ie when I tackle OS9 compatibility) that stays on
the back burner.

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

The current test platform is a VCC2 .pak file that's loaded starting
at $1200 (hex).
as recommended for use under EDTASM DOS. This has worked well so far
since the only thing Basic is used for is DSKCON and the char I/O rom calls.


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

Basic doesn't even get a stack, f83 generously let's the ROM routines
borrow it's stack when it needs to do I/O. Other than that the ROMs are
disabled (this may have to change tho).

Thanks for the info

Brett K. Heath