[Coco] strange nitros9 boot error code, very quickly after loading the boot track I get a tb*v, error 246 not ready
gene heskett
gheskett at wdtv.com
Wed Nov 24 11:35:52 EST 2010
On Wednesday, November 24, 2010 09:51:04 am Robert Gault did opine:
> gene heskett wrote:
> ><snip>
> >
> > Then run ded /dd@ and look at DD.BT at offset $15, which contains 1E
> > F6 9B. No change needed.
> >
> > And that is indeed the 87cd of krn2 if I look at it with ded /sh@ and
> > go to sector $0B
> >
> > Next? What else can I show? Here is the directory of that 128th disk
> > as shown by dir -e /sh
> >
> > Directory of /sh 23:19:19
> >
> > Owner Last modified Attributes Sector Bytecount Name
> > ----- ------------- ---------- ------ --------- ----------
> >
> > 0 00/11/22 1948 ------wr A 7F52 OS9Boot
> > 0 00/02/24 1535 --e-rewr 8B 1FF sysgo
> > 0 00/11/22 1948 d-ewrewr 8E 80 CMDS
> > 0 00/11/22 1948 d-ewrewr D7 60 SYS
> >
> > That sysgo is no doubt wrong, but if it stays on the hard drive its
> > 100% who cares.
>
> The only thing you need on the boot drive is OS9Boot. You could delete
> sysgo, cmds, and sys.
>
> > Do I need to also update the size in /dd's DD.BSZ?
>
> Well, you can definitely find OS9Boot from OS-9 even though it is on
> "drive128", now that you have told OS-9 where to look. Just make sure
> your Boot module tries to get this information from LSN0 in the normal
> fashion.
>
> Also your Boot module needs to know how many sectors to read past
> $1EF69B to get the full OS9Boot file into memory. DD.BSZ in LSN0 has
> that info as the size in bytes of OS9Boot. It also sets an upper limit
> on the size of OS9Boot at $FFFF. DD.BSZ is at $18-$19, just after
> DD.BT.
>
> As long as your Boot module reads the hard drive rather than a floppy,
> you should be set. One last thing. If you want to use Cobbler or OS9gen
> to create a new OS9Boot file, you will need a method for correctly
> pointing DD.BT and DD.BSZ to the new OS9Boot file.
> If you don't want to use Disk Basic at all, then you will need to make
> some choices. 1) Will the boot disk always reside in drive 128?
> 2) Do you want the option of alternate boots by having several drives
> carrying different OS9Boot files? If needed, you could have custom Init
> and Sysgo modules with different names (Init1, Init2, etc.) pointing to
> different directories on the main OS-9 drive.
> 3) How do you want to manipulate your OS-9 boot drive?
> 4) How do you want to change LSN0 to point correctly to your current
> OS9Boot file?
>
> I would not advise using dEd to do this manually unless you intend never
> to change the boot drive number and rarely alter the contents of
> OS9Boot. If you rarely or never use Disk Basic, then you should write
> an OS-9 program to simplify the process of updating DD.BT and DD.BSZ.
> The program should ask you for the boot drive number, calculate the LSN
> starting value of OS9Boot, determine the length in bytes of OS9Boot,
> and alter DD.BT and DD.BSZ. But there is a gotcha here!
> You will have problems reading beyond the end of the OS-9 drive. dEd
> will not read beyond the last OS-9 sector on your drive nor will any
> other program that uses the default driver for the hard drive. You
> would need a special driver and descriptor that would enable setting a
> drive# with Dmode, and then correctly adding a sector offset to all LSN
> values while accessing the boot drive. Looks like you have done this
> with /sh.
>
> On my systems, I chose to install a second driver with descriptors that
> held the drive number in stepping (stp); an option not used on a hard
> drive.
That is how /sh works, using stp for the drive number, in this case $80=128
> Then I can Cobbler or OS9gen my /vh0 drive, or just normally
> read/write to it from OS-9. I can also use Dmode to change stp, the
> boot drive number. I do use LINK.BAS but could now easily use dEd
> because a dir -e /vh0 gives me the sector and byte count of OS9Boot on
> my boot drive.
> Having direct access to the boot drive gets rid of the need to use a
> floppy and then back it up to the hard drive boot drivelette.
>
This is good to know as I have not attempted to run scripts/mb.genes
against /sh, the format step bothers me.
I figured out how to run link.bas (more docs would help, as would having the
docs, disk label and disk all match, they do not. My hdbdos disk carries
an HDBDOS-1.1 label, but a dir0 shows it as HDBDOS-1A. The docs call for
link12.bas or link3.bas, but the disk only has link.bas. So I ran if after
figuring out I had to enclose the name in dbl-quotes, and gave it the 128
argument when it asked. It churned half a second or a little more and
reported success, but a dump of lsn0 remains the same, with dd.bt pointing
at the actual sector os9boot starts on, and dd.bsz which I had already set
to the length of that os9boot file, also unchanged, so it either didn't do
it, or I did it right with ded.
Then I modified my mb.genes script to leave bttemp so I could look at that,
its fine and contains the boot module I specified, boot_tc3.
Now, here is what I think is the aha! clue. If I boot from the floppy, I
get a screen clear to a white 80 column screen the instant it loads track
34. The rest of the boot continues on that screen until such time as sysgo
runs and executes the startup file, and that reverts to a 32 or 40 column
green screen at that point, although my startup creates 3 other 80 column
screens.
Big noisy BUT, if I boot from 128, it reads the HD furiously for at least
enough sectors to have loaded the os9boot file, but it does it on the native
green screen while counting rapidly to something over 30 on this green
screen and eventually, not instantly as the floppy boot does, switches to
the white 80 column screen with the os9boot string in the middle, outputs
"KREL boot tb*v" and then prints "failed" under the "os9boot" at center
screen. That tells me that boot_tc3 is not using the correct screen type.
Both the sysgo's on /dd & /d0, and the 'init' in the os9boot file are set
for /dd if inspected by a dump. When I boot from the floppy, it loads
os9boot, the init module points at /dd and all further boot activity
proceeds from the hard drive, as desired.
Do I need to ded(it) something in boot_tc3 to make its screentype the same
as the boot_floppy which works?
The term is term_win80.dt and CoWin.dr is used and CoVDG is also used. The
term in the bootfile has the same crc as term_win80, both on a working floppy
disk, and in the os9boot being created. I am also working from the 3.2.9
issue of nitros9, dated about Feb 2010.
I was going to make some printouts from vfy so I could compare the working
floppy boot to the one that doesn't but the > redirection is creating a zero
length file. Then I recalled that vfy used stderr for its screen output, so
>> works.
The line in mb.genes that creates the boot track (bttemp) is:
merge ../MODULES/BOOTTRACK/rel_80 ../MODULES/BOOTTRACK/boot_tc3
../MODULES/BOOTTRACK/krn>bttemp
(linewrapped by kmail, and note rel_80, not rel_32)
And I have written bttemp to /d0 as a normal file, so:
{t2|07}/DD/NITROS9/3.2.9:vfy /d0/bttemp
Length of file: $00001200
Module found at offset $00000006 in this file
Header for : REL
Header parity : $D7 (good)
Module size : $012A
Edition : $05
Ty/La At/Rv : $C1 $85
System module, 6809 object, Re-enterable, R/O
Exec. off : $002B
Data Size : $0000
Module CRC is : $7DC4E0 (good)
Module found at offset $00000130 in this file
Header for : Boot
Header parity : $2B (good)
Module size : $01D0
Edition : $01
Ty/La At/Rv : $C1 $83
System module, 6809 object, Re-enterable, R/O
Exec. off : $0012
Data Size : $0013
Module CRC is : $D8B8E3 (good)
Module found at offset $00000300 in this file
Header for : Krn
Header parity : $22 (good)
Module size : $0EDD
Edition : $13
Ty/La At/Rv : $C0 $89
System module, Data, Re-enterable, R/O
Top of free ram $009100, IRQ poll table entries $00, Device table entries
$4B
Module CRC is : $FB6F1B (good)
Bytes read : $00001200
Then {t2|07}/DD/NITROS9/3.2.9/MODULES/BOOTTRACK:vfy rel_80
Length of file: $00000130
Module found at offset $00000006 in this file
Header for : REL
Header parity : $D7 (good)
Module size : $012A
Edition : $05
Ty/La At/Rv : $C1 $85
System module, 6809 object, Re-enterable, R/O
Exec. off : $002B
Data Size : $0000
Module CRC is : $7DC4E0 (good)
and {t2|07}/DD/NITROS9/3.2.9/MODULES/BOOTTRACK:vfy boot_tc3
Length of file: $000001D0
Module found at offset $00000000 in this file
Header for : Boot
Header parity : $2B (good)
Module size : $01D0
Edition : $01
Ty/La At/Rv : $C1 $83
System module, 6809 object, Re-enterable, R/O
Exec. off : $0012
Data Size : $0013
Module CRC is : $D8B8E3 (good)
So thats the same. As is krn. No clues there.
Here is a short dump of /dd@
{t2|07}/DD/NITROS9/3.2.9:dump /dd@
Address 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 2 4 6 8 A C E
-------- ---- ---- ---- ---- ---- ---- ---- ---- ----------------
00000000 1DBB 9028 EDDD 0004 0000 EF00 00FF DF79 .;.(m]....o..._y
00000010 0100 2800 001E F69B 7F52 6509 0B09 0448 ..(...v..Re....H
the 1EF69B 7F52 is correct
Humm, rel_80 is acting like rel_32...
And:
{t2|07}/DD/NITROS9/6309L2/MODULES/BOOTTRACK:vfy rel_80
Length of file: $00000130
Module found at offset $00000006 in this file
Header for : REL
Header parity : $D7 (good)
Module size : $012A
Edition : $05
Ty/La At/Rv : $C1 $85
System module, 6809 object, Re-enterable, R/O
Exec. off : $002B
Data Size : $0000
Module CRC is : $36D3AE (good)
Bytes read : $00000130
That is NOT the same module!
So I made another disk using this rel_80 module, same exact story.
Using 'reboot' to restart it and selecting '1' for the HD boot, it counts
to 33 while reading the hard drive, then switches to the white 80 column
screen, outputs "KREL boot tb*v" and fails.
The only thing I can come up with now is an off by 1 in /dd/dd.bt. But that
will wait till next week sometime as we are heading to Orlando for a family
wedding this weekend.
In the meantime, if dd.siz in /dd's lsn0 is $1DBB90, and the offset in the
/sh descriptor is also $1DBB90, with stp=80, is $1EF69B the correct address
for the start of the os9boot file at offset $0B in /sh? These are base 0
systems, so /dd ends at $1DBB8F and the virtual floppies then should start
at $1DBB90, right? I have one of those exedrin headaches...
> --
> 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)
I cannot draw a cart, nor eat dried oats; If it be man's work I will do it.
More information about the Coco
mailing list