[Coco] NitrOS9 question

Dave Philipsen dave at davebiz.com
Sat Oct 7 18:05:13 EDT 2017


Very interesting. I don't know if it really makes a difference or not 
but as Barry mentioned, I am using Brett's boot loader and it loads 
OS9Boot first and the CCBKrn separately.  Here's what my module 
directory looks like when I boot with the $4401 length boot file (actual 
boot file length is $42F8 and then expanded using dEd):

    Module Directory at 16:56:25

Block Offset Size Typ Rev Attr  Use Module Name
----- ------ ---- --- --- ---- ---- ------------
    1    B00   D41  C0   0 r...    1 KrnP2
    1   1841   91A  C1   5 r...    1 IOMan
    1   215B    6B  C0   0 r...    2 Init
    1   21C6  12EE  D1   3 r...   15 RBF
    1   34B4   37A  E1   0 r...   15 RBSuper
    1   382E   2D4  21   0 r...    1 LLCoCo3FPGA
    1   3B02    48  F1   9 r...   15 DD
    1   3B4A    49  F1   9 r...    0 SD1
    1   3B93   77C  D1   0 r...    4 SCF
    1   430F   502  E1   2 r...    4 SC6551
    1   4811    3F  F1   0 r...    4 Term
    1   4850   253  D1   0 r...    0 PipeMan
    1   4AA3    28  E1   0 r...    0 Piper
    1   4ACB    26  F1   0 r...    0 Pipe
    1   4AF1   207  C1   5 r...    1 Clock
    1   4CF8   100  21   0 r...    1 Clock2
    1   5000   EDF  C0   9 r...    0 CCBKrn
    4      0   2ED  11   1 r...    1 MDir

As you can see, I had moved the clock modules down to the end as David 
Ladd requested but this made no difference.

Dave


On 10/7/2017 4:34 PM, Neal Crook wrote:
> I looked back through my notes and I found:
>
> bootfile failed for me when it was $3d0e bytes
> when I expanded it by adding shell, it worked and was $5af0 bytes. I
> experimented with including/excluding sysgo and found that this made no
> difference
>
> that's consistent with Dave's experience that the bootfile must be >$4401
> bytes in size.
>
> My theory is that it has nothing to do with the boot file itself or with
> the order of modules in the bootfile but instead that it has to do with how
> the first piece of memory is assigned after the (modules of the) bootfile
> have run.
>
> I spent several evenings with the emulator trying to trace through the
> startup and figure out what was going on, without success. At the time I
> had little understanding of the kernel data structures; I might fare better
> if I tried again now having read Kevin Darling's book.
>
> Also, at the time I assumed this was a bug associated with my port.
>
> Dave's padding experiment suggests a debug approach to use in emulation:
>
> * create 2 boot images: one with a too-small bootfile and the other with a
> padded bootfile
> * start each in turn and grab an instruction trace
> * look at where the instruction traces differ
> * from the trace differences, infer the cause.
>
> Neal.
>
> On 7 October 2017 at 22:10, Gene Heskett <gheskett at shentel.net> wrote:
>
>> 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>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> https://pairlist5.pair.net/mailman/listinfo/coco
>>



More information about the Coco mailing list