Making an disk image

[William Beech]

Mark,

I know you wrote a program to manipulate ISIS-I and -II images.  I have
written several programs to manipulate various OS images. These are hard
programs to write and debug.

I wonder if you have given any thought to a single program that would
manipulate all the various disk formats we find working with the old
Intel machines.  I am basically talking about CPM-80, CPM-86, ISIS-I,
ISIS-II, Xenix 86, Xenix 286, Xenix 386, and iRMX disk images.

Just on the floppy side, we have SSSD, DSSD, SSDD, and DSDD.  We have
various formats where track 0, side 0 through track 1, side 1 may be SD
while all other tracks are DD.   I did this on my CPM systems which made
it real difficult to archive the data later on the SS/DSDD PC.  I was
thinking we could write one tool which uses a "recipe" like your program
for manuals to specify the OS format so the program could handle that
one floppy disk format.  Later, we could expand it to handle the hard
disk formats.

I am thinking the IMD format might be the best container.  The IMG
format has so many different definitions!

Thoughts?

Thanks!

Bill

[Al Kossow]

On 6/14/25 5:06 PM, William Beech wrote:

> I am thinking the IMD format might be the best container.

IMD is problematic because it has no definition for M2FM disks.

No one has ever agreed on how to extend it.

[mark.p...@btinternet.com]

Bill
I have thought about this in the past, but not yet gone forward with it. Currently I have

Unidsk which will decode and provided a recreate recipe for ISIS I, ISIS II, ISIS III, ISIS PDS and ISIS DOS (a Russian special version). It also decodes ISIS IV and iRMX. It handles IMD and IMG formats. It does create an information file for ISIS IV and iRMX, although unirmx does a better job. The tool will also use my ISIS repository to auto identify known files, except for ISIS IV and iRMX.

Mkidsk which uses the recipe files to create ISIS I, ISIS II, ISIS III, ISIS PDS and ISIS DOS images in IMD or IMG format. The IMD format also replicates the Intel physical sector order and inter track skew where used.

Unirmx - this does a better job of decoding iRMX disk images. It does not recreate disks and currently only handles IMG formats, but I will probably extend to IMD format and to creating a recipe file for a version that allows recreation of ISIS IV and iRMX disks. I now understand the basic format of the various cluster allocation files, so adding a facility to create/modify new disks is practical.

It is possible that in the next few months I will merge unirmx back into unidsk and add support for writing ISIS IV and iRMX formats disks to mkidsk.
I am likely to keep Unidsk and Mkidsk functionality separate. Modifying a disk can be achieved by using unidsk, edit recipe, mkidsk.

For the other OS options, I have some perl scripts that extract files from Xenix images. Given that there are several Xenix formats, that kernels configs may be different, and I don't understand all the supplementary information in the inodes etc. I am not intending to write a Xenix image creation tool. Fortunately, there are alternative pragmatic options
1) There are several boot images for Xenix available that can be used to create a basic system. If you wish to archive a new variant, using the Xenix tools you should be able to save the boot image to disks and then convert each to IMD format.
2) Consistent with Xenix itself, many updates are done using tar files saved directly to a disk. So, creating a tar file and using the IMD tools to convert a binary file to an IMD file should be feasible, as would writing the tar file to a floppy disk partition directly on Unix/Linux or by using the dd tool.

CPM is another challenge. I currently use cpmtools (with libdisk) that does an adequate job although boot tracks are not so straightforward when cylinder 0, side 0 has a different format from the rest of the disk, something which is common on Intel disks. I have also seen two variants of the 8" Intel disk format, dependent on whether it is a boot/data disk. Implementing a cpmtool replacement is quite an undertaking and would still rely on something akin to the diskdefs model for all supported disks.

Using IMD is not an unreasonable archive for most floppy disks. As you note it doesn't explicitly capture the M2FM encoding, which is probably not a major problem, it can be recorded in the comments and as it would require a bespoke tool to write a disk, having a flag on such a tool to force M2FM would be a reasonable approach. I would also note that IMD assumes the newer IBM format for FM/MFM vs. the older format with single Address Markers.

