[Coco] NitrOS9 question

Sat Oct 7 17:10:30 EDT 2017

On Saturday 07 October 2017 16:10:50 Dave Philipsen wrote:

> I don’t know much about vfy but would it notice and fix extra padding
> in an OS9Boot file that did not belong to any of the modules therein?
>
It has an option to split the bootfile back into its component modules, 
and in the case of splitting a boottrack, (you must first run krnl2dir 
to convert track 34 into a true directory entry) it will save the 1st 6 
bytes in front of the first os9 module as a separate file, and anything 
beyond the crc of the last module will be saved out as a separate file.  
Work in an empty scratchable directory to make sure you don't have any 
false alarms as I don't recall the name I gave the 6 byte header.

I never gave a consideration to this scenario, so I believe w/o the -s 
option it will just read from the end of the last module in os9 boot 
till eof without any action as its just marching fwd one byte at a time 
looking for the $87CD of the next module header. With only the -v 
option, it should not affect the existing os9boot file other than fixing 
any bad parities or crc's.  If you also give it a module name, it will 
only fix that module.  See the help screen it spits out when you do not 
give it any arguments. Adjusting a modules memory size is done by adding 
the hex value to the existing value, and throwing away the carry if 
there is one, which is a roundabout way to effect a reduction in a 
modules memory request. The result then is modulo $10000. Said a 
different way, changing the memory by a $10 byte reduction is done by 
adding $FFE0.

Slightly clearer than the Missouri river used to be 83 years ago. :)

> Dave
>
> > On Oct 7, 2017, at 8:55 AM, Gene Heskett <gheskett at shentel.net> 
wrote:
> >> On Saturday 07 October 2017 07:27:45 Neal Crook wrote:
> >>
> >> That sounds completely reasonable. Memory is allocated based on the
> >> module header declaration.. there's not really any way (or reason)
> >> to look inside the module and determine whether its content is
> >> valid/reasonable  (and no need for you to zero-out the unused
> >> space). In fact you  probably need not change the size of the
> >> bootfile blob at all.. just the header declaration for the last
> >> module. Caveat: assuming you have crc checking turned off (as it is
> >> by default)
> >>
> >> Neal
> >
> > Or you could use my vfy, which will fix the header parity and crc in
> > one swell foop while adjustingthe size of the memory.  Its a swiss
> > army knife about that stuff.
> >
> >>> On 7 Oct 2017 10:52, "Dave Philipsen" <dave at davebiz.com> wrote:
> >>> Ok, I compiled a minimum headless OS9Boot file that should boot
> >>> with a shell on T2 as my terminal.  The size of the bootfile is
> >>> $42F8. When I try to boot with it, as expected,  it fails.  I get
> >>> the banner text from Init and Sysgo.  Interestingly, sometimes
> >>> when it boots I also get a string printed to the screen that says,
> >>> "WHAT?"
> >>>
> >>> Now I use dEd and simply <D>iddle the file length to $4401 and
> >>> manually clear out the extra data to all zeroes. Voila! NitrOS9
> >>> boots and I get the shell prompt on my terminal!  If I diddle it
> >>> one byte shorter to $4400 it will not boot.  So it apparently
> >>> matters only that the length of the file is $4401 or longer.
> >>>
> >>> Another interesting point:  If I diddle the file length of OS9Boot
> >>> even greater to $8000 it still boots but smap reports way less
> >>> system memory. So that tells me that the system memory allocation
> >>> is based upon the size of the OS9Boot file, not its actual
> >>> contents. Apparently no check is made to the contents of the file
> >>> or whether it contains 'non-modulized' data!
> >>>
> >>> Dave
> >
> > Actually in a normal system, system memory is used up by the number
> > of devices each needing a $27 byte long table for each path
> > descriptor. With 2 or more of each style in my boot files, I'm so
> > low on sysram that I've not been able to actually format a floppy in
> > a decade. All I can do is delete everything on it including the boot
> > track if I want to make a new boot.
> >
> >>>> On 10/7/2017 2:48 AM, Neal Crook wrote:
> >>>> My guess is that it will make no difference. If it does,
> >>>> experiment 2 is to
> >>>> pad with 0xff. I await the result with interest.
> >>>>
> >>>> Neal.
> >>>>
> >>>> On 7 Oct 2017 08:04, "Dave Philipsen" <dave at davebiz.com> wrote:
> >>>>
> >>>> That would be an interesting experiment. I’ll see if I can try
> >>>> that this
> >>>>
> >>>>> weekend.
> >>>>>
> >>>>> Dave
> >>>>>
> >>>>> On Oct 6, 2017, at 11:12 PM, Barry Nelson
> >>>>> <barry.nelson at amobiledevice.
> >>>>>
> >>>>> com> wrote:
> >>>>>> What happens if you just pad the end of the OS9Boot file with
> >>>>>> zeros?
> >>>>>>
> >>>>>> --
> >>>>>> Coco mailing list
> >>>>>> Coco at maltedmedia.com
> >>>>>> https://pairlist5.pair.net/mailman/listinfo/coco
> >>>>>
> >>>>> --
> >>>>> Coco mailing list
> >>>>> Coco at maltedmedia.com
> >>>>> https://pairlist5.pair.net/mailman/listinfo/coco
> >>>
> >>> --
> >>> Coco mailing list
> >>> Coco at maltedmedia.com
> >>> https://pairlist5.pair.net/mailman/listinfo/coco
> >
> > Cheers, Gene Heskett
> > --
> > "There are four boxes to be used in defense of liberty:
> > soap, ballot, jury, and ammo. Please use in that order."
> > -Ed Howdershelt (Author)
> > Genes Web page <http://geneslinuxbox.net:6309/gene>
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > https://pairlist5.pair.net/mailman/listinfo/coco

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>