Jump to content
Sign in to follow this  
BeeryMiller

Myarc HFDC Bug?

Recommended Posts

I've been working with Oleksandr who developed the DREM to emulate MFM drives.  Everything has been working fine with drives up to 8 heads x 1024 cylinders (64 MB's).  Our Myarc HFDC is supposed to support 2048 cylinders.

 

First question, has anyone formatted a MFM hard drive that used more than 1024 cylinders?  If so, did you use MDM5 or did you possibly use Mike Maksimik's CFORM program?  If MDM5, do you know what version you are likely to have used?

 

I have used MDM5 V1.30 to format a hard drive.  Whenever there is an attempt to copy a file (under MDOS using XCOPY) to the image, a cylinder 1024 I get an error.  I've been providing Oleksandr with a number of log files of the formatting process and I have enclosed his following comments below.  Under MAME when I have used a 8 head x 2048 cylinder, I do not get an error.  What I do not know is how MAME handles the sector gap information.  Both MAME and the DREM do not  include the gap information, but how they get to the same point may be a bit different????  Hopefully, someone will have some ideas????

 

 

From Oleksandr:

 

I guess it is a bug and real 2048 track HDD will not work too.

Controller should form an id byte as:

0xFE ^ (track >> 8)

 

However for tracks 1024+ it always stay 0xFD I guess it is causing read error.

 

SMC datasheet describe ID Field Ident byte as FE 0 FF 256 FC 512 FD 768 Custom Ident byte is possible, but if we will use  the same scheme:

0xFE ^ (track >> 8) it will produce 0xFB and cause the conflict with data field ident byte.

 

Share this post


Link to post
Share on other sites

As my memory fades, I cannot always remember specifics, but I remember this sort of thing on multiple platforms.  When a product was developed, it was written to work on existing hardware.  Later as new larger storage devices we made, sometimes whole new operating systems had to be made that could support the new equipment.  The problem was even worse for people that relied on firmware in their controllers.  Looking backwards, what appears to be a bug now, might have been the original state. 

 

I'll be keeping an eye on this thread, I want to see if atrax27407's question/suggestion is the solution.  If so, it's probably another one of those technology evolution problems.

Share this post


Link to post
Share on other sites

I remember in the day, the Myarc was quoted as supporting 128 MB drives, however, besides individuals maybe going up to 60 MB's, I am not sure anyone used anything larger.

 

One can get to 128 MB drive another way, and that is with a 16 head, 1024 cylinder image instead of 8 head and 2048 cylinder.  However, to do that, required a hardware modification as the existing lines on the HFDC only supported 8 heads.  I think Barry Boone posted the modification in Micropendium that added the extra heads for signalling purpose.

 

Thus, that goes back to my question did anyone ever have a drive with more than 1024 cylinders?

 

I have not tried with MDM5 V1.50 yet.  The version I had was missing the format routine, so I used 1.30.  I'll be searching for a complete copy of 1.50 as well as testing CFORM out.

 

Beery

 

Share this post


Link to post
Share on other sites

I seem to recall 1023 cylinders was the formatting limit and that increasing the head count was needed here.   Were any MFM drives ever built with more than 1023 cylinders?  This might be a situation where emulation is not matching reality. 

Share this post


Link to post
Share on other sites

From my implementation in MAME:

/*
    Calculate the ident byte from the cylinder. The specification does not
    define idents beyond cylinder 1023, but formatting programs seem to
    continue with 0xfd for cylinders between 1024 and 2047.
*/
uint8_t mfmhd_generic_format::cylinder_to_ident(int cylinder)
{
    if (cylinder < 256) return 0xfe;
    if (cylinder < 512) return 0xff;
    if (cylinder < 768) return 0xfc;
    return 0xfd;
}

Share this post


Link to post
Share on other sites

I did a bit of searching, and it looks like anything above 1024 cylinders were very rare.  Generally, it looks like head count increased rather than cylinder count.  I did see some drives at 1224 cylinders which I hope wasn't a typo for 1024 cylinders in some tables.

 

So, I guess MAME can handle things larger as it just keeps on doing what it can since I would presume the "hardware issue" does not propagate there.  In all likelihood, than means a 256 MB is probably possible assuming MAME with the TI/Geneve operation does not cap the default hardware at 8 lines without the HFDC mod.  

 