IMD however does have some limitations, so extending to large hard disks may be an issue and there is no way of explicitly recording the disk encoding format if for example RLE is used.
Although probably not of interest to this group, IMD doesn't support hard sector disks, and apart from a John Elliott extension, it assumes sector sizes are the same on a track and only standard sector sizes are allowed.
I have thought about creating a new archive standard as a variant of IMD, which would support some extensions, including capturing disk structure, OS, and allow flux streams to be captured where it has not yet been possible to decode a sector/track.

Mark

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/ee273830-eaf9-4251-9696-80e14c74fc2a%40nj7p.org.

[William Beech]

Mark,

Okay.  Sounds like I need to look at Unidsk/Mkidsk as a starting point. 
Keeping the read and write functions makes good sense.  I did not do
this in my tools and they are a pain to modify.  I would be happy to
help you test your updated tools as you work on them.

As a starting point I plan on looking at the floppy disk formats to
start.  I am very familiar with CPM and have tools to read and write
disk images.  But it is all together and, again, a pain to modify. I
also have tools for the SCO, Xenix, and Unix V7 floppy disks in various
states of operation.

An extended IMD definition would be a help in this effort.

Could a tool be made to work with a Catweasel to create M2FM disks from
a flux stream?  Or create the flux stream from an IMD image?

Thanks!

Bill

[William Beech]

Al,

This is true.  It has limitations that could be corrected with revised
"standard".

Bill

[William Beech]

Mark,

I just downloaded your GitHub repository for Disktools.  I built it
under VS2022 but received 2 errors.

Cannot open file
'D:\Devel...\disktools-master\Install\x64-Debug\utility.lib  dmk2imd

'indexPos': undeclared identifier decoders.c

I figured the lib just took another Build command, and the first error
disappeared.  Still have the second.

Bill


On 6/15/2025 8:51 AM, mark.pm.ogden via intel-devsys wrote:

[mark.p...@btinternet.com]

Bill
Do you have a space in your path?
The utility.lib is prefixed by $(OutDir) which unfortunately if it contains a space expands to include the space and hence the build code treats as two separate files.
I came across this in the $(SolutionDir) elsewhere and if put in quotes the trailing \ on the $(...Dir) file escapes the quote creating another problem.
I worked out a solution for $(SolutionDir), looks like I need to replicate for $(OutDir).
For now just rename the path to exclude the space.

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/0373fbee-805c-45c6-b287-e4209c00b5a5%40nj7p.info.

[Herbert Johnson]

I've not looked at the IMD formats in some time so I won't confuse
people by commenting in detail on them. Generally the IMD format which
has per-sector descriptions (as apposed to a flat disk-image format),
has a lot of opportunity to address sector size and features. There's
also some text fields which may provide opportunities for ad-hoc
information.

Mark Ogden's point about M2FM is that a "bespoke tool" is needed to read
or produce M2FM physical diskettes. I'll go further. Since there's very
few M2FM controllers which produced M2FM disks, and since they are
mutually incompatible (both hardware and format incompatible), It's
*essential* to identify the original hardware, so past and future
diskettes can be recovered, as I'll describe.

Identifying the origin hardware, more-or-less identifies the details of
the particular M2FM format. That is, one can search for hardware
information and hopefully recover formatting information associated with
that info. Ideally, some kind of formatting detail can be maintained
with M2FM disk images. However history suggests that's unlikely, as the
bulk of vintage disk-image use is to drive emulators which generally are
oblivious to format details. Thus the bulk of archives (seem to)
separate disk images from hardware and bit-level flux-level documentation.

At least IMD covers FM, MFM and M2FM with some representation of
sector-data content, satisfactory for much of our needs. Outside our
Intel-centric universe, there were all kinds of
disk-format-at-flux-level schemes (hardware and descriptions). Each
scheme has its "bespoke" adherents for the brand (model) of vintage
computer at the center of their universes, and thus they produced their
own schemes for their disk images. A diskette Tower of Babel, where each
cannot speak to the others - that's my experience.

As far a IMD representing hard disks large or small. that was not
intended by that scheme. If someone extends an IMD scheme to hard disk
images, more power to each who does so.

