Jump to content
IGNORED

MG Program copyright protection


acadiel

Recommended Posts

SNUG's sophisticated disk copier. It can analyse non-standard track setups and recreate them.

The MG measures are still beyond its capabilities, though. Mind that you can load the MG disks only with WD17xx-based controllers; the HFDC won't do, so they are quite specific.

 

Edit: Have a look at https://www.s-n-u-g.de/util/index_en.php

Edited by mizapf
Link to comment
Share on other sites

SNUG's sophisticated disk copier. It can analyse non-standard track setups and recreate them.

 

The MG measures are still beyond its capabilities, though. Mind that you can load the MG disks only with WD17xx-based controllers; the HFDC won't do, so they are quite specific.

 

Edit: Have a look at https://www.s-n-u-g.de/util/index_en.php

 

 

Copy-C actually *does* copy the MG programs. I was able to duplicate the disk from my 5.25" original over to a 3.5" and it worked.

  • Like 1
Link to comment
Share on other sites

Fascinating.

 

I wonder how it got along with the special tracks like 11. As said above, you cannot write a track using the Write Track operation for arbitrary data, because the controller intercepts the special values to create the address marks or the CRC values. For example, if your data contains the byte F7, bad luck. From what I found in the MAME log, it reads the source track, finds out what sectors are on it, together with their sequence and sizes, formats the target track, and writes the sectors.

 

Perhaps the track 11 contains a single sector; the specs show values for the length up to 3, which means 1024, but I don't know what happens when you set them to 4 or 5 (would mean 2K or 4K).

 

I still have to understand how to decode track 11. The HFE decoding works perfectly on all other HFE images, so I cannot be too wrong, but it completely fails at that track.

Link to comment
Share on other sites

In a conversation I had with Christopher Winter sometime after he wrote Copy-C, he told me that the original reason he wrote the program was specifically to be able to copy the MG disks. IIRC, it was originally written for the Atronic disk controller (and was called Copy-A), the CorComp version (Copy-C) came later. He didn't like the Myarc floppy controllers, so there was never a plan to make a Myarc compatible version of the program.

  • Like 1
Link to comment
Share on other sites

 

This should be highly depending on the card - the HFDC uses a totally different chip (HDC9234) than the DDCC-1 (WD1770).

 

Back in the 90's with a bit of guidance from Barry Boone, I was able to get the Myarc HFDC to do track reads and display the data by viewing a buffer. I had the 9216B chip on that card, as well as a 32K ram chip upgrade. I was able to see all the inbetween track information as well as the individual sector information. Unfortunately, I could read the same track multiple times, and the contents of the buffer would be offset differently. I was never able to grasp the "why" the order or determine how to identify specific sectors starting and stopping from the limited documentation of the day. My intent had been to add the Myarc HFDC support to HyperCopy.

 

Beery

Link to comment
Share on other sites

I have Pascal and assembly programs that copies Advanced Diagnostics as well as Explorer. They assume a CorComp disk controller, as that's what I have.

I wrote these programs for the same reason as Will McGovern did. I wanted to make my rightful backup copy of the disks I paid for.

Today, there's nobody to hurt any longer, so if you want them, I can publish the source files. They are mine, since I did them myself.

 

Without looking in the code, I remember that these disks used a combination of odd sector numbers in tracks (like 0, 5, 10, 15 etc. instead of 0, 1, 2, 3 and so on) and tracks with unformatted storage. This is not the same thing as having one big sector in the track. Both schemes would confuse the normal controller DSR. As far as I can remember, it's only one of them that uses unformatted tracks.

My program can also copy various disks from Quality 99 Software (Maurice E.T. Swinnen). They didn't use unformatted storage, but oddly numbered sectors.

The copied disks are of course identical, i.e. just as copy protected as the original.

 

I can add that in my software, the assembly part performs four functions:

  1. Write track, i.e. formatting a track.
  2. Read track (unformatted).
  3. Write sector (any sector number).
  4. Read sector (any sector number).

The Pascal part is doing the analysis of the read data, in order to create an identical set of sectors, or an unformatted track with data.

Edited by apersson850
  • Like 2
Link to comment
Share on other sites

I have Pascal and assembly programs that copies Advanced Diagnostics as well as Explorer. They assume a CorComp disk controller, as that's what I have.

I wrote these programs for the same reason as Will McGovern did. I wanted to make my rightful backup copy of the disks I paid for.

Today, there's nobody to hurt any longer, so if you want them, I can publish the source files. They are mine, since I did them myself.

 

Without looking in the code, I remember that these disks used a combination of odd sector numbers in tracks (like 0, 5, 10, 15 etc. instead of 0, 1, 2, 3 and so on) and tracks with unformatted storage. This is not the same thing as having one big sector in the track. Both schemes would confuse the normal controller DSR. As far as I can remember, it's only one of them that uses unformatted tracks.

My program can also copy various disks from Quality 99 Software (Maurice E.T. Swinnen). They didn't use unformatted storage, but oddly numbered sectors.

The copied disks are of course identical, i.e. just as copy protected as the original.

 

I can add that in my software, the assembly part performs four functions:

  1. Write track, i.e. formatting a track.
  2. Read track (unformatted).
  3. Write sector (any sector number).
  4. Read sector (any sector number).

