Re: Rainbow Disk Imager

[Warner Losh via cctalk]

On Fri, Sep 15, 2017 at 1:47 AM, Christian Corti via cctalk <
cctalk@classiccmp.org> wrote:

> On Thu, 14 Sep 2017, Warner Losh wrote:
>
>> On Thu, Sep 14, 2017 at 4:05 PM, Fred Cisin  wrote:
>>
>>> On the IBM PC/AT (5170) with 1.2M, admittedly the only one that is easily
>>> readily available, there is trivial software tweaking required to
>>> format/write "720K"/"quad" density, instead of "high" density: 300 bps
>>> with
>>> single speed (360RPM) drive; 300 RPM/low density for dual speed drive.
>>>
>>
> No. But I don't know what you mean with software tewaking.
>
> You need hardware tweaks as well to make the drives compatible.  Otherwise
>> the recording strength is too high.
>>
>
> No. Guess why there's the /HD input on the 5ź" drive...


The problem is that while that basically works with older drives, it
doesn't work with newer drives. There were several discussions in the
Rainbow community back in the day about how this drive or that drive didn't
write compatible enough RX-50s.


>
> The problem is people try to write RX-50 media with the HD drives. The
>> difference in recording strength causes many of the retention issues. It
>> works better when you write with the IBM drive with HD media.  This may
>> also be drive specific, as the different drive makers have had different
>> levels of competence with the old standards...
>>
>
> No. The floppy controller switches the recording density (and thus the
> write current) with the /HD line on pin 2 of the 34 pin Shugart bus.
>

It's supposed to be. It isn't always. As someone who helped others with
this problem, I know that doesn't always work. I lost my email from this
time in a disk crash years ago, or I'd name the brands / versions that were
problematic.

Warner

Re: Interlace/interleave, skew, side pattern (Was: Rainbow Disk Imager

[Paul Koning via cctalk]

> On Sep 14, 2017, at 10:44 PM, Fred Cisin via cctalk  
> wrote:
> 
> ...
> Alternatively, you could leave the sectors in sequential order, but not put 
> each data block of the file into the sector of the same number.
> Thus, you could put the first data block of the file into the first sector, 
> but put the second data block of the file into the third sector, and the 
> third data block of the file into the fifth sector.
> Again, if the time to read one sector is not long enough to process the 
> incoming data, then you could skip two sectors before the next data block.

An example of that is the DOS-11 DECtape layout (which was also adopted by 
RSTS).  It has the blocks in a linked list, and the next block allocator starts 
looking for a free block 4 blocks beyond the current last block.  So, give or 
take fragmentation, you get 4:1 software interleave.  The block numbers are 
still physical numbers.

> ...

There's one other oddity I know of that shows up in the (PDP11/VAX) RX50 
format, which is the non-standard track numbering.  The first track (the one 
with logical sector 0) is physical track 1.  But instead of skipping physical 
track 0 entirely, that track corresponds to logical track 79 (the last 10 
sectors).  I'm guessing that it started out with a desire to avoid physical 
track 0, but then someone decided not to waste 10 sectors.  But I never saw a 
real explanation, and the optimization reasons that justify interleave and skew 
clearly don't apply.

paul

Re: Rainbow Disk Imager

[Harry via cctalk]

On 14/09/2017 17:02, Rod Smallwood via cctalk wrote:

Hi

  I have a bunch of .dsk RT11 400k image files I need to write to 
RX50 disks so I can boot from them on my 11/73


Somewhere there is a utility that will write the images to RX50 on a 
DEC Rainbow 100 under MS-DOS . Anybody know where to find it?


Rod



 Rod,phew!!Are you any  wiser about making the disks for the 
11/73 !! your question has stirred up everything except a direct 
answer?   Chuck has highlighted the same way I have made many disks 
using imagedisk  but not yet for my 11/73,   I guess once I find a rt11 
image to download, I will give it ago myself and see if the disk I make 
will boot the 11/73?  How are you proceeding if at all?


Harry

Re: Rainbow Disk Imager

[Christian Corti via cctalk]

On Thu, 14 Sep 2017, Warner Losh wrote:

On Thu, Sep 14, 2017 at 4:05 PM, Fred Cisin  wrote:

On the IBM PC/AT (5170) with 1.2M, admittedly the only one that is easily
readily available, there is trivial software tweaking required to
format/write "720K"/"quad" density, instead of "high" density: 300 bps with
single speed (360RPM) drive; 300 RPM/low density for dual speed drive.


No. But I don't know what you mean with software tewaking.


You need hardware tweaks as well to make the drives compatible.  Otherwise
the recording strength is too high.


No. Guess why there's the /HD input on the 5¼" drive...


The problem is people try to write RX-50 media with the HD drives. The
difference in recording strength causes many of the retention issues. It
works better when you write with the IBM drive with HD media.  This may
also be drive specific, as the different drive makers have had different
levels of competence with the old standards...


No. The floppy controller switches the recording density (and thus the 
write current) with the /HD line on pin 2 of the 34 pin Shugart bus.


Christian

Re: Rainbow Disk Imager

[CuriousMarc via cctalk]

What Chuck says. +1 on ImageDisk. 
I also tried OmniDisk which allows you to do just about anything with the 
formats, including a lot of wrong things. I found it much more difficult to 
use, but it taught me quite a few things.
I made 3 videos on YouTube about it, mostly to remember what I did, this was 
all new to me:
https://www.youtube.com/playlist?list=PL-_93BVApb58SkNrwTjOFJJIZobCLzhzQ
On the 3rd one I go through the process to recreate an HP LIF disk from an 
image using ImageDisk. Easy peasy. I have no merit on this, the author of 
ImageDisk gets all the credits for a great utility.
Marc


On Sep 14, 2017, at 8:21 PM, Chuck Guzis via cctalk  
wrote:

Good grief!

All this discussion--about what amounts to a straightforward task.

Get a PC with a 1.2M 5.25" drive and some DD floppies.

Make sure it boots to MS-DOS, not Windows.

Grab a copy of Dave Dunfield's ImageDisk. (on the classiccmp server, if
memory serves).

Use it read and make images of your source disks.

Then use it to write as many copy as you want from the images.

ImageDisk does a "read ID" on each track to get the exact sector
ordering and skew.

Easy peasy--hardly worth more than one or two posts.

(And yes, I've used it to copy RX50 floppies for a customer and they
were very happy with the result.  I think it was for an Air Force
teaching setup using VAXen.One advantage was that I could tell them
just to drop me an email if they needed more, as I had the images.)

--Chuck

Re: Rainbow Disk Imager

[Chuck Guzis via cctalk]

Good grief!

All this discussion--about what amounts to a straightforward task.

Get a PC with a 1.2M 5.25" drive and some DD floppies.

Make sure it boots to MS-DOS, not Windows.

Grab a copy of Dave Dunfield's ImageDisk. (on the classiccmp server, if
memory serves).

Use it read and make images of your source disks.

Then use it to write as many copy as you want from the images.

ImageDisk does a "read ID" on each track to get the exact sector
ordering and skew.

Easy peasy--hardly worth more than one or two posts.

(And yes, I've used it to copy RX50 floppies for a customer and they
were very happy with the result.  I think it was for an Air Force
teaching setup using VAXen.One advantage was that I could tell them
just to drop me an email if they needed more, as I had the images.)

--Chuck

