[Intel-devsys] irmx-80 diskettes

Bill Beech (NJ7P) nj7p at nj7p.info
Fri Aug 16 12:50:11 MDT 2019


Good discussion.  I was kind of out of it during some of this.  I 
vaguely remember the filling of a matrix of programs in the 95 and 97 

Attached is a picture of the disk label for 9500018-03.

I think we are going to need to document the hardware, software, and 
method used to pull the images off the floppies.  I would be glad to 
place these "howtos" on the web and in the google drive.

I seem to be way behind on the imaging stuff with Dave's tools. I am 
glad to see Mark has transitioned from Dave's C to a VS implementation 
on some of the tools.  This is good.  I need to get a box running with 
an FDC that will read SD and DD disk sectors. I have NEVER had any PC 
that would do SD and work with Dave's tools! I believe I have an Adaptec 
board that will do it.  We will see over the weekend.


On 8/16/2019 1:52 AM, Jon Hales wrote:
> Herb, Bill, cc Mark and others
> It's good to see your discussions.
> This is a note on two topics:
> - getting at the files on Intel M2FM-encoded DD disks,
> - the exercise I reported around a year ago, where I imagined a 
> comprehensive list of Intel MDS software releases.
> Part 1.
> As Herb reported, Mark Ogden has a great deal of experience at working 
> with images of Intel disks. He also has a substantial collection of 
> files extracted from particular disks. The 'Intel80' directory 
> contains files for iRMX80 2.4 and iRMX80 4.0. I'm sure Mark will be 
> very interested to see what Bill has on his disks with version 1.3.
> Building on his knowledge of Intel's disk organisation, Mark wrote a 
> program to help me with several collections of Intel double-density 
> disks to which I I have access. The process starts with me making a 
> track-by-track recording of the disk using a device that identifies 
> flux transitions. There are now several such devices, but two of these 
> have only embryonic software support. It's likely that the programming 
> would need some adjustment for each variety. The device I was using 
> saves each track as a separate file, with 77 files for the tracks of a 
> single-sided disk (all MDS disks are single-sided). [A further detail: 
> by default, the system I'm using reads each track six times and saves 
> six copies of the flux transitions - one can pick the copy of a sector 
> that has fewest bad values].
> Mark's program idd2imd.exe can operate on a single track or on a 
> zipfile containing all the tracks from a disk. It outputs a file in 
> Imagedisk (Dave Dunfield) standard (with optional diagnostic data, 
> such as a histogram of the time interval values on the track). Given 
> an IMD image, Mark's program unidsk.exe, works out the filesystem and 
> assembles the sectors into the files on the disk. These files are 
> written to a directory named after the disk name. An additional text 
> file provides the 'directory' of the disk, together with information 
> about each file on the disk.
> [In parentheses:
> 1. Mark's idd2imd program works with flux transitions from single 
> density (FM) and double density (MFM) as well as M2FM disks.
> 2. Mark has recently adapted his algorithm to provide a means of 
> building the files from the sectors recovered from Zilog (ZDOS and 
> RIO) 32 hard sector disks. In addition to the files, the program gives 
> a summary of the types of data in sectors and shows a map of sectors 
> across the entire disk].
> Now, I should point out that this is not exactly comparable to 
> producing, for example, an Imagedisk image of a CP/M disk (encoded in 
> FM or MFM). In the CP/M case, an Imagedisk file allows the user to 
> write a fresh disk that is a copy of the original disk. This doesn't 
> apply to M2FM due to limitations of the disk controller IC in PCs of 
> the DOS era. [To be clear: Imagedisk can make a valid image of an 
> Intel single-density disk, as Herb indicated].
> If we want a copy of an M2FM disk, then the simple way to create it is 
> using the Intel 'copy' utility. [The 'Richard Main' Hobbytronics 
> Serial-to-USB device is another way to 'export' tracks and have the 
> ability to write a copy of the original double-density disk].
> Part 2
> Starting with a list of known '95xxxx-xx' and '97xxxx-xxx' (single and 
> double-density) disks, I tried to imagine what the universe of Intel's 
> software releases might look like. For example, if the suffix of a 
> known disk was '-03', I reasoned that probably there had previously 
> been versions '-01' and '-02', even if these had never been released 
> to customers. By analogy, I also reasoned that if no known disk had a 
> specific code number, then that might well mean that this was a rarely 
> used program, but one that was likely to have existed.
> As I explained in a note accompanying a draft list, we could use the 
> list in at least these ways:
> 1. to check the identification of disk numbers and titles across 
> repositories. (e.g. for consistency, to over-ride abbreviations, etc.)
> 2. to speculate about the existence of disks we haven't seen,
> 3. to establish a framework into which new discoveries can be fitted,
> 4. to estimate what fraction of the 'universe' the existing 
> repositories represent (at the time the list was compiled, this was 54 
> of a possible 183 titles).
> Bill's iRMX-80 disks fit neatly into the scheme, with one exception: 
> the number '9500018-xx'/'9700018-xx' is already occupied by PROM 
> programming software, as located in three of the repositories.
> Best regards
> Jon
> On Fri, 16 Aug 2019 at 00:21, Herb Johnson 
> <hjohnson at retrotechnology.com <mailto:hjohnson at retrotechnology.com>> 
> wrote:
>     Thanks Bill, this is very comprehensive. A few comments.
>     You might do the easy thing first: read off the single-density disks.
>     YOu could do that in CP/M on a CP/M box, or with Dunfield's
>     imagedsk on
>     an MS-DOS box. In any event you can verify the disk scheme.
>     DD M2FM is harder. But you might ask Mark Ogden about it. (now this
>     conversation is in the Intel-dev list, Mark can speak for himself.)
>     He's created a lot of files from Intel disk sources. He's rewritten
>     Dunfield tools to run under Windows. He may have a tool to run under
>     ISIS, or be willing to write one.
>     https://github.com/ogdenpm/disktools/tree/master/unidsk
>     Unpacks an isis .imd or .img file into the individual files.
>          Supports ISIS II SD, ISIS II DD, ISIS III and ISIS IV
>     There is an old CP/M program to read ISIS diskettes, look in the
>     CPMUG.
>     I retrieved it decades ago to read DEC RT-11 diskettes. (And I did
>     tonight, it's in CPMUG #1. I'll zip it up and send it to Bill.)
>     No hurry on this, Bill of course, you have a full plate.
>     Regards,
>     Herb
>     On 8/15/2019 5:38 PM, Bill Beech (NJ7P) wrote:
>     > Herb,
>     >
>     > Indeed I have 5 each 8-inch disks here for RMX/80.
>     >
>     > They are:
>     > 9500013-03 Ver 1.3, RMX/80 Real-time Multitasking executive for
>     iSBC
>     > 80/20 and 80/20-4, SD.
>     > 9500018-03 Ver 1.3, RMX/80 Real-time Multitasking executive for
>     iSBC
>     > 80/10, SD.
>     > 9700016-03, Ver 1.3, RMX/80 Real-time Multitasking executive for
>     iSBC
>     > 80/20 and 80/20-4, DD.
>     > 9700020-03, Ver 1.3, RMX/80 Extensions for iSBC 80/10, iSBC 80/20,
>     > 80/20-4, and 80/30, DD.
>     > 9700021-03, Ver 1.3, RMX/80 Real-time Multitasking executive for
>     iSBC
>     > 80/10, DD.
>     >
>     > The SD disks should not be hard to copy.  The DD may be
>     trickier.  I
>     > suspect they are in 3740 format SD but M2FM format DD.  I
>     suspect I will
>     > need to write a program for the MDS II to create an image file
>     on the
>     > PC.  I need to think about it some more, once I get the other
>     board for
>     > Jon H. done and both tested. And I need to get some simulators to
>     > compile again and run, at least as far as the monitors are
>     concerned.  I
>     > also need to get versions of CP/M-80 to run on the OEM
>     simulators.  I
>     > also have several books I have collected to scan. So my queue is
>     pretty
>     > full!
>     >
>     > Bill
>     >
>     > On 8/15/2019 9:34 AM, Herb Johnson wrote:
>     >> Biil, someone asked me about 8-inch diskettes with iRMX-80 on
>     them. Of
>     >> course I don't have them. So I started looking around for this.
>     This
>     >> doesn't seem to be available "on the Web" or among the intel-dev
>     >> archives.
>     >>
>     >> I searched your Intel Google Drive and then the archive of our
>     >> Intel-dev discussion, for mention of iRMX-80. The only significant
>     >> mention is your Sept 2018 purchase of five iRMX-80 diskettes from
>     >> eBay. I didn't find subsequent email traffic on your results with
>     >> those diskettes. And I don't see any iRMX80 disk images in any
>     of the
>     >> by-person folders in your Google drive. I checked Mark Ogden's
>     gethub;
>     >> no iRMX80 stuff there. One other reference but it seems a dead
>     end.
>     >> I'll detail it as a PS.
>     >>
>     >> Bill, it is still a good "find" to have disks with iRMX-80.
>     Thanks for
>     >> spending the $$$ to get them. I know doing work is tough for you;
>     >> there's no priority for this just because somebody asked me
>     about it.
>     >> But what's the status of those physical diskettes, and were you
>     able
>     >> to image them in some fashion?
>     >>
>     >> Regards, Herb
>     >>
>     >> PS: Jon Hales did something with a bunch of Intel diskette
>     >> label-descriptions posted around Aug 2018. Mark Ogden commented
>     about
>     >> the list, and mentioned this:
>     >>
>     >> 950017.06 looks like irmx80 v2.4
>     >>
>     >> I have no idea what Jon was doing. But I could not find a
>     disk-image
>     >> with that 950017.06 designation.
>     >>
>     >>
>     >
>     >
>     -- 
>     Herbert R. Johnson, New Jersey in the USA
>     http://www.retrotechnology.com OR .net
>     preserve, recover, restore 1970's computing
>     email: hjohnson AT retrotechnology DOT com
>     or try later herbjohnson AT retrotechnology DOT info
>     _______________________________________________
>     Intel-devsys mailing list
>     Intel-devsys at lists.brouhaha.com
>     <mailto:Intel-devsys at lists.brouhaha.com>
>     http://lists.brouhaha.com/mailman/listinfo/intel-devsys
> _______________________________________________
> Intel-devsys mailing list
> Intel-devsys at lists.brouhaha.com
> http://lists.brouhaha.com/mailman/listinfo/intel-devsys
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.brouhaha.com/pipermail/intel-devsys/attachments/20190816/2ed17cb0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DSCN1138.jpg
Type: image/jpeg
Size: 161642 bytes
Desc: not available
URL: <http://lists.brouhaha.com/pipermail/intel-devsys/attachments/20190816/2ed17cb0/attachment-0001.jpg>

More information about the Intel-devsys mailing list