I/O error on root device

[Adam Billyard]

Hi,

I'm using MFM emu on a Tektronix 4404 which had a Micropolis 1304.

I created a blank HD image (cylinders 830, heads 6) and I can see the Tek try and access it on boot up so I take that as a GoodThing that electrically its working:

  Drive 0 Cyl 0->1 select 1, head 0 dirty 0

  Waiting, seek time 0.6 ms max 0.6 min free buffers 75

  Drive 0 Cyl 1->2 select 1, head 0 dirty 0

  Waiting, seek time 1.5 ms max 1.5 min free buffers 75

  Drive 0 Cyl 2->3 select 1, head 0 dirty 0

  Waiting, seek time 2.4 ms max 2.4 min free buffers 75

  Drive 0 Cyl 3->5 select 1, head 0 dirty 0

  Waiting, seek time 0.6 ms max 2.4 min free buffers 75

  ...

select 0 head 0

But since I dont have a boot file on it I need to startup using the floppy drive.  When boot software comes to attempting to write to the MFM emu I get:
I/O error on root device during initialization

and just once I also got:
device full

Any ideas?  Feels like a timing issue perhaps.

Is there a debug extra logging I can enable?

Adam

[David Gesswein]

On Wed, Apr 05, 2023 at 12:38:10AM -0700, 'Adam Billyard' via MFM Discuss wrote:
> Hi,
>
> I'm using MFM emu on a Tektronix 4404 which had a Micropolis 1304.
>
> I created a blank HD image (cylinders 830, heads 6) and I can see the Tek

> try and access it on boot up so I take that as a *GoodThing* that
> electrically its working:

>
> But since I dont have a boot file on it I need to startup using the floppy
> drive. When boot software comes to attempting to write to the MFM emu I
> get:

> *I/O error on root device during initialization*

>
> and just once I also got:

> *device full*

>
> Any ideas? Feels like a timing issue perhaps.
>

The most likely issue is you haven't low level formatted the drive. The
sector headers are written by the host controller and until that is done it
can't write any data to the drive.
Ideally you will have a diagnostic disk/menu with
the option to low level format. For equipment like this they may not have
provided that tool to the user. If the old drive is or can be make alive enough
that mfm_read can determine the format we can use ext2emu to do the equivalent
of low level formatting. Without it you will need to try guessing at the format
but their are many supported. I do have a tektronix_6130 format.
I have a bug in data definition so can't be used right now. My comments say
it only differs from Intel_iSBC_215_512B if you have >= 8 heads so should
be able to use Intel_iSBC_215_512B assuming they used the same format on the
4404.

Try this
cd mfm
./ext2emu --ext /dev/zero --emu filename --cyl 830 --heads 6 --format Intel_iSBC_215_512B

Ignore message
Calculated extract file size 43345920 bytes, actual size 0

Then use filename for mfm_emu

[David Gesswein]

Found Tektronix 4170 used format XEBEC_104527_512B.

[Adam Billyard]

Cheers.  I'm sure you're right wrt low level formatting.  

I tried the Intel_iSBC_215 command but the Tek formatting command still fails with the same weird error:

Any thoughts anyone on what "Read Caps" are? Capabilities?


QQ:   I don't understand why when I use Cylinders:830 heads:6 (which is what 1304 specs say) I get a file that is much larger than 40MB.

[David Gesswein]

Little googling brought this up.
https://bitsavers.org/pdf/tektronix/44xx/070-5603-01_4404_Users_Manual_Dec84.pdf

May want to try crdisk. Apparently the floppy was customized for the system
to it may not work properly if it doesn't match your disk size. Can also
try rpdisk.


version of the operating system and three formatting utilities. They are:
1. crdisk-This utility physically reformats the winchester disk. It uses formatting
information unique to that specific winchester disk.
" "'"./ ../ ..r /...r ..r -.r- -./
) CAUTION ~
"crdisk" uses information specific to the winchester disk assigned to it at the
factory. Do not attempt to use this with any other winchester disk-it could
result in an extremely unreliable or even unusable system. If crdisk" destroys all
data on the winchester disk.
2. qfmt-This utility performs a "logical reformat" of the winchester disk. It
does not physically reformat the disk, but it destroys all information on
the disk.
3. rpdisk-A service formatting utility. Do not attempt to use this utility, it is
for the use of a competent technician only.
Using" rpdisk" requires hard disk information that is not available to the
user. If you use" rpdisk"


Physical format from keyboard-a physical format that requires the user to manually
enter the formatting information. This information is marked on the body of the
winchester disk and is not normally available to the user. This procedure is used by a
service person after replacing a winchester disk. The utility to perform this format is
called rpdisk.

> --
> 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/9765ee31-8c21-4ffa-bea4-037d54160132n%40googlegroups.com.

[Al Kossow]

On 4/5/23 3:10 PM, David Gesswein wrote:
> Little googling brought this up.
> https://bitsavers.org/pdf/tektronix/44xx/070-5603-01_4404_Users_Manual_Dec84.pdf
>
> May want to try crdisk. Apparently the floppy was customized for the system
> to it may not work properly if it doesn't match your disk size. Can also
> try rpdisk.

