Not sure how to convert PERQ_T2 .emu files to images

[Tom Stepleton]

Hi folks,

I suspect I'm doing it wrong when it comes to converting PERQ T2 .emu files to images. My reason for thinking so is that I get a lot of bad sectors when I do that, even on disk images that I don't think are bad. Does anyone have any advice to share?

I don't have any real PERQ disks to draw images from yet, so here's what I'm doing instead: taking some .emu files for MFM hard drives from other systems and then reformatting them inside of my PERQ.

One .emu file emulates a Vertex 150 drive, and the other the mighty Maxtor XT1140. The V150 image is one that has been used in an MFM emulator in someone else's PERQ before, but its provenance is unknown to me. The XT1140 image is all my own: it's the .emu file from here which was never an actual drive --- it started life as a late-night mid-pandemic experiment that I only dimly remember with ext2emu and an ".img" file full of zeros. Either way, it formatted fine in a Whitechapel MG-1, and the .emu file that emerged after that can be --analyze'd and converted to a disk image without any trouble. Here's how mfm_util declares victory:

Found cyl 0 to 917, head 0 to 14, sector 0 to 17                              
Expected 247860 sectors got 247860 good sectors, 0 bad header, 0 bad data
0 sectors marked bad or spare
0 sectors corrected with ECC. Max bits in burst corrected 0

So these are the .emu files that I then serve to my own PERQ 2T2 via the MFM emulator and reformat using the PERQ's own utilities. After I do that, the emulated drives appear to work just fine inside of the PERQ. But when I try to use mfm_util to dump .img files, there are loads of bad sectors, even from the XT1140 image. Here's how mfm_util confesses defeat at the end of many error messages encouraging me to try different --begin_time flag values:

Found cyl 0 to 917, head 0 to 14, sector 0 to 14
Expected sectors 16 doesn't match sectors found 15
Expected 220320 sectors got 177157 good sectors, 0 bad header, 43163 bad data
0 sectors marked bad or spare
0 sectors corrected with ECC. Max bits in burst corrected 0

The V150 image behaves differently, with most of the bad sectors concentrated in the lower-numbered cylinders, and no advice to set --begin_time. I actually have these .emu files online already, linked near the very bottom of https://mg-1.uk/

I'm not setting any drive parameters when I invoke mfm_util; I'm just using the -a flag. Is there something I should do differently to create good images from PERQ .emu files?

nb: In all the above, I've been working with freshly-compiled MFM source code that's up-to-date with the github repo.

Thanks for any tips --- of course, it's excellent that it's possible to have a hard drive replacement for a PERQ at all!

--T

[David Gesswein]

Released fix for V150 image. Didn't see link to XT1140 image to test.

On Mon, May 05, 2025 at 10:27:40PM +0100, Tom Stepleton wrote:
> Hi folks,
>
> I suspect I'm doing it wrong when it comes to converting PERQ T2 .emu files
> to images. My reason for thinking so is that I get a lot of bad sectors
> when I do that, even on disk images that I don't think are bad. Does anyone
> have any advice to share?
>
> I don't have any real PERQ disks to draw images from yet, so here's what
> I'm doing instead: taking some .emu files for MFM hard drives from other
> systems and then reformatting them inside of my PERQ.
>
> One .emu file emulates a Vertex 150 drive, and the other the mighty Maxtor
> XT1140. The V150 image is one that has been used in an MFM emulator in
> someone else's PERQ before, but its provenance is unknown to me. The XT1140
> image is all my own: it's the .emu file from here

> <https://mg-1.uk/42nix/42nix.html> which was never an actual drive --- it

> --
> You received this message because you are subscribed to the Google Groups "MFM Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mfm-discuss...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/mfm-discuss/CAGM3D%2BpqTT_fWOXSe2G%3Dy6P%3Dpj%3DozTzaKpsJH3SJ9KFyKMwV3A%40mail.gmail.com.

[Tom Stepleton]

Wow, thanks for the very rapid fix!

