Jump to content


New Members
  • Content Count

  • Joined

Community Reputation

29 Excellent

About webdeck

  • Rank
    Space Invader

Recent Profile Visitors

631 profile views
  1. What is the best way to connect a Geneve to a TV with HDMI inputs to get the best image? Using the composite output to an HDMI converter isn't very legible for 80 column output. The Geneve can output RGB instead of composite - is that different from YPbPr component video?
  2. I guess the test would be to see if the DSR code cares at all if a sector has DAM or DDAM. From what I can tell is formatted sectors have DDAM and then whenever data is written it changes to DAM. It would simplify things for the emulator code as written if all the DDAMs were replaced with DAMs, but unsure if that would break anything in the real world when using it.
  3. Yes, the FW-2 code that Beery pointed me to uses command >62 to format, which, according to http://www.whtech.com/ftp/datasheets and manuals/Datasheets - Misc/SMC HDC9234.pdf writes the deleted data mark instead of the normal data mark because bit 4 is zero (>72 would write the normal data mark.) Sounds like a bug in MDM5. I would need to see the DSR code to know what it is doing when it writes out a sector to see what command it is sending to the 9234. The meaning of bit 4 is inverted for the write commands vs. the format command, which probably caused confusion.
  4. Okay, #2 turned out to be a mistake and wasn't actually the case with the raw read of my drive. As for #1, not clear on what the deleted data mark is used for. Is the source code for the HFDC DSR available? The good news is that I have been able to use the emulator now with a TI console, PEB, HFDC, FG99, and TIPI, and the files that don't have errors are comparing byte for byte with the ones I copied off my hard drive previously. Force command is making it a breeze to copy files over to the TIPI where I can compare them with linux diff. As for the 256 bad sectors from the original drive, while they are mostly concentrated in one area the drive and mostly on head 3, they are impacting a fair number of files, sadly. This does confirm that it is my physical hard drive that is having issues and not the HFDC at least. I was also able to edit a file successfully, but I haven't tested writes extensively yet.
  5. I pulled the trigger and ordered one of these to use it to try to get a raw image of my dying hard drive. Using the ST-225's recovery mode, I am close to a full read: Found cyl 0 to 614, head 0 to 3, sector 0 to 31 Expected 78720 sectors got 78455 good sectors, 0 bad header, 265 bad data 0 sectors marked bad or spare 149 sectors corrected with ECC. Max bits in burst corrected 8 Track read time in ms min 29.553666 max 1776.017709 avg 38.902760 I have corresponded back and forth with David and he was able to add initial support for the HFDC format to be read based on the raw data from my drive. There is still more work to do to get emulation working properly. You can see the code changes in this commit: https://github.com/dgesswein/mfm/commit/da54ff8cef77b1a1416edcdfea1fca40ac6ff6cf The format he was able to reverse-engineer: // CONTROLLER_MYARC_HFDC // No manual found describing low level format // 6 byte header + 2 byte CRC // byte 0 0xa1 // byte 1 0xfe ^ upper 2? bits of cylinder // byte 2 cylinder low // byte 3 cylinder high in upper 4? bits, low 4 bits head // byte 4 sector number // byte 5 unknown, 1 for sample I have // byte 6-7 CRC // // Data // byte 0 0xa1 // byte 1 0xfb or 0xf8 // Sector data for sector size // ECC code (4 byte) I'm wondering if anyone has some details on the low level specification for the format used by the HFDC. Some key areas to understand: Apparently, at least based on the raw read of my drive, the deleted data mark 0xf8 is used in some data sectors, which is different from other controllers. Anyone know details on this? For the dump of my drive, he saw that the last cylinder was in normal WD format. It has 256 byte sectors with a different polynomial. I wonder if my drive didn't format the last cylinder and that is old data from a prior format? Or is this to be expected? If anyone can point me to some docs I can work with David to try and get his lower cost MFM emulator to fully support the Myarc HFDC. Thanks, -Mike
  6. To fix the empty file issue, in b9_handleCopy.c, remove the totalBlocks == 0 check and error. Should just work if you remove that.
  7. As it turns out, I had bought a spare LS31 and LS32 last year when I started this project before 2020 derailed everything, since I had heard they often needed to be replaced. So I dug those out of the closet today, desoldered the chips, soldered on sockets, and inserted the new chips. I also redid the voltage regulator jumpers while I was at it. Let me know if there's anything else I should try replacing - maybe the caps? It does seem more reliable (or maybe I just got lucky this time), but there are still files that fail to copy. There is one directory I managed to copy before, but now I can't get a full directory listing on it, so while some things are better, others are worse. I wonder if there are any electronics on the hard drive that need to be replaced, or if it's the platters that failed. Which brings me back to my original question - is there a sector-by-sector copy program that will do some retrying and continue copying even if some sectors are bad?
  8. Well, maybe it's both the hard drive and the controller with issues... Today I can't get reliable reads at all. One DIR command succeeds, and the next one on the same directory fails, or returns a partial directory.
  9. Here's my HFDC. I got this directly from Lou Phillips, so it may be a prototype or early model. He had to do some hand work on it because the floppy controller was having issues. The voltage regulators are bypassed (with a very poor soldering job by me from over 30 years ago) because I have a PC power supply in my PEB and provide 5V from that directly.
  10. Silly question - is there a way to repeat the previous command? I'm thinking like the up arrow in linux which lets you go back in history and either redo a command or edit it. I'm guessing there isn't enough memory to maintain a full history stack, but repeating the last command would be useful in some situations.
  11. I did need to get the HFDC repaired (gate array replaced) because it wasn't working at all initially. Are there other common failures? The hard drive has a hard time spinning up - I have to power cycle it several times typically. It's also the same set of files that have issues, and I can hear the hard drive reseeking at the same points when trying to copy the files, so that's why I suspect the hard drive. I was persistent using ForceCommand to copy one of the failed files and it eventually managed to read the whole file after trying a couple dozen times, which is why I still have some hope that I can recover the data. But it is also possible the heads crashed at some point in the past and scratched the surface to make it unrecoverable.
  12. Hi folks. I've busted out my TI equipment again in another attempt to copy the data off an ancient Seagate ST-225 hard drive that is on its last legs. What I'm looking for is a program that can try to recover files. From what I can tell, the directory structure seems to be intact, but many files have sectors with errors. I'm looking for something that does a sector by sector copy of each file, with a very high number of retry attempts for any sector that fails, and continuing to copy remaining sectors even if one or more are unreadable. Even better if it can copy directly to the TIPI. I have a TI console, FinalGROM, TIPI w/32k, and a PEB with a Myarc HFDC, so I should be able to run most software. I also have a Geneve, so either a TI or Geneve program would work. Is there anything like that out there? Thanks, -Mike
  13. I'm loving Force Command. I've been using it to copy files off of my somewhat flaky Seagate ST-225 drive and onto my TIPI. I have a few questions: It sounds like it reads one sector at a time from the hard drive, re-seeking after each sector, which takes a very long time. Is there any way to make it copy faster (e.g. use a larger buffer in RAM)? Right now, I have to copy the files in each directory separately, including subdirectories. Is it possible to do a recursive copy? It gives an error when trying to copy an empty file. Why is that an error as opposed to copying the empty file? My hard drive is not reliable - is there any way to have it keep retrying sectors some number of times before giving up with an error? Thanks again for the awesome tools!
  14. If you know the links to the items that are "out there" somewhere (or at least the thread if it's on this forum), please add them either here or to the main developer resources thread so they're all in one place.
  • Create New...