[Coco] Re: Re: problem with New NitrOS9

Rodney V Hamilton Rodney_Hamilton at GBRonline.com
Mon Jul 5 20:53:23 EDT 2004


In article <40E9B328.8090707 at charter.net>, 
jadonaldson at charter.net says...
>
>Rodney,
>   I used dskini to transfer the first NitrOS9 disk to a 360K DSDD 
>floppy. Then I set JC's
>emulator so that /D0 was the 360K floppy. Then I told it to restart and 
>it almost booted from the
>floppy. What I got was:
>
>KREL Boot Kernel tb.................bkernel P2 t*j
>
>                   NITROS9 BOOT
>                          Failed
>
>So that is progress, but still no cigar.
>
>John Donaldson

This is one scenario I cannot duplicate on my laptop -- it's an olde
IBM Thinkpad 755C.  On early models, including mine, IBM has an odd
hardware mod to the floppy interface wherein they inverted one of
the control signals,  which means programs that do their own floppy
I/O (like the JC/JC emulators) cannot read or write to a real drive
but must instead use disk image files exclusively.  I *can* boot
Linux with the "floppy=thinkpad" option to let me use the floppy,
but the emulator doesn't have any special floppy control support.

In your case, it could just be a head alignment issue if you wrote
the disk on another system (happens to me all the time.)   If it's
a REAL 360K drive, there was a compatibility problem reported which
could apparently be "fixed" by telling the BIOS that the drive was
a 720K instead of a 360K. (see note on Jeff Vavasour's website)

Here's another possibility:  If you're booting the emulator from
a disk in the B: drive instead of a disk image file (which I can't
test, as indicated above,) you will probably need to set BOTH the
D0 and D2 slots to B: (or A: if that's your booting drive) but I
have NO IDEA if this will trick the emulator into reading the
second side of the disk.  If that doesn't work, you should try
using a disk image file instead
probably need to 
The boot sequence looked OK as far as it went, assuming that there
were 121 periods between the "tb" and the "bkernelP2" - as for the
"t*j", I have no clue since the error-in-booting flags do not seem
to be documented, except maybe by reading the source code.  <ick>
Here is what the boot sequence SHOULD have looked like:

KREL Boot Kernel tb.....................\
........................................
........................................\
....................bKernelP2 IOMan Init
 RBF CC3Disk D0 D1 DD SCF CC3IO KeyDrv J\
oyDrv SndDrv WindInt VDGInt Term W W1 W2
 W3 W4 W5 W6 W7 PipeMan Piper Pipe Clock\
 Clock2 i2xo

(deliberately folded at column 40 to avoid line-wrap)

Does this same disk boot successfully on an actual CoCo3?

As I mentioned, I'm using the 720K disk image (with LSN0 patched)
as my D0 disk to boot my 6309 coco3 emulator.  On a real coco3,
you will need to use DMODE to set your descriptors' "dns" values
to match your actual drives.  In my case, D0 is 360K, D1 is a 720K
3.5" (not 5.25") and D2 is a 180K "flippy" from my old SWTPC days.
So for me, it's dns=1 for /DD and /D0, dns=3 for my /D1.  If your
720K drive is a 3.5" like mine, you CAN patch your 720K disks and
image files to use the "dns=1" setting to ignore the double-stepping
that's needed to access a 360K disk in a 5.25" 80trk drive. (for
which you MUST use dns=3)  If you boot from a 360 disk/image, the
descriptors are all set to dns=1, but if you do a 720K boot, they
are *ALL* set to dns=3, hence the need to change things a bit.

{all those who are now totally confused, please raise your hands}
{but please put down those tomatoes first...}  ;^)

Rodney





More information about the Coco mailing list