Beery

 

Share this post


Link to post
Share on other sites
6 minutes ago, mizapf said:

From my implementation in MAME:

 

/*
    Calculate the ident byte from the cylinder. The specification does not
    define idents beyond cylinder 1023, but formatting programs seem to
    continue with 0xfd for cylinders between 1024 and 2047.
*/
uint8_t mfmhd_generic_format::cylinder_to_ident(int cylinder)
{
    if (cylinder < 256) return 0xfe;
    if (cylinder < 512) return 0xff;
    if (cylinder < 768) return 0xfc;
    return 0xfd;
}


 

I sent your comment over to Oleksandr.  I'll let him chew on it.

 

Beery

 

 

Share this post


Link to post
Share on other sites

The HDC9234 is able to address 2048 cylinders. However, SMC did not specify the ident byte beyond 1023 in their HDC9234 specification document, even though they clearly state that there are 11 bits for the cylinder number on the same page.

 

The HDC9234 defines a "PC-AT format" for floppy and hard disks. In this format, the cylinder number only has 8 bits, and the actual cylinder number is derived from the ident byte value. I remember that one particular issue for hard disk sizes in early DOS days was that the INT $80 interface only allowed for 10 bits for the cylinder.

Share this post


Link to post
Share on other sites

Oleksandr had this comment.  Pretty quick with the reply today:

 

Beery,

 

> uint8_t mfmhd_generic_format::cylinder_to_ident(int cylinder) {

>     if (cylinder < 256) return 0xfe;

>     if (cylinder < 512) return 0xff;

>     if (cylinder < 768) return 0xfc;

>     return 0xfd;

> }

 

Exactly. We know it from experiment already.

 

> I do not know if this is something that can be emulated, etc????

 

Yes, we did it already, but it causing reading errors.

My opinion it will not work with the real HDD either.

Share this post


Link to post
Share on other sites

Beery,

 

keep in mind that my implementation is just a reaction to what MDM150 is doing, not backed by other sources. There was also the discrepancy between the fact that the HDC supports 2048 cylinders vs. the lack of information what it means for the ident byte, so I had to assume some solution. The MDM150 continues with the FD byte for higher cylinders, but that may be wrong.

 

The problem is that we don't have more information. As we saw, in the PC world there are max 1024 cylinders, so we must not expect to find a solution there, hence we'd need another non-PC MFM controller to compare what it is doing.

 

I wonder what Oleksandr is testing to get read errors. Is it his MFM emulator at the HFDC, or at another controller?

Share this post


Link to post
Share on other sites

The read errors are on my end with my system, not on Oleksandr's end.  Our HFDC is the first unit that has stepped over the 1024 boundary with MFM Oleksandr has experienced.

 

I do recall Oleksandr indicating he had some other controller for some unknown system that used the same controller chip.  I will make an inquiry with him to see if he can identify what may happen on it.  Still though, MDM5 and presumably CFORM, use the FD byte which would mean any formatting program would have to be modified.  I presume this is at the code level within MDM5 and not the DSR.  While we have the code for MDM5, I have not heard of anyone ever assembling MDM5 as we did not have the notes on how each module was assembled, etc.

 

So, right now, I think we are capped at 64 MB on a stock Myarc HFDC at 32 spt, 8 cylinders, 1024 heads.  I know Mike Maksimik took CFORM on the Geneve to 34 spt, and it looks like MDM5 would likely accept it, however, I would hesitate using 34 spt not knowing if there are any issues with the DSR on the HFDC or Geneve Master DSR at 34 spt.

 

Beery

 

 

 

Share this post


Link to post
Share on other sites
6 minutes ago, BeeryMiller said:

 

 

'I do recall Oleksandr indicating he had some other controller for some unknown system that used the same controller chip.'

 

 

Would he divulge the controller name and system. I'd like to do some 'googling'.

Share this post


Link to post
Share on other sites
15 minutes ago, RickyDean said:

Would he divulge the controller name and system. I'd like to do some 'googling'.

There was something back about a month ago on Ebay that had the specific controller chip in question, but I do not recall what controller it was and it is not there anymore.  I will inquire with Oleksandr.

 

 

