Init Issue on Emulator Disks noticed on Cromemco

[cro memcos]

David,

I've taken and compiled your 236 code.  Thanks for the efforts.

I just made a retest of the issue and it still persists.  From the top

- I initialised into a file a 16 head 50 cylinder disk

- I started the emulator with this as disk 2, boot Cromemco Cromix, this time 167 version on a 68010 system     (cf booting 172 version on a 68020 system previous issue report)

- I run the inithard -n command to initialise the second disk

- I type in std63 into the device name asked by program

- As soon as I hit return the Cromemco system is totally hung

Here is the failing sequence 

VERSION 236 STILL HANGS

# creation of file

root@bonesys01:/cromemco/emu# /cromemco/emu/mfm_emu --quiet 0 --version --initialize --file /cromemco/disk/D47.C50.H16.transfer.hdd.ver236 --heads 16 --cylinders 50 --drive 1 --fill 0

Board revision B detected

Version 2.36

Emulated drive RPM 3600

# setup BBB

root@bonesys01:/cromemco/emu# ./mfm_emu --drive 1,2 --version --quiet 0 --file /cromemco/disk/D45NEW.C1536.H16.master.hdd,/cromemco/disk/D47.C50.H16.transfer.hdd.ver236

Board revision B detected

Version 2.36

Drive 0 num cyl 1536 num head 16 track len 20836 begin_time 0

PRU clock 200000000

Drive 1 num cyl 50 num head 16 track len 20836 begin_time 0

PRU clock 200000000

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

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 5

# boot cromix 167 fine from 1st disk,  our new disk is disk #2 

XPU Cromix-Plus release 167

Login: system

Logged in system May-13-2021 19:43:58 on tty1

system[1] sync

system[2] inithard -n

68010 XPU 167   Inithard source 2.7

Press:          RETURN to supply default answers

                CTRL-C to abort program

Warning:        INITHARD can destroy all disk data

Device name? std63

# BBB output

Free buffers 74,0 delay 0.000

  Waiting, seek time 8.8 ms max 11.0 min free buffers 70

select 0 head 15

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

  Waiting, seek time 8.1 ms max 11.0 min free buffers 70

select 0 head 15

select 0 head 1

# PRESSING ENTER ON CROMEMCO NOW

select 2 head 0

# Cromemco is totally hung :-(

# Need to press reset button to start OS again

-----

So I just put the 3 disk emulator files into a tar gzip file and attached to this posting

I am happy to follow any of your instructions to progress this matter

[David Gesswein]

I dumped the data in your v110 file and got

0000000 aa aa aa aa 00 00 00 00 00 00 00 00 00 00 00 00
0000020 55 55 55 05 55 55 55 55 55 55 55 55 55 55 55 55
0000040 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
*
0000120 55 55 55 55 25 22 92 54 55 55 55 55 55 55 55 55
0000140 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
0000160 00 00 a0 aa 00 00 00 00 00 00 00 00 00 00 00 00
0000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0000240 00 00 00 00 00 00 00 00 00 00 00 00 aa aa 02 00
0000260 55 55 a5 aa 54 55 55 55 aa aa aa aa aa aa aa aa
0000300 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
*
0000360 aa aa aa aa a9 aa aa aa 44 a4 aa 2a 44 44 44 44
0000400 aa aa aa 4a aa aa aa aa 49 15 49 a5 49 15 49 15
0000420 49 15 49 15 49 15 49 15 49 15 49 15 49 15 49 15
*
0000720 49 15 49 15 49 15 49 15 52 aa aa 12 aa aa aa 4a
0000740 91 aa 92 aa aa 4a aa 2a 2a 49 49 aa aa aa aa aa
0000760 aa aa aa 92 aa 4a 49 92 12 51 2a a9 29 29 11 51
0001000 52 aa aa 2a 49 15 49 45 49 15 49 15 49 15 49 15
0001020 49 15 49 15 49 15 49 15 49 15 49 15 49 15 49 15

