[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