Re: Multi-platform distribution format (Was: Backups [was
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
> 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
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 mana
Re: Backups [was Re: Is tape dead?]
On 2015-09-21 23:32, David Brownlee wrote: On 21 September 2015 at 01:55, Jerome H. Fine wrote: Fred Cisin wrote: 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. 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. 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: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Multi-platform distribution format (Was: Backups [was
On 2015-09-21 23:26, Jerome H. Fine wrote: >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? 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: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Multi-platform distribution format (Was: Backups [was
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
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 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 spe
Re: Multi-platform distribution format (Was: Backups [was
>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: Backups [was Re: Is tape dead?]
On 21 September 2015 at 01:55, Jerome H. Fine wrote: >>Fred Cisin wrote: > >> 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. > > > 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. 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
Re: 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 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
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 > > > > >
Re: Multi-platform distribution format (Was: Backups [was
> 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
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
> > 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
>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. Plus in almost every case, the RX01 controller and drive are never present when the RX02 controller and drive are present. The reason is probably that the RX02 drive can read and write RX01 floppies, so why bother. I would guess that both an RX01 and an RX02 could be present in the Qbus (and likely in the Unibus) at the same time, but the CSR and VECTOR would then have to be set to different values - whereas normally when only one or the other is present, the same CSR and VECTOR address is assigned. Also, the CSR of both controllers has the same bit, but in one controller it is 0 and the other controller it is 1 - at least as far as I can remember. That said, a device driver which is able to handle both an RX01 and RX02 would require both sets of the code which is very different along with the additional code to determine which hardware is actually being used. So for RT-11, it seems reasonable that DEC kept the DX(X).SYS device drivers to be used only for the RX01 drive and the DY(X).SYS device drivers to be used only for the RX02 drive. There was one sort of exception when the installation code was produced. Each device, DX or DY, driver checks to make sure that the CSR being tested is for the device which would be installed. The installation code for both DX and DY are executed if the CSR is present when the system is booted and the device driver which passes the test is installed. 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. Under RSX-11 where the memory is used somewhat differently, I presume that the device drive could have supported both the RX01 drive and the RX02 drive. But I would need Johnny to comment on that possibility. Jerome Fine
Re: 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.
Re: 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, i...@tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
Re: 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
Re: 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.
RE: 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.
Re: 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
Re: Multi-platform distribution format (Was: Backups [was
On 21/09/2015 17:43, Johnny Billquist wrote: On 2015-09-21 18:29, Jerome H. Fine wrote: >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. Agreed. The DEC RX01 and RX02 drives could not do a low level format. But your comment above suggested you needed to find some special drive and controller combo which supported RX02 floppies, which would just be irrelevant. If you could format the floppy anywhere, to just IBM SSSD format, then you were good. The RX02 special stuff is something you then did on an RX02. 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 No. (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 Quite possible. (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 Also quite possible. And would be what Jay Jager claims. I don't know myself. I know that RSX refuses to even try formatting an RX50. If it in fact could, I don't know. But the floppy drive itself obviously could. (One reason why some places bought Rainbows in fact...) 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 I don't know how to respond since different individuals will interpret your story in the opposite manner, So I will add my own experience when I used the RX02 drive from DEC along with the DSD RX03 floppy drive. Around 1990 after I
RE: 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
Re: 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" To: "General Discussion: On-Topic and Off-Topic Posts" 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
> > 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. 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. I see absolutely no reason why the latter could not run spreadsheets, accounting programs, language compilers/interpreters, etc. -tony
Re: 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: > > > >[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. 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.. > > 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. > > >>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. > > 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. > > >>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. > > 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... > > 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, &
Re: Multi-platform distribution format (Was: Backups [was
> 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
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
Re: Multi-platform distribution format (Was: Backups [was
On 2015-09-21 18:34, Paul Koning wrote: 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. 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... 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
Re: Multi-platform distribution format (Was: Backups [was
On 2015-09-21 18:29, Jerome H. Fine wrote: >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. Agreed. The DEC RX01 and RX02 drives could not do a low level format. But your comment above suggested you needed to find some special drive and controller combo which supported RX02 floppies, which would just be irrelevant. If you could format the floppy anywhere, to just IBM SSSD format, then you were good. The RX02 special stuff is something you then did on an RX02. 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 No. (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 Quite possible. (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 Also quite possible. And would be what Jay Jager claims. I don't know myself. I know that RSX refuses to even try formatting an RX50. If it in fact could, I don't know. But the floppy drive itself obviously could. (One reason why some places bought Rainbows in fact...) 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 I don't know how to respond since different individuals will interpret your story in the opposite manner, So I will add my own experience when I used the RX02 drive from DEC along with the DSD RX03 floppy drive. Around 1990 after I had acquired the DSD RX03 floppy drive in a DSD 880
RE: Multi-platform distribution format (Was: Backups [was
> 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
> 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
>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 (a
Re: Multi-platform distribution format (Was: Backups [was
On 2015-09-21 17:03, Paul Koning wrote: On Sep 21, 2015, at 10:52 AM, Johnny Billquist wrote: ... 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. 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. Johnny
Re: 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: >> >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. JRJ
RE: 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. On Mon, 21 Sep 2015, tony duell wrote: I guess it depends on what you call a 'commercial' system. I certainly wouldn't class the PX8 as a home computer. It's a "portable" computer. Not typicaally "industrial" except for VERY light industry. Quite suitable for field engineers, etc. The HX-20 was used around here for a while in some cable TV field troubleshooting. 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.
Re: Multi-platform distribution format (Was: Backups [was
> On Sep 21, 2015, at 10:52 AM, Johnny Billquist wrote: > > ... >>> 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. 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
Re: 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: [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. 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. 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. 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. 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
RE: 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
RE: 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 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
On 21/09/2015 10:30, Johnny Billquist wrote: On 2015-09-21 02:11, Jerome H. Fine wrote: >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. 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. 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
Re: Multi-platform distribution format (Was: Backups [was
On 2015-09-21 02:11, Jerome H. Fine wrote: >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. 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. 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: 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 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
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
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
> > 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? -tony
RE: 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
Re: 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: 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. This is the other option: Basic CP/M was for the REAL 8 bit systems. --Chuck OS/9 was nice for the 6809 but all I had was 1 floppy with the COCO II. Ben.
Re: 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 ci...@xenosoft.com
Re: 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
Re: 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: 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
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
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
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
>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: Backups [was Re: Is tape dead?]
>Fred Cisin wrote: 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. 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
Re: Multi-platform distribution format (Was: Backups [was
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
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
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.
Re: Backups [was Re: Is tape dead?]
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.