I rebuilt v1.10 and created an initialized emulator file and got this
0000000 aa aa aa aa 00 00 00 00 00 00 00 00 00 00 00 00
0000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0050540 00 00 00 00 aa aa aa aa 00 00 00 00 00 00 00 00
0050560 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0121300 00 00 00 00 00 00 00 00 aa aa aa aa 00 00 00 00
0121320 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0172040 00 00 00 00 00 00 00 00 00 00 00 00 aa aa aa aa
0172060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0242620 aa aa aa aa 00 00 00 00 00 00 00 00 00 00 00 00
0242640 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0313360 00 00 00 00 aa aa aa aa 00 00 00 00 00 00 00 00
0313400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0364120 00 00 00 00 00 00 00 00 aa aa aa aa 00 00 00 00
0364140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0434660 00 00 00 00 00 00 00 00 00 00 00 00 aa aa aa aa


With 2.36 its all zero.
[djg@laptop mfm]$ od -tx1 /tmp/good_track | more0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
77454200

Was your v110 file formatted by the Cromemco some point in the past? Do you
get the same file as you sent if you regenerate it with v1.10 now?
If you put all the files from a version in its own directory it will
build properly.

> --
> 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/f2c0a794-090e-491b-865d-7b4ff4303d01n%40googlegroups.com.

[cro memcos]

David,

thanks for the detective work ....

To answer,  my original hard disks, that still work fine, and boot etc were built using code level 110

Then in the last few weeks, when the systems are again active again,  when I had problems at the 234 level

I did indeed pull down the older 110 code from your website, put it into a separate directory and compile it up.

On a system running from an existing 'ok' disk, initialised with 110 code,  running under a 234 or 236 current code then the 

only thing that works right now is to initialise an additional disk with 110 code and then use it under 234 or 236

----

Also I just had a brainwave which is the last releases of the RDOS  (Resident Disk Operating System) monitor on the

Diskette controller has some limited support for the STDC Hard Disk controller.

So without starting the OS I've been able to replicate the problem thus

a) On BBB create a emulator file with 110 code

b) On BBB create a emulator file with 234/236 code

c) start Cromemco and go into RDOS monitor i.e. OS not loaded

110 File is fine and RDOS can low level read the whole hard disk

;t

Bank 0 > 0 1 2 3 4 5 6 7 8 9 A B C D E F

         ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^

Type (F, H) H

Unit (0-3F) 1f

Seek Tests

1 OK 2 OK 3 OK 4 OK 5 OK

6 OK 7 OK 8 OK 9 OK 0 OK

31H OK 10H OK 20H OK 0 OK 1 OK

 Restore OK

31H OK

Read/Write Tests

 Data Read OK

Write Test MAY DESTROY Data

CR=Proceed ESC=Abort

 Pattern Write OK

 Pattern Read OK

 Pattern Compare OK

 Data Write OK

ST1F:ra

Starting Cylinder (0-31H) [0]

Ending Cylinder (0-31H) [31H]

Surface (0/1/2/3/4/5/6/7/8/9/A/B/C/D/E/F/All) [All]

 F 031

236 File is not okay and RDOS cannot read anything and does a timeout like this

Cromemco RDOS 03.12

;t

Bank 0 > 0 1 2 3 4 5 6 7 8 9 A B C D E F

         ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^

Type (F, H) H

Unit (0-3F) 1f

 Error-X 0700 > Drive not Ready; No ACK from Drive

Seek Tests

1 Error-S 0700 > Drive not Ready; No ACK from Drive

I hope this begins to give you some clues?

[cro memcos]

Okay,

***Multiple **** compilations later as I've gone back from code 234 ...

I found that ver110 mfm_emu is the latest level  that can initialise a file that I can use.     To be clear ver112 and ver114 etcetera all fail with the same issue

root@bonesys01:/cromemco/emu# ./mfm_emu --drive 1  --version --quiet 0 --file /cromemco/disk/D47.C50.H16.transfer.hdd.ver112

Board revision B detected

Version 2.36

Drive 0 num cyl 50 num head 16 track len 20836 begin_time 0

PRU clock 200000000

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

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 1 head 0

# on cromemco in RDOS monitor

Bank 0 > 0 1 2 3 4 5 6 7 8 9 A B C D E F

         ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^

Type (F, H) H

Unit (0-3F) 1f

 Error-X 0700 > Drive not Ready; No ACK from Drive

Seek Tests

1 Error-S 0700 > Drive not Ready; No ACK from Drive

ALL tests were performed using the current 236 runtime and an emulator file created using the previous code, 110 works.  anything later not.

regards marcus

[David Gesswein]