As far as archiving "flux streams", that also suffers the "bespoke tool"
issue. How many samples per flux change? - that alone creates an issue.
The persons actively working with flux-sampling technology will drive
that discussion, my knowledge is meager. However the regional (middle
Atlantic USA) expert in MFM drive emulation and disk-image capture is
David Gesswein and his work. He has worked with determination to develop
and exercise his technology, and has proven successful. It would seem to
me, consulting him on such matters would be wise and prudent.

https://www.pdp8online.com/mfm/mfm.shtml

Good luck.

Regards Herb

On 6/15/2025 11:51 AM, mark.pm.ogden via intel-devsys wrote:
>
> Using IMD is not an unreasonable archive for most floppy disks. As you note it doesn't explicitly capture the M2FM encoding, which is probably not a major problem, it can be recorded in the comments and as it would require a bespoke tool to write a disk, having a flag on such a tool to force M2FM would be a reasonable approach. I would also note that IMD assumes the newer IBM format for FM/MFM vs. the older format with single Address Markers.
>
> IMD however does have some limitations, so extending to large hard disks may be an issue and there is no way of explicitly recording the disk encoding format if for example RLE is used.
> Although probably not of interest to this group, IMD doesn't support hard sector disks, and apart from a John Elliott extension, it assumes sector sizes are the same on a track and only standard sector sizes are allowed.
> I have thought about creating a new archive standard as a variant of IMD, which would support some extensions, including capturing disk structure, OS, and allow flux streams to be captured where it has not yet been possible to decode a sector/track.
>
> Mark
--

Herb Johnson, New Jersey USA
http://www.retrotechnology.com or .net
preserve and restore 1970's personal computing
email: hjohnson @ retrotechnology dot com
or try later at herbjohnson @ comcast dot net

[mark.p...@btinternet.com]

I suspect the best solution for M2FM is to convert an IMD image into flux transitions file and use Catweazle or similar to create the disk, bypassing the controller and its limitations.

For Intel if a new controller board was developed using a standard floppy controller, probably with a modern small cpu to manage the interface to the Intel main computer, this would allow MFM files to be used and may be a better long term solution. The actual interface from ISIS to the disk controller is quite simple and DMA is used to copy content, so there is no inherent need in ISIS to use M2FM. Indeed, an interface could be developed to a memory card/usb, bypassing floppies completely.

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/efd0ce5b-333a-41f4-aa71-8d86cfaa66b9%40retrotechnology.com.

[Herbert Johnson]

Mark suggests, the simplest means-to-an-end of operating ISIS versions
on native Intel Multibus hardware, with little to no modification of
Intel software, may be 1) to identify the DMA and control-operations of
the old M2FM controller/DMA board set; then 2) build a Multibus card
capable of responding to those operations. On that card would be 3) a
modern microcontroller which would respond to the operations, and also
4) provide modern mass storage (SDcard, USB flash drive) to hold a M2FM
disk image(s) of data not flux changes.

While that does not permit actual physical diskette operations on actual
physical floppy drives - it serves the purpose of running ISIS. Does it
need to do more? And it might also be coerced to run other INtel OSs, if
they are more flexible than ISIS OS. That is they isolate mass storage
hardware from from OS software except at a BIOS level.

Can anyone comment on running iRMX or Xenix or a few other OS's with
different "diskette" hardware as suggested?

Make it also do floppy disk control? There's already old and new MFM
Multibus floppy controllers, Intel's and others. If someone wants to
make such a Multibus floppy card - they will not likely have interest in
M2FM. So keep the "floppy controller" as an end unto itself, at the cost
of another Multibus slot. Divide and conquer.

Mark, this is roughly what you suggest. It's entirely reasonable, and is
within modern hobby practices today on other vintage microcomputer
products. Pieces of that process are likely in hand already. If someone
embarks on this path, they should start their own discussion thread on
the matter.

--------------------------

Is a new M2FM controller needed? Only if M2FM diskettes appear (to a
non-Intel owner) which need to be read off and archived. The solution to
that? Run someone else's legacy hardware. We already have such running.
Why replicate them? Mail your disks to your closest Intel Multibus M2FM
owner for extraction.

