Loading ...
Sorry, an error occurred while loading the content.

Re: Altair CP/M, Lifeboard, Burcon and InfoWorld

Expand Messages
  • thinkpast
    Excuse me for posting a kind of cold response, to the addition of the Burcon CP/M 2.2 BIOS and 88-DCDD disk images which were recently added to the archives
    Message 1 of 16 , Feb 18, 2013
    • 0 Attachment
      Excuse me for posting a kind of "cold" response, to the addition of the Burcon CP/M 2.2 BIOS and 88-DCDD disk images which were recently added to the archives of this discussion group. I don't follow discussions here except by Web access. I have not run through all the discussion of this particular bit of work. But as a member I get announcements from Yahoo about files put in the archives. This work caught my eye, I read the notes included, and I have some comments which I think require some explanation.

      I think my comments are worth posting, because I've supported S-100 repair and restoration for many, many years, and I have some opinions which I think are backed up by experience and research. Excuse me if it takes lots of words to substantiate my opinions.

      The note with that 88-DCDD software, has comments about CP/M 1.4 vs 2.2, and the 88-DCDD software, that suggests more-or-less that hardware and software were better, or more popular, or other positive attributes, by the time CP/M 2.2 came around. The writer seems surprised that "every CP/M implementation imaginable" is not archived, and how much software is required for that particular controller.

      It seems to me that people today who write about the apparent complexity of mid-1970's microcomputer hardware, don't consider that older microcomputers simply did not HAVE the conveniences of what became "standard" sets of complex integrated circuits, to perform what became "standard" functions. Specifically, Western Digital's floppy disk controller chip family. The 88-DCDD software was busy and performed the most fundamental functions, simply because THAT WAS NECESSARY when that product was designed and produced.

      I have notes about even earlier floppy controllers on my Web site,
      as produced by Digital Systems, designed by Dr. John Torode (who built Gary Kildall's first floppy controller). Google will find those notes.

      The 99-DCDD hardware had to do many things under the direction of software, that, say, the WD1771 did automatically but years LATER. When you consider how "discrete" that and other floppy disk controllers were in the mid-1970's, then it eventually becomes no surprise that one sees what you call IN RETROSPECT "non-standard" disk formats. The disk formats did not BECOME "standard", until there were commonly used sets of FDC chips which IMPLEMENTED those "standards". (The IBM 3740 SSSD soft-sectored format was cited by disk drive manufacturers as a standard track/sector format. That was very hard to achieve so many early floppy controllers used hard not soft sectoring.)

      Likewise, the notion that CP/M 2.2 was "more popular" than CP/M 1.4, is simply another way of saying 2.2 came later, when microcomputing was a bigger industry. The surprise that the controller wasn't simply updated by Pertec for use with CP/M 2.2, simply says that Pertec did not happen to bother to do that, they had newer products to work on. Some other company (guys at a kitchen table probably) decided to provide that upgrade and make that dollar. These things happened or did not happen, a matter of circumstance.

      So "standards" that one "expects", are simply practices that came to become common LATER, under various circumstances and when business was greater. Conversely, when you look BEFORE such standards were established, you should EXPECT to see substantial variations in practices. In other words, don't be surprised, to be surprised.

      Another case of "surprise" in the note, was a lack of "every conceivable CP/M disk" in various on-line archives. Why assume that? On my S-100 Web site, I list at last count over 140 BRANDS of S-100 computer company. And there were many more CP/M computers in the 1970's and later than S-100 (Altair bus). Online archives of disk images only cover a fraction of those brands; they don't cover all the various OS's and versions too. There were a LOT of microcomputer companies in the 1970's, a LOT of products with lots of changes over time.

      From a larger point of view: consider that disk image archives are not of a single disk image "standard". Why? the archive owners used their own tools to create the images, or used tools decades old. I see this over and over, and (excuse me) I see it with this particular "archive", which uses the "Altair32 and SIMH emulators" disk image methods, whatever those are. The assumption is that anyone interested, will use this tool, to recover the files for intended use. "Everybody" is presumed to do that.

      No point in arguing the merits of various disk formats, or various emulators, or why someone may be interested. From my point of view - recovery of software from decades past, for reuse decades ahead - please do an old man a favor. If you are gonna post tiny 230K disk images, why not post a ZIP file of the source files and executables too? As you've already posted/archived separately the BIOS, why not add the BOOT, FORMAT and SYSGEN (or equivalents) and make a ZIP file of that? "ZIP" is "the standard" (chuckle) file archive scheme, anyway more "standard" than the disk image format in use here.

      And by the way - having a virtual disk image is not enough, if you don't have the tool to regenerate that image back into a diskette, for use with that hardware. I have no idea if the emulators or their associated tools can reproduce the original disks now imaged. I DO know a "common" disk imaging utility of a few decades ago, "IMAGEDSK" by Dave Dunfield, *will* reproduce disk formats, with ordinary (1980's 90's 00's) class computer hardware. I encourage use of this program, and its archive, every chance I get. Again - google my Web site and you'll find my notes, or google for Dave's good work.

      One other consideration. I see in parts of the posted discussions here, some of the background work on the history of these disk images and sources of information. It looks like good work, I've done history-of work like that and so I know how hard it can be. I urge the author to consolidate and add those notes and other's comments, to the "archive" with the disk images. Just as it's hard to look back 30, 35 years to make sense of how things were done by MITS and Pertec; it will be harder still, decades from now.

      Why go to all this trouble? Well, someone not active here, may get active, if you leave more clues and make it easier to see what's been done. That's the simplest version of what I've been saying today!

      How hard will it be tomorrow? Imagine a future only of portable touch-based computers, running virtual OS's and high-level languages ONLY. Do you think those folks, will find anything "standard" about working with binary code? About magnetic rotating media? with *keyboards*? The more clues we leave behind, the more likely this stuff will be preserved past our lifetimes, which for some of us is not much longer.

      Herb Johnson
      retrotechnology.com
    • W Tom
      Hi Herb, It is good to hear from you. I zipped the .dsk files in the library. Note that ZIP is the standard , but the emulators now have SQUEEZE/UNSQUEEZE and
      Message 2 of 16 , Feb 18, 2013
      • 0 Attachment
        Hi Herb,

        It is good to hear from you. I zipped the .dsk files in the library. Note that ZIP is "the standard", but the emulators now have SQUEEZE/UNSQUEEZE and .LBR support on Altair format . Some source code is in .AQM files. Other files are in .LBR library files. An uzipped file may still require old tools.

        Two things to consider: 1) The .dsk files are not just an archive, most programs run on either emulator; 2) Some images are not CP/M format and all require a MITS controller. IMAGEDSK may be more useful for Altair software written for the Tarbell 1011D and soft-sectored formats. IMAGEDSK would be good for ICOM formats too, if someone has a copy.

        I think a tool to regenerate diskettes will be produced. Keep in mind that very few people will ever have an Altair with working MITS controller and drives. Saving the accounting software was an important event for me. Being able to run the software on the emulators is important too.

        The archive was make because my equipment is working today. I don't know about tomorrow, but now know I can use an emulator with the Accounting software and MITS DOS. Yesterday, I did not have Mike's capture program and now I have a choice emulators. My assumption is that anybody interested has few other choices. Thanks to Mike more choices do and will exist.

        One case of "surprise" is that is that the only known release of Altair CP/M 2.2 is Lifeboat and no copies have been archived. The Burcon diskette is a pre-release partial copy of CP/M. Mike's work increases knowledge of MITS BIOS technology and will produce the programs you note as missing. Mike also made some mods that make the emulators more useful.

        W. Tom S.
      • deramp5113
        Herb, Thank you for your response. While I m inclined to respond to all of your points, we all know that would end up in an unpleasant downward spiral on this
        Message 3 of 16 , Feb 18, 2013
        • 0 Attachment
          Herb,

          Thank you for your response. While I'm inclined to respond to all of your points, we all know that would end up in an unpleasant downward spiral on this forum, so I won't. However, I would like to address the archive format contestation.

          No matter what archive format you start with, there are only three common platforms on which someone can run the Burcon release of CP/M (or any other Altair floppy-based software for that matter): 1) on an S100 computer with the proper MITS floppy controller and drive, 2) on the Altair32 emulator, or 3) on the SIMH emulator. The archive format posted in the Files section is compatible with all three of these possible destinations (as stated in the pdf file about Burcon CP/M, the images can be written directly to an 8" Altair floppy). Any other archive format would be less desirable as it could not be as easily transferred to the three platforms available for execution.

          The archive format chosen is hardly a "format" at all -- it is simply a byte for byte copy of the floppy from track zero, sector zero, byte zero through track 76, sector 31, byte 136. I have written simple utilities that run on the Altair to image any floppy to a PC, or to create a floppy from an image stored on a PC. As an added bonus, the archive format happens to be compatible with the only other platforms on which you could run an Altair disk.

          For readers not interested in actually running the disk images, but who still want to review the source code, you make a valid point that source code should be made available separate from the disk images. I did this, of course, with the BIOS itself as this was the central piece of my effort. I did not generate source code for FORMAT or SYSGEN as the original binaries on the Burcon disk for these utilities work without modification. However, I did disassemble and comment the boot loader, so I will post that as well.

          Mike




          --- In altaircomputerclub@..., "thinkpast" <hjohnson@...> wrote:
          >
          >
          >
          >
          > Excuse me for posting a kind of "cold" response, to the addition of the Burcon CP/M 2.2 BIOS and 88-DCDD disk images which were recently added to the archives of this discussion group. I don't follow discussions here except by Web access. I have not run through all the discussion of this particular bit of work. But as a member I get announcements from Yahoo about files put in the archives. This work caught my eye, I read the notes included, and I have some comments which I think require some explanation.
          >
          > I think my comments are worth posting, because I've supported S-100 repair and restoration for many, many years, and I have some opinions which I think are backed up by experience and research. Excuse me if it takes lots of words to substantiate my opinions.
          >
          > The note with that 88-DCDD software, has comments about CP/M 1.4 vs 2.2, and the 88-DCDD software, that suggests more-or-less that hardware and software were better, or more popular, or other positive attributes, by the time CP/M 2.2 came around. The writer seems surprised that "every CP/M implementation imaginable" is not archived, and how much software is required for that particular controller.
          >
          > It seems to me that people today who write about the apparent complexity of mid-1970's microcomputer hardware, don't consider that older microcomputers simply did not HAVE the conveniences of what became "standard" sets of complex integrated circuits, to perform what became "standard" functions. Specifically, Western Digital's floppy disk controller chip family. The 88-DCDD software was busy and performed the most fundamental functions, simply because THAT WAS NECESSARY when that product was designed and produced.
          >
          > I have notes about even earlier floppy controllers on my Web site,
          > as produced by Digital Systems, designed by Dr. John Torode (who built Gary Kildall's first floppy controller). Google will find those notes.
          >
          > The 99-DCDD hardware had to do many things under the direction of software, that, say, the WD1771 did automatically but years LATER. When you consider how "discrete" that and other floppy disk controllers were in the mid-1970's, then it eventually becomes no surprise that one sees what you call IN RETROSPECT "non-standard" disk formats. The disk formats did not BECOME "standard", until there were commonly used sets of FDC chips which IMPLEMENTED those "standards". (The IBM 3740 SSSD soft-sectored format was cited by disk drive manufacturers as a standard track/sector format. That was very hard to achieve so many early floppy controllers used hard not soft sectoring.)
          >
          > Likewise, the notion that CP/M 2.2 was "more popular" than CP/M 1.4, is simply another way of saying 2.2 came later, when microcomputing was a bigger industry. The surprise that the controller wasn't simply updated by Pertec for use with CP/M 2.2, simply says that Pertec did not happen to bother to do that, they had newer products to work on. Some other company (guys at a kitchen table probably) decided to provide that upgrade and make that dollar. These things happened or did not happen, a matter of circumstance.
          >
          > So "standards" that one "expects", are simply practices that came to become common LATER, under various circumstances and when business was greater. Conversely, when you look BEFORE such standards were established, you should EXPECT to see substantial variations in practices. In other words, don't be surprised, to be surprised.
          >
          > Another case of "surprise" in the note, was a lack of "every conceivable CP/M disk" in various on-line archives. Why assume that? On my S-100 Web site, I list at last count over 140 BRANDS of S-100 computer company. And there were many more CP/M computers in the 1970's and later than S-100 (Altair bus). Online archives of disk images only cover a fraction of those brands; they don't cover all the various OS's and versions too. There were a LOT of microcomputer companies in the 1970's, a LOT of products with lots of changes over time.
          >
          > From a larger point of view: consider that disk image archives are not of a single disk image "standard". Why? the archive owners used their own tools to create the images, or used tools decades old. I see this over and over, and (excuse me) I see it with this particular "archive", which uses the "Altair32 and SIMH emulators" disk image methods, whatever those are. The assumption is that anyone interested, will use this tool, to recover the files for intended use. "Everybody" is presumed to do that.
          >
          > No point in arguing the merits of various disk formats, or various emulators, or why someone may be interested. From my point of view - recovery of software from decades past, for reuse decades ahead - please do an old man a favor. If you are gonna post tiny 230K disk images, why not post a ZIP file of the source files and executables too? As you've already posted/archived separately the BIOS, why not add the BOOT, FORMAT and SYSGEN (or equivalents) and make a ZIP file of that? "ZIP" is "the standard" (chuckle) file archive scheme, anyway more "standard" than the disk image format in use here.
          >
          > And by the way - having a virtual disk image is not enough, if you don't have the tool to regenerate that image back into a diskette, for use with that hardware. I have no idea if the emulators or their associated tools can reproduce the original disks now imaged. I DO know a "common" disk imaging utility of a few decades ago, "IMAGEDSK" by Dave Dunfield, *will* reproduce disk formats, with ordinary (1980's 90's 00's) class computer hardware. I encourage use of this program, and its archive, every chance I get. Again - google my Web site and you'll find my notes, or google for Dave's good work.
          >
          > One other consideration. I see in parts of the posted discussions here, some of the background work on the history of these disk images and sources of information. It looks like good work, I've done history-of work like that and so I know how hard it can be. I urge the author to consolidate and add those notes and other's comments, to the "archive" with the disk images. Just as it's hard to look back 30, 35 years to make sense of how things were done by MITS and Pertec; it will be harder still, decades from now.
          >
          > Why go to all this trouble? Well, someone not active here, may get active, if you leave more clues and make it easier to see what's been done. That's the simplest version of what I've been saying today!
          >
          > How hard will it be tomorrow? Imagine a future only of portable touch-based computers, running virtual OS's and high-level languages ONLY. Do you think those folks, will find anything "standard" about working with binary code? About magnetic rotating media? with *keyboards*? The more clues we leave behind, the more likely this stuff will be preserved past our lifetimes, which for some of us is not much longer.
          >
          > Herb Johnson
          > retrotechnology.com
          >
        • W Tom
          The source code for the acounting software is a special case. As of this minute the printable source likely does not exist in any format. To get the source,
          Message 4 of 16 , Feb 18, 2013
          • 0 Attachment
            The source code for the acounting software is a special case. As of this minute the printable source likely does not exist in any format. To get the source, you must load the program and and list the code to the console or printer. The programs can be saved to disk with the ",A" option but programs would be bigger and slower. There are a lot of programs to process and the result would be difficult to read.

            I wrote one program in the archive that is a pretty printer for MITS BASIC. Another program is a cruncher that removes blanks and comments. A third utility compares two versions and makes a merge file of the differences.

            The .dsk archives and emulators are a starting place that can execute code. More work is needed to package everything in a Zip file. One file of source code is the MTST memory test. The source code is on the DOS Memory Test diskette. The source can be captured if you know how to TYPE a text file in MITS DOS. The capture task is on my list. MTST and the TCS fast copy are not that useful on an emulator. The emulators do allow the software to be studied without owning an Altair

            W. Tom S.
          • thinkpast
            ... [Tom also discussed his work was in progress, the .DSK images are for use with the emulator, few would have hardware to run the programs otherwise. Tom
            Message 5 of 16 , Feb 19, 2013
            • 0 Attachment
              --- In altaircomputerclub@yahoogroups.com, "W Tom" <yahoo@...> wrote:
              >
              > Hi Herb,
              >
              > It is good to hear from you. I zipped the .dsk files in the library. Note that ZIP is "the standard", but the emulators now have SQUEEZE/UNSQUEEZE and .LBR support on Altair format . Some source code is in .AQM files. Other files are in .LBR library files. An uzipped file may still require old tools.\

              [Tom also discussed his work was in progress, the .DSK images are for use with the emulator, few would have hardware to run the programs otherwise. Tom said IMAGEDSK was for use with soft-sectored formats only.]

              Hello to you, Tom. I'll send you a more detailed reply privately, as in effect you are writing mostly to me and my reply would be mostly to you. I'll make some points here for general interest.

              Um, thanks for ZIPping the .DSK files, but you did not do what I tried to suggest. What I tried to suggest, is that you also decompress and de-crypt the files, and post them as clearly, as accessible as possible, WITHOUT use of some emulator. Certainly, without the need for .LBR or SQU tools. I think other people will be interested in them, and they may not be so interested in running the Altair emulator, or those decompression tools, to get access to them.

              If that seems confusing.....Some of those interests, may be to look for common features of BIOSes from different brands or versions for example - as you've already discussed. Many people ask me for "source code" for various S-100 computers, from time to time. Source for one, MAY work for another, if you can rewrite a BIOS, if the hardware is comparable. Other people are just interested in odd disk formats; I discuss odd disk formats on my Web site.

              Regarding the merits of IMAGEDSK for MITS/Altair/Pertec hard-sectored formats, which Tom suggested could not be supported. As I said, I simply point to that facility when I can, on its general merits, which I detail on my Web site, which is also detailed on Dunfield's (hosted) Web site.

              http://www.retrotechnology.com/dri/howto_cpm.html#dunfield
              http://www.classiccmp.org/dunfield/img/index.htm

              However - there ARE "images" of Northstar Horizon *hard sectored* disks there, AND tools for creating such an image on the Northstar and then serial-transport to an MS-DOS machine. the same tools will do the reverse, to regenerate a disk on the native Northstar Horizon. There are even tools for *cassette tape* imaging for Heath H8's. Even *paper tape* tools, I've used them recently myself.

              These are worth looking at. Good tools are ALWAYS worth looking at, I won't go on about the merits of good and general purpose tools.

              > > I think a tool to regenerate diskettes will be produced....One case of "surprise" is that is that the only known release of Altair CP/M 2.2 is Lifeboat and no copies have been archived. The Burcon diskette is a pre-release partial copy of CP/M. Mike's work increases knowledge of MITS BIOS technology and will produce the programs you note as missing. Mike also made some mods that make the emulators more useful.
              >
              > W. Tom S.

              Therefore, following what you've just said, efforts to make results of emulators and disk recovery of files, more ACCESSIBLE with less fuss, are "more useful". Then people can find the knowledge and make the associations across software, that you reference above. Tom, other people want to do those sorts of things, but may not want to run an emulator to do that.

              Please document the .DSK format (if it's not already documented), and provide a stand-alone tool to extract (and insert) files. My posts are already too long, so I hope I don't have to explain why there may be a time when "the emulator" won't be runable, but the .DSK's will still be available. It will be easier to work with a documented definition or ancient extractor code - than a much larger and more complex and elaborate emulator.

              I take this long view, because I (and Tom and yourselves" are ALREADY looking back nearly four decades. Looking ahead in that way is not that hard, if you have that amount of experience already.

              Herb Johnson
              retrotechnology.com
            • thinkpast
              Tom, certainly no one can do everything, much less do it immediately. To the extent that others can figure out what has been done, they can assist and do the
              Message 6 of 16 , Feb 19, 2013
              • 0 Attachment
                Tom, certainly no one can do everything, much less do it immediately. To the extent that others can figure out what has been done, they can assist and do the things of interest to them. Continue to leave a trail of your work and explanations.

                But please continue to do the work that possibly only YOU can do - namely, recover files from disks not likely readable in any other way today, except on original equipment and diskettes. Few beyond you yourself even have these things, much less have them RUNNING. Your achievement is considerable already.

                Regards and thanks for your work,
                herb johnson


                --- In altaircomputerclub@yahoogroups.com, "W Tom" <yahoo@...> wrote:
                >
                > The source code for the acounting software is a special case. As of this minute the printable source likely does not exist in any format. To get the source, you must load the program and and list the code to the console or printer. The programs can be saved to disk with the ",A" option but programs would be bigger and slower. There are a lot of programs to process and the result would be difficult to read.
                >
                > I wrote one program in the archive that is a pretty printer for MITS BASIC. Another program is a cruncher that removes blanks and comments. A third utility compares two versions and makes a merge file of the differences.
                >
                > The .dsk archives and emulators are a starting place that can execute code. More work is needed to package everything in a Zip file. One file of source code is the MTST memory test. The source code is on the DOS Memory Test diskette. The source can be captured if you know how to TYPE a text file in MITS DOS. The capture task is on my list. MTST and the TCS fast copy are not that useful on an emulator. The emulators do allow the software to be studied without owning an Altair
                >
                > W. Tom S.
                >
              • W Tom
                I appreciate the encouragement to document what I know. There are so many things that I ve learned recently. I love my old Altairs, but emulators will speed my
                Message 7 of 16 , Feb 19, 2013
                • 0 Attachment
                  I appreciate the encouragement to document what I know. There are so many things that I've learned recently. I love my old Altairs, but emulators will speed my learning process. Now other won't have to wait to find Pertec drives.

                  Help! There is more work than I can ever do. I will produce more documentation and source code, but I urge everyone to use the emulators, pick a disk, then learn and document something. I don't know MITS DOS and don't want to do more Fortran. Some of the disks I just saw for the first time. I hope some will look and the games and scientific routines. I doubt I'll have time to look at Time Sharing BASIC.

                  What I really hope for is that someone will look at the list and realize that they have a disk that is not included. The Lifeboat 3202 CP/M is an example. Who has a copy? What else did I forget to save besides the Q-Type word processor?

                  I zipped the .dsk files because the File Area is getting full. I can put more information on my website, but the site and Yahoo may not be here in 10 years. Its not just old diskettes that worry me.


                  W. Tom S.
                • thinkpast
                  ... [Mike says he ll post more sources.] ... I m sorry you were offended by my posts, Mike. That was not my intention and I don t look to create unpleasant
                  Message 8 of 16 , Feb 19, 2013
                  • 0 Attachment
                    --- In altaircomputerclub@yahoogroups.com, "deramp5113" <deramp5113@...> wrote:
                    >
                    > Herb,
                    >
                    > Thank you for your response. While I'm inclined to respond to all of your points, we all know that would end up in an unpleasant downward spiral on this forum, so I won't. However, I would like to address the archive format contestation.
                    >
                    > No matter what archive format you start with, there are only three common platforms on which someone can run the Burcon release of CP/M ... Any other archive format would be less desirable .... for execution.
                    >
                    > The archive format chosen is hardly a "format" at all -- it is simply a byte for byte copy of the floppy....
                    >
                    > For readers not interested in actually running the disk images, but who still want to review the source code, you make a valid point that source code should be made available separate from the disk images.
                    [Mike says he'll post more sources.]
                    >
                    > Mike

                    I'm sorry you were offended by my posts, Mike. That was not my intention and I don't look to create "unpleasant downward spirals" in public or private discussions at all. You have my apologies, but I think you are mistaken in whatever you found offensive in my post.

                    I don't "contest" the .DSK format. I am not critical of the Altair emulator. I am not suggesting that anyone's work, including yours if that's the case, is better or worse than anyone else's. In fact, I said up front - I am not familiar with this work in particular detail, that's what "cold post" meant. If some prior discussion is the "unpleasant" reference...I don't know about that, either.

                    One last time: My intentions were 1) to note there's other interests in this Altair stuff, other than running an emulator from imaged disks; 2) by default, the .DSK files amount to an archive and 3) so it might be a good idea to provide means to extract files from disk image files, other than running an emulator.

                    As part of those "other interests", I responded to some comments in an accompanying document to the .DSK files in particular, about the context of the code and hardware. Nobody so far is unhappy about THOSE comments. Half the reason I posted, was about THAT stuff.

                    The rest of my posts, were to substantiate those points. Not to pick a fight. If you, or someone else, thinks I'm just a loudmouth looking for fights - you can go to my Web domain retrotechnology.com, and see what I've done over several years. I have interests in the history of CP/M and the history of early floppy controllers. Also a VERY long history in S-100 systems. I don't say that to show off, I say that because it represents why I believe I can make claims about long-term interests, or abstract things like "the history of floppy disk controllers".

                    Otherwise, as I said, I find value in a particular disk imaging set of tools and an archive. If THAT is the source of your offense, I'm sorry and apologize. IMAGEDSK is not an emulator, period. It's for archival and duplication purposes. There's no "contest" other than the overlapping interest in archiving whole disk images for overlapping purposes.

                    You pointed out in reply, that emulation execution is different from file and disk recovery. Thank you. I agree with your consideration. There's no contest. That does not mean, that other tools would not have other benefits. Or that your tools are obliged to have ALL benefits - that's impractical.

                    Otherwise, programmers often dispute the merits of other people's programs. I try hard to avoid arguments between programmers. If THAT is the "unpleasant downward spiral", I agree to avoid that, that was not my intention. Also, I posted more remarks about IMAGEDSK, in reply to Tom Sanderson's post about that program - BEFORE I read your post as above. Again - no dispute intended, my apologies, don't take my remarks to Tom as a response to your message above. OK?

                    So. Thanks for the notes about the .DSK format. And, thank you for considering that providing files outside the .DSK images is a good idea. That largely responds to my post. Tom's reply, suggests that some kind of file extractor would be worked on. That also responds to my post. What people do with IMAGEDSK or not - up to them. Same with the Altair emulator, about which I've said NOTHING, zero.

                    So there's no real disputes here. I think there's a misunderstanding, and some surprises when someone unfamiliar weighs in. Anyone offended or concerned, can look around my Web site, and decide what I'm about, and if anything I say here (or there) has any merits or not. I'm not looking for fights.

                    herb johnson
                    retrotechnology.com
                  • deramp5113
                    No worries! Enough said. Mike
                    Message 9 of 16 , Feb 19, 2013
                    • 0 Attachment
                      No worries! Enough said.

                      Mike


                      --- In altaircomputerclub@yahoogroups.com, "thinkpast" <hjohnson@...> wrote:
                      >
                      >
                      >
                      > --- In altaircomputerclub@yahoogroups.com, "deramp5113" <deramp5113@> wrote:
                      > >
                      > > Herb,
                      > >
                      > > Thank you for your response. While I'm inclined to respond to all of your points, we all know that would end up in an unpleasant downward spiral on this forum, so I won't. However, I would like to address the archive format contestation.
                      > >
                      > > No matter what archive format you start with, there are only three common platforms on which someone can run the Burcon release of CP/M ... Any other archive format would be less desirable .... for execution.
                      > >
                      > > The archive format chosen is hardly a "format" at all -- it is simply a byte for byte copy of the floppy....
                      > >
                      > > For readers not interested in actually running the disk images, but who still want to review the source code, you make a valid point that source code should be made available separate from the disk images.
                      > [Mike says he'll post more sources.]
                      > >
                      > > Mike
                      >
                      > I'm sorry you were offended by my posts, Mike. That was not my intention and I don't look to create "unpleasant downward spirals" in public or private discussions at all. You have my apologies, but I think you are mistaken in whatever you found offensive in my post.
                      >
                      > I don't "contest" the .DSK format. I am not critical of the Altair emulator. I am not suggesting that anyone's work, including yours if that's the case, is better or worse than anyone else's. In fact, I said up front - I am not familiar with this work in particular detail, that's what "cold post" meant. If some prior discussion is the "unpleasant" reference...I don't know about that, either.
                      >
                      > One last time: My intentions were 1) to note there's other interests in this Altair stuff, other than running an emulator from imaged disks; 2) by default, the .DSK files amount to an archive and 3) so it might be a good idea to provide means to extract files from disk image files, other than running an emulator.
                      >
                      > As part of those "other interests", I responded to some comments in an accompanying document to the .DSK files in particular, about the context of the code and hardware. Nobody so far is unhappy about THOSE comments. Half the reason I posted, was about THAT stuff.
                      >
                      > The rest of my posts, were to substantiate those points. Not to pick a fight. If you, or someone else, thinks I'm just a loudmouth looking for fights - you can go to my Web domain retrotechnology.com, and see what I've done over several years. I have interests in the history of CP/M and the history of early floppy controllers. Also a VERY long history in S-100 systems. I don't say that to show off, I say that because it represents why I believe I can make claims about long-term interests, or abstract things like "the history of floppy disk controllers".
                      >
                      > Otherwise, as I said, I find value in a particular disk imaging set of tools and an archive. If THAT is the source of your offense, I'm sorry and apologize. IMAGEDSK is not an emulator, period. It's for archival and duplication purposes. There's no "contest" other than the overlapping interest in archiving whole disk images for overlapping purposes.
                      >
                      > You pointed out in reply, that emulation execution is different from file and disk recovery. Thank you. I agree with your consideration. There's no contest. That does not mean, that other tools would not have other benefits. Or that your tools are obliged to have ALL benefits - that's impractical.
                      >
                      > Otherwise, programmers often dispute the merits of other people's programs. I try hard to avoid arguments between programmers. If THAT is the "unpleasant downward spiral", I agree to avoid that, that was not my intention. Also, I posted more remarks about IMAGEDSK, in reply to Tom Sanderson's post about that program - BEFORE I read your post as above. Again - no dispute intended, my apologies, don't take my remarks to Tom as a response to your message above. OK?
                      >
                      > So. Thanks for the notes about the .DSK format. And, thank you for considering that providing files outside the .DSK images is a good idea. That largely responds to my post. Tom's reply, suggests that some kind of file extractor would be worked on. That also responds to my post. What people do with IMAGEDSK or not - up to them. Same with the Altair emulator, about which I've said NOTHING, zero.
                      >
                      > So there's no real disputes here. I think there's a misunderstanding, and some surprises when someone unfamiliar weighs in. Anyone offended or concerned, can look around my Web site, and decide what I'm about, and if anything I say here (or there) has any merits or not. I'm not looking for fights.
                      >
                      > herb johnson
                      > retrotechnology.com
                      >
                    Your message has been successfully submitted and would be delivered to recipients shortly.