[Coco] [CoCo] bootlink, SH, NitrOS-9 info needed
David Ladd
davidwladd at gmail.com
Fri Sep 8 17:08:48 EDT 2017
Gene,
Thank you for getting back with me. I did some looking through the
makefile for the modules folder and saw that for the IDE stuff there is a
ih.dd being created. Thank you for pointing that out. As this stuff I
never had back when I had the B&B MFM. I always had to create a new 35
track single sided floppy disk and make it bootable and then back it up
into one of the RGBDOS virtual drives and then run link on it.
I must have missed seeing the HDBDOS options in the makefile the last time
I looked or I need new glasses. :P
Thanks for pointing out this stuff. :D
+-----------------------------------------------------------------------+
| David Ladd a.k.a. PacoOtaktay a.k.a. Drencor |
| YouTube: http://www.youtube.com/user/PacoOtaktay |
| YouTube Gaming Live: https://gaming.youtube.com/user/PacoOtaktay/live |
| Websites: http://dwladd.com & http://www.theterrorzone.com |
| G+: https://plus.google.com/113262444659438038657 |
| G+: https://plus.google.com/+DavidLaddPacoOtaktay |
| |
| Do you have your CoCo 3 yet? |
+-----------------------------------------------------------------------+
On Fri, Sep 8, 2017 at 5:34 AM, Gene Heskett <gheskett at shentel.net> wrote:
> On Friday 08 September 2017 01:45:46 Gene Heskett wrote:
>
> > On Friday 08 September 2017 00:11:41 David Ladd wrote:
> > > Gene Heskett,
> > >
> > > I am asking this if you still remember off hand or anyone else whom
> > > has used the /SH descriptor for accessing the HDBDOS vdisk #'s from
> > > within NitrOS-9.
> > >
> > > I was reading your documentation Gene for bootlink and see that
> > > using this SH descriptor for what ever superdrive HDD interface you
> > > are using you can access your virtual HDBDOS drive's. What I would
> > > like to know is where does one find this SH driver or build it?
> > >
> > > I have been browsing the NitrOS-9 repo looking for a reference to
> > > this SH descriptor and didn't see one other than listed in your
> > > documentation. Just wanted to know if this is still a valid option
> > > in current NitrOS-9 and RBSuper or no?
> > >
> > > Thanks :D
> >
> > Sure is, or was the last time I pulled and built nitros9. About 18
> > months back now.
> >
> > Let me see if I can describe the requirements to use it. Starting with
> > the superdesc.asm, you'll need to set the descriptor option that
> > splits the 512 byte sector into a low half and high half of 256 bytes
> > each, so that you can make use of every byte of the 512 byte disk
> > sector.
> >
> > This, when a disk read is done, hands os9 the low half of the sector
> > if the sector address is an even number, and the high half of the
> > sector if the address is odd.
> >
> > Next, get the hard drives lsn0, first 3 bytes, which is the hex
> > representation of the size of the portion of the disk which is
> > allocated to os9's use. Call it a partition if you'd like because
> > thats what it is.
> >
> > Add 1 to that hex value and break it into 2 pieces to be written to
> > the sh descriptors ofs and wpc positions in the descriptor. What you
> > just did was to give that descriptor the starting address of the first
> > byte of the first 35 track floppy image, in the first bank of 256 disk
> > images usable by hdb-dos and basic. There's another bit in the /sh
> > descriptor that enables the "stp" value to set the disk images offset
> > so that all 256 disk image locations can be used from one descriptor,
> > just change the stp with dmode and you are looking at a new disk
> > image. This won't work for hd to hd copies, you'll need two
> > descriptors for that since the stp does not take effect until os9 has
> > had a chance to reread lsn0 and update its drive tables. That never
> > gets a chance to be done while doing a copy.
> >
> > This scheme can be repeated by setting up an additional descriptor and
> > adding 35*18*256 to the value placed in /sh for the initial 3 byte
> > sector offset to establish the start of the 2nd bank in /si, step &
> > repeat for /sj, /sk etc until the hard drive has been fully allocated.
> >
> > There are several other ways to make use of the basic /sh skeleton, I
> > have even, before I had drivewire working, located where I had put an
> > install .dsk image on the hard drive using a serial cable and rzsz,
> > took its address from the file descriptor, and pointed /sh at the
> > image, and actually installed it from where that file was sitting just
> > as if it was a floppy image, except it was much faster since it was
> > being accessed at the hard drives speed.
> >
> > One huge, HUGE caveat! Once you have first of all these descriptors
> > configured, make a new directory someplace safe (marked real floppy?)
> > and save all those descriptors as you get them figured out, because
> > all this data is going to be unique to your system. And recovering it
> > if its lost is going to be a 9 digit excedrin headache.
> >
> > This means you will need to write a script so that anytime you make a
> > new build, you can copy all those descriptors back over the top of the
> > ones just built else you will be reinventing several different sized
> > wheels before you are up and running on the new install. I usually do
> > that while the install image is mounted by drivewire.
> >
> > And I've no doubt left out some vital details, so use superdesc.asm as
> > the final word. Unfortunately its too terse and concise and will need
> > several reads. Or it sure did for me. But as I come up on 83 next
> > month, I find myself pleading oldtimers way too often. :)
> >
> > It can be complex until the lights come on but don't give up.
> >
> And I missed that your question was asking about a driver. Its not a
> driver, but a pair of descriptors, one for the scsi_tc3 systems, and a
> duplicate functionwise, for the ide using systems. Because the drivers
> and descriptors have been broken up so much in order to save some
> bootfile memory, we now have a 4 name chain for each descriptor. doing
> an os9dump of one of the two:
>
>
> Addr 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 87cd 0041 002b f189 a700 2d00 30ff ffff .M.A.+q.'.-.0...
> 00000010 7416 0100 0081 0800 2301 0100 1200 1203 t.......#.......
> 00000020 0800 0000 0000 0000 0037 0253 c852 42c6 .........7.SHRBF
> 00000030 7262 7375 7065 f26c 6c74 63b3 0000 e450 rbsuperlltc3..dP
> 00000040 51 Q
>
> Shows the device name, SH, with the msb of the H set to mark the end of
> the descriptors name, followed by RBF with the msb of the F set for the
> same reason, then the main drivers name rbsuper with the last r's msb
> set, and finally the hardware adapter, lltc3 that translates the rbsuper
> connands to the actual hardware that does the work, in this case
> lltc3 "low level tc3", which for an ide system would have been llide.
>
> Neither of these two descriptors exist in the src tree until the Makefile
> actually assembles "sh_tc3.dd" or "ih_ide.dd", and you choose one or the
> other to use as the RBF foundation of your disk system by selecting it
> from the bootlist when you do an "mb"
>
> All this modularization moves more data into "sysram", at least doubling
> the sysram useage per device descriptor and my machine is now out of
> sysram to the point that I don't have enough left to format a floppy.
> There are other ways to empty a disk, but they are a right pain in the
> ass. They do work, but it can be a bunch of putzing around. All
> compounded into that right pain in the ass by the fact that os9gen, if
> it finds track 34 pre-allocated, does a skip of writing a new boottrack,
> skipping it silently without a report of any kind to alert the user that
> his boottrack did NOT get updated. Grrr. So you have to make it
> visible by creating a directory entry to it along with an fd.sector just
> so it can be deleted, clearing those 18 bits in the FAT. KRNL_2_DIR
> does that, get it from my web page.
>
> But this should explain why you cannot find them in the repo pull until
> you have built the pull.
>
> Does this help explain things?
>
> > Cheers David, 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>
>
>
> 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