Anyone using an MFM emulator with a PERQ 2T2?

[Tom Stepleton]

Hi folks,

I'm trying to revive an old PERQ 2T2, and it might be nice to eliminate the hard drive as a source of trouble. I've got an MFM emulator set up and ready to go, but I don't have a PERQ-formatted drive image, and I can't easily make one with ext2emu because this requires a metadata tag file that I lack.

Does anyone on this list have use an MFM emulator with their PERQ T2? Would you be willing to share your hard drive image with me?

And incidentally, if anyone has an idea of why the boot process would fail with 231 on the DDS, I'd love to collect your theories!

Many thanks,

--Tom

[Tom Stepleton]

To follow up with a general question that might help me understand how functional my PERQ's hard drive system is:

If you see mfm_emu generate a sequence of "Waiting, seek time <etc>" messages but no other kinds of messages (e.g. no "select N head M" or "Cyl X,Y select <etc>" messages), what might you infer that the computer was telling the drive to do?

Finally, some clarification on my earlier message: by "boot process" I mean the POS boot process specifically. And by "make one with ext2emu", my hope had been that I could create a hard drive's worth of fake extracted data (a bit over 36 MiB in my case) and convert that into an emulation file with ext2emu.

Thanks again,

--Tom

[Joan Touzet]

Hi Tom,

Yes, I've used the MFM emulator with my PERQ T2. It works well enough. I demoed Accent and POS at a computer show in the greater Toronto area with one a couple of years ago, and it seemed to be stable enough in that environment.

T2s are more reliable than the older PERQs, but they still can have flaky hardware. If you can rule out hardware problems with an already working drive, that might help. Do you have a drive that works with the machine right now? Can you just image that drive with the emulator?

My T2 came to me missing the DIB (says Drive Adapter Board on it, but abbreviated DIB), but a friend managed to secure one for me. (I also had to repair a failed PAL on mine.)

Error 231 looks like a memory error: https://github.com/jdersch/PERQemu/blob/master/PERQemu/Docs/POS%20Pascal%20Source/memory.pas#L805

I've asked Josh Dersch if there's a way the .phd images he and skeezicsb developed for the PERQ emulator can be converted to .emu files quickly, as I don't have permission to redistribute the drive image I have. However, as a quick stopgap, the command line used to read an older Priam drive that was successfully emulated was:

    --format PERQ_T2 --sectors 16,0 --heads 5 --cylinders 987 --header_crc 0x0,0x8005,16,0 --data_crc  0x0,0x8005,16,0 --sector_length 512 --retries 50,4 --drive 0  --begin_time 742400

Hopefully this is enough breadcrumbs to get you going with ext2emu.

Cheers,

Joan

[Tom Stepleton]

Thanks Joan,

Unfortunately I don't have any MFM drive I can image. This is why I'm hoping someone on this list can help me out. It's understandable if you can't share your drive image, but might it be possible for you to share the tag metadata file that you will have recovered from your Priam drive when you created an image of it?

The metadata file (called <image name>.metadata) shouldn't contain any private information at all, and if I combine that with an all-zeros file that is exactly the same size as the extracted data file that you recovered alongside of it, I should be able to use ext2emu to create a proper PERQ-formatted disk image. ext2emu can't create PERQ_T2-formatted emulator files without a metadata file.

Which variety of DIB do you have: Maxtor or Micropolis? I actually have three of them, all Micropolis types, but my understanding is that both models should be compatible with most MFM drives.

Thanks for the theory about what's bothering my PERQ... DDS=231 does look like a memory issue, but skeezicsb and I have been wondering if this might be a red herring. Last night I found out that this PERQ can boot PNX from a floppy disk, and the kind of operations that POS is doing on RAM in that part of InitMemory and in ChangeSize don't seem very complicated at all in comparison to getting a full-blown UNIX up and running.

Instead, since ChangeSize contains a few references to the disk (using it for swapping, etc.), we've wondered if our POS boot floppy might require a correctly-formatted disk in order to avoid running into troubles. I'm a bit dubious that this should be the problem, particularly given the log messages from mfm_emu (see my other question), but it would be very nice to rule out the disk as a possible culprit.

(Finally, in case the thought crossed anyone's mind: I can't low-level format a drive in PNX for use with POS because at this point we still don't have a functioning display. I can't see what I'm typing yet --- instead, it's just DDS=255 that tells me that we have a successful PNX boot.)

Thanks again,

--T

--
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 on the web visit https://groups.google.com/d/msgid/mfm-discuss/c5279104-b96f-411f-abc5-8051cbd96d91n%40googlegroups.com.

[Joan Touzet]

Hi Tom,

Sadly, I don't have any metadata file created by David's toolset. I just have the .emu file itself, which includes the extraction data in the header that I put in the last email.

I contacted you off-list with the promised .emu files. Check your email! You should be able to boot directly from either of those - though without a display it may be challenging to make them work usefully!  😉

I believe I have a Micropolis DIB.

[David Gesswein]

On Tue, Oct 22, 2024 at 12:17:41PM -0700, Joan Touzet wrote:
> Hi Tom,
>
> Sadly, I don't have any metadata file created by David's toolset. I just
> have the .emu file itself, which includes the extraction data in the header
> that I put in the last email.
>

If you use mfm_util to create extracted data file from emulator file it
will create metadata file also.