Or if you wish and as Mark suggests, mail them to 1) whomever has some
kind of flux-reading technology and 2) has the magic decoder ring
software to convert M2FM into formatted tracks into data sectors and 3)
is willing to that despite not likely having any interest in or
experience with "Intel Multibus". Unless a Multibus owner also possesses
points 1) and 2). By sharing their wealth and time, they save other's
wealth and time plus preserve one more piece of the Intel legacy.

I don't recall clearly now. But I believe M2FM disks sat around for some
time, until actual Intel hardware was restored to recover them. I do not
recall when and which modern hardware (and software, and decoders) were
amassed to read Intel M2FM physical disks to extract sector data. Some
who knows can comment.

These seem to be sensible arguments.

Regards Herb Johnson

On 6/15/2025 5:04 PM, mark.pm.ogden via intel-devsys wrote:
> I suspect the best solution for M2FM is to convert an IMD image into flux transitions file and use Catweazle or similar to create the disk, bypassing the controller and its limitations.
>
> For Intel if a new controller board was developed using a standard floppy controller, probably with a modern small cpu to manage the interface to the Intel main computer, this would allow MFM files to be used and may be a better long term solution. The actual interface from ISIS to the disk controller is quite simple and DMA is used to copy content, so there is no inherent need in ISIS to use M2FM. Indeed, an interface could be developed to a memory card/usb, bypassing floppies completely.
>
>
> -----Original Message-----
> From: Herbert Johnson
> Sent: 15 June 2025 21:50

>

> Mark Ogden's point about M2FM is that a "bespoke tool" is needed to read or produce M2FM physical diskettes. I'll go further. Since there's very few M2FM controllers which produced M2FM disks, and since they are mutually incompatible (both hardware and format incompatible), It's
> *essential* to identify the original hardware, so past and future diskettes can be recovered, as I'll describe.

[roger arrick]

Great conversation.

I have MDS888 and MDSII systems that can R/W real M2FM diskettes AND single density.  It takes some effort to keep them running.

Don't forget that intel first provided a single-density 8" floppy controller and drives for their dev systems.  Regular 77 track, 26 sec, 128b.

Intel's single and double density board sets could coexist in a system and up to 6 drives.

I guess it would be cool is to have a multibus board that emulated a floppy controller/DMA pair and could exist in a system with floppy drives while providing access to a SD card that had a FAT file system so we could transfer data.  There could be a utility that selected floppy images with thousands of programs on the SD card.  But that's a lot of work and there are other ways to accomplish this.

This reminds me of the QBone board for DEC PDP11 QBus.  it's fantastic. https://decromancer.ca/qbone/

QBone - The Decromancer QBone Yukon Gold. Note: We are considering bringing back the QBone Yukon Gold in the new Dual format as a limited edition.If you would be interested in purchasing one at the price shown, let us know. The QBone Yukon Gold special edition sports "hard gold" edge fingers, thickened gold plating on all pin headers and IC sockets, and specially selected DS3662 bus driver chips. decromancer.ca

I guess my main interest would be to able to have access of all the preserved software out there for ISIS.  And don't forget that CPM will boot on MDS hardware and of course there are thousands of CPM programs out there.  If I could buy a multibus board that emulated an FDC and had access to all existing software, all versions of the OS, assembliers, etc, I'd probably buy that.

--  Roger Arrick -- Tyler, Texas, USA -- Ro...@Arrick.com --

---

From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of Herbert Johnson <hjoh...@retrotechnology.com>
Sent: Sunday, June 15, 2025 6:27 PM
To: intel-...@googlegroups.com <intel-...@googlegroups.com>

Subject: Re: intel-devsys Making an disk image

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/75a7bdf0-d32e-4422-9f8b-a6df3c9c0393%40retrotechnology.com.

[William Beech]

Mark,

Yes.  I had a space in the path.  That corrected the problem.  I can
create recipes with unidsk now.  I had to create an empty ncatalog.db
file in the IFILEREPO directory to get it working.  It appears you just
get the Usage message if something is wrong, like no file or bad file. 
That through me for a bit initially.

Off to see what I can do with this.

Thanks!