And, Oleksandr did provide me another reply back:

 

Beery,

 

I have no experience with larger MFM drives.

 

> I recall you said you had some other system using a 9234 chip. Was

> there software for that system that would permit formatting at 2048

> cylinders?  If so, did it use a different ID byte?

 

Never tried, but consider the following...

9234 chip support two types of ID: "standard" and "custom sector size"

Standard is the same as western digital and it has one byte for LSB track## and Ident byte 0xFE ^ (track>>8), this scheme provides 1024 tracks max.

So called "custom sector size" support custom Ident byte + two bytes fo track ##

 

Myarc ID is actually have full track ## encoded as one byte LSB and MSB as ((track## & 0x F00) >> 4) | head##

 

So information is present in ID. I guess the bug is in myarc sector reading routine, which is looking for certain Ident byte to reconstruct track##

Share this post


Link to post
Share on other sites
23 minutes ago, BeeryMiller said:

The read errors are on my end with my system, not on Oleksandr's end.  Our HFDC is the first unit that has stepped over the 1024 boundary with MFM Oleksandr has experienced.

This means that you are running his emulator at your HFDC, right? Can you format the drive beyond cylinder 1024 using MDM150? The point is: Why is the emulator failing to read sectors there? If we do a false assumption (with the behavior past cylinder 1023), and he abides by this assumption, everything should be OK. I was able to format the MAME-emulated hard disk using MDM150 up to 240 MiB, so in principle it should work.

 

Are you trying it with MDM150?

Share this post


Link to post
Share on other sites

All my testing was done on the MDOS side of the Geneve 9640 as far as copying files and on the GPL interpreter side with Rompage using MDM5 (V1.30).  If I have time, I may look through some of the MDOS source code to see if anything makes sense.


Beery

 

Share this post


Link to post
Share on other sites
19 minutes ago, mizapf said:

This means that you are running his emulator at your HFDC, right? Can you format the drive beyond cylinder 1024 using MDM150? The point is: Why is the emulator failing to read sectors there? If we do a false assumption (with the behavior past cylinder 1023), and he abides by this assumption, everything should be OK. I was able to format the MAME-emulated hard disk using MDM150 up to 240 MiB, so in principle it should work.

 

Are you trying it with MDM150?

I had no problem with MDM130 formatting at home on real hardware.  On one of my MAME setups, it was using MDM150.  I will test MDM150 on real hardware and see if it makes a difference this evening.

 

It was only after a number of files had been copied using the XCOPY command did I get an error.  I could watch on the DREM monitor and things were fine up until cylinder 1023, but the moment it crossed onto 1024, was when the issue hit.

 

I was still a bit perplexed as the DREM was reporting cylinder writes starting somewhere around 990's or so in MDOS.  I would have thought cylinder writes would have started at a much lower count.


Beery

 

Share this post


Link to post
Share on other sites
45 minutes ago, RickyDean said:

Would he divulge the controller name and system. I'd like to do some 'googling'.

 

Beery,

 

DEC RQDX3 is using 9224

Unfortunately I do not recall now other systems...

Share this post


Link to post
Share on other sites

I use MDM5 v1.29 as it has been the most consistent version for testing hardware.  There was a later version, 1.31 IIRC, that had problems and was to be avoided. 

 

Beery do you know if a change log was maintained for MDM5?

Share this post


Link to post
Share on other sites

I've not seen a change log, and to my knowledge, there was only one set of source files.  Not sure what the version number was.

 

Beery

 

Share this post


Link to post
Share on other sites

The source files I retrieved from John Birdwell's hard drive backups may have been v1.29 or 1.3x.  I don't recall if 1.50 was built from that set of source or one from Paul as part of your MDOS buyout.  'twas so long ago.

Share this post


Link to post
Share on other sites

I never got source code from Paul for MDM5 or the HFDC DSR that I recall.  It definitely was not part of the MDOS buyout.  It was likely from either you or from Mike, though during the time, someone else may have emailed the file to me.

 

As you said, twas so long ago.


Beery

 

Share this post


Link to post
Share on other sites

Not unexpected, but MDOS does not like CFORM formats above cylinder 1024 either.

 

Beery

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...