Interlace/interleave, skew, side pattern (Was: Rainbow Disk Imager

[Fred Cisin via cctalk]

On Thu, 14 Sep 2017, Eric Christopherson via cctalk wrote:

Does interlace mean the same as interleave?


Usually.

But, each manufacturer develops their own terminology, so one thing can 
have different names in different companies, or different things can have 
the same name. For example, MS-DOS and 400K Mac have some similarities in 
their directory structure, including 2 copies of a linked list of 12 bit 
pointers starting in the second sector, (In MS-DOS, that is called the 
"File Allocation Table".  What is it called on a Mac?) followed by an 
array of data structures that contain filename and the number of the 
location on disk of the first data block of the file.
Q: With all of the possible data structures for a disk directory, why did 
they end up with ones almost identical?
No, I do not think that it was because of obvious advantages over all 
other possible structure.




INTERLACE/INTERLEAVE
When multiple sectors are read from a file and "put away", if you can 
process them quickly enough, then all of the sectors can be read in one 
revolution.   But, what happens if the first sector is not completely 
processed before the disk rotation gets to the next sector?  It will have 
to goallthe way around again to get to it.  It's going to take one 
revolution per sector.

But, if you were to rearrange the sectors, instead of
1 2 3 4 5 6 7 8 9
instead arranging them as
1 6 2 7 3 8 4 9 5,
then you could read a sctor, and have the duration of the next sector to 
process it.  If THAT is enough time, then you can read all of the sectors 
in two revolutions.
If THAT is not enough time, then you could put two other sectors between 
the first and second, and read all of them in three revolutions.  It's a 
lot longer than reading them all in one revolution, but a whole bunch 
quicker than taking one revolution per sector.


That is called "interlace" or "interleave".

Alternatively, you could leave the sectors in sequential order, but not 
put each data block of the file into the sector of the same number.
Thus, you could put the first data block of the file into the first 
sector, but put the second data block of the file into the third sector, 
and the third data block of the file into the fifth sector.
Again, if the time to read one sector is not long enough to process the 
incoming data, then you could skip two sectors before the next data block.


When you are analyzing an unfamiliar disk format, if you find that the 
sectors are not placed on the disk in sequential order, then you 
presumably have a physical interleave, and you just need to read the 
sectors in their sequential order, ignoring what sequence they physically 
are on the diskette.


If the sectors on the diskette are in sequential order, then either you 
have 1:1, or you may have a logical interleave.  You need to look at 
sequential sectors and see whether the content seems to make sense in that 
order.  Text files or source code are the easiest, of course.  Look at the 
start and end of each sector, and see if you see "half a worm" - the first 
or last part of a word, and whether you can find the other half of it in 
another sector.  With enough samples, you can determine the sequence.


System tracks and data tracks might not be the same interleave, sometimes 
not even the same number of sectors or density!


On double sided diskettes, the interleave is USUALLY the same on both 
sides, but not always, and sometimes you will encounter an interleave that 
uses a sector on one side followed by a sector on the other side, back and 
forth.



SKEW
It takes time to move from one cylinder to the next.  Accordingly, after 
you read the last sector on one track, you might not be ready to read the 
first sector of the next track in time.  Rearranging the sectors so that 
the first sector of the next track is not physically the first one can 
help with that.  Of course, that means that the last sector of that track 
will no longer be the physically last one, so the next track will need to 
be changed, either further, or in some cases back to the previous 
sequence.


That is called "skew".


SIDE PATTERN
On a single sided disk, it makes sense that the tracks would be used in 
sequential order.  There are a few rare exceptions, particularly on 
some of the formats where the directory is on a track in the middle of the 
disk.


It is much faster to switch sides, than it is to move to a different 
cylinder.  Accordingly, it is efficient to use the sector on one track, 
and then change sides, and follow with the sectors on the other side.
In some cases, each of those is considered to be a track.  In some other 
cases, the sectors of both sides of the cylinder are considered together 
to be one long track.  That often doesn't matter in data recovery, but 
becomes apparent if the interleave switches sides between sectors.  Or, if 
the sector numbers on the second side don't restart, but are numbers 
continuing the count from the first side.  Of 

Re: Rainbow Disk Imager

[Warner Losh via cctalk]

On Thu, Sep 14, 2017 at 6:51 PM, Eric Christopherson via cctalk <
cctalk@classiccmp.org> wrote:

> On Thu, Sep 14, 2017, Paul Koning via cctalk wrote:
> >
> > > On Sep 14, 2017, at 4:39 PM, Warner Losh  wrote:
> > >
> > > ...
> > > I don't see where you read the first 2 tracks uninterlaced, and the
> other tracks interlaced?  For DOS formatted disks, that's what's required.
> While screwing up the first two tracks won't affect your ability to read
> DOS floppies (since they were reserved for the boot blocks), other formats
> aren't so forgiving and it makes the disk unbootable...
> >
> > The question was about RX50 disks, which are uniformly interlaced and
> skewed.
> >
> >   paul
> >
>
> Does interlace mean the same as interleave?
>

Yes. I've heard both terms describe the same thing.

Warner

Re: Rainbow Disk Imager

[Eric Christopherson via cctalk]

On Thu, Sep 14, 2017, Paul Koning via cctalk wrote:
> 
> > On Sep 14, 2017, at 4:39 PM, Warner Losh  wrote:
> > 
> > ...
> > I don't see where you read the first 2 tracks uninterlaced, and the other 
> > tracks interlaced?  For DOS formatted disks, that's what's required. While 
> > screwing up the first two tracks won't affect your ability to read DOS 
> > floppies (since they were reserved for the boot blocks), other formats 
> > aren't so forgiving and it makes the disk unbootable...
> 
> The question was about RX50 disks, which are uniformly interlaced and skewed.
> 
>   paul
> 

Does interlace mean the same as interleave?

-- 
Eric Christopherson

Re: Rainbow Disk Imager

[Fred Cisin via cctalk]

On Thu, 14 Sep 2017, jim stephens via cctalk wrote:

have none of the systems Fred posted, or much interest in getting them, so


Here are the ones that I supported in XenoCopy  (NO LONGER AVAILABLE):
http://www.xenosoft.com/fmts.html#720K

A PC/AT with 1.2M is the most readily available hardware, although an XT 
with appropriate drive (55F, 465, TM100-4) added is the easiest to deal 
with, if you plan to continue to deal with them regularly.


--
Grumpy Ol' Fred ci...@xenosoft.com

"720K" floppies in AT (Was: Rainbow Disk Imager

[Fred Cisin via cctalk]

For those who never had to suffer through it, 
in case there isn't sufficient confusion, . . .



The 1.2M drives ran at 360 RPM.
To handle 360K, which would be every other track and ran at 300RPM, some 
could switch speed to 300 RPM, while others relied on the FDC to 
compensate for the speed.


The FDC had to be able to handle 500K bps data transfer rate for 1.2M
(2.8M required 1000K bps)
It also had to do 250K bps for use with 360K drive.
To be able to handle a 360K disk in a 1.2M drive, most, but not all, also 
had a 300K bps data transfer rate for a 360K disk spinning at 360RPM.


To handle a 720K diskette, you need the 96tpi, either by using a 1.2M 
drive, or the more obscure 720K 5.25" drive.
But, in addition to the 96tpi, you also needed to read and write at "360K" 
bit rates.  That could be done either at 300RPM at 250K bps, OR at 360RPM 
at 300K bps.  If you have a "single speed" (360RPM) drive, and an FDC with 
250K/500K bps, but without 300K bps support, then you can't do it.


The simplest is to use a "720K" drive, such as Teac 55F, Shugart 465, 
Tandom TM100-4 (NOT M!).  You can lie to the SETUP and tell the AT CMOS 
that it is a "360K".  Or on later machines, tell the AT that it is a 3.5" 
"720K".
And even simpler, use an XT, instead of an AT, where the FDC is ONLY 250K 
bps.


Diskettes must be 300 Oersted (same as "360K").
HD (600 Oersted) diskettes are absolutely unusable.
"180K" SSDD, "360K" DSDD, and "720K" DSQD diskettes are the same 
formulation.  The difference is whether they have been tested/certified 
for using both sides, and/or all tracks.


At one point in the early days, when diskettes were hideously expensive, 
there might or might not have been manufacturers who sold diskettes that 
passed testing on both sides as "double sided", and sold ones with only 
one good side as "single sided".  But, as production ramped up, the 
price came down and failure rate declined, and it wasn't worth heroic 
efforts for a reputable manufacturer to try to save a diskette that had a 
known bad side.


Nevertheless, DS testing is more through than SS testing, and 96tpi 
testing would be more thorough than 48tpi testing.  With almost total 
falloff of sales of "quad" density, few manufacturers bothered to continue 
SS or 96tpi testing.  So, a "DSQD" diskette is likely to be the same, but 
OLDER than a "360K" diskette.


Again, DO NOT USE "HD" diskettes for anything other than "1.2M" formats.



YMMV


--
Grumpy Ol' Fred ci...@xenosoft.com

Re: Rainbow Disk Imager

[Warner Losh via cctalk]

On Thu, Sep 14, 2017 at 5:15 PM, jim stephens via cctalk <
cctalk@classiccmp.org> wrote:

>
>
> On 9/14/2017 3:51 PM, Warner Losh via cctalk wrote:
>
>> As you might tell from this thread, floppies, reading
>> them, and their formatting stir way too much passion in me (for which if
>> it
>> was too much I apologize)
>>
>> Warner
>>
> Really fantastic timing for what a friend and I are doing.  On the topic
> of your reading, can you or have you shared the images, details?
>

I've shared the images of the Venix disks, as well as a copy of Jeff
Anderson's rbimg program. Though DISKCOPY does a decent job if you don't
need to retry for errors a lot and are going from disk to disk instead of
from disk to file.


> I currently am positioned behind the starting line, having collected on
> spec a mass of all these systems and RX-50s.  And my buddy has a bunch
> too.  Ultimately I want to use these with the PDP11s mostly, and will part
> with spare Rainbows.
>

OK. If you want to image (read) the diskettes, I recommend getting a TEAC
FDC-55GFR or similar drive and using kyroflux (https://www.kryoflux.com/)
to do the deed. That's what I did for my bulk collection of floppies. Other
drives work, as you can see on the kyroflux web site, I did use a variation
of rbimg to read the Venix disks on my rainbow, then kermit them up to my
FreeBSD server...


> I have the 11/73, Microvax, Decmate, Rainbow, and Pros I would like to
> reconstitute media for.  What my friend has for now is not candidate
> material as it needs to be imaged and saved as well, he has very little
> "scratch" media  candidates.
>
> Only "free" media as I posted earlier is third party pre-formatted media,
> and formatting it ourselves on IBM At's then reconstituting it elsewhere.
> I have none of the systems Fred posted, or much interest in getting them,
> so hopefully a path to getting this media type exists w/o more rare or
> oddball systems.
>

I've never had any luck formatting  on the IBM AT or newer 5.25" drives
then reading on the Rainbow. Others apparently have had better luck, but my
luck has been terrible. If you have a running Rainbow and want to use the
media for other DEC gear of that era, you're better off using it to format
the media. You might even be able to use the DISKCOPY program to duplicate
the disks w/o RBIMG (it's good for reading disks to a file on a hard disk).

I've had good luck with old "new stock" from ebay, even the 48TPI stuff.
Avoid the HD media like the plague, it will not work well at all for what
you want to do. I paid like $10 per box of 10 (plus way too much shipping)
for mine and they've worked out OK. 96TPI are better, if you can find them,
but only if they are quad density, not high density. When I was looking,
they were too pricy so I took my chances with the 48TPI ones. It all
depends on what you're objectives are...

Warner

Re: Rainbow Disk Imager

[Fred Cisin via cctalk]

On Thu, 14 Sep 2017, Warner Losh wrote:

Yea. It depends on the controller. WDC765 (or was that a clone of the NEC
uP765)


I'm not sure if their legal people would like it being called a "clone", 
but it was definitely designed to be just like the NEC 765, instead of 
like WD's 179x



and the Intel 8287A

8272[A].  The 8287 was a bus driver/transceiver


and their ilk need these details since they try
to cope with reading and they need some help guessing where the sector
started. For some reason, the older WDC-179x chips didn't care, but on
those chips to format a track you had to send it the sequence of bytes
which would ultimately make it onto the drive (so there was no format track
command, just a write track command).


But, the loss of a "read track" on the 765 took away some capabilites.



The speed improvement is quite noticeable. It was 2-3x faster with the
interleave for a mostly sequential work loads, and the skew that venix did
added about a 20% improvement on top of that. Random workloads sucked no
matter what you did :(


There were also issues of how much processing the software tried to do 
between sectors.  Different programs could get best advantage with 
different interlace and skew.



I have run into quite a few badly maintained drives.  The innermost
(higher numbered) tracks are the most sensitive to problems.



Yes. I had the most errors on those tracks when I was reading my big box of
floppies back. My wife thought I was crazy for doing that... I'm not sure
she was wrong :) As you might tell from this thread, floppies, reading
them, and their formatting stir way too much passion in me (for which if it
was too much I apologize)


It dominated my life for a few decades.

Wasn't that the MOST IMPORTANT aspect of microcomputers?

--
Grumpy Ol' Fred ci...@xenosoft.com

Re: Rainbow Disk Imager

[jim stephens via cctalk]

On 9/14/2017 3:51 PM, Warner Losh via cctalk wrote:

As you might tell from this thread, floppies, reading
them, and their formatting stir way too much passion in me (for which if it
was too much I apologize)

Warner
Really fantastic timing for what a friend and I are doing.  On the topic 
of your reading, can you or have you shared the images, details?


I currently am positioned behind the starting line, having collected on 
spec a mass of all these systems and RX-50s.  And my buddy has a bunch 
too.  Ultimately I want to use these with the PDP11s mostly, and will 
part with spare Rainbows.


I have the 11/73, Microvax, Decmate, Rainbow, and Pros I would like to 
reconstitute media for.  What my friend has for now is not candidate 
material as it needs to be imaged and saved as well, he has very little 
"scratch" media  candidates.


Only "free" media as I posted earlier is third party pre-formatted 
media, and formatting it ourselves on IBM At's then reconstituting it 
elsewhere.  I have none of the systems Fred posted, or much interest in 
getting them, so hopefully a path to getting this media type exists w/o 
more rare or oddball systems.


Very much appreciate your and the other posters (can name Fred and Paul, 
as well as Rod for asking) for the information.

thanks
jim

Re: Rainbow Disk Imager

[Fred Cisin via cctalk]

  I have a bunch of .dsk RT11 400k image files I need to write to

RX50 disks so I can boot from them on my 11/73

such as:
PBM 1000
Tandy 2000
. . . 
IBM PC/JX



On Thu, 14 Sep 2017, Warner Losh wrote:

Right. I didn't see the Atari on the list, which was the only one, prior to
this thread, that I knew for sure had the right drives in it... I also
misread the IBM PC/JX as pcjr, which had the 360k floppy drive in it.


Yes, the PC/JX was kinda obscure.  (Japan?, Australia?) It was never sold 
in USA. 
There were quite a few more.  I have difficulty remembering a lot of them.



On the IBM PC/AT (5170) with 1.2M, admittedly the only one that is easily
readily available, there is trivial software tweaking required to
format/write "720K"/"quad" density, instead of "high" density: 300 bps with
single speed (360RPM) drive; 300 RPM/low density for dual speed drive.
Admittedly, none of the Dec Rainbow 100 diskettes that I wrote with PC/AT
are more than 30 years old. Yet.



You need hardware tweaks as well to make the drives compatible.  Otherwise
the recording strength is too high.


Actually, that can be done in software on virtually all such systems, 
certainly the OEM IBM AT.  The capability is there, in order to handle 
360K.
The problem is getting the drive to single step (96tpi) while using the 
recording strength, (and rotational speed and data transfer rate) normally 
associated with the 360K. I have run into a few after-market clones that 
made that difficult.



But, the software could be a lot simpler with a 720K drive, such as Teac 
55F, Shugart 465, Mitsubishi 4853, or even the old Tandon TM100-3 or 
TM100-4 (NOT the TM100-4M, which was 100tpi for Micropolis compatability)

There were many other brands, but I don't remember all of them.
And, of course even simpler with PC (5150) or XT (5160) FDC and using 720K 
drive, where you didn't even have to get around FDC "features".




The problem is people try to write RX-50 media with the HD drives. The
difference in recording strength causes many of the retention issues. It
works better when you write with the IBM drive with HD media.  This may
also be drive specific, as the different drive makers have had different
levels of competence with the old standards...


Yeah.
If people record at the HD level on DD disks, there will be problems, and 
recording DD on HD disks gives an extremely short data retention!  We had 
a buyer in the college who insisted on getting us Roytype (600 oersted?) 
diskettes, that would go blank minutes after writing on TRS80.




Yes. I ran TEAC FDC55FRs in my Rainbow for years to get double-sided space
(with tweaks to DOS from a gentleman in New Mexico).


I used a lot of 55F (before the 55FR) drives on PCs.  Also the Shugart 
465.


55E was the single sided version.
Anything that it could do could, of course, be done with the 55F, by 
leaving it on side 'A'


55B was the 360K; 55A was SS.

Some of the earliest 55G (HD 96tpi) s'posedly only went to 77 tracks! 
Some of those could make it to track 79, but not always reliably.


TEAC 55GF was a pretty reliable drive that could work in place of either 
the 55F or 55G (1.2M).  it worked very nicely for systems to do both 1.2M 
and 720K.


55FR was newer version of the 55F  ('R" was "revised"?)
Circuitry "improvements"? and lower power consumption.
There were 55BR, 55FR, 55GR, and 55GFR.
The A (48tpi SS) and E (96tpi SS) were discontinued when they came out 
with the R revisions.



I originally put two TM100-2 drives into my first 5150 (1981).  DS support 
didn't come out until DOS 1.10, but there was a strange set of patches for 
1.00 to use the second side as if it were another drive.  When Shugart 
came out with their half-height drives (The Qumetrak 142 was not reliable 
enough), I changed it to 2 455s and 2 465s.  Later I replaced one of the 
465s with a 55F and when DOS 3.20 came out, replaced the other 465 with a 
3.5".  For a little while, I played with Vista, Maynard, and a few other 
controllers that supported [external] 8".

Re: Rainbow Disk Imager

[Chuck Guzis via cctalk]

On 09/14/2017 03:27 PM, Fred Cisin via cctalk wrote:

> 
> I have run into quite a few badly maintained drives.  The innermost
> (higher numbered) tracks are the most sensitive to problems.

This.

And you can hook a "native" 96 tpi DD drive to a PC and use Dave
Dunfield's IMD to do the copying.  It'll even get the interleave right.

--Chuck

Re: Rainbow Disk Imager

[Warner Losh via cctalk]

On Thu, Sep 14, 2017 at 4:27 PM, Fred Cisin via cctalk <
cctalk@classiccmp.org> wrote:

> On Thu, 14 Sep 2017, Warner Losh via cctalk wrote:
>
>> And then there's Venix disks, which have both an interlace, as well as a
>> skew from track to track (as well as doing one side in ascending track
>> order followed by the other side in descending track order), but I
>> digress...
>>
>
> The software that you use must deal with interlace and skew.
>

Yea, as with the DOS disk, this was all logical. The physical sectors on
the disk weren't skewed (they all started at the index mark) and were
numbered 1..10 in order. It's the logical swap done in the drivers for
speed that the upper layers didn't know (or care) about. So if you looked
at the headers, you'd never know that these sorts of things were going on.

For the record, Venix's f0 device skipped track 0 and used the 2:1
interleave on the rest of the tracks with a span of 7. so the first track
was 1 3 5 7 9 2 4 6 8 10, but the next track was skewed by 7, so track 2
ran 6 8 10 1 3 5 7 9 2 4 etc. All the 'restore' disks and 'tar' disks for
Venix were like this and it took some trial and error to discover this to
recover the raw tar files from the Rainbow Venix disks... These values are
slightly different for 1.2MB disks for the IBM PC version of Venix, but the
same for 360k disks (well, with fewer sectors, obviously).

You can read through my trial and error sequence starting at
http://bsdimp.blogspot.com/2017/04/rainbow-100-venix86r-disks-found.html if
anybody cares. There's quite a few mis-steps along the way...


> (typically with a list/table of sector sequences, and variables such as
> index gap and inter-sector gaps)
>

Yea. It depends on the controller. WDC765 (or was that a clone of the NEC
uP765) and the Intel 8287A and their ilk need these details since they try
to cope with reading and they need some help guessing where the sector
started. For some reason, the older WDC-179x chips didn't care, but on
those chips to format a track you had to send it the sequence of bytes
which would ultimately make it onto the drive (so there was no format track
command, just a write track command).


> Thank you for the details.
>

You bet.


> There are an amazing variety of possibilities.
> A physical skew and/or interlace/arrangement of sectors will sometimes
> work in the wrong order, but with a performance penalty (or, in some cases,
> improvement).
>

The speed improvement is quite noticeable. It was 2-3x faster with the
interleave for a mostly sequential work loads, and the skew that venix did
added about a 20% improvement on top of that. Random workloads sucked no
matter what you did :(


> I have run into quite a few badly maintained drives.  The innermost
> (higher numbered) tracks are the most sensitive to problems.
>

Yes. I had the most errors on those tracks when I was reading my big box of
floppies back. My wife thought I was crazy for doing that... I'm not sure
she was wrong :) As you might tell from this thread, floppies, reading
them, and their formatting stir way too much passion in me (for which if it
was too much I apologize)

Warner

Re: Rainbow Disk Imager

[Warner Losh via cctalk]

On Thu, Sep 14, 2017 at 4:05 PM, Fred Cisin  wrote:

>   I have a bunch of .dsk RT11 400k image files I need to write to
 RX50 disks so I can boot from them on my 11/73

>>> such as:
>>> PBM 1000
>>> Tandy 2000
>>> Eagle II
>>> Toshiba T300
>>> Altos
>>> Canon AS100
>>> IBM PC/JX
>>> Seiko 8610
>>> Televideo TS1603
>>> or IBM PC/AT (5170) with 1.2M
>>>
>>
> On Thu, 14 Sep 2017, Warner Losh wrote:
>
>> None of those system produces disks that are quite right... They may work
>> for short-term transfers, but long term the data retention rates are
>> terrible.
>>
>
> All of THOSE, with the exception of the IBM PC/AT (5170) with 1.2M drive,
> have hardware that is completely compatible with Dec Rainbow 100.
> Those are all 96tpi, but NOT "high density/1.2M".
> They have capacities ranging from 640K to 800K, often
> rounded/over-simplified to call them "720K" or "quad" density.
> ALL, of course, require appropriate software, since RX50 is not the
> "native" format for the operating system on them.
>

Right. I didn't see the Atari on the list, which was the only one, prior to
this thread, that I knew for sure had the right drives in it... I also
misread the IBM PC/JX as pcjr, which had the 360k floppy drive in it.


> On the IBM PC/AT (5170) with 1.2M, admittedly the only one that is easily
> readily available, there is trivial software tweaking required to
> format/write "720K"/"quad" density, instead of "high" density: 300 bps with
> single speed (360RPM) drive; 300 RPM/low density for dual speed drive.
> Admittedly, none of the Dec Rainbow 100 diskettes that I wrote with PC/AT
> are more than 30 years old. Yet.
>

You need hardware tweaks as well to make the drives compatible.  Otherwise
the recording strength is too high.


> There is no hardware incompatability that would cause data retention
> problems if you are using the correct diskettes, written at the correct
> data transfer rate for the rotational speed.
>
> If you are having data retention problems, then it could be due to trying
> to use HD ("1.2M"/600 Oersted) diskettes, when you need 300 Oersted
> ("360K/720K") diskettes.
>

The problem is people try to write RX-50 media with the HD drives. The
difference in recording strength causes many of the retention issues. It
works better when you write with the IBM drive with HD media.  This may
also be drive specific, as the different drive makers have had different
levels of competence with the old standards...


> HD/600Oersted diskettes recorded at "double" density (such as
> "360K"/"720K"), instead of "high" density ("1.2M") will lose their content
> very quickly.  The color of the cookie is slightly different; presence or
> absence of hub-ring is not a reliable indicator of which type of diskette.
>

True.

(Dec Rainbow is SSDD 96tpi, with similar disk format (not necessarily
> circuitry) to MOST of the "quad" density systems, other than only using one
> side.  Similar to "720K" formats, but with 10 512 byte sectors per track,
> instead of 8 or 9.)
>

Yes. I ran TEAC FDC55FRs in my Rainbow for years to get double-sided space
(with tweaks to DOS from a gentleman in New Mexico).

Warner

Re: Rainbow Disk Imager

[Fred Cisin via cctalk]

On Thu, 14 Sep 2017, Warner Losh via cctalk wrote:

And then there's Venix disks, which have both an interlace, as well as a
skew from track to track (as well as doing one side in ascending track
order followed by the other side in descending track order), but I
digress...


The software that you use must deal with interlace and skew.
(typically with a list/table of sector sequences, and variables such as 
index gap and inter-sector gaps)

Thank you for the details.

There are an amazing variety of possibilities.
A physical skew and/or interlace/arrangement of sectors will sometimes 
work in the wrong order, but with a performance penalty (or, in some cases, 
improvement).



I have run into quite a few badly maintained drives.  The innermost 
(higher numbered) tracks are the most sensitive to problems.

Re: Rainbow Disk Imager

[Fred Cisin via cctalk]

  I have a bunch of .dsk RT11 400k image files I need to write to
RX50 disks so I can boot from them on my 11/73

such as:
PBM 1000
Tandy 2000
Eagle II
Toshiba T300
Altos
Canon AS100
IBM PC/JX
Seiko 8610
Televideo TS1603
or IBM PC/AT (5170) with 1.2M


On Thu, 14 Sep 2017, Warner Losh wrote:

None of those system produces disks that are quite right... They may work
for short-term transfers, but long term the data retention rates are
terrible.


All of THOSE, with the exception of the IBM PC/AT (5170) with 1.2M drive,
have hardware that is completely compatible with Dec Rainbow 100.
Those are all 96tpi, but NOT "high density/1.2M".
They have capacities ranging from 640K to 800K, often 
rounded/over-simplified to call them "720K" or "quad" density.
ALL, of course, require appropriate software, since RX50 is not the 
"native" format for the operating system on them.


On the IBM PC/AT (5170) with 1.2M, admittedly the only one that is 
easily readily available, there is trivial software tweaking 
required to format/write "720K"/"quad" density, instead of "high" density: 
300 bps with single speed (360RPM) drive; 300 RPM/low density for dual 
speed drive.
Admittedly, none of the Dec Rainbow 100 diskettes that I wrote with PC/AT 
are more than 30 years old. Yet.



There is no hardware incompatability that would cause data retention 
problems if you are using the correct diskettes, written at the correct 
data transfer rate for the rotational speed.


If you are having data retention problems, then it could be due to trying 
to use HD ("1.2M"/600 Oersted) diskettes, when you need 300 Oersted 
("360K/720K") diskettes.


HD/600Oersted diskettes recorded at "double" density (such as 
"360K"/"720K"), instead of "high" density ("1.2M") will lose their 
content very quickly.  The color of the cookie is slightly different; 
presence or absence of hub-ring is not a reliable indicator of which type 
of diskette.



(Dec Rainbow is SSDD 96tpi, with similar disk format (not necessarily 
circuitry) to MOST of the "quad" density systems, other than only using 
one side.  Similar to "720K" formats, but with 10 512 byte sectors per 
track, instead of 8 or 9.)


--
Grumpy Ol' Fred ci...@xenosoft.com

Re: Rainbow Disk Imager

[Warner Losh via cctalk]

On Thu, Sep 14, 2017 at 2:50 PM, Paul Koning  wrote:

>
> On Sep 14, 2017, at 4:47 PM, Warner Losh  wrote:
>
>
>
> On Thu, Sep 14, 2017 at 2:44 PM, Paul Koning 
> wrote:
>
>>
>> > On Sep 14, 2017, at 4:39 PM, Warner Losh  wrote:
>> >
>> > ...
>> > I don't see where you read the first 2 tracks uninterlaced, and the
>> other tracks interlaced?  For DOS formatted disks, that's what's required.
>> While screwing up the first two tracks won't affect your ability to read
>> DOS floppies (since they were reserved for the boot blocks), other formats
>> aren't so forgiving and it makes the disk unbootable...
>>
>> The question was about RX50 disks, which are uniformly interlaced and
>> skewed.
>
>
> No. They are not. CP/M MS-DOS on the Rainbow didn't do it uniformly. Venix
> on the Rainbow did it a different way. They are not uniform, and the first
> two tracks were not skewed. The DECMATE did it differently (not skewing
> tracks 78 and 79). I'm unsure how other OSes handled things, but it was
> anything but uniform.
>
> I wrote IMPDRIVE back in the day to read 3.5" floppies and had to cope
> with this. I have the BIOS listing for MS-DOS that shows clearly that the
> first two tracks weren't skewed. I also have the CP/M listing, but don't
> have it as handy. I'm quite certain of the non-uniformity.
>
>
> I guess I missed the fact that Rainbow did things differently.  What I
> said is valid for MSCP and Pro RX50s.  Thanks for the correction.
>

Never used a Pro...  If the guy has a Rainbow and needs to make copies of
the disks, his best bet is to do it with rbimg, in phyisical mode and to
buy old new media to receive the copies. There's several places on ebay
that sells the 96TPI quad (not high) density media that works the best and
that the Rainbow can format. I bought 20 disks recently for the Rainbow
Venix copies I made for someone on the list... Hopefully, he doesn't also
need a UNZIP program :)

Warner

Re: Rainbow Disk Imager

[Paul Koning via cctalk]

> On Sep 14, 2017, at 4:47 PM, Warner Losh  wrote:
> 
> 
> 
> On Thu, Sep 14, 2017 at 2:44 PM, Paul Koning  > wrote:
> 
> > On Sep 14, 2017, at 4:39 PM, Warner Losh  > > wrote:
> >
> > ...
> > I don't see where you read the first 2 tracks uninterlaced, and the other 
> > tracks interlaced?  For DOS formatted disks, that's what's required. While 
> > screwing up the first two tracks won't affect your ability to read DOS 
> > floppies (since they were reserved for the boot blocks), other formats 
> > aren't so forgiving and it makes the disk unbootable...
> 
> The question was about RX50 disks, which are uniformly interlaced and skewed.
> 
> No. They are not. CP/M MS-DOS on the Rainbow didn't do it uniformly. Venix on 
> the Rainbow did it a different way. They are not uniform, and the first two 
> tracks were not skewed. The DECMATE did it differently (not skewing tracks 78 
> and 79). I'm unsure how other OSes handled things, but it was anything but 
> uniform.
> 
> I wrote IMPDRIVE back in the day to read 3.5" floppies and had to cope with 
> this. I have the BIOS listing for MS-DOS that shows clearly that the first 
> two tracks weren't skewed. I also have the CP/M listing, but don't have it as 
> handy. I'm quite certain of the non-uniformity.

I guess I missed the fact that Rainbow did things differently.  What I said is 
valid for MSCP and Pro RX50s.  Thanks for the correction.

paul

Re: Rainbow Disk Imager

[Warner Losh via cctalk]

On Thu, Sep 14, 2017 at 2:47 PM, Warner Losh  wrote:

>
>
> On Thu, Sep 14, 2017 at 2:44 PM, Paul Koning 
> wrote:
>
>>
>> > On Sep 14, 2017, at 4:39 PM, Warner Losh  wrote:
>> >
>> > ...
>> > I don't see where you read the first 2 tracks uninterlaced, and the
>> other tracks interlaced?  For DOS formatted disks, that's what's required.
>> While screwing up the first two tracks won't affect your ability to read
>> DOS floppies (since they were reserved for the boot blocks), other formats
>> aren't so forgiving and it makes the disk unbootable...
>>
>> The question was about RX50 disks, which are uniformly interlaced and
>> skewed.
>
>
> No. They are not. CP/M MS-DOS on the Rainbow didn't do it uniformly. Venix
> on the Rainbow did it a different way. They are not uniform, and the first
> two tracks were not skewed. The DECMATE did it differently (not skewing
> tracks 78 and 79). I'm unsure how other OSes handled things, but it was
> anything but uniform.
>
> I wrote IMPDRIVE back in the day to read 3.5" floppies and had to cope
> with this. I have the BIOS listing for MS-DOS that shows clearly that the
> first two tracks weren't skewed. I also have the CP/M listing, but don't
> have it as handy. I'm quite certain of the non-uniformity.
>

I also have 4 real DEC Rainbows 100's in my basement (two 100As and two
100Bs), as well as 300 imaged disks (and the physical disks as well) that
needed exactly the kind of skewing I talked about to be readable by other
utilities.

Warner

Re: Rainbow Disk Imager

[Warner Losh via cctalk]

On Thu, Sep 14, 2017 at 2:44 PM, Paul Koning  wrote:

>
> > On Sep 14, 2017, at 4:39 PM, Warner Losh  wrote:
> >
> > ...
> > I don't see where you read the first 2 tracks uninterlaced, and the
> other tracks interlaced?  For DOS formatted disks, that's what's required.
> While screwing up the first two tracks won't affect your ability to read
> DOS floppies (since they were reserved for the boot blocks), other formats
> aren't so forgiving and it makes the disk unbootable...
>
> The question was about RX50 disks, which are uniformly interlaced and
> skewed.


No. They are not. CP/M MS-DOS on the Rainbow didn't do it uniformly. Venix
on the Rainbow did it a different way. They are not uniform, and the first
two tracks were not skewed. The DECMATE did it differently (not skewing
tracks 78 and 79). I'm unsure how other OSes handled things, but it was
anything but uniform.

I wrote IMPDRIVE back in the day to read 3.5" floppies and had to cope with
this. I have the BIOS listing for MS-DOS that shows clearly that the first
two tracks weren't skewed. I also have the CP/M listing, but don't have it
as handy. I'm quite certain of the non-uniformity.

Warner

Re: Rainbow Disk Imager

[Paul Koning via cctalk]

> On Sep 14, 2017, at 4:39 PM, Warner Losh  wrote:
> 
> ...
> I don't see where you read the first 2 tracks uninterlaced, and the other 
> tracks interlaced?  For DOS formatted disks, that's what's required. While 
> screwing up the first two tracks won't affect your ability to read DOS 
> floppies (since they were reserved for the boot blocks), other formats aren't 
> so forgiving and it makes the disk unbootable...

The question was about RX50 disks, which are uniformly interlaced and skewed.

paul

Re: Rainbow Disk Imager

[Warner Losh via cctalk]

On Thu, Sep 14, 2017 at 11:57 AM, Rod Smallwood via cctalk <
cctalk@classiccmp.org> wrote:

>
>
> On 14/09/2017 18:37, Rod Smallwood via cctalk wrote:
>
>>
>>
>> On 14/09/2017 17:55, Paul Koning via cctalk wrote:
>>
>>> On Sep 14, 2017, at 12:41 PM, Paul Koning via cctalk <
 cctalk@classiccmp.org> wrote:


 On Sep 14, 2017, at 12:27 PM, jim stephens via cctalk <
> cctalk@classiccmp.org> wrote:
>
>
>
> On 9/14/2017 9:19 AM, Fred Cisin via cctalk wrote:
>
>> You have some .dsk images of SSDD 96tpi for 11/73.
>>
> I have some also, and would love if there is a writeup of a known
> working procedure to use as a reference.
>
> Having a list of programs and systems is great, but I'd also like to
> know a few formulas that absolutely worked for someone as a starting 
> point.
>
> We have copies of a VMS 4.3 floppy set on RX50's which we will image
> as well, and using something other than the DEC hardware will be useful.
>
 It's easy on Linux.  PC 5.25 inch drives have settable format
 parameters.  The PC default is 9 sectors per track, but you can set it to
 10 for RX50 compatibility.

 At one point you'd do that with an entry in /etc/fdprm:

 rx5080010   1  800 0x23 0x01 0xDF 0x50

 There's still a command line approach, I forgot the command name
 though.  You can also do it under program control with the the FDSETPRM
 ioctl.  I have some Python code (in my "FLX" utility for operating on RSTS
 file systems) that does this.

 One complication: if you have an image which has the blocks in logical
 order, you need to shuffle them to account for the strange track numbering,
 interleaving, and track to track sector skew.  Here's a program that will
 do that.  (It operates on image files, not on the actual floppy drive.)

>>> Ok, attachments get stripped.  Here it is.
>>>
>>> #!/usr/bin/env python3
>>>
>>> """rx50.py
>>>
>>> This is a simple program to convert between interleaved and
>>> non-interleaved
>>> (logical block order) layouts for RX50 floppies or container files.
>>>
>>> Invocation:
>>>  rx50.py [-i] infile [-i] outfile
>>>
>>> If the filename is preceded by -i, that file is/will be interleaved.
>>> Infile
>>> or outfile may be an actual floppy (in which case -i is in effect
>>> automatically).
>>> While it is legal to specify -i twice, or not at all, this is rather
>>> uninteresting
>>> because it merely makes an image copy of the container in a fairly
>>> inefficient
>>> manner.
>>> """
>>>
>>> from rstsio import disk
>>> import sys
>>>
>>> def main (args):
>>>  a = iter (args)
>>>  il = False
>>>  ifn = next (a)
>>>  if ifn == "-i":
>>>  il = True
>>>  ifn = next (a)
>>>  idisk = disk.Disk (ifn, interleave = il)
>>>  il = False
>>>  ofn = next (a)
>>>  if ofn == "-i":
>>>  il = True
>>>  ofn = next (a)
>>>  odisk = disk.Disk.create (ofn, idisk.sz, interleave = il)
>>>  odisk.setrwdisk (True)
>>>  dcns = idisk.sz // idisk.dcs
>>>  for i in range (dcns):
>>>  ic = idisk.readclu (i)
>>>  oc = odisk.newclu (i)
>>>  oc[:] = ic
>>>  odisk.flush ()
>>>  idisk.close ()
>>>  odisk.close ()
>>>
>>> if __name__ == "__main__":
>>>  main (sys.argv[1:])
>>>
>>> Sounds good.
>> But I have to work with what I have:
>>
>> An 11/73 with:
>> One serial (console) line
>> An RX50 booting xxdp
>> A CQD220 SCSI controller with a DSP5200s attached.
>> RT11 customer diagnostics A and B
>>
>> The DSP5200S is formatted and is seen as DU6
>>
>> One PC running windows 10
>>
>> There's no Linux systems, no C compilers, emulators or weird hardware
>> available.
>>
>> But I do have a Rainbow which is the console to the 11/73
>>
>> I just need to write the RT11 disk images I have to RX50 using the
>> Rainbow.
>>
>> I found this
> As part of my entry for this year's RetroChallenge Winter Warm-Up (
> http://retrochallenge.net/2009/winter/news.html),
>  I've created some disk imaging utilities for the Rainbow 100.
> Specifically, the utilities can create RX50 images from disks, or write
> disks from RX50 images, similar to dd on GNU/Linux and rawrite on
> Windows/DOS.
> The utilities are downloadable from my blog (http://jeff.rainbow-100.com/?
> p=50).
>
> But its a dead end


Why is it a dead end? I've used that very program to read/write all the
Venix disks... Jeff may be running his site on his rainbow again, which
isn't the most stable connection there is (since the Rainbow is serial
only, no ethernet[*]). I've hacked on this to improve it, but the
improvements are all on my Rainbow (and many are one-off hacks designed to
cope with media that's in the throws of failure, but that hasn't thrown in
the towel just yet). I've uploaded a copy of rbimg to
http://people.freebsd.org/~imp/rbimg.zip, which I believe is Jeff's
original.

Re: Rainbow Disk Imager

[Warner Losh via cctalk]

On Thu, Sep 14, 2017 at 10:55 AM, Paul Koning via cctalk <
cctalk@classiccmp.org> wrote:

>
> > On Sep 14, 2017, at 12:41 PM, Paul Koning via cctalk <
> cctalk@classiccmp.org> wrote:
> >
> >
> >> On Sep 14, 2017, at 12:27 PM, jim stephens via cctalk <
> cctalk@classiccmp.org> wrote:
> >>
> >>
> >>
> >> On 9/14/2017 9:19 AM, Fred Cisin via cctalk wrote:
> >>> You have some .dsk images of SSDD 96tpi for 11/73.
> >> I have some also, and would love if there is a writeup of a known
> working procedure to use as a reference.
> >>
> >> Having a list of programs and systems is great, but I'd also like to
> know a few formulas that absolutely worked for someone as a starting point.
> >>
> >> We have copies of a VMS 4.3 floppy set on RX50's which we will image as
> well, and using something other than the DEC hardware will be useful.
> >
> > It's easy on Linux.  PC 5.25 inch drives have settable format
> parameters.  The PC default is 9 sectors per track, but you can set it to
> 10 for RX50 compatibility.
> >
> > At one point you'd do that with an entry in /etc/fdprm:
> >
> > rx50   80010   1  800 0x23 0x01 0xDF 0x50
> >
> > There's still a command line approach, I forgot the command name
> though.  You can also do it under program control with the the FDSETPRM
> ioctl.  I have some Python code (in my "FLX" utility for operating on RSTS
> file systems) that does this.
> >
> > One complication: if you have an image which has the blocks in logical
> order, you need to shuffle them to account for the strange track numbering,
> interleaving, and track to track sector skew.  Here's a program that will
> do that.  (It operates on image files, not on the actual floppy drive.)
>
> Ok, attachments get stripped.  Here it is.
>

I don't see where you read the first 2 tracks uninterlaced, and the other
tracks interlaced?  For DOS formatted disks, that's what's required. While
screwing up the first two tracks won't affect your ability to read DOS
floppies (since they were reserved for the boot blocks), other formats
aren't so forgiving and it makes the disk unbootable...

And then there's Venix disks, which have both an interlace, as well as a
skew from track to track (as well as doing one side in ascending track
order followed by the other side in descending track order), but I
digress...

Warner


> #!/usr/bin/env python3
>
> """rx50.py
>
> This is a simple program to convert between interleaved and non-interleaved
> (logical block order) layouts for RX50 floppies or container files.
>
> Invocation:
> rx50.py [-i] infile [-i] outfile
>
> If the filename is preceded by -i, that file is/will be interleaved.
> Infile
> or outfile may be an actual floppy (in which case -i is in effect
> automatically).
> While it is legal to specify -i twice, or not at all, this is rather
> uninteresting
> because it merely makes an image copy of the container in a fairly
> inefficient
> manner.
> """
>
> from rstsio import disk
> import sys
>
> def main (args):
> a = iter (args)
> il = False
> ifn = next (a)
> if ifn == "-i":
> il = True
> ifn = next (a)
> idisk = disk.Disk (ifn, interleave = il)
> il = False
> ofn = next (a)
> if ofn == "-i":
> il = True
> ofn = next (a)
> odisk = disk.Disk.create (ofn, idisk.sz, interleave = il)
> odisk.setrwdisk (True)
> dcns = idisk.sz // idisk.dcs
> for i in range (dcns):
> ic = idisk.readclu (i)
> oc = odisk.newclu (i)
> oc[:] = ic
> odisk.flush ()
> idisk.close ()
> odisk.close ()
>
> if __name__ == "__main__":
> main (sys.argv[1:])
>
>
>

Re: Rainbow Disk Imager

[Warner Losh via cctalk]

On Thu, Sep 14, 2017 at 10:19 AM, Fred Cisin via cctalk <
cctalk@classiccmp.org> wrote:

> On Thu, 14 Sep 2017, Rod Smallwood via cctalk wrote:
>
>>   I have a bunch of .dsk RT11 400k image files I need to write to
>> RX50 disks so I can boot from them on my 11/73
>> Somewhere there is a utility that will write the images to RX50 on a DEC
>> Rainbow 100 under MS-DOS . Anybody know where to find it?
>>
>
> Just to clarify:
> You have some .dsk images of SSDD 96tpi for 11/73.  You want to write them
> to disk.
> You are looking for a program running on DEC Rainbow 100 MS-DOS to do it.
>
> Any particular reason that you don't use any of the other systems that
> have hardware capability to do it?
>
> such as:
> PBM 1000
> Tandy 2000
> Eagle II
> Toshiba T300
> Altos
> Canon AS100
> IBM PC/JX
> Seiko 8610
> Televideo TS1603
> or IBM PC/AT (5170) with 1.2M
>

None of those system produces disks that are quite right... They may work
for short-term transfers, but long term the data retention rates are
terrible.

Warner

Re: Rainbow Disk Imager

[Warner Losh via cctalk]

On Thu, Sep 14, 2017 at 10:02 AM, Rod Smallwood via cctalk <
cctalk@classiccmp.org> wrote:

> Hi
>
>   I have a bunch of .dsk RT11 400k image files I need to write to RX50
> disks so I can boot from them on my 11/73
>
> Somewhere there is a utility that will write the images to RX50 on a DEC
> Rainbow 100 under MS-DOS . Anybody know where to find it?


I recently hacked on one written by Jeff Armstrong as part of my efforts to
read the Venix disks... If all you want is to copy, his version is fine
(mine added retries, etc before I had kyroflux working reliably)

It understands both physical layout (so the ability to dump / restore the
sectors in format order, which is 1, 2, 3, ... 10) as well as logical
layout (where you read the physical sectors in the order 1 3 5 7 9 2 4 6 8
10 to construct an image that upper layers view as being in order).

It's call rbimg. You can get it form his web site:
http://jeff.rainbow-100.com/wp/?tag=rbimg or you can download a mirrored
image at http://people.freebsd.org/~imp/rbimg.zip that I just copied over
since Jeff's site is on his Rainbow and a little slow...

You just need DOS which can FORMAT the drive, and then this program can
copy the disks (of course, if you have the physical media, you can use
diskcopy which also copies the whole disk, but has limited retry ability).

As for using Linux to read/write RX-50's, that works... To an extent... The
disks read are fine, but due to differences in write heads due to the
differences in so-called QD and HD media, the disks written tend to have
issues. Usually they will read fine on other 5.25" PC drives. Most of the
time, the RX-50 can read them as well. But In the 300 Rainbow floppies I
recently images, of the 15 that didn't read, 10 were disks that had been
written on the high density 5.25" drives drives (and only 4 were
readable).  Those disks were written prior to 1995 (as were the majority of
the other ones, I'll add), so this is clearly a retention issue...

Warner

RE: Rainbow Disk Imager

[Rob Jarratt via cctalk]

 
> There's no Linux systems, no C compilers, emulators or weird hardware
> available.
> 
> But I do have a Rainbow which is the console to the 11/73
> 


And the Rainbow isn't "weird hardware"?

:-)

Re: Rainbow Disk Imager

[Fritz Chwolka via cctalk]

maybe here ?

http://oldcomputers.dyndns.org/public/pub/mirror/os2site/sw/dec/rainbow/floppy/



Am 14.09.2017 um 18:02 schrieb Rod Smallwood via cctalk:
> Hi
>
>I have a bunch of .dsk RT11 400k image files I need to write to 
> RX50 disks so I can boot from them on my 11/73
>
> Somewhere there is a utility that will write the images to RX50 on a DEC 
> Rainbow 100 under MS-DOS . Anybody know where to find it?
>
> Rod
>
>
>

-- 



Best Regards

Mit freundlichen Grüssen

Fritz Chwolka

Re: Rainbow Disk Imager

[Rod Smallwood via cctalk]

On 14/09/2017 18:37, Rod Smallwood via cctalk wrote:



On 14/09/2017 17:55, Paul Koning via cctalk wrote:
On Sep 14, 2017, at 12:41 PM, Paul Koning via cctalk 
 wrote:



On Sep 14, 2017, at 12:27 PM, jim stephens via cctalk 
 wrote:




On 9/14/2017 9:19 AM, Fred Cisin via cctalk wrote:

You have some .dsk images of SSDD 96tpi for 11/73.
I have some also, and would love if there is a writeup of a known 
working procedure to use as a reference.


Having a list of programs and systems is great, but I'd also like 
to know a few formulas that absolutely worked for someone as a 
starting point.


We have copies of a VMS 4.3 floppy set on RX50's which we will 
image as well, and using something other than the DEC hardware will 
be useful.
It's easy on Linux.  PC 5.25 inch drives have settable format 
parameters.  The PC default is 9 sectors per track, but you can set 
it to 10 for RX50 compatibility.


At one point you'd do that with an entry in /etc/fdprm:

rx50    800    10   1  80    0 0x23 0x01 0xDF 0x50

There's still a command line approach, I forgot the command name 
though.  You can also do it under program control with the the 
FDSETPRM ioctl.  I have some Python code (in my "FLX" utility for 
operating on RSTS file systems) that does this.


One complication: if you have an image which has the blocks in 
logical order, you need to shuffle them to account for the strange 
track numbering, interleaving, and track to track sector skew.  
Here's a program that will do that.  (It operates on image files, 
not on the actual floppy drive.)