The Pascal part is doing the analysis of the read data, in order to create an identical set of sectors, or an unformatted track with data.

 

 

You should load the HFE files I posted in this thread in the HxC Floppy software track viewer. It has a very interesting track viewer that shows you a pictorial representation of how these disks were laid out. And yes, there was one that had completely unformatted tracks. :) One had 1K sectors, another had 1K and 512 byte sectors, and a third had non standard sectors plus unformatted direct-write tracks.

Link to comment
Share on other sites

Back in the 90's with a bit of guidance from Barry Boone, I was able to get the Myarc HFDC to do track reads and display the data by viewing a buffer. I had the 9216B chip on that card, as well as a 32K ram chip upgrade. I was able to see all the inbetween track information as well as the individual sector information.

 

Does it show the inter-sector gaps? When I re-implemented the HDC9234 in MAME, I was not quite sure how to interpret the specification - see below. From what I understood, it only reads the sector preambles and the sector contents, so this is the way I implemented it. I have a HFDC at home, but I don't know whether it is still working, and this makes me a bit unsure to plug it into my PEB with my Geneve. Maybe I should give it a try. On the other hand, I would need a program that actually calls the Read Track function.

post-35000-0-25245700-1523976043.jpg

Link to comment
Share on other sites

 

Does it show the inter-sector gaps? When I re-implemented the HDC9234 in MAME, I was not quite sure how to interpret the specification - see below. From what I understood, it only reads the sector preambles and the sector contents, so this is the way I implemented it. I have a HFDC at home, but I don't know whether it is still working, and this makes me a bit unsure to plug it into my PEB with my Geneve. Maybe I should give it a try. On the other hand, I would need a program that actually calls the Read Track function.

The software I wrote did show all the between sector gap information. It was just something I never understood.

 

There were some bits that were very obscure Barry figured out that passed information to the 9234 for the track commands. I might be lucky enough to have the original 9234 manual I made those notes in that detailed what was needed. I will try and check this evening to see if I have those notes. If not, that is a piece of history lost...........

 

I do know I used Bruce Hellstrom's memory viewer program I called up after the track read to "see" the information.

Link to comment
Share on other sites

My original hardware manual that had my detailed notes was not where I thought it was for the 9234. My non marked up manuals were there however along with some other manuals if they would assist in any work.

 

I do however have some additional manuals that I do not see up on whtech.

 

TN 6-5 Programming the HDC 9224 Universal Disk controller

TN 6-2 Improved Functionality Simplifies Disk Controller Design

 

Right now, I am wondering where that marked up manual is. Hmmmm.

Link to comment
Share on other sites

 

 

You should load the HFE files I posted in this thread in the HxC Floppy software track viewer. It has a very interesting track viewer that shows you a pictorial representation of how these disks were laid out.

You mean I could look at the "artwork" of the disk using that software? Good to get an overview, I'm sure. If I wanted to, I could quite easily expand my own software to do the same. After all, it does read a track, figure out which sectors are there, formats an identical track on the copy diskette, reads the "funny" sectors from the original and copies them to the new disk. Automatically. So there's already some analytical capability in my program.

  • Like 1
Link to comment
Share on other sites

You mean I could look at the "artwork" of the disk using that software? Good to get an overview, I'm sure. If I wanted to, I could quite easily expand my own software to do the same. After all, it does read a track, figure out which sectors are there, formats an identical track on the copy diskette, reads the "funny" sectors from the original and copies them to the new disk. Automatically. So there's already some analytical capability in my program.

Anders, you sure have some amazing treasures in your arsenal! :)

Link to comment
Share on other sites

My original hardware manual that had my detailed notes was not where I thought it was for the 9234. My non marked up manuals were there however along with some other manuals if they would assist in any work.

 

I do however have some additional manuals that I do not see up on whtech.

 

TN 6-5 Programming the HDC 9224 Universal Disk controller

TN 6-2 Improved Functionality Simplifies Disk Controller Design

 

Right now, I am wondering where that marked up manual is. Hmmmm.

Hope you find it and post it soon, I've 'googled' those names and haven't been able to locate them. We need them archived :grin:

Link to comment
Share on other sites

Hope you find it and post it soon, I've 'googled' those names and haven't been able to locate them. We need them archived :grin:

 

Those two manuals I have and I know exactly where they are. I will either scan them tonight on my scanner, or tomorrow morning on the work scanner.

 

Beery

  • Like 1
Link to comment
Share on other sites

The issue was indeed in the read_track implementation in MAME. Funnily, I found it after my own posting: http://atariage.com/forums/topic/277906-controller-chip-manuals/?p=4011090

 

Reading starts with the leading edge of the first encountered index pulse and continues until the next index pulse. All gap, header, and data bytes are assembled and transferred to the data register and DRQs are generated for each byte. The accumulation of bytes is synchronized to each address mark encountered.

You probably know how it feels when you say something and then wonder "ehm, do we actually do that?".

 

Indeed, when I looked into the code, I found that there was a resync, but only for MFM, so I added the FM variant. Of course, it did not immediately work (you know that as well, when you seemingly found the solution, and the solution refused to solve). With this resync, a fraction of a byte remains, and it must be decided whether to deliver or to dispose of it. I increased the threshold (which means you need more bits for the fractioned byte to count as a full byte), and then...

 

  • Like 4
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...