you may want to check with Josh Dersch if he made any progress getting his 4404 to
work.

I have one, but put it on the back burner when I couldn't find the right external
drive box for it.

[Adam Billyard]

Nice.  Great to have other Tek4404 owners I can contact.

I will try crdisk - my Sysreformat disk has a /etc/formatw  command that appeared to work - mfm emu logged lots of dirty sectors being flushed but I have no clue what the commandline args are (strings -a is not a Thing I have!) and although I have most of the 4404 docs (both physical and pdf) and cannot find mention of formatw..  It said it was formatting a 20MB Winchester with 8MB swap - which seemed vaguely sensible.

On the off chance I pinged Tektronix Support and they pointed me at this site for IMDs of all the floppies.

http://bitsavers.trailing-edge.com/bits/Tektronix/4404/4404/

I've converted them to .IMG  so just need to find a computer with floppy drives that I can dd to make pristine floppies of everything.  I appear to have multiple copies of Franz Lisp and Smalltalk-80 floppies but only 1 system software floppy.. Doh!

Thanks for all your suggestions - will keep you posted.

[Adam Billyard]

Just answer my own question and capturing for posterity:

I'd forgotten Tek4404 use a rebadged un*x clone called Uniflex.  The manuals are here and include formatw docs:  http://www.bitsavers.org/pdf/tsc/uniflex_68xxx/  

Also random tip:  The SysReformat floppy disk will not boot if the floppy is write protected.  Go figure!

[Al Kossow]

On 4/6/23 3:02 AM, 'Adam Billyard' via MFM Discuss wrote:

> http://bitsavers.trailing-edge.com/bits/Tektronix/4404/4404/ <http://bitsavers.trailing-edge.com/bits/Tektronix/4404/4404/>
>
that is my site, the original is bitsavers.org

>
> I've converted them to .IMG  so just need to find a computer with floppy drives that I can /dd/ to make pristine floppies of everything.  I

> appear to have multiple copies of Franz Lisp and Smalltalk-80 floppies but only 1 system software floppy.. Doh!
>

it would be nice to add any unique images that you have to the archive

[Adam Billyard]

Love to.  I have no idea how I image a physical floppy - presuming I need an old PC?

[Adam Billyard]

Doing a low level format of the emu disk, I get lots of this pasted below.  I'm presuming that is bad..

Drive 0 Cyl 15->16 select 1, head 0 dirty 3f

Free buffers 69,0 delay 0.040

  Waiting, seek time 6.4 ms max 180.5 min free buffers 52

glitch count 3956

glitch value d00

select 1 head 2

glitch count 4003

glitch value a00

select 1 head 5

  Drive 0 Cyl 16->17 select 1, head 0 dirty 3f

Free buffers 69,0 delay 0.040

  Waiting, seek time 6.3 ms max 180.5 min free buffers 52

glitch count 4032

glitch value e00

select 1 head 1

glitch count 4079

glitch value b00

select 1 head 4

  Drive 0 Cyl 17->18 select 1, head 0 dirty 3f

Free buffers 69,0 delay 0.040

  Waiting, seek time 6.4 ms max 180.5 min free buffers 52

glitch count 4108

glitch value a00

select 1 head 1

glitch count 4155

glitch value c00

select 1 head 3

  Drive 0 Cyl 18->19 select 1, head 0 dirty 3f

Free buffers 69,0 delay 0.040

  Waiting, seek time 6.4 ms max 180.5 min free buffers 52

glitch count 4198

glitch value a00

glitch count 4231

glitch value d00

select 1 head 2

glitch count 4278

glitch value a00

select 1 head 5

[cub...@gmail.com]

A Greaseweazle along with the appropriate drive(s) is what  I use for imaging in most cases these days, along with the software that goes with the HXC2001 for translating formats.  This generally works for both reading and writing.  There are other tools that do require an older PC with the right kind of floppy controller.

(Of course, if a .img file already exists for a given floppy, that would do nicely.)

[David Gesswein]

I assume you are referring to the glitch messages. They don't necessarly
indicate problems. The processor has a psuedo interrupt. When the interrupt
handler check the lines if it doesn't find the cause for the interrupt it
updates the glitch values. Some systems seem to just output noisy signals.
I don't have a system that does it to see why.

These are on the head select signals.

> --
> 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/512367ff-82a9-45e7-8261-f410470b7924n%40googlegroups.com.

[Adam Billyard]

Is there a part of the MFM protocol that determines if a device is a block special device?

In trying to create a useable HD image, I’ve got a failure a couple of times where the host says /dev/disk (aka mfm_emu)  is not a "block special device".

Adam

To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/ZC3x1yOt%2BYywo2eo%40hugin3.

[d...@pdp8online.com]

On Tuesday, April 11, 2023 at 7:14:54 AM UTC-4 Adam wrote:

Is there a part of the MFM protocol that determines if a device is a block special device?

In trying to create a useable HD image, I’ve got a failure a couple of times where the host says /dev/disk (aka mfm_emu)  is not a "block special device".

No. On Unix like systems the device type is set by the mknod command creating the file in /dev.