I don't think I saw an answer to why the file I created with v1.10 didn't
match the v110 file you attached to an earlier reply.

The v1.10 file I create is slightly different than the file created by 2.36.
It has 4 bytes of 0xaa with the rest 0.

On Sat, May 15, 2021 at 08:48:19AM -0700, cro memcos wrote:
> Okay,
>
>
> ***Multiple **** compilations later as I've gone back from code 234 ...
>

> *I found that ver110 mfm_emu is the latest level that can initialise a
> file that I can use.* To be clear ver112 and ver114 etcetera all fail

> with the same issue
>
> root@bonesys01:/cromemco/emu# ./mfm_emu --drive 1 --version --quiet 0

> --file /cromemco/disk/D47.C50.H16.transfer.hdd.*ver112*

> > *110 File is fine and RDOS can low level read the whole hard disk*

> >
> > ;t
> >
> > Bank 0 > 0 1 2 3 4 5 6 7 8 9 A B C D E F
> > ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
> > Type (F, H) H
> > Unit (0-3F) 1f
> >
> > Seek Tests
> > 1 OK 2 OK 3 OK 4 OK 5 OK
> > 6 OK 7 OK 8 OK 9 OK 0 OK
> > 31H OK 10H OK 20H OK 0 OK 1 OK
> > Restore OK
> > 31H OK
> > Read/Write Tests
> > Data Read OK
> > Write Test MAY DESTROY Data
> > CR=Proceed ESC=Abort
> > Pattern Write OK
> > Pattern Read OK
> > Pattern Compare OK
> > Data Write OK
> >
> > ST1F:ra
> > Starting Cylinder (0-31H) [0]
> > Ending Cylinder (0-31H) [31H]
> > Surface (0/1/2/3/4/5/6/7/8/9/A/B/C/D/E/F/All) [All]
> > F 031
> >
> >

> > *236 File is not okay and RDOS cannot read anything and does a timeout
> > like this*

> To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/6242fc30-8d89-4297-baa5-f7391c308aacn%40googlegroups.com.

[cro memcos]

David,

Regarding the differences in the V110 file between mine and yours.   The V110 file I prev sent you will have been put thru my Cromemco Cromix Initialisation program.

Er so starting again ... with a new attachment

a) the File created with the V110 code == D47.C50.H16.transfer.hdd.ver110.original

b) That file, attached to cromemco system and initialised by the Operating system (inithard and then makfs to make a cromix filesystem)

== D47.C50.H16.transfer.hdd.ver110.makfs

Both files attached in the compressed tarfile

od -tx1 -a D47.C50.H16.transfer.hdd.ver110.original | more

0000000  ee  4d  46  4d  0d  0a  1a  00  00  02  02  02  5c  00  00  00

          n   M   F   M  cr  nl sub nul nul stx stx stx   \ nul nul nul

0000020  64  51  00  00  0c  00  00  00  32  00  00  00  10  00  00  00

          d   Q nul nul  ff nul nul nul   2 nul nul nul dle nul nul nul

0000040  80  96  98  00  2b  00  00  00  2d  2d  68  65  61  64  73  20

        nul syn can nul   + nul nul nul   -   -   h   e   a   d   s  sp

0000060  31  36  20  2d  2d  63  79  6c  69  6e  64  65  72  73  20  35

          1   6  sp   -   -   c   y   l   i   n   d   e   r   s  sp   5

0000100  30  20  20  2d  2d  72  61  74  65  20  31  30  30  30  30  30

          0  sp  sp   -   -   r   a   t   e  sp   1   0   0   0   0   0

0000120  30  30  00  01  00  00  00  00  00  00  00  00  78  56  34  12

          0   0 nul soh nul nul nul nul nul nul nul nul   x   V   4 dc2

0000140  00  00  00  00  00  00  00  00  aa  aa  aa  aa  00  00  00  00

        nul nul nul nul nul nul nul nul   *   *   *   * nul nul nul nul

0000160  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00

        nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul

*

0050700  00  00  00  00  00  00  00  00  00  00  00  00  78  56  34  12

        nul nul nul nul nul nul nul nul nul nul nul nul   x   V   4 dc2

0050720  00  00  00  00  01  00  00  00  aa  aa  aa  aa  00  00  00  00

        nul nul nul nul soh nul nul nul   *   *   *   * nul nul nul nul