Bill

[William Beech]

Well, we have that card possibly with the Zendex ZX-200A controller.  It
uses an 8085 processor, an 8257 DMA controller,  and implements an FDC
in TTL logic.  I am sure the chips that implement the M2FM could be
programmed to do MFM, and the board supports FM as is.

What you are suggesting is GOTEK for M2FM.  With a regular IMG file, a
GOTEK will do this now.  The GOTEK does not care if the original was FM,
MFM, M2FM, or one of the Amiga or Commodore low-level disk formats.

We could run other Intel OSs on the same system.

I have run ISIS-II and CP/M-80 on newer media than the original was
designed.  I am using 3.5-inch floppies on my MDS-II with no problem.

I am in the process of designing a replacement JadeDD FDC replacement
with a 33 MHz Zilog Z180 and the WD 2797 FDC for the S-100 bus.  I need
some more FDCs to get my other S-100 systems running.  I prefer the WD
to the NEC/Intel FDC chip operation.

Bill

[scott baker]

Well there is my raspberry pi based SBC-202 emulator. I wouldn't call it a Gotek-style M2FM emulator, as it replaces the whole disk controller board set. It sounds like what roger is describing. And yes, the pi' can simultaneously hold every disk image that currently exists and probably every disk image that ever did exist, and you can switch images and even live-edit images as it's running. I really ought to do a write-up and a video on it one of these days.

Wow, I couldn't even find a digital picture of the thing; I must have really jumped to whatever project was next on my list. Took a picture of it tonight. In addition to the disk emulator, it also has RAM, optional ROM, and a pair of multimodule slots. It's a bus master using a D8218. It's all up on github.

As far as I know, it's only useful for ISIS though. To get CP/M running, I used a real iSBX-218 multimodule, which would be a lot easier to just outright clone and hook a conventional Gotek up to.

Scott

[mark.p...@btinternet.com]

The M2FM encoding was effectively the BetaMax of floppy formats. I am only aware of Intel and Dec using it on 8” DD disks, and like the hard sector formats used by various companies, the format is now increasingly difficult to preserve. I suspect the move to stepper motor drives in later disks, improved the signal quality and the need for the more complex M2FM coding was no longer justified, hence the rise of MFM, supported by single chip controllers. The IBM PC also clearly accelerated this change.

 

Given the rarity of working 8” disk drives and floppy disks, a M2FM codec, possibly as an application on something like a Raspberry Pi, is likely to be needed. In principle devices like Catweazle can do this. However, at the risk of being slightly contentious, as a long-term preservation goal for working systems, would direct emulation of a small set of disk controllers using memory cards rather than real or emulated floppies be a simpler and more robust solution, also the disk transfer speeds would be much faster.

The Intel IOC board communication for disk controllers is a relatively simple interface, and is used for Intel ISIS and CP/M, neither OS cares about the floppy encoding, other than sector size. The interface for Winchester disks in later versions of ISIS is also relatively simple.

 

With careful design, it should be possible to separate out the interface to the host computer, from the disk controller emulation, allowing elements of the solution to be reused across systems.

 

Clearly if a host computer has an embedded disk controller, the readily available floppy emulators can already be used. This includes Intel MDS with the SD disk controller. But these are limited to floppy disk read/write speed limitations.

 

Mark

From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of scott baker
Sent: 16 June 2025 06:50
To: intel-devsys <intel-...@googlegroups.com>
Subject: Re: intel-devsys Making an disk image

 

Well there is my raspberry pi based SBC-202 emulator. I wouldn't call it a Gotek-style M2FM emulator, as it replaces the whole disk controller board set. It sounds like what roger is describing. And yes, the pi' can simultaneously hold every disk image that currently exists and probably every disk image that ever did exist, and you can switch images and even live-edit images as it's running. I really ought to do a write-up and a video on it one of these days.

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/15036aab-8c7d-41d9-8fd1-f4e9dd59f2ean%40googlegroups.com.

[William Beech]

Scott,

That is an interesting approach!  And it is 1 board.  The Zendex is also a single board solution.

I would bet it could host a CP/M-80 disk image, just as well.  I would need to see the software.  I will look on GitHub later today.

