Controller Chip Manuals

[+9640News]

I am attaching copies of the two manuals for disk controller and the HDC 9224 I mentioned the other day. If someone would, please upload them to whtech as I am unable to login over there.

 

Beery

TN6-2 Improved Functionality Simplifies Disk Controller Design.pdf

TN6-5 Programming the HDC 9224.pdf

[+mizapf]

Thanks, Beery!

 

The 9224 is not the chip on our HFDC which uses the 9234, but it is largely similar. It is compatible in the basic commands, having differences in bit positions in the commands and other rate specifications. I know both because someone once asked me to add the 9224 emulation to MAME, but neither did I have a way to reasonably test it, nor did that person report any success or failure.

 

https://github.com/mamedev/mame/blob/master/src/devices/machine/hdc92x4.cpp

[+9640News]

I figured the programming logic would be similar for the 9224 as it would be for the 9234. Hopefully, there is some useful information there for you.

 

Beery

[+mizapf]

I think it is. The 9234 added some more features (which we don't use anyway), but it loads tracks or sectors the same way, as I believe.

[+InsaneMultitasker]

I have the 9234 manual (it says 'preliminary) that I downloaded from a site long ago, along with my hard copy. Do you already have this one or should I post it ?

[+mizapf]

Thanks, I have both HDC9224 and HDC9234 specifications (needed them for the implementation in MAME).

[+9640News]

For myself, I have an original 9234 Preliminary manual. That manual is also up on Whtech. I think I scanned that documents years ago. What I have not been able to locate is my original notes I made in another copy of the 9234 Preliminary manual. I know I made notes in two different sections, one with some bits/registers that had to be set for drive select due to the way Myarc wired things up, and the other for "something" my memory no longer recalls.

 

The bits/registers, I could probably chase down within the MDM5 source code and figure out. I do not recall if the other information was details on bits or registers that needed to be set for 8K vs 32K ram chip on the card, or if was related to something specific on track reads.

 

Too many years. Nowadays, I do not think there is any interest with a HFDC version of HyperCopy to investigate anyways.

 

Does the MAME emulation of the 9234 have options for specifying 8K or 32K? By default, the Myarc HFDC was 8K but simply pulling the chip, one could change it out to 32K.

 

Beery

[+mizapf]

You mean this kind of notes (below)?

 

I implemented the HFDC with 32K RAM.

[+9640News]

Are those your notes you made on the document, or were they on the original PDF? It's possible years ago I scanned my original document with the comments, however the copy I saw on whtech did not seem to have any notes.

 

Beery

[+mizapf]

Not my notes. Here are the two parts of the HDC9234 spec that I have.

Universal Disk Controller smc9234 1-13.pdf

Universal Disk Controller SMC9234 14-END.pdf

[+InsaneMultitasker]

For myself, I have an original 9234 Preliminary manual. That manual is also up on Whtech. I think I scanned that documents years ago. What I have not been able to locate is my original notes I made in another copy of the 9234 Preliminary manual. I know I made notes in two different sections, one with some bits/registers that had to be set for drive select due to the way Myarc wired things up, and the other for "something" my memory no longer recalls.

 

 

I got my original preliminary manual through Cecure. I had some notes that Mike M. made while working on his tape backup software but beyond that, most of what I used for documentation was gleaned from the manual, MDM5, and the HFDC EPROM.

 

Your mentioning Hypercopy reminds me that I was modifying it to create .DSK images. I got so far as using the track copier routine to read the disk and then spit out a a raw image to my hard drive, but the sector order always seemed goofed up. Maybe I was running into the same thing that you mentioned earlier. My desire was for a FAST way to create disk images by using the track copy software. Ah well.

[+9640News]

Hard to say if that is my handwriting or not, but that definitely looks like one piece of information Barry Boone had provided me some 20+ years ago. Seems like I had at least one other note in that document, but I do not see it present in what you posted.

 

Doesn't matter either way really I guess.

Beery

[+mizapf]

I got so far as using the track copier routine to read the disk and then spit out a a raw image to my hard drive, but the sector order always seemed goofed up.

 

The nature of track reading is that the sectors occur in their sequence on the disk, which means you typically have some interleave.

 

Track reading is inherently difficult. The problem is that you have a soft-sectored disk, and you just cannot tell where you are on the track. For synchronizing on the track, the address marks are required. There are three types: Index AM, ID AM, and Data AM. The IXAM is typically not used with floppy disks; there we have an index hole that serves the purpose.

 

The description of the WD177x Read Track command says:

 

"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."

 

That is, until the first IDAM or DAM appears, you cannot really rely on the delivered bytes. They may be complete nonsense because there may have been a minimal difference between the recording and the reading. If there is a shift by only one cell, no byte can be correctly assembled. But when the first IDAM (or DAM) shows up, the controller locks on the mark, and all following bytes are correctly assembled. When the write splice shows up, there may again be a shift, but the DAM should again synchronize the controller.

 

My research on track 11 showed that there are two address marks on the track: a DAM, and an IDAM.

[+InsaneMultitasker]

I couldn't make heads or tails of the order at the time. I think it had to do with the skew and interlace settings in the program. Fun exercise that didn't yield much

[+9640News]

I remember my work years ago, I had specifically typed text in each sector of a track I wanted to read. That way, I did not have to visually look at something "too complex". When I issued the track read command, I could see the individual sectors. I just could not make sense of the sector ordering and in-between track information compared to what was described in the preliminary manual.

 

Pretty much a non-issue now I guess.

 

Beery

[apersson850]

I remember that during my work to create programs that could copy Advanced Diagnostics and Explorer, I learned about the sector interleaving command. I also found out that the formatting subprogram on the CorComp controller can handle different interleaving. I used that to create a dformat program for the p-system, which worked better than the original one. The dformat program delivered with the p-system can't format double density disks, even if it says it can. Thus you had to go outside of the p-system to format the disks, then back in to set up the disk catalog the p-system uses.

My dformat can format double density as well, and can also format with two sector interleave, if it detects a CorComp controller, or use the standard three sector interleave, if it's a TI controller.

The faster disk reading routines in the p-system benefits from a tighter interleave than what the standard system uses.

 

I also remember that I spent quite some time developing the logic in my copier software, which tried to detect where in an unformatted track the data actually started. As you write above, the special sync bits aren't visible in the data stream you get from the controller.