0050740  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00

        nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul

[David Gesswein]

For me v1.10 and v1.12 generate identical output files and match the v110
file you provided unless i'm missing something. I don't see how v1.12 can't
work. Did the v1.12 file you created have the same md5sum?


3de70ac85df66cb4d1951a765137e3e2 D47.C50.H16.transfer.hdd.ver110.original
3de70ac85df66cb4d1951a765137e3e2 D47.C50.H16.transfer.hdd.ver1.10
3de70ac85df66cb4d1951a765137e3e2 D47.C50.H16.transfer.hdd.ver1.12

Assuming we figure out what is going on I think we have two ways of
making the current code generate a useable file.

One is to use ext2emu.
./ext2emu --emu D47.C50.H16.transfer.hdd.ext2emu --ext /dev/zero --heads 16 --cylinders 50 --format cromemco
Calculated extract file size 8192000 bytes, actual size 0
You can see if this works for you.

The other it to get rid of --fill and have something like --initialize cromemco
which will generate whatever we figure out is the magic format that works.

On Sat, May 15, 2021 at 08:48:19AM -0700, cro memcos wrote:

> Okay,
>
>
> ***Multiple **** compilations later as I've gone back from code 234 ...
>

> *I found that ver110 mfm_emu is the latest level that can initialise a
> file that I can use.* To be clear ver112 and ver114 etcetera all fail

> with the same issue
>
> root@bonesys01:/cromemco/emu# ./mfm_emu --drive 1 --version --quiet 0

> --file /cromemco/disk/D47.C50.H16.transfer.hdd.*ver112*

> > *110 File is fine and RDOS can low level read the whole hard disk*

> >
> > ;t
> >
> > Bank 0 > 0 1 2 3 4 5 6 7 8 9 A B C D E F
> > ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
> > Type (F, H) H
> > Unit (0-3F) 1f
> >
> > Seek Tests
> > 1 OK 2 OK 3 OK 4 OK 5 OK
> > 6 OK 7 OK 8 OK 9 OK 0 OK
> > 31H OK 10H OK 20H OK 0 OK 1 OK
> > Restore OK
> > 31H OK
> > Read/Write Tests
> > Data Read OK
> > Write Test MAY DESTROY Data
> > CR=Proceed ESC=Abort
> > Pattern Write OK
> > Pattern Read OK
> > Pattern Compare OK
> > Data Write OK
> >
> > ST1F:ra
> > Starting Cylinder (0-31H) [0]
> > Ending Cylinder (0-31H) [31H]
> > Surface (0/1/2/3/4/5/6/7/8/9/A/B/C/D/E/F/All) [All]
> > F 031
> >
> >

> > *236 File is not okay and RDOS cannot read anything and does a timeout
> > like this*

> To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/6242fc30-8d89-4297-baa5-f7391c308aacn%40googlegroups.com.

[m]

David,

your logic about the md5sum has me confounded.  You must be right !! ....   I am going to retest presently.

Here are the files I will use initially created yesterday ...  (I had to delete the others I tested due to disk space limits)

md5sum D47.C50.H16**
585758418a6f294fadaecb9663eb35db  D47.C50.H16.transfer.hdd.ver110.makfs
3de70ac85df66cb4d1951a765137e3e2  D47.C50.H16.transfer.hdd.ver110.original
3de70ac85df66cb4d1951a765137e3e2  D47.C50.H16.transfer.hdd.ver112
3de70ac85df66cb4d1951a765137e3e2  D47.C50.H16.transfer.hdd.ver114
3de70ac85df66cb4d1951a765137e3e2  D47.C50.H16.transfer.hdd.ver118
5622563f87a994cb220615d6c6f18fb4  D47.C50.H16.transfer.hdd.ver234
243d6ccc3d23a8ab602c90abd22b16f6  D47.C50.H16.transfer.hdd.ver236

Speak soon.

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

[cro memcos]

David,

Okay I have been busy testing and compiling .... you are right about the earlier compatibilities.

Let's start with some MD5's ...

root@bonesys01:/cromemco/disk# md5sum D47.C50.H16.transfer.hdd.**

3de70ac85df66cb4d1951a765137e3e2  D47.C50.H16.transfer.hdd.ver110

585758418a6f294fadaecb9663eb35db  D47.C50.H16.transfer.hdd.ver110.makfs

