On Thu, May 10, 2018 at 10:41 AM, Rob Clarke <crock@clarke-family.org.uk> wrote: > On 09/05/2018 22:28, Spiro Trikaliotis wrote: >> So it seems we have a general communication problem. >> >> Does anyone else have success or was unsuccessfull with other IEEE >> drives (4040, 8x50, ...)? >> > I've used the ZF with most of the common IEEE drives without issue. I just > tried again with an SFD-1001 and it works without issue, detecting, > formatting with cbmctrl command, reading status and directory, and both > reading and writing an image with imgcopy. Cool. I was about to bust out a 4040 for comparison testing. The SFD-1001 is one I do not have. > I then tried the same setup but with a 2031 LP and saw the same symptoms as > those people previously, seeing multiple different footprint values, > occasionally hanging, failing to read the ROM etc, though reading the status > usually seemed to work. I also tried with a high profile version, with > exactly the same outcomes. Mine is a 2031 LP. I put 'cbmctrl status 8' in a for loop and it reads reliably every time. The other operations still return what appears to be status text in the 'magic' field or lock up or work intermittently as previously described. Like Rob, my memory dumps are zero bytes. Every time. Same for files pulled with cbmread. $ cbmread -vvv 8 "dumper" magic = 0x3030 magic = 0x4f20 [Info] reading DUMPER -> dumper.prg [Debug] using transfer mode `serial2� magic = 0x3233 [Info] identified a *unknown*, footprint=<CBCC> drive [Warning] *** unknown drive type [Debug] no turbo code upload is required [Debug] start of copy .\[Debug] done [Info] 00, OK,00,00 $ cbmread -t o -vvv 8 "dumper" [Info] reading DUMPER -> dumper.prg [Debug] using transfer mode `original� magic = 0x3030 [Info] identified a *unknown*, footprint=<C@C@> drive [Warning] *** unknown drive type [Debug] no turbo code upload is required [Debug] start of copy .\[Debug] number of bytes read for block 0: 0 [Debug] done [Info] 00, OK,00,00 [Warning] could not write dumper.prg: Resource temporarily unavailable Something comes to mind here... I haven't memorized all the designs, but the 2031 LP happens to use SN75160/SN75161 IEEE drivers and many (all?) of the older drives use MC3446 IEEE drivers. What I don't know is the difference in current sink/drive between the two approaches or what handshaking logic differences there are in the two interface designs (since there are typically one or two operations that are done in hardware not software because a 1MHz 6502 isn't fast enough to meet the IEEE-488 spec). I don't happen to have a short IEEE-IEEE cable - mine are all standard Commodore issue or "real" cables that came from a physics lab (premium grade, shielded, low-loss cable). If someone has a 2031 and a short cable (or could even make a male-male adapter that would be the shortest cable possible), that could eliminate cable length/current drive as a factor. For the software side of debugging this, the fact that "detect" returns the wrong thing is a good place to start. The bus traffic should be fairly small and easier to follow byte for byte than, say "dir". I do find it interesting that either I get nothing back from a dir, or when I do get something back, it's the header and the "blocks free" but not the file list. I know there's a lot of messages back and forth to read the directory, but what I don't have is the exact sequence of what gets sent, what gets returned etc. I'm sure it's in the source (which I have not read in detail yet). The different phases of the "dir" command could be a clue as to what's not working right, though. -ethanReceived on 2018-05-10 18:00:02
Archive generated by hypermail 2.2.0.