Emulation in an AT&T 3B2/310

[Zachary Hardesty (SuigintouLain)]

Howdy,

Right now I'm working with a Rev C that was pre-assembled and acquired at VCF East '21. When I started this project last night, I flashed 7.11, then 11.8 from the website, then did the git pull / make clean / make dance.

I have it installed in a 3B2/310 that originally had a CDC Wren II 72MB, which formatted correctly but later encountered some issues (potentially with weak sectors) while booted into SysV.

Attempting to emulate that configuration (925 cyl, 9 heads), as well as the smaller 30MB configuration (697 cyl, 5 heads), spews the console with the following:

  Waiting, seek time 0.3 ms max 0.3 min free buffers 200
  Waiting, seek time 0.3 ms max 0.3 min free buffers 200
  Waiting, seek time 0.3 ms max 0.3 min free buffers 200
  Waiting, seek time 0.3 ms max 0.3 min free buffers 200
  Waiting, seek time 0.3 ms max 0.3 min free buffers 200
  Waiting, seek time 0.3 ms max 0.3 min free buffers 200
  Waiting, seek time 0.3 ms max 0.3 min free buffers 200
glitch count 1
glitch value f00
  Waiting, seek time 0.3 ms max 0.3 min free buffers 200
  Waiting, seek time 0.3 ms max 0.3 min free buffers 200
  Waiting, seek time 0.3 ms max 0.3 min free buffers 200
  Waiting, seek time 0.3 ms max 0.3 min free buffers 200
  Waiting, seek time 0.3 ms max 0.3 min free buffers 200
  Waiting, seek time 0.3 ms max 0.3 min free buffers 200
  Waiting, seek time 0.2 ms max 0.3 min free buffers 200

This repeats through to glitch count 16, when the system itself seems to give up and ask for the physical info. Proceeding through the formatting process, it seems to write successfully:

  Drive 0 Cyl 0->1 select 1, head 0 dirty 1f
Free buffers 195,0 delay 0.012
  Waiting, seek time 7.1 ms max 7.1 min free buffers 195

The moment it attempts to verify the format it throws one or two glitch counts and then fails to read with "FORMHARD: Verify Read of cylinder 0 head 0 failed due to failing sector 0", which ends the formatting process and it gives up.

I did notice in the dmesg log that it's consistently throwing the following error during the entire process:

[  147.733763] irq 110, desc: 66dd23b7, depth: 1, count: 0, unhandled: 0
[  147.733806] ->handle_irq():  ec9e4981, handle_bad_irq+0x0/0x270
[  147.733819] ->irq_data.chip(): de309118, 0xc2938e40
[  147.733826] ->action(): 00000000
[  147.733837]    IRQ_NOPROBE set
[  147.733845] unexpected IRQ trap at vector 6e

Any clue as to what could be wrong?

[David Gesswein]

Can you compress and upload the emulator file from one of the format attempts
to http://www.pdp8online.com/upload/abuploadab.html

> Waiting, seek time 0.3 ms max 0.3 min free buffers 200

These are odd. It triggered the seek logic but didn't think that the
cylinder changed. Think this will happend if it tries to step to a lower
cylinder when its already on cylinder 0.

Glitch counts are normally harmless. I did see them being generated in one
test recently but haven't had time to investigate further.

> I did notice in the dmesg log that it's consistently throwing the following
> error during the entire process:
>

Looks to be a change with the new OS. I think I know how to stop those messages
but will need some testing. Don't think they are causing problem but should
be stopped.

> The moment it attempts to verify the format it throws one or two glitch
> counts and then fails to read with "FORMHARD: Verify Read of cylinder 0
> head 0 failed due to failing sector 0", which ends the formatting process
> and it gives up.
>

