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

[N8WQ]

Hi Brett,
What is the "f83" you keep talking about?

Alan Jones

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



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