Ok, attachments get stripped.  Here it is.

#!/usr/bin/env python3

"""rx50.py

This is a simple program to convert between interleaved and 
non-interleaved

(logical block order) layouts for RX50 floppies or container files.

Invocation:
 rx50.py [-i] infile [-i] outfile

If the filename is preceded by -i, that file is/will be interleaved.  
Infile
or outfile may be an actual floppy (in which case -i is in effect 
automatically).
While it is legal to specify -i twice, or not at all, this is rather 
uninteresting
because it merely makes an image copy of the container in a fairly 
inefficient

manner.
"""

from rstsio import disk
import sys

def main (args):
 a = iter (args)
 il = False
 ifn = next (a)
 if ifn == "-i":
 il = True
 ifn = next (a)
 idisk = disk.Disk (ifn, interleave = il)
 il = False
 ofn = next (a)
 if ofn == "-i":
 il = True
 ofn = next (a)
 odisk = disk.Disk.create (ofn, idisk.sz, interleave = il)
 odisk.setrwdisk (True)
 dcns = idisk.sz // idisk.dcs
 for i in range (dcns):
 ic = idisk.readclu (i)
 oc = odisk.newclu (i)
 oc[:] = ic
 odisk.flush ()
 idisk.close ()
 odisk.close ()

if __name__ == "__main__":
 main (sys.argv[1:])


