[Coco] NitrOS9 question

[Dave Philipsen]

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?

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