3de70ac85df66cb4d1951a765137e3e2  D47.C50.H16.transfer.hdd.ver112

3de70ac85df66cb4d1951a765137e3e2  D47.C50.H16.transfer.hdd.ver114

3de70ac85df66cb4d1951a765137e3e2  D47.C50.H16.transfer.hdd.ver118

ed37be16c0f897bdee23bafce12c7745  D47.C50.H16.transfer.hdd.ver118.makfs

3de70ac85df66cb4d1951a765137e3e2  D47.C50.H16.transfer.hdd.ver123

3de70ac85df66cb4d1951a765137e3e2  D47.C50.H16.transfer.hdd.ver126

2b4feb745ff584d0ba7191e1f8d59792  D47.C50.H16.transfer.hdd.ver126.makfs

5622563f87a994cb220615d6c6f18fb4  D47.C50.H16.transfer.hdd.ver127

5622563f87a994cb220615d6c6f18fb4  D47.C50.H16.transfer.hdd.ver129

5622563f87a994cb220615d6c6f18fb4  D47.C50.H16.transfer.hdd.ver141

5622563f87a994cb220615d6c6f18fb4  D47.C50.H16.transfer.hdd.ver210

5622563f87a994cb220615d6c6f18fb4  D47.C50.H16.transfer.hdd.ver234

5622563f87a994cb220615d6c6f18fb4  D47.C50.H16.transfer.hdd.ver236

So after some more downloading and compiling and then use of a command like

/cromemco/code/126/emu/mfm_emu --quiet 0 --version --initialize --file /cromemco/disk/D47.C50.H16.transfer.hdd.ver126 --heads 16 --cylinders 50 --drive 1

I generated many sample disk files

I got  D47.C50.H16.transfer.hdd.ver126 to work

Explanation? It seems probably that once the Cromemco System STDC hard disk controller is 'screwed' a reset button which is what I was doing is not sufficient  [to reset state of STDC].  You need to power off, then I wait for 30 seconds, then power on.   Then retest.

So now then,  I can get upto and including ver126 of file created working.

After that it looks like the file that is created is the same from ver 127 of code upto today 236

I try any of those files ....

system[1] sync

system[2] inithard -n

68010 XPU 167   Inithard source 2.7

Press:          RETURN to supply default answers

                CTRL-C to abort program

Warning:        INITHARD can destroy all disk data

Device name? std63

SYSTEM HANGS

Corresponding BBB screen 

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

Free buffers 74,0 delay 0.000

  Waiting, seek time 8.8 ms max 9.9 min free buffers 72

select 0 head 15

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

  Waiting, seek time 8.1 ms max 9.9 min free buffers 72

select 2 head 0     <---------   HOST HANGS HERE

----

So what changed ver 127 and later ??

----

BTW I found this in the STDC Hard Disk Controller manual

STDC Disk Layout lowest level

The STDC formats the hard disk by track, not by sector. Each track is formatted

to store 10K bytes of data, as follows:

FROM Bytes Value

Preamble 64 all zeros

Sync byte 1 04

Start alignment         5 00,AA,AA,AA,00

Header 3 low cylinder, high cylinder, surface

Data 10,240

End alignment         4 00,AA,AA,00

End header 3 low cylinder, high cylinder, surface

CRC 2 varies

Syndrome 2 0000 (if no errors)

Postamble 2 0000

regards marcus

[David Gesswein]

On Sun, May 16, 2021 at 06:55:46AM -0700, cro memcos wrote:
>
> So what changed ver 127 and later ??
>

I fixed a bug in the code.

#define ARRAYSIZE(x) (sizeof(x) / sizeof(x[0]))
uint32_t *data;

data = calloc(1,track_size);

for (i = 0; i < ARRAYSIZE(data); i++) {
data[i] = 0xaaaaaaaa;
}

Current

for (i = 0; i < track_size / sizeof(data[0]); i++) {
data[i] = 0xaaaaaaaa;
}


Original only filled the first word. The rest was zero from calloc. New
code fills all. No idea why that pattern works.

Did you have a preference on two two approaches to fixing this in the
earlier email? My preference is ext2emu since it already exists assuming
it works for you.

