[Coco] Nitros Partitioning Was: CoCo SDC and others

[Bill Pierce]

Brett, I think I get where you are coming from. You want a way ANY OS (not just Nitros9) can ID what partitions are present on a drive... I.E. YaDos can know where OS9 partitions start and end or where RSDOS partitions start and end.
To me, changing LSN0 would be disasterous. Too many utilities and system modules would need to be rewritten, many of which no sources exist to make changes easy. But as Gene said, there is space not being used in LSN0, so why not an ID byte (denoting the OS of current partition), and an offset to the next partition?
OS9 would rely on it's descriptor info to get to the proper partitions and RSDOS/YaDOS could step through the offsets until the ID is found, then store the offset value.

Also, I think others are getting confused thinking this is referring to NitrOS9 itself, and on all systems, when it is mainly referring to the SD card access on the Coco3FPGA (though it could apply to other systems if implemented right).

 

 


Bill Pierce
"Charlie stole the handle, and the train it won't stop going, no way to slow down!" - Ian Anderson - Jethro Tull

 

My Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page
Global Moderator for TRS-80/Tandy Color Computer Forums
http://www.tandycoco.com/forum/

E-Mail: ooogalapasooo at aol.com


 

 

-----Original Message-----
From: Brett Gordon <beretta42 at gmail.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Wed, Mar 8, 2017 11:46 am
Subject: Re: [Coco] Nitros Partitioning Was: CoCo SDC and others

Yup,  maybe an even lighter weight approach would be to (at build time) setthe wps/ofs of /dd and friends to something other than zero...for thecocoFpga build.brettOn Mar 8, 2017 11:22 AM, "Tim Fadden" <t.fadden at cox.net> wrote:> On 3/8/2017 8:56 AM, Brett Gordon wrote:>>> 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>>>> I don't get the comment about sharing the HD.>> Superdriver already does partitioning.  Any space on the drive left> partitioned can be used by whatever. and you can put the os9 partitions> where ever you would like to.>>> --> Tim Fadden> "Hey Schmidt, don't forget about the six P's.> Proper Preparation Prevents Piss-Poor Performance!">>> --> Coco mailing list> Coco at maltedmedia.com> https://pairlist5.pair.net/mailman/listinfo/coco>-- Coco mailing listCoco at maltedmedia.comhttps://pairlist5.pair.net/mailman/listinfo/coco