Re: Multi-platform distribution format (Was: Backups [was

[Johnny Billquist]

On 2015-09-22 06:58, tony duell wrote:

HOWEVER, while the PDP-11 is still unable to perform an
LLF on an RX50 when an RQDX3 is present, it is possible
to perform an LLF on a floppy in an RX33.  Does that still
seem compatible with your explanation?


Yes, that confused me too. The RQDX3 is clearly capable of
LLFing a floppy. So either (unlikely) DEC specifically do
not allow the right set of commands to LLF an RX50 or
(more likely) that bit of software you have doesn't do it
(although others can) possibly so as not to cut into DEC's
sales of pre-formatted disks.

Sorry I don't know more, the RQDXs are too modern for me.


I don't know for sure, but I really think it's the RQDX3 that explicitly 
refuses to format the RX50.


If I just had an RX33 I could easily test this, as I can easily patch 
the RSX FMT program to treat an RX50 as an RX33...


Johnny

Re: Multi-platform distribution format (Was: Backups [was

[Holm Tiffe]

tony duell wrote:

> > 
> > For both the DEC  RX01 and the DEC  RX02 8" floppy drives,
> > while it might have been possible that DEC engineers were unable
> > to initially figure out how to allow users to perform an LLF (Low
> > Level Format) on the 8" floppy drives, it seems certain that after
> > 3rd party manufactures figured out, DEC could also have supported
> > that function as well.
> 
> The controller microcode ROMs in both the RX01 and RX02 are tightly
> packed, there is not enough room (IMHO) for a LLF routine. And to use
> larger ROMs (certainly in the RX01) would mean some other electronic
> modifications.
> 
> [...]
> 
> > After I managed to locate a DSD (Data Systems Design)
> > drive which supported the DEC  RX02 floppy drive function,
> 
> The RX02 can reformat an RX01 as double-density. An RX01 is
> essentially IBM3740 format. I have no problems formatting a
> blank disk as SSSD in a CP/M machine and then using a (real
> DEC) RX02 drive to turn it into a DEC double density disk.
> 
> [...]
> 
> > Note that the RX50 was the same.  DEC finally changed
> 
> Not really. The RX01 and RX02 have the controller electronics
> in the drive chassis, and that determines what the drive unit
> can do (like not doing an LLF). The RX50 is just a bare drive,
> the interface is much the same as a PC (say) floppy drive
> interface. An RX50 drive, given the right pulses on the 
> write data line, will most certainly do an LLF. Some DEC
> controllers used with it, and some software that used said
> controllers might have been unable to do an LLF, but that's
> not a problem with the drive.
> 
> -tony

I do have a question here. I got an russian Elektronika 60 (what is
something like an 11/03 clone) and repaired it. Part of that machine is a
russian GMD7012 dual Floppy drive which seems to be a copy of the RX02 too.
All the Disks I've got for that machine are in RX01 Format but while
repairing the Drive I found a jumper in there that is to be used to switch
the Drive from RX01 to RX02 mode.
I've tried to boot an RX01 Floppy in RX02 mode, that failed on all disks
I've tried. Is an original RX02 able to boot (RT11) from an RX01 disk?
I know that a different device driver has to be used  normally, but I had
no RX02 media and wasn't able to make one, since the machine has no other
drives connected and the card cage is mechanically not compatible (metric
dimensions including the fingers).
I know that in the RX02 Mode the Drive has an format track command that
doesn't exist in RX01 mode, that's documented. How about the RX02?

Is there somewhere a picture from the Conteroller PCB of the DEC RX02
(just to look at). The russian controller has a 2910 and four 2901 if
I remember correctly... (K1804VU1 and 4xK1804VS1)

Regards,

Holm
-- 
  Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, 
 Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583
  www.tsht.de, i...@tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

RE: Multi-platform distribution format (Was: Backups [was

[tony duell]

> HOWEVER, while the PDP-11 is still unable to perform an
> LLF on an RX50 when an RQDX3 is present, it is possible
> to perform an LLF on a floppy in an RX33.  Does that still
> seem compatible with your explanation?

Yes, that confused me too. The RQDX3 is clearly capable of
LLFing a floppy. So either (unlikely) DEC specifically do
not allow the right set of commands to LLF an RX50 or
(more likely) that bit of software you have doesn't do it
(although others can) possibly so as not to cut into DEC's
sales of pre-formatted disks.

Sorry I don't know more, the RQDXs are too modern for me.

-tony

Re: Multi-platform distribution format (Was: Backups [was

[Johnny Billquist]

On 2015-09-21 22:27, Paul Koning wrote:



On Sep 21, 2015, at 3:49 PM, Jerome H. Fine  wrote:


Johnny Billquist wrote:



On 2015-09-21 17:03, Paul Koning wrote:



And it would certainly be possible to write a driver that can handle both 
controllers; it would start by determining which controller it's dealing with, 
and then run the one or the other set of algorithms.  Since a boot block is 
just a small driver, the same is true there, so long as the whole body of code 
fits in the available space.  I suspect in this case that's doable; most 
bootloaders (other than MSCP ones) require only a small fraction of the 
available space.


You are absolutely right.
And I don't know the actual size of the boot blocks. It might very well be that 
they both fits in the same boot block, which would be nice.
I know that the M9312 have separate boot roms for the RX11 and the RX211, but 
those boot roms are pretty tiny...

And I don't know if the RX211 boot rom also deals with RX01 floppies, but I 
would assume it does.


I don't know how RSX-11 and RSTS/E manage their device
drivers and allocate the memory for that code.  BUT, under
RT-11, each device driver uses memory which the user program
can't use. ...
Finally, while the boot code could certainly support both
the RX01 and the RX02 drive, there would be no point
since the code in the device driver supports only one
drive.


RSTS isn't as frugal with memory as RT11 is.  It has a bit of per-unit memory 
whether the device is present or not.  But the kernel can be built with all 
sorts of device drivers for devices that aren't actually present.  If so, those 
are disabled at boot.


RSX does it somewhat different, but the basic idea is similar. At boot 
time, devices are mark offline or online depending on whether they 
actually exists. And in addition, you can always load and unload drivers 
while the system is running. So, you can do as you choose.
The drivers for RX11 and RX211 are separate and different. You might 
have both loaded at the same time, and just have one online, depending 
on which controller you actually have.
Or, if you have a multiprocessor system, you can always hot-plug them as 
well, and bring devices on- and offline as you feel like it, just as 
easily as you can change what CSR address and vector to use.



So for RSTS, it certainly makes sense to have a multi-lingual boot block, if 
you're dealing with a medium that can be installed into several types of drives 
with different controllers.


Also true for RSX, whenever possible. Unfortunately, not all devices can 
be booted by the same bootblock, but the most common ones can.



The RX01/RX02 case doesn't occur for RSTS since those aren't supported as boot 
devices.  But the analogous scenario does apply to magtape.  The RSTS magtape 
boot block works with every PDP-11 controller capable of supporting that tape, 
so 1600 BPI tapes can boot on TU16, TS80 (gag) and TMSCP controllers.  Yes, 
that's a fun bit of code.


Same with RSX. RX01/RX02 are too small to even be possible to boot from. 
All magtapes use the same bootblock. MSCP and Massbus disks also share a 
common boot block. RL01/RL02 have its own boot block, as do the 
RK06/RK07. And those are the only available options for booting.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

RE: Multi-platform distribution format (Was: Backups [was

[tony duell]

>
> > Epson PX8?
> 
> That's a commercial or industrial system?  Did it run an EDM setup,
> turret lathe  or vacuforming machine?  Anyone keep their AR, AP, GL,
> payroll and inventory on one?   I doubt that one could run a PBX.

I guess it depends on what you call a 'commercial' system. I certainly
wouldn't class the PX8 as a home computer.

> I never looked at the Geneva or QX-10 as much more than word processing
> setups.

Then IMHO you didn't look at them carefully. I think the QX10 is one of the 
best 
all-in-one (as opposed to S100 bus, say) CP/M machines. Good graphics, 256k
(bank switched) RAM, those nice Epson voice-coil drives, RS232 and Centronics
interfaces, expansion slots if you need more, good documentation, etc, etc, etc
It certainly is a lot more than a word processing system.

-tony



--Chuck

Re: Multi-platform distribution format (Was: Backups [was

[Jerome H. Fine]

>Johnny Billquist wrote:


In any case, adding and correcting the extra code was quite
easy.  The challenge was to also add support for a user buffer
being above the 1/4 MB boundary in a PDP-11 with all 4 MB
of memory when a Mapped RT-11 Monitor was used since
the controller supported only 18-bit addresses. 


This would be the Qbus controller. And that is an annoying detail, 
yes. You need a bounce buffer in the low part of memory. One of a few 
Qbus controllers with 18-bit addressing for DMA.


Well, it was an early controller and since it was for a floppy
drive and the problem was really only with a Mapped RT-11
Monitor when the user buffer was in extended memory above
1/4 MB, it really was not a major problem.   What actually
might be more of a problem (if I ever finish the job of placing
the code and bounce buffer into extended memory) is making
sure that the portion of extended memory is below 1/4 MB.
That would be the responsibility of the installation code to
allocate the memory and check to make sure that the bounce
buffer is below 1/4 MB. 


I guess that could also be done with the RK05 controller
and the original RL01 / RL02 controller.  The latter versions
of the RL01 / RL02 controller support 22-bit user buffer
addresses.  What about tape controllers?

And then there is the problem of making sure that other programs
and device drivers don't gobble up the memory below 1/4 MB
which they don't actually require.  That aspect, it turns out is
actually very easy to solve.  The code to allocate any extended
memory in RT-11 normally allocates memory from the bottom
up.  However, it is possible to change a single word of just one
of the instructions in the XALLOC subroutine in RT-11 so that
all of the memory is allocated from the top down!  And since it
is a single word being changed, it is not even necessary to stop
interrupts while it is being done.  Eventually I want to write the
code for XAX.SYS which will support:
SET  XA  HIGH
SET  XA  LOW
SET  XA  TOGGLE
SET  XA  BOOT=[LOW,HIGH]
SET  XA  SHOW
SET  XA  HELP
and allow the user to control how extended memory is allocated
under a Mapped RT-11 Monitor.

R  RESORC /Z
already provides the current setting, otherwise provided by:
SHOW  CONFIGURATION

I guess I could check the setting in DYX.SYS before I allocate
the extended memory and toggle the setting back after the
extended memory is allocated.


Another problem was that the index hole for single-sided floppies
was offset about 1/2" from the index hole for double-sided
floppies.  That challenge was solved by using a DPDT switch
to flip the sensors that were used on the DSD 880/30 and
that supported using, as double-sided, floppies with the single-
sided index hole.  While a number of 8" floppies had been
purchased that had the double-sided index hole, that was less
than 10% of the total and after punching the extra pair of holes
in single-sided floppies just a few times, it was very quickly
apparent that the DPDT switch was a much better one-time
solution.  What was initially a surprise was that EITHER the
single-sided OR double-sided index hole could be used with
the same floppy to access the sectors even though the holes
were in different positions.  The timing did not seem to matter.
Only the device driver software cared if the bit was set one
way or the other, so flipping the sensors which were activated
was an excellent one-time solution when the user (me!!)
wanted to use a floppy with a single-sided index hole as a
double-sided floppy.

In any case, the code was enhanced, my version of DYX.SYS
supported the RX03 double-density, double-sided floppy drive
under a 22-bit RT-11 monitor.  So I set about the job of the
LLFs for double-sided 8" floppy media.  As mentioned above,
in addition to a couple of dozen 8" DEC floppies, I had about
a dozen other brands.  To make a long story short at this point,
the results were "interesting".  Every non-DEC branded 8" floppy
could hold an LLF for double-sided, double-density.  On the other
hand, I seem to remember that only about 2/3 of the DEC 8"
floppies managed to complete the LLF.  The other 1/3 of the
DEC 8" floppies could hold an LLF on the normal first side,
but not on the second side.

Obviously this story was somewhat different since it was not
necessary to ask DEC maintenance to make the LLF capability
with the DSD 880/30 to work - it already worked.  In addition,
there was no DEC maintenance contract in the first place and
there was no 50 gallon oil drum.  There was also no refusal
by DEC to enhance the DY.MAC device driver to support
the RX03 floppy drive since DEC was not asked.

Over the decades since, I have always wondered how it was
even possible for ONLY the DEC 8" floppies to be unable to
take an LLF double-sided when every other brand managed
to do so.  There was probably one floppy that was so severely
damaged that it would not take an LLF on either side, but that
was a specific exception.  Any 8" floppy which could take a
double-sided, 

Re: Multi-platform distribution format (Was: Backups [was

[Johnny Billquist]

On 2015-09-21 19:20, Paul Koning wrote:



On Sep 21, 2015, at 12:47 PM, Johnny Billquist  wrote:
...

I suppose you could on a Pro, since that had its own particularly disgusting 
junk controller.  But I haven't seen RX50 formatting there.  My impression was 
that they came factory formatted, with the DEC-specific 10 sector per track 
format.


Ugh! The PRO controller probably was weird enough to not allow you, even though 
as far as I understand, it was also way more primitive than MSCP.


Way more primitive is a polite way of putting it.  Just like all other PRO 
controllers DEC ever built, it uses programmed I/O.  The curious thing is that 
the PRO bus actually appears to support DMA, but it was never used, not even 
for the hard drive or network interface.  All those devices do I/O to on-card 
memory, and then the driver has to move it to/from host memory.


DECs various decisions related to the PRO are probably a mystery to all.


I haven't tried this, but the PRO technical manual (on Bitsavers) shows that 
(a) there is no way to do formatting, but (b) you can configure the controller 
to accept, for reading but not writing, various non-RX50 formats.


Interesting. I haven't even tried digging that deep into the 
documentation. If I ever found the drivers for the hardisk and floppy 
for P/OS I could possibly consider trying to build something more purely 
RSX-like, but I doubt that will happen.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

Re: Multi-platform distribution format (Was: Backups [was

[Johnny Billquist]

On 2015-09-22 03:09, Jerome H. Fine wrote:

 >Johnny Billquist wrote:


In any case, adding and correcting the extra code was quite
easy.  The challenge was to also add support for a user buffer
being above the 1/4 MB boundary in a PDP-11 with all 4 MB
of memory when a Mapped RT-11 Monitor was used since
the controller supported only 18-bit addresses.


This would be the Qbus controller. And that is an annoying detail,
yes. You need a bounce buffer in the low part of memory. One of a few
Qbus controllers with 18-bit addressing for DMA.


Well, it was an early controller and since it was for a floppy
drive and the problem was really only with a Mapped RT-11
Monitor when the user buffer was in extended memory above
1/4 MB, it really was not a major problem.   What actually
might be more of a problem (if I ever finish the job of placing
the code and bounce buffer into extended memory) is making
sure that the portion of extended memory is below 1/4 MB.
That would be the responsibility of the installation code to
allocate the memory and check to make sure that the bounce
buffer is below 1/4 MB.
I guess that could also be done with the RK05 controller
and the original RL01 / RL02 controller.  The latter versions
of the RL01 / RL02 controller support 22-bit user buffer
addresses.  What about tape controllers?


Yes, it was an early controller, from before the Qbus actually was 
22-bit addressed.


RSX solves this by creating a partition when the driver comes online, 
and making sure this memory partition is below 256K. And then all DMA 
goes through that memory partition, and then the drive copies the data 
to the final destination when DMA finishes (or the reverse on writes).

All done only in the case it detects it's an RXV21 and not an RX211.


Another problem was that the index hole for single-sided floppies
was offset about 1/2" from the index hole for double-sided
floppies.  That challenge was solved by using a DPDT switch
to flip the sensors that were used on the DSD 880/30 and
that supported using, as double-sided, floppies with the single-
sided index hole.  While a number of 8" floppies had been
purchased that had the double-sided index hole, that was less
than 10% of the total and after punching the extra pair of holes
in single-sided floppies just a few times, it was very quickly
apparent that the DPDT switch was a much better one-time
solution.  What was initially a surprise was that EITHER the
single-sided OR double-sided index hole could be used with
the same floppy to access the sectors even though the holes
were in different positions.  The timing did not seem to matter.
Only the device driver software cared if the bit was set one
way or the other, so flipping the sensors which were activated
was an excellent one-time solution when the user (me!!)
wanted to use a floppy with a single-sided index hole as a
double-sided floppy.

In any case, the code was enhanced, my version of DYX.SYS
supported the RX03 double-density, double-sided floppy drive
under a 22-bit RT-11 monitor.  So I set about the job of the
LLFs for double-sided 8" floppy media.  As mentioned above,
in addition to a couple of dozen 8" DEC floppies, I had about
a dozen other brands.  To make a long story short at this point,
the results were "interesting".  Every non-DEC branded 8" floppy
could hold an LLF for double-sided, double-density.  On the other
hand, I seem to remember that only about 2/3 of the DEC 8"
floppies managed to complete the LLF.  The other 1/3 of the
DEC 8" floppies could hold an LLF on the normal first side,
but not on the second side.

Obviously this story was somewhat different since it was not
necessary to ask DEC maintenance to make the LLF capability
with the DSD 880/30 to work - it already worked.  In addition,
there was no DEC maintenance contract in the first place and
there was no 50 gallon oil drum.  There was also no refusal
by DEC to enhance the DY.MAC device driver to support
the RX03 floppy drive since DEC was not asked.

Over the decades since, I have always wondered how it was
even possible for ONLY the DEC 8" floppies to be unable to
take an LLF double-sided when every other brand managed
to do so.  There was probably one floppy that was so severely
damaged that it would not take an LLF on either side, but that
was a specific exception.  Any 8" floppy which could take a
double-sided, double-density LLF held the data successfully
when used in practice.


Probably qualification differences. DEC only cared if one side was
good. So floppies with one bad side were still acceptable for DEC,
since they only used one side anyway.
Floppies sold as double sided needed to pass testing on both sides.


I would agree with your analysis if any of the other non-DEC floppy
brands had even a couple of floppies which had not accepted an LLF
for double-sided operation.  BUT,  NOT  EVEN  ONE??
It seems a bit unlikely unless DEC specifically managed to locate a
shipment at an excellent cost advantage and the 

Re: Multi-platform distribution format (Was: Backups [was

[Jerome H. Fine]

>tony duell wrote:


If it was possible to perform a LLF using the same RX50 drive on
the Rainbow, what was the reason why an LLF could not also be


It is. Remember the RX50 is just a drive, it does not include any of
the controller electronics.


performed on a PDP-11?  There seems to be a number of possibilities:

(a)  There was some hardware that the Rainbow had which was missing
  on the PDP-11 systems

It's more the reverse!. The Rainbow just has a standard controller chip on the 
processor bus (I forget which processor, I can look at the schematics if you

want). The controller chip can do what is needed for a LLF, and there is
nothing in the way to prevent software from sending the commands to do
that.


Well that is a reverse explanation!  Completely opposite of
what I thought might be the actual situation.


On the PDP11 there is a lot more stuff between the processor and the disk
controller chip. Even the Pro 300 series has a microcontroller (8051?) on
the floppy controller board. Therefore the processor you can program
(PDP11) can't do arbitrary things to the disk controller chip, it is very likely
that sending the right commands to do an LLF is one of the things you
can't do.


HOWEVER, while the PDP-11 is still unable to perform an
LLF on an RX50 when an RQDX3 is present, it is possible
to perform an LLF on a floppy in an RX33.  Does that still
seem compatible with your explanation?

I would not attempt a trick question with you since I don't
know enough to set one up.  Again, I am just trying to
understand what DEC did and how DEC managed to
still avoid being able to perform an LLF on an RX50
using an RQDX3, yet supported an LLF right from
RT-11 on the RX33 using an RQDX3?

The one time I watched it being done, I nearly fell off
my chair in astonishment.  After all those decades using
the PDP-11, I was finally allowed to FORMAT a floppy
and it actually worked.  Of course, the floppy in question
was identical to a HD 5 1/4" PC floppy which any PC
at that time would also be able to FORMAT.  And in
any case, the floppies were usually sold with a FORMAT.
So all that would normally be needed would be the
INITIALIZE command.  But it would be nice to be
able to understand how the RQDX3 can FORMAT
an RX33, but not an RX50.  I also have an RX23
drive on a CQD 220/TM which I have never tried.
But since that is a non-DEC host adapter, I don't
think it counts,

Jerome Fine

Re: Multi-platform distribution format (Was: Backups [was

[Paul Koning]

> On Sep 21, 2015, at 12:28 PM, Jay Jaeger  wrote:
> 
> On 9/21/2015 4:30 AM, Johnny Billquist wrote:
> 
>> On 2015-09-21 02:11, Jerome H. Fine wrote:
 Chuck Guzis wrote:
>>> Note that the RX50 was the same.  DEC finally changed
>>> their marketing policy with the RX33 drive which used the
>>> same 3.5" HD floppy media as the PC.  It was actually
>>> possible to FORMAT those floppies under RT-11.
>> 
>> No, DEC actually did support users formatting RX50 floppies on their
>> own, but only on the Rainbow.
>> 
>>Johnny
>> 
> 
> There was also a standalone PDP-11 diagnostic program available that
> could do it.

For RX50?  On standard PDP11s, those used an MSCP controller, which means the 
controller would have to do it.  Did it?  The only MSCP controller I remember 
that did formatting was the UDA50.

I suppose you could on a Pro, since that had its own particularly disgusting 
junk controller.  But I haven't seen RX50 formatting there.  My impression was 
that they came factory formatted, with the DEC-specific 10 sector per track 
format.

paul

RE: Multi-platform distribution format (Was: Backups [was

[tony duell]

> 
> Not CP/M admittedly, but small contemporary
> Burroughs machines certainly used cassettes, both
> for program and data storage. I wrote several
> fairly complex diskless accounting systems using
> four cassette drives, one or two card readers and
> a line printer (in addition to the console
> printer).
> 
> Why not; not much different conceptually after all
> from early systems using open-reel mag tape, or
> even punch(ed) cards.

I feel there are 2 distinct types of cassette system from the
user perspective. 

The first is the sort used on 1980s home computers with a
standard or slightly modified (Commodore, Atari) audio
cassette recorder. These needed considerable manual
intervention to position the tape (rewind, fast forward),
select record or play mode, etc. Essentially only useable
for loading/saving programs and sequential files

The second has the tape mechanism under computer control
like the HP9830 (HP9865 add-on drive too), this Burroughs
the PX8, etc. With these you can load particular files, rewrite
files, possibly have a block-structured file system. Often these
units (but not the PX8) used a special tape with a different
coercivity to audio tape.

The second type would seem to be entirely useable for
'business' computing before floppy drives were 
available. I am not so sure about the first type :-)

-tony

Re: Multi-platform distribution format (Was: Backups [was

[Mike Stein]

Not CP/M admittedly, but small contemporary
Burroughs machines certainly used cassettes, both
for program and data storage. I wrote several
fairly complex diskless accounting systems using
four cassette drives, one or two card readers and
a line printer (in addition to the console
printer).

Why not; not much different conceptually after all
from early systems using open-reel mag tape, or
even punch(ed) cards.

m

- Original Message - 
From: "Chuck Guzis" <ccl...@sydex.com>

To: "General Discussion: On-Topic and Off-Topic
Posts" <cctalk@classiccmp.org>
Sent: Monday, September 21, 2015 1:42 AM
Subject: Re: Multi-platform distribution format
(Was: Backups [was



On 09/20/2015 09:55 PM, tony duell wrote:




Gee, I thought we were talking about CP/M
here.  How many CP/M
systems used cassette for storage.  Better
yet, how many
commerical/industrial CP/M systems used
cassettes for program
storage.


Epson PX8?


That's a commercial or industrial system?  Did
it run an EDM setup, turret lathe  or
vacuforming machine?  Anyone keep their AR, AP,
GL, payroll and inventory on one?   I doubt that
one could run a PBX.

I never looked at the Geneva or QX-10 as much
more than word processing setups.

--Chuck

RE: Multi-platform distribution format (Was: Backups [was

[Fred Cisin]

> Why not; not much different conceptually after all
> from early systems using open-reel mag tape, or
> even punch(ed) cards.

On Mon, 21 Sep 2015, tony duell wrote:

I feel there are 2 distinct types of cassette system from the
user perspective. 


The first is the sort used on 1980s home computers with a
standard or slightly modified (Commodore, Atari) audio
cassette recorder. These needed considerable manual
. . . 
The second has the tape mechanism under computer control
. . . 
The second type would seem to be entirely useable for
'business' computing before floppy drives were 
available. I am not so sure about the first type :-)


and, of course, as a third type, Exatron Stringy-Floppy
computer based, but NOT entirely usable.

Re: Multi-platform distribution format (Was: Backups [was

[Chuck Guzis]

On 09/21/2015 10:22 AM, tony duell wrote:


Have you ever read the technical manual for the QX10?

It appears there were 2 keyboards sold for it. One had Valdocs-specific
keys, the other (which seems more common over here, not that the QX10
is a common machine) doesn't and was used for a more standard
CP/M system.


Yes, as well as a fair amount of TP/M source code.  It's just that the 
QX-10s strong selling point was Valdocs and that's mostly why people 
bought the thing.


On the subject of cassette machines, here's one:

https://www.youtube.com/watch?v=G8oXxO5FT3A

1991, 68K-based controller, dual color CRT with graphics.  Some have 
been upgraded to floppy--if so, they're running CP/M 68K, but this 
appears to be the original cassette model.


--Chuck

Re: Multi-platform distribution format (Was: Backups [was

[Jerome H. Fine]

>Rod Smallwood wrote:


>On 21/09/2015 10:30, Johnny Billquist wrote:


>On 2015-09-21 02:11, Jerome H. Fine wrote:


You bring up a VERY notable lack of support by DEC of that
situation!!

For both the DEC  RX01 and the DEC  RX02 8" floppy drives,
while it might have been possible that DEC engineers were unable
to initially figure out how to allow users to perform an LLF (Low
Level Format) on the 8" floppy drives, it seems certain that after
3rd party manufactures figured out, DEC could also have supported
that function as well.

Instead, DEC pretended that all 8" floppy media HAD to be
purchased PRE-FORMATTED from DEC.  Well, if you
ever discussed that option with a DEC person, it certainly
did not seem like the individual was pretending.

After I managed to locate a DSD (Data Systems Design)
drive which supported the DEC  RX02 floppy drive function,
it was game over for that particular DEC monopoly.  The
DSD drive was able to perform an LLF for either single
density or double density in addition to being both single
sided and double sided. 


Not that tricky. All you needed was a way to format into RX01 format, 
which is plain simple IBM single side, single density format.
RX02 floppies have the same low level formatting. To use them in RX02 
mode just requires flipping a bit in the sector header, and the RX02 
drive is able to do that.



I am not sure that I understand your suggestion.  While I agree
that the RX02 was able to switch a single-density floppy to a
double-density floppy (and visa versa), the difficulty, as you
pointed out, was performing the initial LLF (Low Level
Formatting) in the first place on Un-Formatted 8" floppies.
That may have been easy with IBM hardware, but DEC
made that impossible if all the user had was a DEC system.

For readers unfamiliar with DEC vocabulary, the FORMAT
command did NOT create a file structure!  That command
in RT-11 was INITIALIZE and something similar was
probably used for RSTS/E and RSX-11.  Note that under
RT-11, the FORMAT command for the RX02 did NOT
perform an LLF, but did set the density bit in each sector
if an LLF had already been performed and was sufficiently
intact to support clearing out all the data in the sector setting
and the density bit to the value requested by the user.

In practice, I found that when an RX02 floppy started having
problems, the LLF was VERY rarely a problem.  For reasons
which were not understood, when the floppy media started to
have read and or write errors, it was usually possible to have
the RX02 floppy drive perform the software command which
DEC called FORMAT and re-initialize all the sectors so that
the media could be used again without any read and or write
errors.  That obviously would have required the LLF to be
sufficiently present for the software and hardware to repair
the problems and reset all the sectors as either single-density
or double-density depending on what the user requested.

I am not sure what conclusions can be drawn from this example.


Note that the RX50 was the same.  DEC finally changed
their marketing policy with the RX33 drive which used the
same 3.5" HD floppy media as the PC.  It was actually
possible to FORMAT those floppies under RT-11. 


No, DEC actually did support users formatting RX50 floppies on their 
own, but only on the Rainbow.


Johnny



If it was possible to perform a LLF using the same RX50 drive on
the Rainbow, what was the reason why an LLF could not also be
performed on a PDP-11?  There seems to be a number of possibilities:

(a)  There was some hardware that the Rainbow had which was missing
  on the PDP-11 systems
(b)  The firmware in the controller on the Rainbow supported an LLF,
  but the firmware in the controller on the RQDX1, RQDX2 or RQDX3
  on the PDP-11 did not support an LLF
(c)  The Rainbow used a program which DEC supplied that could
  perform an LLF, but DEC did not supply such a program for
  the PDP-11 systems
(d)  Another possibility of which I am not aware.

Is there an answer as to which possibility supported the Rainbow
being able to perform an LLF using an RX50 drive, but that the
PDP-11 systems with that same RX50 could not perform an LLF?

Take me back to my desk in DECPark thirty years ago and I could have 
pulled out the internal documents on this.


 I cant do that so we will have to make do with my dodgy memory.
When floppy disks first appeared end users just wanted to take the 
disk out of the box and use it.

They could not see why they should waste time preparing every new one.
They did not need matching to a particular drive as DEC's 
manufacturing tolerances made sure any disk would work on any drive.


In fact it was more difficult and expensive to provide pre-formatted 
disks.
It was more about customer service and making sure the equipment kept 
running.


I heard the following story

One customer went out and got a huge pile of unformatted (and 
untested) floppys and a third party 

RE: Multi-platform distribution format (Was: Backups [was

[tony duell]

> If it was possible to perform a LLF using the same RX50 drive on
> the Rainbow, what was the reason why an LLF could not also be

It is. Remember the RX50 is just a drive, it does not include any of
the controller electronics.

> performed on a PDP-11?  There seems to be a number of possibilities:

> (a)  There was some hardware that the Rainbow had which was missing
>on the PDP-11 systems

It's more the reverse!. The Rainbow just has a standard controller chip on the 
processor bus (I forget which processor, I can look at the schematics if you
want). The controller chip can do what is needed for a LLF, and there is
nothing in the way to prevent software from sending the commands to do
that.

On the PDP11 there is a lot more stuff between the processor and the disk
controller chip. Even the Pro 300 series has a microcontroller (8051?) on
the floppy controller board. Therefore the processor you can program
(PDP11) can't do arbitrary things to the disk controller chip, it is very likely
that sending the right commands to do an LLF is one of the things you
can't do.

-tony

Re: Multi-platform distribution format (Was: Backups [was

[Paul Koning]

> On Sep 21, 2015, at 12:47 PM, Johnny Billquist  wrote:
> ...
>> I suppose you could on a Pro, since that had its own particularly disgusting 
>> junk controller.  But I haven't seen RX50 formatting there.  My impression 
>> was that they came factory formatted, with the DEC-specific 10 sector per 
>> track format.
> 
> Ugh! The PRO controller probably was weird enough to not allow you, even 
> though as far as I understand, it was also way more primitive than MSCP.

Way more primitive is a polite way of putting it.  Just like all other PRO 
controllers DEC ever built, it uses programmed I/O.  The curious thing is that 
the PRO bus actually appears to support DMA, but it was never used, not even 
for the hard drive or network interface.  All those devices do I/O to on-card 
memory, and then the driver has to move it to/from host memory.

I haven't tried this, but the PRO technical manual (on Bitsavers) shows that 
(a) there is no way to do formatting, but (b) you can configure the controller 
to accept, for reading but not writing, various non-RX50 formats.

paul

RE: Multi-platform distribution format (Was: Backups [was

[tony duell]

> 
> and, of course, as a third type, Exatron Stringy-Floppy
> computer based, but NOT entirely usable.

Along with its inferior friend the Sinclair Microdrive
which was entirely NOT useable.

-tony

Re: Multi-platform distribution format (Was: Backups [was

[Jay Jaeger]

On 9/21/2015 11:34 AM, Paul Koning wrote:

> For RX50?  On standard PDP11s, those used an MSCP controller, which means the 
> controller would have to do it.  Did it?  The only MSCP controller I remember 
> that did formatting was the UDA50.
> 
> I suppose you could on a Pro, since that had its own particularly disgusting 
> junk controller.  But I haven't seen RX50 formatting there.  My impression 
> was that they came factory formatted, with the DEC-specific 10 sector per 
> track format.
> 
>   paul
> 

Acch.  Bad memory cells.  This actually was discussed back in 2002.
Some of the correspondents in that discussion are also denizens of this
mailing list, may recall I made the same mistake back then:

The diagnostic was/is:

BL-FN7AP-MC CZFNAP0 M-11 FORMTR RX50

So, just to verify, I fired up my 11/23 (which hasn't been on in YEARS),
which came right up, and inserted the floppy and booted it:

It formats:

RD51, RD52, RD53 on an RQDX1 or RQDX2
RD51, RD52, RD53, RD54, RD31, RD32, RX33 on an RQDDX2

Sorry for the confusion.

JRJ

Re: Multi-platform distribution format (Was: Backups [was

[Paul Koning]

> On Sep 21, 2015, at 3:49 PM, Jerome H. Fine  wrote:
> 
> >Johnny Billquist wrote:
> 
>> >On 2015-09-21 17:03, Paul Koning wrote:
>> 
>>> And it would certainly be possible to write a driver that can handle both 
>>> controllers; it would start by determining which controller it's dealing 
>>> with, and then run the one or the other set of algorithms.  Since a boot 
>>> block is just a small driver, the same is true there, so long as the whole 
>>> body of code fits in the available space.  I suspect in this case that's 
>>> doable; most bootloaders (other than MSCP ones) require only a small 
>>> fraction of the available space. 
>> 
>> You are absolutely right.
>> And I don't know the actual size of the boot blocks. It might very well be 
>> that they both fits in the same boot block, which would be nice.
>> I know that the M9312 have separate boot roms for the RX11 and the RX211, 
>> but those boot roms are pretty tiny...
>> 
>> And I don't know if the RX211 boot rom also deals with RX01 floppies, but I 
>> would assume it does. 
> 
> I don't know how RSX-11 and RSTS/E manage their device
> drivers and allocate the memory for that code.  BUT, under
> RT-11, each device driver uses memory which the user program
> can't use. ...
> Finally, while the boot code could certainly support both
> the RX01 and the RX02 drive, there would be no point
> since the code in the device driver supports only one
> drive.

RSTS isn't as frugal with memory as RT11 is.  It has a bit of per-unit memory 
whether the device is present or not.  But the kernel can be built with all 
sorts of device drivers for devices that aren't actually present.  If so, those 
are disabled at boot.

So for RSTS, it certainly makes sense to have a multi-lingual boot block, if 
you're dealing with a medium that can be installed into several types of drives 
with different controllers.

The RX01/RX02 case doesn't occur for RSTS since those aren't supported as boot 
devices.  But the analogous scenario does apply to magtape.  The RSTS magtape 
boot block works with every PDP-11 controller capable of supporting that tape, 
so 1600 BPI tapes can boot on TU16, TS80 (gag) and TMSCP controllers.  Yes, 
that's a fun bit of code.

paul

Re: Multi-platform distribution format (Was: Backups [was

[Holm Tiffe]

Holm Tiffe wrote:
[..]

..forgot to mention one interesting thing:
The E60 is that PDP11 clone on which Alexei Paschitnow wrote the original
of Tetris...

Regards,

Holm

-- 
  Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, 
 Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583
  www.tsht.de, i...@tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

Re: Multi-platform distribution format (Was: Backups [was

[Fred Cisin]

Ah, but when people with Valdocs wanted to change to another 
word-processing system, as was likely to happen often in business, they 
would contact, Chuck, me, or any of our colleagues in the disk format 
conversion field.


The CP/M users might not have as frequent a conversion need, and/or might 
be more likely to make use of other options, such as XMODEM.


Accordingly, WE saw Valdocs users more often than the other QX-10 users.



On Mon, 21 Sep 2015, Chuck Guzis wrote:


On 09/21/2015 10:22 AM, tony duell wrote:


Have you ever read the technical manual for the QX10?

It appears there were 2 keyboards sold for it. One had Valdocs-specific
keys, the other (which seems more common over here, not that the QX10
is a common machine) doesn't and was used for a more standard
CP/M system.


Yes, as well as a fair amount of TP/M source code.  It's just that the QX-10s 
strong selling point was Valdocs and that's mostly why people bought the 
thing.

Re: Multi-platform distribution format (Was: Backups [was

[Fred Cisin]

and, of course, as a third type, Exatron Stringy-Floppy computer
based, but NOT entirely usable.


The department chair at one of the colleges attempted to convert an entire 
TRS80 based student computer lab over to stringy floppy.
He was the same one who later had a lab full of TRS80 model 3s converted 
into model 4s at a slightly higher price per unit than buying model 4s. 
Nodel 3s were still quite in demand in that lab, and the student 
technicians were quite capable of adding memory and disk drives.  The same 
expenditure could have resulted in almost twice as many usable machines, 
plus a few 3s waiting for funding for RAM and drives.
Later, he thought that it would be cool to have all of the 5150 PCs on 
their sides, ("to look more professional"), with the switch on the 
underside.
And, of course, although it meant far fewer machines, all of the AT 
machines used for teaching spreadsheets, word processing, and beginning 
programming HAD TO have color monitors.

Re: Multi-platform distribution format (Was: Backups [was

[Jerome H. Fine]

>Jay Jaeger wrote:


On 9/21/2015 11:34 AM, Paul Koning wrote:



For RX50?  On standard PDP11s, those used an MSCP controller, which means the 
controller would have to do it.  Did it?  The only MSCP controller I remember 
that did formatting was the UDA50.

I suppose you could on a Pro, since that had its own particularly disgusting 
junk controller.  But I haven't seen RX50 formatting there.  My impression was 
that they came factory formatted, with the DEC-specific 10 sector per track 
format.


Acch.  Bad memory cells.  This actually was discussed back in 2002.
Some of the correspondents in that discussion are also denizens of this
mailing list, may recall I made the same mistake back then:

The diagnostic was/is:

BL-FN7AP-MC CZFNAP0 M-11 FORMTR RX50

So, just to verify, I fired up my 11/23 (which hasn't been on in YEARS),
which came right up, and inserted the floppy and booted it:

It formats:

RD51, RD52, RD53 on an RQDX1 or RQDX2
RD51, RD52, RD53, RD54, RD31, RD32, RX33 on an RQDDX2

Sorry for the confusion.

JRJ


Then you have answered the question!!

But it there may be some possible confusion.  If I remember
correctly, the RQDX3 was used with the RD54 and RX33
and the RQDX2 or RQDX3 was used with the RD53.

I could be wrong, but that is what I seem to remember.

So on a PDP-11 Qbus system, it is not possible to FORMAT the
RX50 which uses an RQDX1, RQDX2 or an RQDX3.

BUT, how is it possible to FORMAT the 5 1/4" RX33  HD floppy
which uses an RQDX3 controller?

If it can be dome with the RX33, why not with the RX50?

Jerome Fine

Re: Multi-platform distribution format (Was: Backups [was

[Chuck Guzis]

On 09/20/2015 03:03 PM, Fred Cisin wrote:

On Sun, 20 Sep 2015, ben wrote:

I was just digging in to old CP/M a bit and it was/is tied mostly
to the IBM 8" standard floppy and the floppy interface used at the
time. Even that gave a very small amount memory per track. Ben.


single sided FM/SD 77 tracks, 26 sectors per track, 128 bytes per
sector 256,256 bytes (250.25K)


There was a good reason for that.

Many early disk controllers did not have a "write index to index" 
fucntion that also enabled writing special (i.e. missing clocks) 
characters.  As a result, one had to purchase 8" floppies pre-formatted 
(this actually persisted for quite some time).  IBM 3740 format was the 
most common format out there; hence the easiest to obtain.


--Chuck

Re: Multi-platform distribution format (Was: Backups [was

[Jerome H. Fine]

>Chuck Guzis wrote:


>On 09/20/2015 03:03 PM, Fred Cisin wrote:


>On Sun, 20 Sep 2015, ben wrote:


I was just digging in to old CP/M a bit and it was/is tied mostly
to the IBM 8" standard floppy and the floppy interface used at the
time. Even that gave a very small amount memory per track. Ben. 


single sided FM/SD 77 tracks, 26 sectors per track, 128 bytes per
sector 256,256 bytes (250.25K) 


There was a good reason for that.

Many early disk controllers did not have a "write index to index" 
fucntion that also enabled writing special (i.e. missing clocks) 
characters.  As a result, one had to purchase 8" floppies 
pre-formatted (this actually persisted for quite some time).  IBM 3740 
format was the most common format out there; hence the easiest to obtain.


You bring up a VERY notable lack of support by DEC of that
situation!!

For both the DEC  RX01 and the DEC  RX02 8" floppy drives,
while it might have been possible that DEC engineers were unable
to initially figure out how to allow users to perform an LLF (Low
Level Format) on the 8" floppy drives, it seems certain that after
3rd party manufactures figured out, DEC could also have supported
that function as well.

Instead, DEC pretended that all 8" floppy media HAD to be
purchased PRE-FORMATTED from DEC.  Well, if you
ever discussed that option with a DEC person, it certainly
did not seem like the individual was pretending.

After I managed to locate a DSD (Data Systems Design)
drive which supported the DEC  RX02 floppy drive function,
it was game over for that particular DEC monopoly.  The
DSD drive was able to perform an LLF for either single
density or double density in addition to being both single
sided and double sided.

Note that the RX50 was the same.  DEC finally changed
their marketing policy with the RX33 drive which used the
same 3.5" HD floppy media as the PC.  It was actually
possible to FORMAT those floppies under RT-11.

Jerome Fine

Re: Multi-platform distribution format (Was: Backups [was

[Fred Cisin]

single sided FM/SD 77 tracks, 26 sectors per track, 128 bytes per
sector 256,256 bytes (250.25K)

On Sun, 20 Sep 2015, Chuck Guzis wrote:

There was a good reason for that.
Many early disk controllers did not have a "write index to index" fucntion 
that also enabled writing special (i.e. missing clocks) characters.  As a 
result, one had to purchase 8" floppies pre-formatted (this actually 
persisted for quite some time).  IBM 3740 format was the most common format 
out there; hence the easiest to obtain.


It certainly made absolute sense as the format to use.

But, I had thought that there should then be a SECOND standard for 5.25", 
for those machines without 8" support.
Gary disagreed.  Having more than ONE "standard" makes it not completely a 
standard.  Still, a 5.25" "recommended" format, or a specific family with 
sides and densities,  would have made a lot of people less miserable, 
(did we really need thousands of mutually incompatable formats?),

and I would have been programming some other project.

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

Re: Multi-platform distribution format (Was: Backups [was

[ben]

On 9/20/2015 7:55 PM, Chuck Uzis wrote:


So it was still fragmented.



So did it matter? You ran Basic or played games from cassete.
That was for domestic systems, heaven help you lived out of USA
for computers.


--Chuck

Ben.

Re: Multi-platform distribution format (Was: Backups [was

[Chuck Guzis]

On 09/20/2015 09:55 PM, tony duell wrote:




Gee, I thought we were talking about CP/M here.  How many CP/M
systems used cassette for storage.  Better yet, how many
commerical/industrial CP/M systems used cassettes for program
storage.


Epson PX8?


That's a commercial or industrial system?  Did it run an EDM setup, 
turret lathe  or vacuforming machine?  Anyone keep their AR, AP, GL, 
payroll and inventory on one?   I doubt that one could run a PBX.


I never looked at the Geneva or QX-10 as much more than word processing 
setups.


--Chuck

Re: Multi-platform distribution format (Was: Backups [was

[Chuck Guzis]

On 09/20/2015 05:32 PM, Fred Cisin wrote:


But, I had thought that there should then be a SECOND standard for
5.25", for those machines without 8" support. Gary disagreed.  Having
more than ONE "standard" makes it not completely a standard.  Still,
a 5.25" "recommended" format, or a specific family with sides and
densities,  would have made a lot of people less miserable, (did we
really need thousands of mutually incompatable formats?), and I would
have been programming some other project.


Well, the 5.25" world was far less organized than the 8".  We didn't 
have an IBM to set some sort of widely-accepted standard.  The 3740 
format also served to cement the notion of a 128-byte sector firmly 
within CP/M (and early MS-DOS) long after that sector size had ceased to 
be a real physical concept.


But consider--the early Shugart (what was it, SA-400?) floppies recorded 
35 tracks at 48 tpi single-sided.  At a 250KHz clock, that's what, 16 
sectors * 128 bytes * 35 tracks = 70KiBytes.  What good is that?


At the same time Micropolis was working a 5.25" drive that could hold 
about as much as an 8", using some tricks.  The Micropolis drive was 100 
tpi, 77 track and, by using GCR, could hold 12 512-byte sectors per 
track.  That's 462KiB.  This was about 1977-78.


So which should have Gary embraced?  The Shugart drive was dirt-simple, 
but didn't hold much, but was (compratively) cheap.  The Micropolis 
drive and controller implementation (ours was done by a guy we'd 
recruited from Sperry ISS) was more complex and expensive, but gave you 
a useful amount of storage.


There weren't any really good choices for several years.  Keep in mind 
that 96 tpi drives also made their appearance.


The other day, I had to figure out why a fellow with CNC disks written 
using a Teac FD-50C couldn't read his disks in a normal 1.2MB AT drive. 
 Well, the Teac beast is one of the very few 100 tpi drives that Teac 
made--and this was for a system manufactured in the early 1980s.


So it was still fragmented.

And the nuttiness continued well into the 90s and the 3.5" drives (cf. 
the Mac 400 and 800K GCR flooppies).  I routinely get Brother WP disks 
that are 38 track, single-sided, Brother-encoded GCR that hold a 
whopping 120K on 2D floppies.  On the other hand, they're extremely 
reliable.


--Chuck

Re: Multi-platform distribution format (Was: Backups [was

[Jon Elson]

On 09/20/2015 03:46 PM, ben wrote:

On 9/20/2015 2:19 PM, Fred Cisin wrote:



There were several reasons why there was never a STANDARD 
5.25" CP/M
format.  I once had the opportunity to ask Gary Kildall 
what the
standard would be for 5.25".  He replied, "8 inch single 
sided single
density".  I repeated, "Yes, but waht about 5.25"?  He 
repeated, "8 inch
single sided single density".  I understood, but was not 
much enlightened.


I was just digging in to old CP/M a bit and it was/is tied 
mostly
to the IBM 8" standard floppy and the floppy interface 
used at the

time. Even that gave a very small amount memory per track.
It was fairly easy to make CP/M work with other disk types 
and formats.  Even **I** was able to write a driver to add a 
SASI Winchester drive to my CP/M system.  (That made it run 
SOOO much better!)


Jon

Re: Multi-platform distribution format (Was: Backups [was

[Fred Cisin]

On Sun, 20 Sep 2015, ben wrote:

So did it matter? You ran Basic or played games from cassete.


Sure.  But, I was never happy with cassette for program nor data storage. 
I bought an Expansion Interface the day that it became available, but I 
never bought a drive from Radio Shack nor IBM.  Bare drives were already 
available much cheaper.  And the MPI B51 came out soon after.  Split band 
positioner worked better for me than spiral cam.
And, of course, I already had a small stack of TM100-1 drives in 1981, 
when I needed some for 5150 PC.



That was for domestic systems, heaven help you lived out of USA
for computers.

True.   I was in driving distance of Silicon Valley.


And, I never thought that the Micropolis 100tpi would ever be the 
mainstream.  I bought one, and got a Micropolis OS with it that I never 
used.  Their 48tpi drive, however, was the most reliable, albeit slow, 
drive for my TRS80s.
96tpi, admittedly took a little longer to be available, but it 
seemed an obvious better choice than 100tpi, just for the [admittedly 
flawed] interchange possibility.  Many years later, in a pile of TM100-4 
drives, I got a TM100-4M, even though I could never find one when I wanted 
one.



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

Re: Multi-platform distribution format (Was: Backups [was

[Chuck Guzis]

On 09/20/2015 08:48 PM, ben wrote:


OS/9 was nice for the 6809 but all I had was 1 floppy with the COCO
II. Ben.


Before I got a (dual) floppy drive with my personal system, I used a 
Techtran dual cassette drive.  One side was read-write, the other was 
read-only.It was intended as a substitute for traditional paper tape 
systems.  Really nice, with high-speed search, filemarks and 
read-reverse.  Speeds to 9600 bps serial.  It had some fairly 
sophisticated command support--you could do an entire tape or just a 
file copy with a single command.


I wrote my own operating system of a sort for it and got a lot of work 
done until I got my floppies going (I used Don Tarbell's controller, 
which I still have).


--Chuck

Re: Multi-platform distribution format (Was: Backups [was

[Fred Cisin]

On Sun, 20 Sep 2015, ben wrote:

I was just digging in to old CP/M a bit and it was/is tied mostly
to the IBM 8" standard floppy and the floppy interface used at the
time. Even that gave a very small amount memory per track.
Ben.


single sided FM/SD 77 tracks, 26 sectors per track, 128 bytes per sector
256,256 bytes (250.25K)

Re: Multi-platform distribution format (Was: Backups [was

[ben]

On 9/20/2015 2:19 PM, Fred Cisin wrote:



There were several reasons why there was never a STANDARD 5.25" CP/M
format.  I once had the opportunity to ask Gary Kildall what the
standard would be for 5.25".  He replied, "8 inch single sided single
density".  I repeated, "Yes, but waht about 5.25"?  He repeated, "8 inch
single sided single density".  I understood, but was not much enlightened.


I was just digging in to old CP/M a bit and it was/is tied mostly
to the IBM 8" standard floppy and the floppy interface used at the
time. Even that gave a very small amount memory per track.
Ben.