[Coco] Nitros Partitioning Was: CoCo SDC and others

[Brett Gordon]

Nitros is awesomely flexible unto itself.  It needs a little help with
sharing the hd though.

Gene: how about lsn 1?  MBR likes the last half (or so) of that sector.  My
ccpt and taylor's partitioning want all of sector 0.  The last half of
sector zero is not really helpful.

We dont have to make nitros read and apply the table.  Lets just add an
offset to each sector access in the fpga's sd driver.  We'll trick nitros
into beleiving sector 256 is actually sector 0 :)  This platform will
greatly benefit from this change.  And its such a bloody simple change. I
can/will do the work and sumbit the work to Tormod.  he, justly so, takes
heed of the list's input, so lets have a good discussion about it!

I'm not asking nitros to actually read, write, or apply the table to it's
descriptors.  Thats a bigger project, as boisy's superdriver could be used
to apply this.   Or the boot/init code could call a module to noodle with
wps/ofs of matching descriptors.

"OSes of the CoCo Unite!  Throw off the chains of os9 oppression!  Let the
people seize control of their own equipment.  Let there be partitioning!"
- Comrade Tyranous, the Red ( blue, and green) Leader of the People.

;)  cheers!

brett
On Mar 8, 2017 7:38 AM, "Gene Heskett" <gheskett at shentel.net> wrote:

On Wednesday 08 March 2017 01:34:04 Brett Gordon wrote:

> On Mar 7, 2017 7:52 PM, "Ron Klein" <ron at kdomain.org> wrote:
> > If you decide to use YA-DOS with the CoCo3FPGA, you will need to
> > flash it to the same bank that you use for Brett's NitrOS9 SD
> > loader.  That flash slot on the CoCo3FPGA is reserved for alternate
> > DOS's and can accommodate 16K roms like YA-DOS.  I'm not sure how
> > the NitrOS9 SD boot loader works, but perhaps we can see if Brett is
> > able to incorporate that boot loader into YA-DOS for those using a
> > CoCo3FPGA.
>
> Yeah, the ROM-able nitros boot loader will have to be replaced with
> ya-dos.  But no worries: There's a decb loadable .bin file in the
> nitros9 repo that'll load up nitros too.  I think invoking 'make' just
> right will pop out a .dsk file.  Just get that image copied over.
> Yados can copy the dsk from DW to the SD card.
>
> Nitros has no partitioning.  That needs to change.  Maybe we can just
> hack a offset into Gary's nitros drivers, and force nitros to skip a
> few sectors to allow for a real partition table.
>
> brett

Yes it does Brett, and it works just fine. So let me step up to the
podium and preach a bit here.

One of my HD's is setup for an os9 allocation/partition of just under 500
megs starting at LSN0. By inserting a sector offset that starts with the
next sector above that which is in DD.SIZ in LSN0, and some trickery
involving the dmode stp setting, this is how we do the 256 virtual 35
track SS floppies on the next 80 some megabytes after the end of the os9
allocation.  My /sh descriptor is setup to do exactly that. stp is byte
wide, so setting its number to anything, $00 to $FF is one of the 256 of
these virtual floppies.

Not enough? copy the sh.dd file to si.dd, use ded to change its name to
si internally, and adjust the offset in ofs and wpc to point at the next
startng sector after the end of those 256 vdisks, and do it again.
Wash, rinse & repeat for a third set of 256 vdisks named /sj, /sk, /sl
etc. Since that is a 1Gb drive, if I was so inclined, I could do it
several more times before I was out of drive, but I'd be totally out of
system ram long before I was out of drive.

As for an LSN0 based partition table I don't recall a thing that makes
use of anything past offset $6F, so there is no reason we couldn't
implement that 5 bytes at a time in this unused space, for a partition
table, 3 for offset, 2 for size exactly as laid out in the first $20
bytes of lsn0 now. One could allocate one more byte per partition for
the cluster size, thereby eliminating the nominally 131 megabyte limit
per partition so added.

It could be done, using a mount command that looked up the proper offset
from that table, and installed it in just one descriptor, maybe 2 if you
wanted to do a partition to partition copy without using the base
partition as a scratchpad buffer.  That would certainly save some system
ram by getting rid of those data tables in memory, at IIRC, $27 bytes a
path descriptor in the boot file. That would require this new mount
command needing 2 arguments, the descriptor to modify, and the partition
to set it to.

Regardless of how its done, present way, or by looking it up in LSN0, we
have an ability to do partitioning just by taking advantage of what we
have right now.

The problem? It's differing individual setups because no 2 of us have
identical drive setups. Except for a vanishingly slim chance at the
fests, we'll never have identical setups on adjacent tables.

But drivewire removes that limitation by putting the differences in the
descriptor being accessed.

I would investigate, for purposes of moving stuff around at the fests,
the probability of setting up a central drivewire server, and with a 10
meter usb extension cable such as I use, so my drivewire setup is
actually a usb-2 circuit, and if DW can make use of 2 different ports, I
don't know that it can, one could publish his latest whiz-bang package
to everyone in the room in 45 minutes of carrying the cable from machine
to machine. If DW could be convinced to sit there and wait for the cable
to be plugged into the next machine without a complicated kill and
restart as the cable was moved to the next machine, that would be cut to
15 minutes.

Or, if DW will run on the debian jessie installed on an r-pi3, and mount
the r-pi on a 6 volt jel-cell, it could be carried from table to table
and short cables used, negating the need for that $40 10 meter extension
cable, just a good usb to coco drivewire cable 4 or 5 feet long.
Drivewire works just fine over usb in the middle of its cabling useing
a /dev/ttyUSB# port on this linux box.  My long cable is plugged into a
usb port, on a hub this box drives, the far end of that cable is plugged
into a 7 port hub on the coco3's desk, and a usb to drivewire cable is
plugged into that 7 port.

The coco3's printer can also be plugged into this same hub, and has been
up until we had the basement work late done last spring. But since that
printers other main job is keeping the LinuxCNC configuration listings
on my machines up to date, I moved it up to here so I don't have to
coerce these ancient legs down and back up a flight of stairs to get a
fresh printout. That has been quite handy, and when I bring my coco3
back to life, I may just go get another of these brother $110 black and
white laser printers and put it on the top shelf of the coco3's desk
where this one lived for several years. It will be just another printer
to cups in the localhost:631/printers display. And the coco is pleased
either way as its a 19 page a minute printer, and the typeface can be
any font loaded. To me, the default is such an improvement in
readability compared to an old DMP thats its beautyfull.

Whats not to like?

Its called making use of the resources we already have in the nitros9
world. I hope this "sermon" is helpfull. ;-)

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