Sounds good.
But I have to work with what I have:

An 11/73 with:
One serial (console) line
An RX50 booting xxdp
A CQD220 SCSI controller with a DSP5200s attached.
RT11 customer diagnostics A and B

The DSP5200S is formatted and is seen as DU6

One PC running windows 10

There's no Linux systems, no C compilers, emulators or weird hardware 
available.


But I do have a Rainbow which is the console to the 11/73

I just need to write the RT11 disk images I have to RX50 using the 
Rainbow.



I found this
As part of my entry for this year's RetroChallenge Winter Warm-Up 
(http://retrochallenge.net/2009/winter/news.html),

 I've created some disk imaging utilities for the Rainbow 100.
Specifically, the utilities can create RX50 images from disks, or write 
disks from RX50 images, similar to dd on GNU/Linux and rawrite on 
Windows/DOS.
The utilities are downloadable from my blog 
(http://jeff.rainbow-100.com/?p=50).


But its a dead end
R

--
Wanted one pdp-8/i rocker switch leaver to copy.

Re: Rainbow Disk Imager

[Paul Koning via cctalk]

> On Sep 14, 2017, at 1:37 PM, Rod Smallwood via cctalk  
> wrote:
> 
> ...
> Sounds good.
> But I have to work with what I have:
> 
> An 11/73 with:
> ...
> There's no Linux systems, no C compilers, emulators or weird hardware 
> available.

Understood.  I was commenting on a more general question asked by another 
reader.

paul

Re: Rainbow Disk Imager

[Rod Smallwood via cctalk]

On 14/09/2017 17:55, Paul Koning via cctalk wrote:

On Sep 14, 2017, at 12:41 PM, Paul Koning via cctalk  
wrote:



On Sep 14, 2017, at 12:27 PM, jim stephens via cctalk  
wrote:



On 9/14/2017 9:19 AM, Fred Cisin via cctalk wrote:

You have some .dsk images of SSDD 96tpi for 11/73.

I have some also, and would love if there is a writeup of a known working 
procedure to use as a reference.

Having a list of programs and systems is great, but I'd also like to know a few 
formulas that absolutely worked for someone as a starting point.

We have copies of a VMS 4.3 floppy set on RX50's which we will image as well, 
and using something other than the DEC hardware will be useful.

It's easy on Linux.  PC 5.25 inch drives have settable format parameters.  The 
PC default is 9 sectors per track, but you can set it to 10 for RX50 
compatibility.

At one point you'd do that with an entry in /etc/fdprm:

rx50 80010   1  800 0x23 0x01 0xDF 0x50

There's still a command line approach, I forgot the command name though.  You can also do 
it under program control with the the FDSETPRM ioctl.  I have some Python code (in my 
"FLX" utility for operating on RSTS file systems) that does this.

One complication: if you have an image which has the blocks in logical order, 
you need to shuffle them to account for the strange track numbering, 
interleaving, and track to track sector skew.  Here's a program that will do 
that.  (It operates on image files, not on the actual floppy drive.)

Ok, attachments get stripped.  Here it is.

#!/usr/bin/env python3

"""rx50.py

This is a simple program to convert between interleaved and non-interleaved
(logical block order) layouts for RX50 floppies or container files.

Invocation:
 rx50.py [-i] infile [-i] outfile

If the filename is preceded by -i, that file is/will be interleaved.  Infile
or outfile may be an actual floppy (in which case -i is in effect 
automatically).
While it is legal to specify -i twice, or not at all, this is rather 
uninteresting
because it merely makes an image copy of the container in a fairly inefficient
manner.
"""

from rstsio import disk
import sys

def main (args):
 a = iter (args)
 il = False
 ifn = next (a)
 if ifn == "-i":
 il = True
 ifn = next (a)
 idisk = disk.Disk (ifn, interleave = il)
 il = False
 ofn = next (a)
 if ofn == "-i":
 il = True
 ofn = next (a)
 odisk = disk.Disk.create (ofn, idisk.sz, interleave = il)
 odisk.setrwdisk (True)
 dcns = idisk.sz // idisk.dcs
 for i in range (dcns):
 ic = idisk.readclu (i)
 oc = odisk.newclu (i)
 oc[:] = ic
 odisk.flush ()
 idisk.close ()
 odisk.close ()

if __name__ == "__main__":
 main (sys.argv[1:])
 


Sounds good.
But I have to work with what I have:

An 11/73 with:
One serial (console) line
An RX50 booting xxdp
A CQD220 SCSI controller with a DSP5200s attached.
RT11 customer diagnostics A and B

The DSP5200S is formatted and is seen as DU6

One PC running windows 10

There's no Linux systems, no C compilers, emulators or weird hardware 
available.


But I do have a Rainbow which is the console to the 11/73

I just need to write the RT11 disk images I have to RX50 using the Rainbow.

--
Wanted one pdp-8/i rocker switch leaver to copy.

Re: Rainbow Disk Imager

[Paul Koning via cctalk]

> On Sep 14, 2017, at 12:41 PM, Paul Koning via cctalk  
> wrote:
> 
> 
>> On Sep 14, 2017, at 12:27 PM, jim stephens via cctalk 
>>  wrote:
>> 
>> 
>> 
>> On 9/14/2017 9:19 AM, Fred Cisin via cctalk wrote:
>>> You have some .dsk images of SSDD 96tpi for 11/73.
>> I have some also, and would love if there is a writeup of a known working 
>> procedure to use as a reference.
>> 
>> Having a list of programs and systems is great, but I'd also like to know a 
>> few formulas that absolutely worked for someone as a starting point.
>> 
>> We have copies of a VMS 4.3 floppy set on RX50's which we will image as 
>> well, and using something other than the DEC hardware will be useful.
> 
> It's easy on Linux.  PC 5.25 inch drives have settable format parameters.  
> The PC default is 9 sectors per track, but you can set it to 10 for RX50 
> compatibility.
> 
> At one point you'd do that with an entry in /etc/fdprm:
> 
> rx50   80010   1  800 0x23 0x01 0xDF 0x50
> 
> There's still a command line approach, I forgot the command name though.  You 
> can also do it under program control with the the FDSETPRM ioctl.  I have 
> some Python code (in my "FLX" utility for operating on RSTS file systems) 
> that does this.
> 
> One complication: if you have an image which has the blocks in logical order, 
> you need to shuffle them to account for the strange track numbering, 
> interleaving, and track to track sector skew.  Here's a program that will do 
> that.  (It operates on image files, not on the actual floppy drive.)

Ok, attachments get stripped.  Here it is.

#!/usr/bin/env python3

"""rx50.py

This is a simple program to convert between interleaved and non-interleaved
(logical block order) layouts for RX50 floppies or container files.

Invocation:
rx50.py [-i] infile [-i] outfile

If the filename is preceded by -i, that file is/will be interleaved.  Infile
or outfile may be an actual floppy (in which case -i is in effect 
automatically).
While it is legal to specify -i twice, or not at all, this is rather 
uninteresting
because it merely makes an image copy of the container in a fairly inefficient
manner.
"""

from rstsio import disk
import sys

def main (args):
a = iter (args)
il = False
ifn = next (a)
if ifn == "-i":
il = True
ifn = next (a)
idisk = disk.Disk (ifn, interleave = il)
il = False
ofn = next (a)
if ofn == "-i":
il = True
ofn = next (a)
odisk = disk.Disk.create (ofn, idisk.sz, interleave = il)
odisk.setrwdisk (True)
dcns = idisk.sz // idisk.dcs
for i in range (dcns):
ic = idisk.readclu (i)
oc = odisk.newclu (i)
oc[:] = ic
odisk.flush ()
idisk.close ()
odisk.close ()

if __name__ == "__main__":
main (sys.argv[1:])

Re: Rainbow Disk Imager

[Paul Koning via cctalk]

> On Sep 14, 2017, at 12:27 PM, jim stephens via cctalk  
> wrote:
> 
> 
> 
> On 9/14/2017 9:19 AM, Fred Cisin via cctalk wrote:
>> You have some .dsk images of SSDD 96tpi for 11/73.
> I have some also, and would love if there is a writeup of a known working 
> procedure to use as a reference.
> 
> Having a list of programs and systems is great, but I'd also like to know a 
> few formulas that absolutely worked for someone as a starting point.
> 
> We have copies of a VMS 4.3 floppy set on RX50's which we will image as well, 
> and using something other than the DEC hardware will be useful.

It's easy on Linux.  PC 5.25 inch drives have settable format parameters.  The 
PC default is 9 sectors per track, but you can set it to 10 for RX50 
compatibility.

At one point you'd do that with an entry in /etc/fdprm:

rx50 80010   1  800 0x23 0x01 0xDF 0x50

There's still a command line approach, I forgot the command name though.  You 
can also do it under program control with the the FDSETPRM ioctl.  I have some 
Python code (in my "FLX" utility for operating on RSTS file systems) that does 
this.

One complication: if you have an image which has the blocks in logical order, 
you need to shuffle them to account for the strange track numbering, 
interleaving, and track to track sector skew.  Here's a program that will do 
that.  (It operates on image files, not on the actual floppy drive.)

paul

RE: Rainbow Disk Imager

[Bill Gunshannon via cctalk]

From: cctalk [cctalk-boun...@classiccmp.org] on behalf of Rod Smallwood via 
cctalk [cctalk@classiccmp.org]
Sent: Thursday, September 14, 2017 12:02 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Rainbow Disk Imager

Hi

   I have a bunch of .dsk RT11 400k image files I need to write to
RX50 disks so I can boot from them on my 11/73

Somewhere there is a utility that will write the images to RX50 on a DEC
Rainbow 100 under MS-DOS . Anybody know where to find it?

___

I used to use VTServer to move images onto real media on a PDP-11.  Worked
for both RX and RL disks.  No reason why it woldn't have worked for bigger disks
other than the time needed to move the data over a serial line.  :-)

bill

Re: Rainbow Disk Imager

[jim stephens via cctalk]

On 9/14/2017 9:19 AM, Fred Cisin via cctalk wrote:

You have some .dsk images of SSDD 96tpi for 11/73.
I have some also, and would love if there is a writeup of a known 
working procedure to use as a reference.


Having a list of programs and systems is great, but I'd also like to 
know a few formulas that absolutely worked for someone as a starting point.


We have copies of a VMS 4.3 floppy set on RX50's which we will image as 
well, and using something other than the DEC hardware will be useful.


Throw in the DEC "we don't format diskettes" twist, and having a formula 
page would be nice.  I'll document what I get on my blog pages if noone 
else has.


thanks
Jim

Re: Rainbow Disk Imager

[Rod Smallwood via cctalk]

Because I don't have any of those. I'm nearly all DEC here

Rod



On 14/09/2017 17:19, Fred Cisin via cctalk wrote:

On Thu, 14 Sep 2017, Rod Smallwood via cctalk wrote:
  I have a bunch of .dsk RT11 400k image files I need to write to 
RX50 disks so I can boot from them on my 11/73
Somewhere there is a utility that will write the images to RX50 on a 
DEC Rainbow 100 under MS-DOS . Anybody know where to find it?


Just to clarify:
You have some .dsk images of SSDD 96tpi for 11/73.  You want to write 
them to disk.

You are looking for a program running on DEC Rainbow 100 MS-DOS to do it.

Any particular reason that you don't use any of the other systems that 
have hardware capability to do it?


such as:
PBM 1000
Tandy 2000
Eagle II
Toshiba T300
Altos
Canon AS100
IBM PC/JX
Seiko 8610
Televideo TS1603
or IBM PC/AT (5170) with 1.2M




--
Wanted one pdp-8/i rocker switch leaver to copy.

Re: Rainbow Disk Imager

[Fred Cisin via cctalk]

On Thu, 14 Sep 2017, Rod Smallwood via cctalk wrote:
  I have a bunch of .dsk RT11 400k image files I need to write to 
RX50 disks so I can boot from them on my 11/73
Somewhere there is a utility that will write the images to RX50 on a DEC 
Rainbow 100 under MS-DOS . Anybody know where to find it?


Just to clarify:
You have some .dsk images of SSDD 96tpi for 11/73.  You want to write them 
to disk.

You are looking for a program running on DEC Rainbow 100 MS-DOS to do it.

Any particular reason that you don't use any of the other systems that 
have hardware capability to do it?


such as:
PBM 1000
Tandy 2000
Eagle II
Toshiba T300
Altos
Canon AS100
IBM PC/JX
Seiko 8610
Televideo TS1603
or IBM PC/AT (5170) with 1.2M

Rainbow Disk Imager

[Rod Smallwood via cctalk]

Hi

  I have a bunch of .dsk RT11 400k image files I need to write to 
RX50 disks so I can boot from them on my 11/73


Somewhere there is a utility that will write the images to RX50 on a DEC 
Rainbow 100 under MS-DOS . Anybody know where to find it?


Rod



--
Wanted one pdp-8/i rocker switch leaver to copy.