[Coco] CoCo SDC and others

[Gene Heskett]

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>