> >> https://groups.google.com/d/msgid/mfm-discuss/20210516021803.GA931658%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 on the web visit https://groups.google.com/d/msgid/mfm-discuss/d7bb7407-5216-40ff-92b1-9ea51f52ee24n%40googlegroups.com.

[cro memcos]

David,

Replying to your earlier point about using ext2emu to create an emulator file using your clever command line .... tried it and it did not go so well .   here is the printout

# run command to generate emulator file, this works fine

/cromemco/mfm/ext2emu --version --quiet 0 --emulation_file /cromemco/disk/D47.C50.H16.test.ext2emu --extracted_data_file /dev/zero --heads 16 --cylinders 50 --format cromemco

ls -l /cromemco/disk/D47.C50.H16.test.ext2emu

-rw-r--r-- 1 root root 16678637 May 16 22:04 /cromemco/disk/D47.C50.H16.test.ext2emu

md5sum /cromemco/disk/D47.C50.H16.test.ext2emu

6470f45acd6f7038857eaed915c538b9  /cromemco/disk/D47.C50.H16.test.ext2emu

# try to use it with any existing working file as a second disk .... FAILS due to Begin time issue

./mfm_emu --drive 1,2 --version --quiet 0 --file /cromemco/disk/D45NEW.C1536.H16.master.hdd,/cromemco/disk/D47.C50.H16.test.ext2emu

Board revision B detected

Version 2.36

Drive 0 num cyl 1536 num head 16 track len 20836 begin_time 0

PRU clock 200000000

Drive 1 num cyl 50 num head 16 track len 20836 begin_time 6000

PRU clock 200000000

Emulation files must all agree on begin_time

# So I thought, but hey is the file good in itself, so can I start up machine with this single fine and do a test

# from the monitor only.  

# Cromemco is switched off first

# at BBB

./mfm_emu --drive 1 --version --quiet 0  --file /cromemco/disk/D47.C50.H16.test.ext2emu

Board revision B detected

Version 2.36

Drive 0 num cyl 50 num head 16 track len 20836 begin_time 6000

PRU clock 200000000

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

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

# okay to be paranoid cromemco is off until now.  Now poweron  but see below error

# At cromemco

Bank 0 > 0 1 2 3 4 5 6 7 8 9 A B C D E F

         ^ ^ ^ ^ ^ ^ ^ ^ X X X X X X X X

Preparing to boot, ESC to abort

Cromemco RDOS 03.12

;t

Bank 0 > 0 1 2 3 4 5 6 7 8 9 A B C D E F

         ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^

Type (F, H) H

Unit (0-3F) 1f

Seek Tests

1 Error-S 0005 > Failed to Seek & Read Header; Header Does not Compare

Flup!

Marcus

[cro memcos]

David,

A further comment ....

I did a test to revert your code into the 234 version   (as the changes you posted I could not immediately find in the 236 version?)  so it was like this ....

# create a whole new 234 code directory

/cromemco/code/234OH

# edited mfm_emu.c  like this

# code base was 234 as the line disappeared in 236

    673       drive_params.cmdline = parse_print_cmdline(&drive_params, 0);

    674       // If data rate about 8.68 MHz assume it is a SA1000 drive rotating

    675       // at 3125 RPM otherwise 3600 RPM

    676       if (drive_params.rpm == 0) {

    677          drive_params.rpm = round(emu_rps(drive_params.sample_rate_hz) * 60.0);

    678       }

    679       msg(MSG_INFO, "Emulated drive RPM %d\n", drive_params.rpm);

    680       // Calculate round number of words for track based on rotation rate

    681       // and bit rate

    682       track_size = ceil(1.0/(drive_params.rpm/60.0) * drive_params.sample_rate_hz / 8 / 4)*4;

    683       // 20210516 test revert mwb   data = calloc(1,track_size);

    684       // 20210516 test revert mwb   for (i = 0; i < track_size / sizeof(data[0]); i++) {

    685       // 20210516 test revert mwb    data[i] = 0xaaaaaaaa;

    686       // 20210516 test revert mwb }

    687

    688       // 20210516 test revert mwb

    689 #define ARRAYSIZE(x) (sizeof(x) / sizeof(x[0]))

    690 uint32_t *data;

    691

    692 data = calloc(1,track_size);

    693

    694 for (i = 0; i < ARRAYSIZE(data); i++) {

    695 data[i] = 0xaaaaaaaa;

    696 }