Bill

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/15036aab-8c7d-41d9-8fd1-f4e9dd59f2ean%40googlegroups.com.

[William Beech]

Mark,

Excellent description!

I see there are two camps working with the old systems.  One group are the purists who have to have the original hardware and software working - EG the computer museums.  The other group is us, trying to keep the systems working with newer hardware solutions or like me, simulation of the old systems.  And archiving the old software.  Different goals.  Nothing wrong with either approach!

I think even in 1979 when I built my first S-100 system, FM and MFM, with single chip controllers,  were the clear winner.  I agree that a small set of controller cards, possibly like Scott made for multibus I might be the correct solution.  I agree the FD and HD IOPB interface is a simple interface. 

Reuse across systems is a plus!

So the solution is beyond the GOTEK idea to emulating the entire FD and HD subsystems with modern hardware/software and providing the original hardware interface to the bus?  This really sounds like Scott's board.

Maybe my way forward is to do the same thing for the S-100 bus?  We could have common software and different hardware solutions?

Good discussion!

Bill

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/012c01dbdedd%24a7b7c960%24f7275c20%24%40btinternet.com.

[William Beech]

Scott,

Could you post the schematic of the diskboard like you did with the ramboard?

Thanks!

Bill

On 6/15/2025 10:49 PM, scott baker wrote:

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/15036aab-8c7d-41d9-8fd1-f4e9dd59f2ean%40googlegroups.com.

[Herbert Johnson]

I'm dithering on responding to Mark Ogden's post, because I mostly agree
with it but I dispute a few things. So I'll be brief.

I have a Web page on M2FM / MMFM history:

https://www.retrotechnology.com/herbs_stuff/m2fm.html

It needs updating from year 2017, because more documents are available.
Parts are unclear. I don't intend to document all the flux-change
controllers that came after the Catweasel, a now-dead product.

But it presents most of the same considerations that Mark Ogden refers
to. It also lists the origins of M2FM format, from IBM and SHugart. I
list *all* of the M2FM implementations and references I'm aware of.
There's so few implementations, and they are I believe mutually
incompatible.

Of the lot, only Intel's M2FM and DEC's RX02 implementations have any
followings. So I'll just say that anything we do for M2FM re
implementation on Intel, may not do much for DEC's RX02, and won't be
noticed for any other M2FM implementations.

As far as why almost nobody used M2FM, it's largely because the Western
Digital WD177X series of microcontroller FDCs did not implement it (one
exception). It became easier to build WD177X, 178X, 179X, floppy
controllers than discrete/microcontroller equivalents. All that happened
before the 1981 IBM PC by about five years, by the way.

But the general idea of separating the bus interface controller from the
floppy drive formatting controller, makes sense. It's a means to
mix-and-match different floppy "geometries" with different vintage buss
and model controller "geometries", to the extent an OS (or a program in
an OS) has some flexibility. In the end, there's not many M2FM
implementations to deal with, maybe two.