Did it print select message? (select # head #)

Did you try reading the existing disk?

> --
> 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/ea9fb00a-c77d-45e7-936b-f68b88be0fd0n%40googlegroups.com.

[Zachary Hardesty (SuigintouLain)]

I was incorrect about the acquisition time, it was VCF '22.

> Can you compress and upload the emulator file from one of the format attempts

Uploaded both the output of the machine and the emulator, unannotated.

> These are odd. It triggered the seek logic but didn't think that the
> cylinder changed. Think this will happend if it tries to step to a lower
> cylinder when its already on cylinder 0.

I was joking with someone else that it was stepping backwards like a Disk II or something

> Did it print select message? (select # head #)

It's in the upload but for public consumption, these were the lines in the log (925 cyl, 9 head):

  Drive 0 Cyl 923->924 select 1, head 0 dirty 1ff
Free buffers 191,0 delay 0.024
  Waiting, seek time 12.1 ms max 12.9 min free buffers 191
  Drive 0 Cyl 924->0 select 1, head 0 dirty 1ff
Free buffers 191,0 delay 0.024
  Waiting, seek time 12.1 ms max 12.9 min free buffers 191
  Waiting, seek time 0.3 ms max 12.9 min free buffers 191

etc.

> Did you try reading the existing disk?

Not yet, that was my next step. I have two units and the expansion box; I can give multiple samples a try when I can get to the other units.

[David Gesswein]

Can you upload att310 also?

> To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/3b4d39ab-fc69-4d60-991a-caa4146d125fn%40googlegroups.com.

[Zachary Hardesty (SuigintouLain)]

Done, also added the logfile.txt which is mostly useless here but for completeness.

[Zachary Hardesty (SuigintouLain)]

I dumped the original Wren II which went perfectly:

Found cyl 0 to 924, head 0 to 8, sector 0 to 17
Expected 149850 sectors got 149850 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
Track read time in ms min 31.168791 max 422.619459 avg 37.453357

Someone elsewhere speculated that /TRACK0 was stuck. I checked and pin 31 (TRK0) on the uPD7261AD is always low while the emulator is high.

I'm going to pull the board and investigate closer, and I don't think it's the cables because they were able to dump the disk just fine.

In the meanwhile, if you want the 3B2 formatted Wren dump I can send that your way.

[Zachary Hardesty (SuigintouLain)]

??? Either I or my tester were broken last night, because the TRK0 line is working fine. Per the 7261 datasheet it runs through an LS14 NOT gate so it's acting as expected, but the problem persists. If there are any other ideas, let me know because I'm stumped.

The machine is also unable to read or format the original Wren, it fails to format even faster than the emulator (but still understands it exists).

[David Gesswein]

I assume you have verified that track0 is high at the 7261 when emulator is
at cylinder 0.

The image you sent doesn't decode. I do see formatted data. A lot of the
data should be repeating fill patterns but doesn't seem to be. If you have
a scope check the mfm write data when its formatting and see if the transitions
are at 200ns, 300ns, and 400ns between rising edges.

You can upload the image you read from the drive and I can see if it does
have the expected patterns.

> To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/3c9f195b-ca61-4900-bb5e-89fd9facbe49n%40googlegroups.com.

[Zachary Hardesty (SuigintouLain)]

> I assume you have verified that track0 is high at the 7261 when emulator is

> at cylinder 0.

Yes, that was my triple post confusion that was eventually rectified.

> If you have a scope

It's packed away but I know where it is. I'm going to scope all the lines.

I uploaded the image, the command as ran, and an image of the top of the drive for the bad sector map.

[d...@pdp8online.com]

I did a release that fixed the incorrect glitch message I was able to trigger here. The interrupt errors are going to take longer to figure out. Haven't seen and issues from them in my testing.

Image from real drive has the data patterns I expected so looks like your controller has problems.

[Joan Touzet]

I have a fix for the interrupt errors, it's been posted to GitHub as a PR:

    https://github.com/dgesswein/mfm/pull/42

To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/e024270a-11d3-43ad-87ad-ca418a794344n%40googlegroups.com.