20 Sep
2015
20 Sep
'15
10:53 a.m.
On 09/19/2015 10:58 PM, John Foust wrote:
The other recent development that makes me want to
quit?
Someone's demonstrated you can hide in the firmware of
hard drives.
https://blog.kaspersky.com/equation-hdd-malware/7623/ - John
Well, one would
assume this is also OS specific. I would
guess it would be incredibly hard to make a "disk" virus
that would work on greatly differing OS's like Linux AND
Windows. No telling what would happen if one of these disk
viruses got onto a hard drive on a Windows system and then
the drive was reformatted and loaded with Linux.
Most likely you'd have odd crashes or something.
Jon
20 Sep
20 Sep
11:18 a.m.
On 9/20/2015 11:53 AM, Jon Elson wrote:
On 09/19/2015 10:58 PM, John Foust wrote:
I think the real problem is back to the OS and dynamic link libraries.
The other recent development that makes me want
to quit? Someone's
demonstrated you can hide in the firmware of hard drives.
https://blog.kaspersky.com/equation-hdd-malware/7623/ - John
Well, one would
assume this is also OS specific. I would guess it would
be incredibly hard to make a "disk" virus that would work on greatly
differing OS's like Linux AND Windows. No telling what would happen if
one of these disk viruses got onto a hard drive on a Windows system and
then the drive was reformatted and loaded with Linux.
Most likely you'd have odd crashes or something. Jon
Ben.
12:28 p.m.
On Sun, 20 Sep 2015, Jon Elson wrote:
Well, one would assume this is also OS specific. I
would guess it would be
incredibly hard to make a "disk" virus that would work on greatly differing
OS's like Linux AND Windows. No telling what would happen if one of these
disk viruses got onto a hard drive on a Windows system and then the drive was
reformatted and loaded with Linux.
Most likely you'd have odd crashes or something.
It is possible to create an executable file that identifies the OS that it
is running on and does a conditional jump to different code, assuming that
the processor uses the same instruction set.
How different the OS's are would determine how much code could be shared.
If they are very different, then the executable file could be twice as
large, with no code in common.
It is even possible to make a disk that is readable as multiple disk
formats, so long as each is expecting the DIRectory tracks to be in
different places.
One of the many projects that I never got ready for market was to make a
multi-platform distribution format for software. "Save a few cents on
media costs by putting all of your platforms on one disk" But, after
August 1981, it eventually became apparent that the need for such was not
going to be around much longer.
If the boot code is short enough, it is even possible to have an FM, an
MFM, and a GCR boot sector in the same boot track, since each will not
even see any except its own. Formatting/recording a track with mixed
densities and/or encodings and multiple sector sizes is not a supported
function in most operating systems, nor even FDCs, but can be done with
some flux transition controllers.
12:43 p.m.
It is possible to create an executable file that
identifies the OS that it
is running on and does a conditional jump to different code, assuming that
the processor uses the same instruction set.
In some cases it should be possible to write a machine code program that executes
on 2 processors with wildly different instruciton sets.
One way that spring to mind (assuming instructions are a 1 or more bytes long) is to
find a byte which :
Processor A interprets as a single byte instruction
Processor B interprets as a 16 bit load to a register, hence taking 2 bytes of operand
Start the program with that byte, then put a 2-byte relative branch instruction in
Processor A machine code.
Processor A then reads the single byte instrucion and executes it (not doing a lot), then
runs the relative branch, goes off somewhere where there is pure Processor A code
Processor B reads the values for the relative branch into a register (which does no
damage)
then contines with the 4th byte of the program, which is pure Processor B code.
There are plenty of other ways to do it, I suspect certainly in some cases the right
instruction
bytes exist.
It is even possible to make a disk that is readable as
multiple disk
formats, so long as each is expecting the DIRectory tracks to be in
different places.
The OS-9 Level II distribution disk for the CoCo 3 is like that. It is mostly OS-9 format
(which
assumes some kind of pointers, if not the root directory, in cylinder 0). One file,
carefully postioned
at the middle track number, is actually a Color TRS-DOS directory and a couple of
programs. Said
directory appears to contain a very large (non-contiguous) file covering most of the disk,
along with
a couple of utilities (a bootstrap for the older version disk controller ROM being the
main one).
So when used under OS-9 it acts normally (directory where the OS expects to find it), just
with
this apparently useless file. Ditto under Color TRS-DOS.
-tony
1:19 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
It is even possible to make a disk that is readable as
multiple disk
formats, so long as each is expecting the DIRectory tracks to be in
different places.
On Sun, 20 Sep 2015, tony duell wrote:
So when used under OS-9 it acts normally (directory where the OS expects to find it), just
with
this apparently useless file. Ditto under Color TRS-DOS.
Exactly.
Trying to combine Coco, TRS80 model 1, and Apple][, would require track
17 to have MFM, FM, and GCR sectors/encoding.
BUT, many CP/M formats had different number of "reserved tracks" (how many
tracks the DIRectory was from the beginning of the disk). A good handful
of those could be mixed.
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.
A rare few vendors actually WANTED their disks to be inaccessible by
others! At NCC 84? (the one in Anaheim, where a couple of people died
from the heat in the tents), I asked Intertec
(Superbrain) and Televideo
about their disk formats. They both, and only them out
of all
manufacturers that I asked, asserted that the only possible reason to read
their disks with another machine was to pirate their proprietary software!
(So, I added those formats that night in my hotel room).
Dysan (remember them?) thought that they had a solution. When
"shirt-pocket" disks were on the horizon, there was much debate about 3" V
3.5" V 3.25". Dysan was pushing the 3.25" size, because other than a
solid hub, it was the same as a conventional floppy, and would require
much less retooling. They set standard format(s) for 3.25". Then to make
absolutely sure that it would get adopted, they bet the company, and set
up a software distribution company! Most major software products were
available on 3.25"!! I eventually ended up with some of the
drives and disks from Micropro (WORDSTAR). But then, Amstrad,
Gavilan, etc. went with 3". Apple and HP went with 3.5", and the battle
was over. In spite of the impressive library of available software, as
near as I can find out, the Seequa Chameleon 325 was the ONLY machine to
reach market with 3.25" drives.
George Morrow said that standards are wonderful, that everybody should
have a unique one of their own.
1:46 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
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.
3:03 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
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)
4:21 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
On 09/20/2015 03:03 PM, Fred Cisin wrote:
On Sun, 20 Sep 2015, ben 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.
--Chuck
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) 
5:11 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
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)
9:52 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
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
11:50 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
tony duell wrote:
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, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
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
21 Sep
21 Sep
7:02 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
[Russian PDP11-a-like]
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?
As far as I know, it can't. An RX02 can read/write an RX01 disk, but the software
interface to the controller is so different (the RX)2 uses DMA, the RX01 doesn't for
one thing) that the RX02 cannot boot 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?
The RX02 has a 'set density' command that can be used to reformat a
formatted single density disk as double density.
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)
The RX02 drive contains a couple of 2901s and a few of the sequencer chips
(I think 2911s, maybe 2909s). I've seen a 3rd party Qbus card that connected to
normal Shugart drives and which could red/write RX02 disks, I think that had
a couple of 2901s and a 2910 on it.
-tony
7:52 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
Not that I care what Holm Tiffe smokes, but I can at least comment what
you write, Tony. :-)
On 2015-09-21 16:02, tony duell wrote:
Of course an RX02 *drive* can read an RX01 *floppy*. And yes, a system
with an RX211 and an RX02 *drive* can boot from a floppy that what
written by an RX01 *drive*. But you need the boot code for an RX211
controller, and that boot code also needs to handle RX01 format
floppies. If the boot sector on the floppy is for an RX11, then no, an
RX211 will not understand things. The programming model for the two
controllers are different. You need different device drivers.
But this is really a question about the controller and the software
running it, not the floppy or the drive.
Yes. And it's just flipping a bit in the sector header. And the drive
changes between the densities for the data part of each sector. So you
can actually have different densities on a per-sector basis with an RX02
drive.
What people need to understand is that there are a bunch of controllers
and combinations. If we just contain our self to Unibus controllers, we
have two. The RX11 and RX211. The RX11 works with both the RX01 and
RX02. However, an RX02 needs to be set in an RX01-compatible mode if
used with an RX11 (a couple of dip-switches in the drive). And that also
turns it into essentially an RX01 (can't deal with double density within
the RX11 interface). The interface to an RX01 is different than the
interface to an RX02, even though they use the same flat cable.
The RX211 can be used with both an RX01 and an RX02, as far as I can
remember. But that implies that there would need to be some switch or
jumper on the RX211 in order to interface it with an RX01 (or some
automatic detection), and I can't remember seeing that. But it might
just be my memory failing me.
But the RX211 works differently than the RX11, so from a program point
of view, they are totally different.
The RX02 drive, then, in turn, can read and write both RX01 and RX02
floppies. No special tricks are required. The drive will detect, for
each sector, which format it is in, and will switch mode accordingly,
and return the right about of data (RX02 sectors holds 256 bytes, while
RX01 sectors holds 128 bytes). The software can thus also easily see
what type of floppy it is reading.
RX211 device drivers obviously then can handle both RX01 and RX02
floppies, when used with an RX02 drive. And from the software point of
view, the sectors just contains different amount of data.
Johnny
[Russian PDP11-a-like]
All bets are off when we talk about clones, since they might be rather
different in details...
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?
As far as I know, it can't. An RX02 can read/write an RX01 disk, but the software
interface to the controller is so different (the RX)2 uses DMA, the RX01 doesn't for
one thing) that the RX02 cannot boot 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?
The RX02 has a 'set density' command that can be used to reformat a
formatted single density disk as double density. 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)
The RX02 drive contains a couple of 2901s and a few of the sequencer chips
(I think 2911s, maybe 2909s). I've seen a 3rd party Qbus card that connected to
normal Shugart drives and which could red/write RX02 disks, I think that had
a couple of 2901s and a 2910 on it. 
8:03 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
On Sep 21, 2015, at 10:52 AM, Johnny Billquist <bqt
at Update.UU.SE> wrote:
...
Of course an RX02 *drive* can read an RX01 *floppy*. And yes, a system with an RX211 and
an RX02 *drive* can boot from a floppy that what written by an RX01 *drive*. But you need
the boot code for an RX211 controller, and that boot code also needs to handle RX01 format
floppies. If the boot sector on the floppy is for an RX11, then no, an RX211 will not
understand things. The programming model for the two controllers are different. You need
different device drivers.
But this is really a question about the controller and the software running it, not the
floppy or the drive.
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.
paul
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?
As far as I know, it can't. An RX02 can read/write an RX01 disk, but the software
interface to the controller is so different (the RX)2 uses DMA, the RX01 doesn't for
one thing) that the RX02 cannot boot an RX01 disk.
9:30 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
On 2015-09-21 17:03, Paul Koning wrote:
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.
Johnny
On Sep 21, 2015, at 10:52 AM, Johnny Billquist
<bqt at Update.UU.SE> wrote:
...
Of course an RX02 *drive* can read an RX01 *floppy*. And yes, a system with an RX211 and
an RX02 *drive* can boot from a floppy that what written by an RX01 *drive*. But you need
the boot code for an RX211 controller, and that boot code also needs to handle RX01 format
floppies. If the boot sector on the floppy is for an RX11, then no, an RX211 will not
understand things. The programming model for the two controllers are different. You need
different device drivers.
But this is really a question about the controller and the software running it, not the
floppy or the drive.
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. 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?
As far as I know, it can't. An RX02 can read/write an RX01 disk, but the software
interface to the controller is so different (the RX)2 uses DMA, the RX01 doesn't for
one thing) that the RX02 cannot boot an RX01 disk.
12:49 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
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.
1:27 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
On Sep 21, 2015, at 3:49 PM, Jerome H. Fine
<jhfinedp3k at compsys.to> wrote:
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
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.
6:49 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
On 2015-09-21 22:27, Paul Koning wrote:
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.
On Sep 21, 2015, at 3:49 PM, Jerome H. Fine
<jhfinedp3k at compsys.to> wrote:
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.
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. 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: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
10:22 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
Johnny Billquist wrote:
Not that I care what Holm Tiffe smokes, but I can at
least comment what
you write, Tony. :-)
On 2015-09-21 16:02, tony duell wrote:
Hmm..
I don't know if the Controller board (Inside the Computer) would
be "RX02-able" when I read this.
Just FYI:
http://www.tiffe.de/Robotron/PDP-VAX/E60/E60-06.jpg
That's the I4 Controller board that is connected with a flat cable to the
Drive..working as RX01 at least..
And that is the Controller Board in the Drive itself, the red cable goes
tro the I4 Board in The computer:
http://www.tiffe.de/Robotron/PDP-VAX/E60/disk-proz.jpg
..and if I look at this picuture it looks more that it contains AM2909
sequencers instead of an AM2910..
[Russian PDP11-a-like]
All bets are off when we talk about clones, since they might be rather
different in details...
>>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?
>
>As far as I know, it can't. An RX02 can read/write an RX01 disk, but the
>software
>interface to the controller is so different (the RX)2 uses DMA, the RX01
>doesn't for
>one thing) that the RX02 cannot boot an RX01 disk. 
Of course an RX02 *drive* can read an RX01 *floppy*. And yes, a system
with an RX211 and an RX02 *drive* can boot from a floppy that what
written by an RX01 *drive*. But you need the boot code for an RX211
controller, and that boot code also needs to handle RX01 format
floppies. If the boot sector on the floppy is for an RX11, then no, an
RX211 will not understand things. The programming model for the two
controllers are different. You need different device drivers.
But this is really a question about the controller and the software
running it, not the floppy or the drive.
Yes. And it's just flipping a bit in the sector header. And the drive
changes between the densities for the data part of each sector. So you
can actually have different densities on a per-sector basis with an RX02
drive.
What people need to understand is that there are a bunch of controllers
and combinations. If we just contain our self to Unibus controllers, we
have two. The RX11 and RX211. The RX11 works with both the RX01 and
RX02. However, an RX02 needs to be set in an RX01-compatible mode if
used with an RX11 (a couple of dip-switches in the drive). And that also
turns it into essentially an RX01 (can't deal with double density within
the RX11 interface). The interface to an RX01 is different than the
interface to an RX02, even though they use the same flat cable.
Ok, got it. But I know that this russian drive has the described Jumper
for switching between RX01 and RX02, but I don't know what this requires as
Controller in the computer...
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?
The RX02 has a 'set density' command that can be used to reformat a
formatted single density disk as double density. 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)
The RX02 drive contains a couple of 2901s and a few of the sequencer chips
(I think 2911s, maybe 2909s). I've seen a 3rd party Qbus card that
connected to
normal Shugart drives and which could red/write RX02 disks, I think that
had
a couple of 2901s and a 2910 on it.
The RX211 can be used with both an RX01 and an RX02, as far as I can
remember. But that implies that there would need to be some switch or
jumper on the RX211 in order to interface it with an RX01 (or some
automatic detection), and I can't remember seeing that. But it might
just be my memory failing me.
But the RX211 works differently than the RX11, so from a program point
of view, they are totally different.
The RX02 drive, then, in turn, can read and write both RX01 and RX02
floppies. No special tricks are required. The drive will detect, for
each sector, which format it is in, and will switch mode accordingly,
and return the right about of data (RX02 sectors holds 256 bytes, while
RX01 sectors holds 128 bytes). The software can thus also easily see
what type of floppy it is reading.
RX211 device drivers obviously then can handle both RX01 and RX02
floppies, when used with an RX02 drive. And from the software point of
view, the sectors just contains different amount of data.
Johnny
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, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
11:33 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
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, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
2:30 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
On 2015-09-21 02:11, Jerome H. Fine 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.
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.
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) 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
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
3:13 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
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.
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. 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 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 format program.
He expected DEC to make it work.
The account manager asked to see his DEC maintainance contract and had
to be restrained from tearing it up.
Through the window of the office was building site and the inevitable 50
gallon oil drum burning rubbish.
He was offered a choice; he could put the disks or the contract in the
burning drum.
Rod Smallwood
DEC supplied pre formatted disks
--
Wanted : KDJ11-E M8981 KK8-E M8300 KK8-E M8310 KK8-E M8320 KK8-E M8330
9:28 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
On 9/21/2015 4:30 AM, Johnny Billquist wrote:
On 2015-09-21 02:11, Jerome H. Fine wrote:
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.
JRJ
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.
9:34 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
On Sep 21, 2015, at 12:28 PM, Jay Jaeger <cube1 at
charter.net> wrote:
On 9/21/2015 4:30 AM, Johnny Billquist 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
On 2015-09-21 02:11, Jerome H. Fine wrote:
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. 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.
9:47 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
On 2015-09-21 18:34, Paul Koning wrote:
For Unibus, the controller would be the RUX50. MSCP, as you say. And I
suspect that one didn't do formatting.
For Qbus, it would be the RQDX, which was MSCP, and did both the RD
disks and RX50. I'm not sure, but I think the RQDX could perform some
sort of low level formatting for the RD anyway. Not sure what it would
say if you pointed it at the RX...
On Sep 21, 2015, at 12:28 PM, Jay Jaeger
<cube1 at charter.net> wrote:
On 9/21/2015 4:30 AM, Johnny Billquist 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. On 2015-09-21 02:11, Jerome H. Fine wrote:
There was also a standalone PDP-11 diagnostic program available that
could do it. > 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
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.
Johnny
10:20 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
On Sep 21, 2015, at 12:47 PM, Johnny Billquist <bqt
at update.uu.se> wrote:
...
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
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.
6:29 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
On 2015-09-21 19:20, Paul Koning wrote:
DECs various decisions related to the PRO are probably a mystery to all.
On Sep 21, 2015, at 12:47 PM, Johnny Billquist
<bqt at update.uu.se> wrote:
...
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 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. 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: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
1:22 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
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
1:32 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
RD51, RD52, RD53, RD54, RD31, RD32, RX33 on an *** RQDX3 **
(There should be a "Fat Finger Day" ;) ).
JRJ
On 9/21/2015 3:22 PM, 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.
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
2:26 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
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
6:58 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
On 2015-09-21 23:26, Jerome H. Fine wrote:
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?
Good question. I don't know why, but it is correct, as far as I know.
The RQDX3 can format an RX33. Since the RX33 can be formatted for either
single density or double density, and for that floppy this actually
means it needs to be reformatted, the RQDX3 supports doing that. So I
guess the microcode in the RQDX3 just simply detects the RX50 and
refuses to do the operations required to do formatting there.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
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
20 Sep
20 Sep
5:32 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
> 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 cisin at xenosoft.com
6:55 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
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
7:59 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
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.
8:12 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
On 09/20/2015 07:59 PM, ben wrote:
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.
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.
I've seen plenty of CNC systems that used cassettes as a paper tape
replacement, but none were running CP/M.
--Chuck
8:48 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
On 9/20/2015 9:12 PM, Chuck Guzis wrote:
On 09/20/2015 07:59 PM, ben wrote:
This is the other option: Basic
CP/M was for the REAL 8 bit systems.
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.
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.
I've seen plenty of CNC systems that used cassettes as a paper tape
replacement, but none were running CP/M. --Chuck
OS/9 was nice for the 6809 but all I had
was 1 floppy with the COCO II.
Ben.
10:39 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
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
10:42 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
On 09/20/2015 09:55 PM, tony duell wrote:
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
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?
21 Sep
21 Sep
6:57 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
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.
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
8:54 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
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.
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.
Valdocs influenced the perception and image of the machine.
9:49 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
On 09/21/2015 08:54 AM, Fred Cisin wrote:
Valdocs influenced the perception and image of the
machine.
That. All the QX10 conversion jobs I've ever received have been for
valdocs documents. Nothing, in the way of accounting, process conrol,
etc. I can do accounting on many word processors, but they're still
fundamentally word processors.
--Chuck
10:22 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
Valdocs
influenced the perception and image of the machine.
That. All the QX10 conversion jobs I've ever received have been for
valdocs documents. Nothing, in the way of accounting, process conrol,
etc. I can do accounting on many word processors, but they're still
fundamentally word processors.
11:11 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
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
11:22 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
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. 
10:31 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
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" <cclist at sydex.com>
To: "General Discussion: On-Topic and Off-Topic
Posts" <cctalk at 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:
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
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?
10:35 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
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
11:17 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
> 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.
11:31 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
On 09/21/2015 11:17 AM, Fred Cisin wrote:
and, of course, as a third type, Exatron
Stringy-Floppy computer
based, but NOT entirely usable.
I was hoping that nobody would mention that thing. Okay, I'll add the
TI Wafertape...
--Chuck
11:41 a.m.
New subject: Multi-platform distribution format (Was: Backups [was
> 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.
20 Sep
20 Sep
8:32 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
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 cisin at xenosoft.com
8:08 p.m.
New subject: Multi-platform distribution format (Was: Backups [was
On 09/20/2015 03:46 PM, ben wrote:
On 9/20/2015 2:19 PM, Fred Cisin wrote:
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
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. 
12:47 p.m.
> I would guess it would be incredibly hard to make
a "disk" virus
> that would work on greatly differing OS's like Linux AND Windows.
This is actually a good reason to encrypt your whole disk. The disk
can't serve up working malware if the bits it returns get mangled by
decryption with an unknown(-to-the-disk) key before being used.
Of course, this will generally mean booting off something other than
the disk in question; that thing then becomes a possible target for
attack. But this can be made more or less arbitrarily hard for the
attacker - consider network booting from a bootserver that isn't even
running the same ISA as the client....
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
5:55 p.m.
Fred Cisin wrote:
On Sun, 20 Sep 2015, Jon Elson wrote:
I used the above example when I created a CD which had files to be used
with RT-11 in addition to being a normal CD under Windows. I found that
for a normal CD under Windows, sectors 0 to 15 (hard disk blocks 0 to 63)
on the CD were empty. I don't know if that area is reserved for boot code
under Windows when the CD is bootable, but my goal did not require the
CD to be bootable under Windows.
Under RT-11, the first six hard disk blocks (0 to 5) are reserved for boot
code (when that is present) and hard disk blocks from 6 up to 67 are used
for an RT-11 directory. RT-11 rarely uses that large a directory and the
minimum directory is only two hard disk block long. For the CD, that
allowed an RT-11 directory from hard disk blocks 6 to 63 or up to
sector 15.
What may have been unique was that only the RT-11 directory and the
CD ISO directory were distinct. Otherwise, all the files were the same
with each directory pointing to the same location on the ISO image.
In practice, the same CD could be used as a data CD under Windows
in addition to being a boot disk on a real DEC RT-11 system which
supported that operating system. I was actually on the phone at one
point when the first individual who received a copy of the CD used
it to boot RT-11 on a CDROM drive configured to support 512 byte
blocks using a CQD 220/TM host adapter.
The same ISO image file can also be used under both SimH and Ersatz-11
in the same manner, although it is STRONGLY recommended that the
ATTACH or MOUNT command use the ISO image file as READ ONLY.
Ersatz-11 is also able to MOUNT the actual RAW CD on a CDROM
SCSI drive and boot RT-11 from the CD. Of course, the Windows
operating system under which Ersatz-11 is also able to see all the same
files on the CD as well, BUT NOT AT THE SAME TIME - at
least I never did attempt that possibility.
If this can be done with Windows and RT-11 which have completely
different file structures and instructions sets, it certainly seems likely
that other operating systems and system hardware can also be supported.
The one thing that seemed reasonable from a security point of view is
that the CD is READ ONLY, so no virus can be introduced on the
CD after it is burned.
Tim Shoppa did almost the same thing with his RT-11 Freeware CD
when an RT-11 directory was added at the end of the ISO image file
for the CD.
If anyone finds this interesting and has additional questions, please ask.
Jerome Fine
Well, one would assume this is also OS specific.
I would guess it
would be incredibly hard to make a "disk" virus that would work on
greatly differing OS's like Linux AND Windows. No telling what would
happen if one of these disk viruses got onto a hard drive on a
Windows system and then the drive was reformatted and loaded with Linux.
Most likely you'd have odd crashes or something.
It is possible to create an executable file that identifies the OS
that it is running on and does a conditional jump to different code,
assuming that the processor uses the same instruction set.
How different the OS's are would determine how much code could be
shared. If they are very different, then the executable file could be
twice as large, with no code in common.
It is even possible to make a disk that is readable as multiple disk
formats, so long as each is expecting the DIRectory tracks to be in
different places.
One of the many projects that I never got ready for market was to make
a multi-platform distribution format for software. "Save a few cents
on media costs by putting all of your platforms on one disk" But,
after August 1981, it eventually became apparent that the need for
such was not going to be around much longer.
If the boot code is short enough, it is even possible to have an FM,
an MFM, and a GCR boot sector in the same boot track, since each will
not even see any except its own. Formatting/recording a track with
mixed densities and/or encodings and multiple sector sizes is not a
supported function in most operating systems, nor even FDCs, but can
be done with some flux transition controllers.
21 Sep
21 Sep
7:25 a.m.
On Sep 20, 2015, at 8:55 PM, Jerome H. Fine
<jhfinedp3k at compsys.to> wrote:
I did something similar a long time ago, when some people at DEC were working to create an
"Everything for RSTS/E" CD (similar, I think, to what was done for VMS at that
time). In my utility "rstsflx" I added a mode to produce a split structure
somewhat like what you mentioned, but simpler. The RSTS file system looked like a CD
file, and the rest of the CD looked like allocated space to the RSTS file system.
I heard rumors that the CD it was meant for was created, but I never actually saw one.
paul
...
I used the above example when I created a CD which had files to be used
with RT-11 in addition to being a normal CD under Windows. I found that
for a normal CD under Windows, sectors 0 to 15 (hard disk blocks 0 to 63)
on the CD were empty. I don't know if that area is reserved for boot code
under Windows when the CD is bootable, but my goal did not require the
CD to be bootable under Windows. 
2:32 p.m.
On 21 September 2015 at 01:55, Jerome H. Fine <jhfinedp3k at compsys.to> wrote:
Before the price of media and storage dropped so much NetBSD install
ISOs were multiboot - one image which booted on alpha, i386, pmax, and
sparc (and I think theoretically also macppc, vax and sun2, sun3 and
sun3x if it hadn't run out of room for the install files :)
http://www.netbsd.org/docs/bootcd.html#multiimage
So much cool stuff no-one bothers with now days...
David
Fred Cisin
wrote:
On Sun, 20 Sep 2015, Jon Elson wrote:
I used the above example when I created a CD which had files to be used
with RT-11 in addition to being a normal CD under Windows. I found that
for a normal CD under Windows, sectors 0 to 15 (hard disk blocks 0 to 63)
on the CD were empty. I don't know if that area is reserved for boot code
under Windows when the CD is bootable, but my goal did not require the
CD to be bootable under Windows.
Under RT-11, the first six hard disk blocks (0 to 5) are reserved for boot
code (when that is present) and hard disk blocks from 6 up to 67 are used
for an RT-11 directory. RT-11 rarely uses that large a directory and the
minimum directory is only two hard disk block long. For the CD, that
allowed an RT-11 directory from hard disk blocks 6 to 63 or up to
sector 15.
What may have been unique was that only the RT-11 directory and the
CD ISO directory were distinct. Otherwise, all the files were the same
with each directory pointing to the same location on the ISO image.
In practice, the same CD could be used as a data CD under Windows
in addition to being a boot disk on a real DEC RT-11 system which
supported that operating system. I was actually on the phone at one
point when the first individual who received a copy of the CD used
it to boot RT-11 on a CDROM drive configured to support 512 byte
blocks using a CQD 220/TM host adapter.
The same ISO image file can also be used under both SimH and Ersatz-11
in the same manner, although it is STRONGLY recommended that the
ATTACH or MOUNT command use the ISO image file as READ ONLY.
Ersatz-11 is also able to MOUNT the actual RAW CD on a CDROM
SCSI drive and boot RT-11 from the CD. Of course, the Windows
operating system under which Ersatz-11 is also able to see all the same
files on the CD as well, BUT NOT AT THE SAME TIME - at
least I never did attempt that possibility.
If this can be done with Windows and RT-11 which have completely
different file structures and instructions sets, it certainly seems likely
that other operating systems and system hardware can also be supported.
The one thing that seemed reasonable from a security point of view is
that the CD is READ ONLY, so no virus can be introduced on the
CD after it is burned.
Tim Shoppa did almost the same thing with his RT-11 Freeware CD
when an RT-11 directory was added at the end of the ISO image file
for the CD.
If anyone finds this interesting and has additional questions, please ask. Well, one would assume this is also OS specific.
I would guess it would
be incredibly hard to make a "disk" virus that would work on greatly
differing OS's like Linux AND Windows. No telling what would happen if one
of these disk viruses got onto a hard drive on a Windows system and then the
drive was reformatted and loaded with Linux.
Most likely you'd have odd crashes or something.
It is possible to create an executable file that identifies the OS that it
is running on and does a conditional jump to different code, assuming that
the processor uses the same instruction set.
How different the OS's are would determine how much code could be shared.
If they are very different, then the executable file could be twice as
large, with no code in common.
It is even possible to make a disk that is readable as multiple disk
formats, so long as each is expecting the DIRectory tracks to be in
different places.
One of the many projects that I never got ready for market was to make a
multi-platform distribution format for software. "Save a few cents on media
costs by putting all of your platforms on one disk" But, after August 1981,
it eventually became apparent that the need for such was not going to be
around much longer.
If the boot code is short enough, it is even possible to have an FM, an
MFM, and a GCR boot sector in the same boot track, since each will not even
see any except its own. Formatting/recording a track with mixed densities
and/or encodings and multiple sector sizes is not a supported function in
most operating systems, nor even FDCs, but can be done with some flux
transition controllers.
6:59 p.m.
On 2015-09-21 23:32, David Brownlee wrote:
On 21 September 2015 at 01:55, Jerome H. Fine
<jhfinedp3k at compsys.to> wrote:
Before the price of media and storage dropped so much NetBSD install
ISOs were multiboot - one image which booted on alpha, i386, pmax, and
sparc (and I think theoretically also macppc, vax and sun2, sun3 and
sun3x if it hadn't run out of room for the install files :)
http://www.netbsd.org/docs/bootcd.html#multiimage
So much cool stuff no-one bothers with now days...
I actually did boot NetBSD/vax from CD at one point, so it worked in
practice as well.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Fred
Cisin wrote:
On Sun, 20 Sep 2015, Jon Elson wrote:
I used the above example when I created a CD which had files to be used
with RT-11 in addition to being a normal CD under Windows. I found that
for a normal CD under Windows, sectors 0 to 15 (hard disk blocks 0 to 63)
on the CD were empty. I don't know if that area is reserved for boot code
under Windows when the CD is bootable, but my goal did not require the
CD to be bootable under Windows.
Under RT-11, the first six hard disk blocks (0 to 5) are reserved for boot
code (when that is present) and hard disk blocks from 6 up to 67 are used
for an RT-11 directory. RT-11 rarely uses that large a directory and the
minimum directory is only two hard disk block long. For the CD, that
allowed an RT-11 directory from hard disk blocks 6 to 63 or up to
sector 15.
What may have been unique was that only the RT-11 directory and the
CD ISO directory were distinct. Otherwise, all the files were the same
with each directory pointing to the same location on the ISO image.
In practice, the same CD could be used as a data CD under Windows
in addition to being a boot disk on a real DEC RT-11 system which
supported that operating system. I was actually on the phone at one
point when the first individual who received a copy of the CD used
it to boot RT-11 on a CDROM drive configured to support 512 byte
blocks using a CQD 220/TM host adapter.
The same ISO image file can also be used under both SimH and Ersatz-11
in the same manner, although it is STRONGLY recommended that the
ATTACH or MOUNT command use the ISO image file as READ ONLY.
Ersatz-11 is also able to MOUNT the actual RAW CD on a CDROM
SCSI drive and boot RT-11 from the CD. Of course, the Windows
operating system under which Ersatz-11 is also able to see all the same
files on the CD as well, BUT NOT AT THE SAME TIME - at
least I never did attempt that possibility.
If this can be done with Windows and RT-11 which have completely
different file structures and instructions sets, it certainly seems likely
that other operating systems and system hardware can also be supported.
The one thing that seemed reasonable from a security point of view is
that the CD is READ ONLY, so no virus can be introduced on the
CD after it is burned.
Tim Shoppa did almost the same thing with his RT-11 Freeware CD
when an RT-11 directory was added at the end of the ISO image file
for the CD.
If anyone finds this interesting and has additional questions, please ask. Well, one would assume this is also OS specific.
I would guess it would
be incredibly hard to make a "disk" virus that would work on greatly
differing OS's like Linux AND Windows. No telling what would happen if one
of these disk viruses got onto a hard drive on a Windows system and then the
drive was reformatted and loaded with Linux.
Most likely you'd have odd crashes or something.
It is possible to create an executable file that identifies the OS that it
is running on and does a conditional jump to different code, assuming that
the processor uses the same instruction set.
How different the OS's are would determine how much code could be shared.
If they are very different, then the executable file could be twice as
large, with no code in common.
It is even possible to make a disk that is readable as multiple disk
formats, so long as each is expecting the DIRectory tracks to be in
different places.
One of the many projects that I never got ready for market was to make a
multi-platform distribution format for software. "Save a few cents on media
costs by putting all of your platforms on one disk" But, after August 1981,
it eventually became apparent that the need for such was not going to be
around much longer.
If the boot code is short enough, it is even possible to have an FM, an
MFM, and a GCR boot sector in the same boot track, since each will not even
see any except its own. Formatting/recording a track with mixed densities
and/or encodings and multiple sector sizes is not a supported function in
most operating systems, nor even FDCs, but can be done with some flux
transition controllers. 
23 Sep
23 Sep
4:38 p.m.
On 21/09/15 01:55, Jerome H. Fine wrote:
I used the above example when I created a CD which had files to be used
with RT-11 in addition to being a normal CD under Windows. I found that
for a normal CD under Windows, sectors 0 to 15 (hard disk blocks 0 to 63)
on the CD were empty. I don't know if that area is reserved for boot
code
under Windows when the CD is bootable, but my goal did not require the
CD to be bootable under Windows.
I did something very similar (or rather, used someone else's code to do
something
very similar) with ODS-2 under OpenVMS and ISO9660 (which is what Windows
uses for CD media iirc).
As you say, ISO9660 leaves the first 16 (or thereabouts) 2048 byte
blocks undefined.
ODS-2, on the other hand, uses them. So the code builds an ISO9660 CD
and then
overlays the ODS-2 structure on top. It finds the ISO9660 directory
structures and
arranges for them to live in BADBLK.SYS so VMS is happy enough when
mounting the
media. All the ODS-2 structures get packed into the beginning of the
image so anything
looking at the ISO9660 side sees nothing untoward. This only works well
for filetypes
that have no special structure under ODS-2: basically CR-LF text files
and binary
formats (such as PDF). I still have a CD that I built this way many
moons ago.
I remember reading a message in one of the EASYnet NOTES conferences
(inside DEC) which more or less said that ISO9660 leaving those initial
blocks
free wasn't a coincidence and that DEC's representative (Andy Goldstein
perhaps)
had pushed for that.
Antonio
arcarlini at iee.org
3379
days inactive
3382
days old
58 comments
15 participants
participants (15)
-
a.carlini＠ntlworld.com -
abs＠absd.org -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
bqt＠update.uu.se -
cclist＠sydex.com -
cisin＠xenosoft.com -
cube1＠charter.net -
elson＠pico-systems.com -
holm＠freibergnet.de -
jhfinedp3k＠compsys.to -
mhs.stein＠gmail.com -
mouse＠Rodents-Montreal.ORG -
paulkoning＠comcast.net -
rodsmallwood52＠btinternet.com