MFM_EMU lockup at second INDEX Pulse?

[Jefferey Wilson]

I am in the process of bringing up a CompuPro 8/16 with a Disk3 HDD Interface and CDOS 4.1E, using the BeagleBone Green (the base model...not the Wireless or Gateway version).  I am using a Rev C. MFM_EMU emulator board.

I don't have an original Quantum 540 drive image so I created a raw image with the --initialize option:

    mfm_emu --drive 1 --file Q540A --initialize --cylinders 512 --heads 8

Upon running setup_emu and starting the emulator as follows:

    mfm_emu --drive 1 --file Q540A

I get the following output:

    Board revision C detected
    Drive 0 num cyl 512 num head 8 track len 20836 begin_time 0
    PRU clock 200000000
      Waiting, seek time 0.0 ms max 0.0 min free buffers 200
    bad pattern count 0
    Read queue underrun 0
    Write queue overrun 0
    Ecapture overrun 0
    glitch count 0
    glitch value 0
    0:test 0 0
    0:test 1 0
    0:test 2 0
    0:test 3 0
    0:test 4 0
    1:test 0 0
    1:test 1 0
    1:test 2 0
    1:test 3 0
    1:test 4 0
    select 0 head 0

I then started the CompuPro DISK3 format program, which prints that it is formatting cylinder 000, and I saw the LED that I put on J7 for Drive Select 0 light up.  After the drive select went active, I saw MFM_EMU (on the console) respond with:

    select 1 head 0

And then everything froze.  No further activity on the MFM_EMU nor on the CompuPro.  Doing some repeated tests and scope captures, I have see some odd index behavior; namely, upon the initial drive selection I get just one index pulse and then ~16.6ms later, the index line goes low and stays low until I reboot the BeagleBone.

Could this be a PRU issue, an emulation file initialization issue, or maybe a BeagleBone board revision issue?

I can share the relevant emulation file if needed.

So, any suggestions on a fix or what to try next?

Thanks in advance!

-Jeff

[David Gesswein]

On Mon, Aug 19, 2024 at 09:24:20AM -0700, Jefferey Wilson wrote:
>
> So, any suggestions on a fix or what to try next?
>

Try forcing a dump and send me the output

Run mfm_emu with output directed to a file and put in background

For new OS image
/opt/prudebug-0.24b/prudebug
halt
q

Adjust path as needed

Should get a file with a bunch of hex data.

[Steve Mastrianni]

Jeff, I’m running David’s boards on one of my CompuPro systems with a q540 image of cdos 41. I don’t recall if it’s a cpu 8086/87 or 8085/88, I can check. It’s running on a disk3.

Anything I can do to help, ping me.

--Steve

Dr. Steve Mastrianni
Sent from my iPhone

> On Aug 19, 2024, at 9:57 PM, David Gesswein <d...@pdp8online.com> wrote:

> --
> 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/ZsP4JUZUxHA5sutC%40hugin3.

[Jefferey Wilson]

Thanks Steve and David!

At this point, if you'll pardon the pun, I think my BeagleBone is boned.  It was a used eBay purchase, and I have seen other evidence that all is not well with it.

I have a new one from Mouser arriving today, so I'll give an update when I get the new board set up and tested.

-Jeff

[Jefferey Wilson]

Update:

The new BeagleBone arrived and behaved the same way as the old one, so the BeagleBone was not the issue.

At this point I decided I was chasing software phantoms that weren't there, so I started ringing everything out...ICs, wiring, build options, even resistor divider voltages.

Turns out I had a bad R/W Cable...now fixed and everything is operational.

I let it spend the afternoon formatting, and read/write and seek testing.  Then I copied the system files, SYSGEN'ed the OS and I now have it up and running Concurrent DOS 4.1E.

Next up is days of configuration and software installation.

Thanks for all the support, and sorry for the false alarm!

Cheers,

Jeff