Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
AnalogChipDesigner wrote: ↑Thu Jun 26, 2025 3:21 pmAll 3 drives that i tested behaving in the exact same way though?
Well, I have no explanation for that! Do you have any way to measure how many index pulses occur between sending the command to the WD1770 and the first DRQ?
Well I could probably do that with a scope... I will try and let you know.
Also if I use the write sector command, then it messes up all the synchronization bytes, when I read the entire track back to inspect. But the strange thing is that if I use read sector it can find the sectors and read them back without errors. Totally crazy. The data itself is never corrupted though, only the gaps and ID fields have a few different bytes, but they seem constant and do not change.... I will try my other drive to see if I get the same result but I suspect so... But the write track command itself perfectly writes everything. Its just the write sector command that messes up the headers... What do you think is happening?
AnalogChipDesigner wrote: ↑Fri Jun 27, 2025 5:09 amWhat do you think is happening?
Those are write splices. The newly-written data is never perfectly aligned with the previously-written data. That can cause a partial byte that doesn't have all eight bits, resulting in the following data being split into bytes at the wrong locations. Sometimes there's also noise that causes inconsistent reads at the splice point. Address marks contain special patterns to correctly split the following bits into bytes. Writes begin and end inside gaps to avoid corruption of nearby data.
AnalogChipDesigner wrote: ↑Fri Jun 27, 2025 5:09 amWhat do you think is happening?
Those are write splices. The newly-written data is never perfectly aligned with the previously-written data. That can cause a partial byte that doesn't have all eight bits, resulting in the following data being split into bytes at the wrong locations. Sometimes there's also noise that causes inconsistent reads at the splice point. Address marks contain special patterns to correctly split the following bits into bytes. Writes begin and end inside gaps to avoid corruption of nearby data.
So what I observe is FE becoming CE and FB becoming CB when I write a sector. Also 00 and FF gap bytes can be shifted and changed a bit. Strangely though reading the sector is OK, it can find them. How can it find them when FE becomes CE and FB becomes CB? I don't understand it. My CPUs read cycle is 200ns, and the WD released data 200ns max after CS goes low. Maybe I am too close to the limit and its malfunctioning?
AnalogChipDesigner wrote: ↑Sat Jun 28, 2025 6:58 amHow can it find them when FE becomes CE and FB becomes CB?
Address marks are encoded with unique flux patterns that can't appear anywhere in normal data. It's not looking for FE or FB, it's looking for the unique flux patterns. I'm not sure why writing a sector causes the address marks to read back as different values, though.
AnalogChipDesigner wrote: ↑Sat Jun 28, 2025 6:58 amMy CPUs read cycle is 200ns, and the WD released data 200ns max after CS goes low. Maybe I am too close to the limit and its malfunctioning?
That's possible, although I don't see why it would only affect the address marks and not the rest of the data.
AnalogChipDesigner wrote: ↑Fri Jun 27, 2025 5:09 amBut the write track command itself perfectly writes everything. Its just the write sector command that messes up the headers...
If you don't mind a suggestion, could you perhaps read-modify-write whole tracks and forget about sectors? It depends whether you have the RAM to spare, and if there is, it depends on your development philosophy: Are you all right with dropping features to get on? I'm bringing it up because I sometimes have to be reminded that dropping features is an option.
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie
AnalogChipDesigner wrote: ↑Fri Jun 27, 2025 5:09 amBut the write track command itself perfectly writes everything. Its just the write sector command that messes up the headers...
If you don't mind a suggestion, could you perhaps read-modify-write whole tracks and forget about sectors? It depends whether you have the RAM to spare, and if there is, it depends on your development philosophy: Are you all right with dropping features to get on? I'm bringing it up because I sometimes have to be reminded that dropping features is an option.
Hi Eekee, thank you for the suggestion. That is for sure a possibility. I am still curious about why it is behaving this way. Some people in another forum have said I just don't understand how it is working and that everything is actually correct. I don't have the time at the moment to learn how it really works unfortunately. Thanks a lot
Is anyone able to format a disk for me and send it to me? I will pay you for it. I would like to have a disk formatted somewhere else so I can compare things.
AnalogChipDesigner wrote: ↑Sun Jun 29, 2025 5:47 amSome people in another forum have said I just don't understand how it is working and that everything is actually correct.
I agree. From what you've described, it sounds like everything is working correctly now and there's nothing to worry about.
AnalogChipDesigner wrote: ↑Sun Jun 29, 2025 11:35 amI would like to have a disk formatted somewhere else so I can compare things.
I'm pretty sure you can format a disk using an ordinary PC, if you have one with a floppy drive controller. If you set the jumpers for drive select 1, the drives are PC-compatible. You'll also need to set the termination according to how you cable the drive. The hardest part might be finding software willing to write FM-encoded 128-byte sectors instead of MFM-encoded 512-byte sectors, but you could probably just write your own software for that, right?
AnalogChipDesigner wrote: ↑Sun Jun 29, 2025 5:47 amSome people in another forum have said I just don't understand how it is working and that everything is actually correct.
I agree. From what you've described, it sounds like everything is working correctly now and there's nothing to worry about.
AnalogChipDesigner wrote: ↑Sun Jun 29, 2025 11:35 amI would like to have a disk formatted somewhere else so I can compare things.
I'm pretty sure you can format a disk using an ordinary PC, if you have one with a floppy drive controller. If you set the jumpers for drive select 1, the drives are PC-compatible. You'll also need to set the termination according to how you cable the drive. The hardest part might be finding software willing to write FM-encoded 128-byte sectors instead of MFM-encoded 512-byte sectors, but you could probably just write your own software for that, right?
Hey Octo. Thanks again for your time with this...
Yes the reason why I haven't bought a used PC from ebay to test things is because I read that they will only deal with MFM and would require software for FM. I don't have the time to try and write software for that, especially given the controller will be different than the one I have...
I got a BBC micro FM disk from ebay to see how it reads. That's all I can do at the moment...