And it's an old idea. DEC's RX01 and RX02. Digital Systems drive system
in the S-100 CP/M era (ask my Web site). Non-bus based floppy
controllers for minicomputers did that (ask my Web site for "first
floppy controller").

And such a division, lends itself to no-floppy floppies. That is a
modern mass-storage media controller for disk images as part of 21st
century file-systems on mass storage (disk images on FAT32, etc.) This
is a popular thing for 21st century vintage computing owners.

So I think the M2FM situation, may prove to be a special case; FM and
MFM may be the general case; and modern mass-storage (SDcard, USB flash
drive) may be the modern case.

If that is going to be the discussion and plan, I suggest changing the
topic from "making a disk image" to something else. That's up to
whomever "bells the cat", whomever creates some designs.

regards Herb

> *From:*intel-...@googlegroups.com <intel-...@googlegroups.com> *On
> Behalf Of *scott baker
> *Sent:* 16 June 2025 06:50
> *To:* intel-devsys <intel-...@googlegroups.com>
> *Subject:* Re: intel-devsys Making an disk image

> <mailto:intel-devsys...@googlegroups.com>.

> To view this discussion visit

> https://groups.google.com/d/msgid/intel-devsys/15036aab-8c7d-41d9-8fd1-f4e9dd59f2ean%40googlegroups.com <https://groups.google.com/d/msgid/intel-devsys/15036aab-8c7d-41d9-8fd1-f4e9dd59f2ean%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "intel-devsys" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to intel-devsys...@googlegroups.com

> <mailto:intel-devsys...@googlegroups.com>.

> To view this discussion visit

> https://groups.google.com/d/msgid/intel-devsys/012c01dbdedd%24a7b7c960%24f7275c20%24%40btinternet.com <https://groups.google.com/d/msgid/intel-devsys/012c01dbdedd%24a7b7c960%24f7275c20%24%40btinternet.com?utm_medium=email&utm_source=footer>.

[Michael Thompson]

On Mon, Jun 16, 2025 at 3:01 PM William Beech <nj...@nj7p.org> wrote:

Mark,

Excellent description!

I see there are two camps working with the old systems.  One group are the purists who have to have the original hardware and software working - EG the computer museums.  The other group is us, trying to keep the systems working with newer hardware solutions or like me, simulation of the old systems.  And archiving the old software.  Different goals.  Nothing wrong with either approach!

Bill

The Rhode Island Computer Museum tries to keep machines operational because a static computer display is boring. We have disk and diskette emulators on many of our microprocessor based systems because the real drives are not reliable enough to use on a running display. We even have disk emulators for our 1960s and 1970s minicomputers for the same reason. We will do just about anything to keep a 60 year old system running so our visitors can interact with it.

 

--

Michael Thompson

[William Beech]

Michael,

Exactly!  You are purists and exactly right in your goal.  Absolutely nothing with this goal.  I have different goal and nothing is wrong with mine, either.

Bill

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/CAH1BU%3D-SC%2BJ70BgwzuXaSaeB4RFF5k90KE5V6v-YxGt2y64i5A%40mail.gmail.com.

[scott baker]

Bill,

Sure -- diskboard schematic is up at https://github.com/sbelectronics/multibus/tree/master/boards/diskboard

Scott

[William Beech]

Scott,

But where is the multibus P1 connector?

I know.  Picky, picky, picky!

The S100 Computers group has an S-100 board that interfaces a Pi 0 to the S-100 bus.  It appears I could use your code on this to implement an FDC/HDC for the S-100 bus.

Bill

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/4e22cc5d-4015-4e5f-88d9-5cb22ea4792cn%40googlegroups.com.

[scott baker]

Doh! It printed the current page instead of all the pages.

Fixed.

Scott

[William Beech]

Hey, it is still Monday!

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/76ad8778-997e-4472-a0c1-411c0642eaban%40googlegroups.com.

[William Beech]

Mark,

I have played for a solid week trying to rework your UNIDSK to handle other disk types like CPM, MSDOS, and Xenix.  All I managed to do was break your work. 

I have decided what was needed was a different input and output program for each listed OS type.  So I will try to make a UNCDSK, UNDDSK,  and UNXDSK to handle the listed disk formats.   A one size fits all is just not going to work.

I will attempt to work into your database for the recipe.  I will then attempt to do the MKxDSK for each OS.

I am going to start with PCDOS versions I have disassembled and made to be byte-for-byte solutions for Boot, IBMBIO and IBMDOS.

Bill 

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/012c01dbdedd%24a7b7c960%24f7275c20%24%40btinternet.com.

[mark.p...@btinternet.com]

Bill

I have put the following files on my website at https://mark-ogden.uk/files/intel/prebuilt/, they may be helpful

Uncdsk.pl         perl tool that uses cpmtools to extract files, handles different user areas and reserved MSDOS names

                  I use a version of cpmtools with libdsk support, so I can process img and imd files

xenixdump.pl          perl tool that extracts xenix files. It only processes .img files

Unirmx            an improved iRMX/ISIS IV file extractor. It only processes .img files for now. Source is on github

Tarimd.cmd        extracts tar files from a .imd file. Requires  perl

Mark

---

From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of William Beech <nj...@nj7p.org>
Sent: 23 June 2025 04:33
To: intel-...@googlegroups.com <intel-...@googlegroups.com>

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/76c91ed2-402b-4492-8600-7b03b88cdf38%40nj7p.org.

[William Beech]

Mark,

I will check those out.  Thanks!

Bill

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/VI1PR05MB441324A7F9D4FC705B2ADCB3FC79A%40VI1PR05MB4413.eurprd05.prod.outlook.com.

[Eric Smith]

On Mon, Jun 16, 2025 at 10:42 AM mark.pm.ogden via intel-devsys <intel-...@googlegroups.com> wrote:

The M2FM encoding was effectively the BetaMax of floppy formats. I am only aware of Intel and Dec using it on 8” DD disks,

It's worse than that. With Betamax, at least you could interchange tapes between Sony, Sanyo, Toshiba, Pioneer, Aiwa, and NEC Beta VCRs. There was literally no standard for M2FM, so Intel and DEC M2FM are completely different. Any other M2FM disk formats that aren't deliberately designed for Intel or DEC compatibility are likely to be completely different as well.

AFAIK, the only VLSI FDC chips that can support M2FM are the TI TMS9909 and the Signetics 8X330. I'm not sure whether the TMS9909 is capable of reading and writing DEC RX02 M2FM, but apparently the Zendex ZX-203 used the 8X330 for Intel M2FM format.

[Frode M]

DEC "M2FM" isn't even true M2FM in the sense in that it would suggest the bit-stream encoding is "double-modified" in terms of FM. It's in my understanding just standard MFM sector data, with standard FM sector headers. Other than alternating between encoding scheme, none of the bit-stream encoding schemes have additional modification. There are no fourth time-delta state added.

HP M2FM is another beast, that is truly M2FM, and different compared to Intel M2FM.

-Frode

[mark.p...@btinternet.com]

I went back and checked my flux2idm data tables re DEC and HP

My memory had clearly failed me in my initial posting, and I had swapped DEC & HP.  DEC does not appear to be one of the M2FM formats, however HP is. The format I have seen is the 30 sectors of 256 bytes.

Key differences between HP and INTEL implementations

• The DATA address marker is different from the INTEL 128 byte sector one, which is reasonable due to sector sizing.
• I hadn't been able to match any Index Marker, which may have been omitted, again with soft sector disks this is possible as it would give more room for data on the track.
• The data bits for a byte are sent to disk in reverse order compared to INTEL. This also impacts the CRC calculation done on this bit stream.
• The IDAM has 2 additional data bytes.

Mark

---

From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of Frode M <fvdm...@gmail.com>
Sent: 22 July 2025 23:29

To: intel-devsys <intel-...@googlegroups.com>
Subject: Re: intel-devsys Making an disk image

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/82525f9a-fff6-4eeb-854c-f7c77d742642n%40googlegroups.com.

[Eric Smith]

On Tue, Jul 22, 2025, 16:29 Frode M <fvdm...@gmail.com> wrote:

DEC "M2FM" isn't even true M2FM in the sense in that it would suggest the bit-stream encoding is "double-modified" in terms of FM. It's in my understanding just standard MFM sector data, with standardd FM sector headers.

No, DEC RX02 does use the M2FM encoding rules, though to a limited extent. It's covered in the RX02 tech docs.

[Frode M]

Right.. I see what you mean after checking the mentioned document, but after reading it I would still be hesitant to use the terminology "M2FM" based on the intent of the modification it refers to. The DEC modification is more of a quickfix for a potential problem with their own layout scheme, while Intel and HP used "M2FM" as a marketing term for encodings that deliberately added a fourth time-delta state for the sole reason of reducing the number of flux reversals in general. You also see this reflected in the DEC documentation, as they mostly only use the terms MFM or Miller-code when describing the data-format, without mentioning it being modified except for the brief section where the low-level details are described.

-Frode

--
You received this message because you are subscribed to a topic in the Google Groups "intel-devsys" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/intel-devsys/Y6P9XJPwYbk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to intel-devsys...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/CAFrGgTSVvatrMvwFqy9ep2ZXJQZ1z9XLsDvxHoZVM4ws_X-88w%40mail.gmail.com.