# recompiled obviously

# create new initialised file

./mfm_emu --drive 1 --version --quiet 0  --file /cromemco/disk/D47.C50.H16.transfer.hdd.ver234OH

root@bonesys01:/cromemco/disk# md5sum D47.C50.H16*

6470f45acd6f7038857eaed915c538b9  D47.C50.H16.test.ext2emu

6470f45acd6f7038857eaed915c538b9  D47.C50.H16.testfile.extemu

3de70ac85df66cb4d1951a765137e3e2  D47.C50.H16.transfer.hdd.ver110

585758418a6f294fadaecb9663eb35db  D47.C50.H16.transfer.hdd.ver110.makfs

3de70ac85df66cb4d1951a765137e3e2  D47.C50.H16.transfer.hdd.ver112

3de70ac85df66cb4d1951a765137e3e2  D47.C50.H16.transfer.hdd.ver114

3de70ac85df66cb4d1951a765137e3e2  D47.C50.H16.transfer.hdd.ver118

ed37be16c0f897bdee23bafce12c7745  D47.C50.H16.transfer.hdd.ver118.makfs

3de70ac85df66cb4d1951a765137e3e2  D47.C50.H16.transfer.hdd.ver123

3de70ac85df66cb4d1951a765137e3e2  D47.C50.H16.transfer.hdd.ver126

2b4feb745ff584d0ba7191e1f8d59792  D47.C50.H16.transfer.hdd.ver126.makfs

5622563f87a994cb220615d6c6f18fb4  D47.C50.H16.transfer.hdd.ver127

5622563f87a994cb220615d6c6f18fb4  D47.C50.H16.transfer.hdd.ver129

5622563f87a994cb220615d6c6f18fb4  D47.C50.H16.transfer.hdd.ver141

5622563f87a994cb220615d6c6f18fb4  D47.C50.H16.transfer.hdd.ver210

5622563f87a994cb220615d6c6f18fb4  D47.C50.H16.transfer.hdd.ver234

3de70ac85df66cb4d1951a765137e3e2  D47.C50.H16.transfer.hdd.ver234OH

5622563f87a994cb220615d6c6f18fb4  D47.C50.H16.transfer.hdd.ver236

5622563f87a994cb220615d6c6f18fb4  D47.C50.H16.transfer.hdd.ver236.notime

So the file md5's the same as the rest and then unsurprisingly in the OS it initialises fine

[David Gesswein]

Since mfm_util doesn't decode the D47.C50.H16.transfer.hdd.ver110.makf and
the controller doesn't like the ext2emu file the controller you are using
probably is using a different format than the one the format was originally
created for.

Up to you if you would prefer --initialize cromemco to initialize with the
pattern below that works so you can move on or we spend the time to figure out
the format and get ext2emu to create a useable file.

On Sun, May 16, 2021 at 05:15:12PM -0700, cro memcos wrote:
> David,
>

> *3de70ac85df66cb4d1951a765137e3e2 D47.C50.H16.transfer.hdd.ver234OH*

> > Drive 1 num cyl 50 num head 16 track len 20836 *begin_time 6000*

> > *1 Error-S 0005 > Failed to Seek & Read Header; Header Does not Compare*

> To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/395e92c5-4e57-4637-b7d7-e8e7d4070725n%40googlegroups.com.

[m]

David, regarding the initialisation issue   my suggestion is to go for a --initialize cromemco   flag.

And ALL of this was actually a precursor to the issue that I raised over 4 years ago about mfm_util behaviour stopping working as I had been using it.  But that's a different error and I wanted first to at least get a way to intialise new disks at current 234/236 code.

Please incorporate and then I will test.

So if you build in the ability to initialise I will separately post the mfm_util issue that appeared again after a code level change.

Regards marcus

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

[David Gesswein]

Added --initialize=cromemco or -icromemco option. md5 looks good.

> > https://groups.google.com/d/msgid/mfm-discuss/20210517003447.GB1008927%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 on the web visit https://groups.google.com/d/msgid/mfm-discuss/CAD6VEAYVWq0p6NYEOMuNcp76vMK5SX7zR5nw_KqqR3Tm%3D35P%2Bg%40mail.gmail.com.

[cro memcos]

I just tested the --initialize=Cromemco option with your code level 237

No issues now, works perfectly.

Thank you.