[Coco] ASM newbie question

[Gene Heskett]

On Sunday 14 February 2010, Tim Fadden wrote:
>On 2/14/2010 3:44 PM, Gene Heskett wrote:
>> On Sunday 14 February 2010, Tim Fadden wrote:
>>> Hi,
>>>
>>> I am trying to assemble a program called cron_vE.asm.  On my first try
>>> it failed because it couldn't find  /dd/defs/os39defs.
>>
>> That is my code, and yes it depends on a 6309 aware defsfile.  The
>> changes I made to the defsfile weren't done so as to be automatically
>> adapting between the cpu differences.  It has been made to do so for many
>> versions of nitros9 now.
>>
>> Today that can probably be changed to just os9defs, IF the file and the
>> make are properly configured such that at assembly time the environment
>> variable passed to mamou has the symbol H6309 set equ 1.
>>
>> OTOH, and its been yonks since I walked around in that code, I imagine
>> that if you do not have a 6309 in your coco, it can be made to assemble
>> for a 6809 with only a little work.
>>
>>> I assumed it was a typo, and changed it to os9defs.
>>>
>>> No I get---    Error: Symbol Table Full.
>>>
>>> This program has a script to merge the crontab-datammodule to the exe so
>>> that it can get its info from memory, instead of from disk.
>>
>> Yes, that was a later addition.  Having it access the floppy to see if it
>> has anything to do this exact minute was a bit of a drag and wear on the
>> floppy of course.  The disadvantage of course it that to edit the
>> 'crontab', it was a total rebuild.
>
>Well, I do have a 6309 installed , but using 6809 build.  With the defs
>that come with the nitros build.
>Perhaps I will put the 6309 defs on there with the name os39defs, and
>see what happens.

I don't believe the same cpu switching incantations are in that as I used in 
my 6309defs.  But its probably worth the try, the error messages will be 
educational I think.

>Seems  everybody has gone the linux, off platform build route, and
>forgotten us who still do it all on the original hardware. :-)
>
>I am compiling  this on my coco.
>
>I do have cron working to do nightly incremental backups with hdback to
>a drivewire image.  So, being able to compile
>cron is not essential, just trying to give it a go.
>
>Also, why would cron have to be re=compiled every time the datamod is
>changed?  couldn't the same one be used, and just merge a different
>datamod to it?

Probably easily done, but then its a reboot to install it if its part of the 
bootfile.  I have used it both ways, and separate from the bootfile is 
probably more sensible.  That just needs enough unlinking to knock it out of 
memory, and then run the new version.

>Perhaps I am doing some thing wrong.
>
>The script compiles the cron program, and then merges the cron program
>and the datamod and puts it in /dd/cmds.
>never mentions compiling the datamod in there any where.  So...
>Im thinking the cron program never changes any way right.  If you did an
>ident on the merged cron/datamod you would get two.
>seperate things the cron program and then the datamod.

This is correct.

>You caould always use the saame cron, and then merge whatever datamod
>you wanted.  This make sense?

Yes, you are on the right page.

>I think the script should not be mucking with cron, but compiling the
>datamod, and then  merging the two.  Eh?

If you already have a separately compiled cron.  In your case, rather than 
rebuilding cron each time, I would use my utility 'vfy' with the -s (split a 
merged file into its pieces) by renaming the merged module to something else 
like crondat so that the cron in it won't be there to be over-written when 
vfy splits it.  Then you can rename that cron module slightly, like to 
cron.exe, then re-merge that renamed cron and your new datamod, all into one 
package called cron, and then just run cron & from a shell.

We have 2 utilities for combining files, in addition to merge, you can always 
use 'cp file1 file2 outfile' IIRC.  That was a well written utility too.

>I'll do some testing and see if thats so.  Don't really have much asm
>experience, and that was a long time ago.  Just gettin back into it.

The biggest prob I have with assembly is that I'm typically taking someone 
else's code apart to fix or expand on it, and it takes me way too long to get 
my head into the exact coding style of the original author when the dis I 
start with has no comments, so you go through it, figuring out what its doing 
and add your own comments.  OTOH, I'm now 75, so maybe that's to be expected. 
;-)

>Thanks for the input.
>
>I'll let you know what I find out.
>
>Tim
>
>>> The archive already had an assembled cron_ve that works, so I can most
>>> likely get it working OK.  But would like to be able to assemble it
>>> myself. I can asm the datamodule just fine, but having problems with the
>>> exe file.  I don't mind working it out myself, but a few
>>> pointer-directions would be great!
>>> Im running Nitros9L2-6809, 030209
>>>
>>>
>>> Thanks,
>>>
>>> Tim
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>
>--
>Coco mailing list
>Coco at maltedmedia.com
>http://five.pairlist.net/mailman/listinfo/coco
>


-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

In specifications, Murphy's Law supersedes Ohm's.