I hadn't shared an XT1140 image, but here is one. Beware that this small compressed file expands to a 290 MB .emu file:

https://archive.mg-1.uk/tmp/pos_G.7_land_amendment_pascal_and_empty_partitions_PERQ_T2_Maxtor_XT1140.emu.bz2

Your patch actually improves the decoding of this image considerably, but it doesn't fix everything. Either mfm_util is incorrectly looking for a 16th sector on every track, or there is a 16th sector that mfm_util is having trouble decoding.

Thanks again for the quick work!

--T

To view this discussion visit https://groups.google.com/d/msgid/mfm-discuss/aBlmO2koZjeZCrQt%40hugin3.

[David Gesswein]

Problem is begin_time wasn't specified when emulator file was created.
Its probably better to create new file with --initialize and other
proper options than reuse.

Specifying begin_time during decode of an emulator file does nothing. The
V150 decodes properly since it had begin_time set when it was created.

The code decodes data from index to index. Begin_time adjusts actual
capture from index so capture starts between sectors. If capture starts
in middle of sector it can't decode it. On a real disk the
index pulse isn't accurate enough that you can just wrap around and start
decoding from the beginning of the capture to get the rest of the data for
a sector. The emulator file is is accurate so that should work. Thats why it
works on the real machine.

I tried to put in a quick hack to wrap around on the decoding but it
didn't work.

My code was originally written to decode captures from real disks so works
off time deltas between rising edges of the MFM data. To make my life
easier I convert the MFM bitstream in an emulator file back to time deltas
to feed to the decoder. That makes the delta that wraps around on the
track wrong. I might be able to make it work but will need more though
that I have time for right now.

> To view this discussion visit https://groups.google.com/d/msgid/mfm-discuss/CAGM3D%2BrB7mtH-MFis-d0rXzftvG8oVUD2k4JFE2bm6xQWH2CbA%40mail.gmail.com.

[Tom Stepleton]

Thanks for the tip. I did some experimentation and found that this command will yield a Maxtor XT1140 .emu file that the PERQ likes to format and that mfm_util likes to decode:

mfm_emu --initialize --begin_time 754000 --cylinders 918 --heads 15 --drive 1 --file my_xt1140.emu --rpm 3600 --rate 10000000 --options " --format PERQ_T2 --cylinders 918 --heads 15 --sectors 16,0 --header_crc 0x0,0x8005,16,0 --data_crc 0x0,0x8005,16,0"

--T

To view this discussion visit https://groups.google.com/d/msgid/mfm-discuss/aBoSo41Q4Yo0JfJk%40hugin3.

[David Gesswein]

FYI: Its a little confusing since some --format such as PERQ_T2 specify all
the parameters and some don't. For ones that do you don't need to specify
the crc and other parameters so can simplify the command line.

Do you wish me to look further at decoding the existing xt1140 files or are
you ok with recreating as below?

> > https://groups.google.com/d/msgid/mfm-discuss/aBoSo41Q4Yo0JfJk%40hugin3.

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

> To view this discussion visit https://groups.google.com/d/msgid/mfm-discuss/CAGM3D%2BobFsCaS4s-dih_saNBXqfpV67W8-hj09t6cj13h6haXw%40mail.gmail.com.

[Tom Stepleton]

Thanks David, there's no need to look into it on my account; I'm happy to start fresh with new XT1140 .emu files. I suspect that there is probably not a pressing need for other XT1140 .emu files to be decoded either.

Instead of that, if you feel like it, I think something that would be really helpful for PERQ pals is tips on how best to use ext2emu for PERQs. I think it will soon be possible to convert PERQemu hard drive files to `.img` and `.img.metadata` files before long, and being able to turn those into .emu files will make it easier to try out lots of interesting software on real hardware.

PERQ 2T2 machines tended not to use a wide variety of hard drives, so far as I know. So, if it matters, the kinds of drives that I expect are more likely to need simulating are the Micropolis 1304, the Vertex V150, and the Maxtors XT1105 and XT1140.

Thanks,

--T