| Author: | Nate (guest: search) |
|---|---|---|
| Date: | Sun, Mar 22nd, 2009 @ 13:06 ( . ) |
Hi guys. I did add an IHS to my 1541 and patched mnib to support it. I sent the listing to Pete with comments on how to add more general support to mnib for this. Here is a duplicate of those comments: Yes, I used the UU method of hooking the IR LED up to the same line as the status LED. Then you just reconfigure it for input instead of output and read it. Bit 7 of 1c00 will go low when the hole passes. You can find the schematic in one version of the SuperCard disks. Attached is the diff I made to mnib to use it. It may have bugs but hopefully it will help. I think you only want to make the pin input while using the IHS since otherwise the LED won't work for status. Also, I considered adding a diode to prevent current flowing into the VIA but it turned out it would not forward bias correctly so I never used it. It turns out to not be a problem. I think there are several steps to adding IHS support to mnib. First, add a flag to mnib to enable the IHS at runtime. I just used an ifdef. Also, add a separate test function to be sure the IHS is working (similar to "cbmctrl detect"). Next, create a new flag in the header area for .nib files to indicate that the data in these tracks is synchronized. That way we can tell if a .nib file was made with IHS enabled or not. When creating an image with IHS enabled, mnib can just bump the head, wait for IHS detected, then begin reading. This way every track in the .nib file starts from the same location. Write support can work the same way (wait for IHS, then begin writing). By doing this, the new disk will match the old. Also, the .nib file will be synchronized properly for use with emulators if they honor the flag in the header or keep the sync the same as in the .g64 file. My ultimate goal was to use the hardware IHS to test various signature-based synchronization schemes like Womo built in order to work without an IHS. Then, all newer versions of mnib would set the "track-synchronized" .nib header bit if they were able to successfully detect the skew. Such software-only schemes might have a hard time for tracks that had only a small amount of data and all sync, for example. If the track just before the key track for RapidLok disks (t35) had little data, it might be hard to detect the skew for the key track. |
Attachments: |
| 1237741569_nate-ihs.txt |
 | Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Sun, Mar 22nd, 2009 @ 14:21 ( . ) |
I ran into an issue with just reading starting right at the index hole pass- It starts reading in the middle of sector 0 quite often. It seems (at least on the 1571 IHS) that it isn't fast enough to catch the sync and header for sector 0. Did your IHS solution have this issue also? :) I left the routine waiting for a sync mark to end after the hole, but this is also not 100% optimal, since we can get off a good bit if the index occurs in the middle of a sync. Waiting gets me data starting at data block 0 (missing header 0) most of the time. Easy to fix in software, but not 100% accurate. |