[Intel-devsys] irmx-80 diskettes

Jon Hales jonhales at gmail.com
Sat Aug 17 05:58:42 MDT 2019


Bill

Here is a photo of the label on Intel disk P/N 9700018-03 "Intellec PROM
Programming Software" (C) 1978.

Here my listing of one of your disks:

BB037,9700018-03,ISIS-II,V3.4,PROM Programming Software,V2.0,img,DD,500.50
KB

and two disks in Mark Ogden's collection:

# 970018.03 promad.pgm-34  prom programming software v2.0 - isis ii
label: PROMAD.PGM
version: 34
format: ISIS II DD 1H5
os: NONE
Files:
ISIS.T0,2944,54884,Intel80/isis.t0_ns
UPM,15391,7191,Intel80/upm_2.0

# 970018.05-41 universal prom mapper v3.2 - isis ii
label: 970018.05
version: 41
format: ISIS II DD
os: NONE
Files:
ISIS.T0,2944,54884,Intel80/isis.t0_ns
UPM,13413,17683,Intel80/upm_3.2
UPM.OV0,2736,1540,Intel80/upm_3.2
UPM.OV1,3193,59140,Intel80/upm_3.2
UPM.OV2,2233,48387,Intel80/upm_3.2

The conclusion, as we have discussed previously, is that the 'system' of
Intel's Order Numbers was not quite as 'systematic' as me might have
assumed. Specifically, this instance challenges my assumption that 95xxxx
and 97xxxx numbers represent single and double density versions of the same
software.

Best regards

Jon


On Fri, 16 Aug 2019 at 19:51, Bill Beech (NJ7P) <nj7p at nj7p.info> wrote:

> Jon,
>
> 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 series.
>
> 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.
>
> Bill
> 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>
> 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
>> http://lists.brouhaha.com/mailman/listinfo/intel-devsys
>>
>
> _______________________________________________
> Intel-devsys mailing listIntel-devsys at lists.brouhaha.comhttp://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/20190817/0651bc8e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 9700018-03_PROM.JPG
Type: image/jpeg
Size: 140048 bytes
Desc: not available
URL: <http://lists.brouhaha.com/pipermail/intel-devsys/attachments/20190817/0651bc8e/attachment-0001.jpe>


More information about the Intel-devsys mailing list